WordPress 网站的现代部署

已发表: 2022-06-30

如果您像我一样，您第一次将文件推送到 Web 服务器上的经历要么是通过 cPanel 等基于 Web 的文件管理器，要么是通过 Transmit 或 Filezilla 等文件传输协议 (FTP) 客户端。 连接到服务器，将文件拖过来，然后等待传输完成。

容易，对吧？

然而，一旦我开始使用比静态 HTML 文件更复杂的东西，部署我的代码就变得更加复杂：如果我错过了其他人需要的文件，或者全局包含中的分号并且它会白屏整个网站？ 如果在此过程中错过了关键步骤怎么办？

随着更多的人、环境和依赖关系的参与，这些“牛仔编码”问题只会变得更糟。 因此，在兼顾所有这些活动部件的同时，不断取得进步变得越来越难。 最糟糕的是，发布代码变成了一件大事，并且是一个持续的焦虑来源。

随着我们的应用程序、站点和商店变得更加现代化，我们也应该对我们的部署进行现代化改造。 从版本控制到持续交付，现代化的发布流程可以缓解围绕部署的焦虑。

使用版本控制跟踪更改

摆脱临时更新和牛仔编码的第一步是使用 Git 之类的工具使您的网站处于版本控制之下。

使用版本控制意味着您将能够查看已更改的内容、进行更改的人员，甚至可以使用分支同时处理多组更改。 因此，工作不会被覆盖，文件之间的任何冲突都会被清楚地突出显示。

如果您以前没有使用过 Git，请不要害怕：我们已经编写了 Git 简介以及有关更高级 Git 工作流程的文章。

决定追踪什么

当我们在版本控制下移动我们的网站时，我们不跟踪的几乎与我们所做的一样重要：

一般来说，版本控制是为了跟踪源代码，而不是工具或流程生成的资产。 这包括连接/缩小的 CSS 和 JavaScript、外部依赖项等。我们将这些项目统称为工件。

例如，如果您使用像 Sass 这样的 CSS 预处理器，则不应在版本控制下跟踪生成的 CSS 文件。 它们不仅易于重现，而且难以阅读，并且在涉及多个开发人员时是合并冲突的常见来源。

当涉及到依赖项（库、WordPress 插件等）时，请利用 Composer 和 WPackagist 等工具，而不是在存储库中捆绑您不负责的代码。

此外，Git 存储库不应包含密码、私人 SSH 密钥或任何其他被视为机密的机密信息，因为每个拥有存储库副本的开发人员都会在他们的计算机上拥有这些敏感信息。

构建您的存储库

在为 WordPress 或 WooCommerce 站点设置 Git 存储库时，通常最好将 wp-content/ 视为存储库的根目录，因为您通常不会接触此目录上方的文件。

您的站点使用但您不为其维护代码的插件和主题应该通过 Composer 加载，因为它们是外部依赖项。 同样，应通过 .gitignore 文件排除已处理的 CSS 和 JavaScript 文件，因为这些工件将作为我们发布过程的一部分为我们构建。

我们在 GitHub 上提供了一个免费的存储库模板来帮助您入门。

CI/CD 简介

在部署软件时，需要理解两个重要术语：持续集成(CI) 和持续交付(CD)。

这两个术语密切相关，以至于它们经常被统称为“CI/CD”，我们的变更流经的路径因此成为“CI/CD 管道”。 该管道通常采用以下形式：

  1. 构建版本：安装依赖项（Composer、npm 等），然后构建工件（Webpack、Grunt、Sass 等）
  2. 测试构建：运行单元测试、检查编码标准、执行静态代码分析等。
  3. 将版本部署到一个或多个环境

持续集成是持续测试我们的代码以确保更改不会破坏现有功能的过程，以便我们的新更改与现有代码库干净地集成。 每当推送新更改时，都会运行检查以确保我们不会“破坏构建”。

为了使持续集成有用，这些检查必须是自动化的。 例如，如果您有一套单元测试，您可以选择在每次打开新的拉取请求时运行此测试套件，从而在代码投入生产之前提醒您可能出现的损坏。

然而，持续集成不限于单元测试，因为有许多“无代码”检查可以针对您的代码自动运行，包括：

  • 编码标准检查 (PHP_CodeSniffer, PHP Coding Standards Fixer)
  • 静态代码分析（PHPStan、Psalm）

在每次推送时自动运行这些检查还可以确保所有代码都通过相同的检查运行，从而防止未通过的代码被释放。

另一方面，持续交付是我们应该能够在任何给定时刻“交付”（部署）我们的代码的想法。 为了实现这一点，我们必须有一个脚本化的部署过程，只需单击一个按钮，就可以将我们的代码无缝地投入生产。

为您的部署编写脚本意味着您可以定期和一致地进行部署； 每个部署都应该与之前的部署相同。 因此，您的团队可以更有信心地进行更频繁的部署，并且更少担心有人在此过程中错过了一步。 对于一些团队来说，一天部署数十次（甚至数百次）的情况并不少见！

根据您的站点，您甚至可能想要查看“另一张 CD”，持续部署； 它与持续交付非常相似，但在此模型下，每次推送到分支都会自动部署。 这在使用分支版本控制方案（例如 Github Flow）时可能非常强大，但如果您需要安排发布窗口或在主分支中完成所有工作，则可能不受欢迎。

使用 CI/CD 部署 WordPress 或 WooCommerce 站点

现在我们已经掌握了基本术语，让我们来看看部署一个典型的 WordPress 或 WooCommerce 网站：

在本练习中，我们将使用 Branch，这是一个 CI/CD 工具，它是围绕 WP Pusher 背后的同一个人的 WordPress 开发人员的需求而设计的。 最重要的是，Branch 内置了对部署到 Nexcess 的支持！

首先，通过连接您的 GitHub、GitLab 或 Bitbucket 帐户注册 Branch，然后创建您的第一个站点。

接下来，我们将要配置构建站点所需的所有步骤。 Branch 为常见操作（安装 Composer 依赖项、运行 Webpack 等）提供了许多“配方”，但也使我们能够添加任意数量的自定义步骤。

一旦我们概述了构建网站所需的步骤，我们就可以进入管道的下一个阶段：测试。

如果您的站点已经有一个自动化测试套件，您可以简单地告诉 Branch 运行任何必要的命令。 即使您还没有测试，Branch 也可以轻而易举地添加 linting、编码标准和兼容性检查。

现在我们已经安装了依赖项，构建了所有内容并通过了测试，是时候将我们的代码投入生产了！

Branch 包含部署到 Nexcess（以及其他主要托管服务提供商）的方法，并且连接两个平台很容易：

  1. 在分支仪表板中选择您的站点，单击“设置”，然后获取您的分支站点的公共 SSH 密钥
  2. 将此公钥添加到 Nexcess 门户中的密钥列表中

一旦 Branch 能够与您的 Nexcess 站点进行通信，我们就可以选择“Nexcess”部署方案并填写一些详细信息：

  1. 站点的主机名和用户名（可通过站点“访问”屏幕上的 Nexcess 门户获得）
  2. 我们要部署到的 Web 根目录。 如果我们的 git repo 打算用作 wp-content/ 目录，那么这个值应该是“public_html/wp-content”。
  3. 我们希望部署的文件（通常默认的“*”就足够了）
  4. 要部署到此环境的 git 分支

“Git 分支”设置尤其重要，因为它可以让您为不同的分支指定不同的部署。 例如，您可能有一个“暂存”分支部署到您的暂存环境，让您在更改生效之前对其进行测试。

值得注意的是，Branch 默认使用持续部署模型，其中管道在每次推送到给定分支时运行。 如果您更喜欢持续交付模型（必须采取一些手动操作），您可能会考虑维护一个“生产”分支，该分支仅在您准备发布时才合并。

此时，Branch 应配置为构建并部署您的 git 存储库到 Nexcess！ 您可以通过单击站点“管道”页面上的“运行部署”按钮或推送到您的 Git 存储库来触发您的第一次部署。

定制您的发布流程

Branch 的一个非常好的功能是能够在成功部署后配置其他步骤，例如在部署后自动清除站点的对象缓存。 这可以使用“其他”下的 WP-CLI 配方来完成。

主机和用户名通常与我们在部署步骤中使用的相同，您可以根据需要链接任意数量的命令。

结论

如果您仍在为牛仔编码的滑稽动作和/或焦虑困扰的发布而苦苦挣扎，请查看 Branch，让部署变得轻而易举！