使用 Jenkins 部署 Symfony 项目：最佳实践

Question

我在部署到实时服务器的 Jenkins 服务器上管理一些 Symfony 2/3 项目。这是我目前的设置：

构建

• 使用 git 插件结帐
• 删除数据库（如果存在）
• 执行composer install（prod 模式，优化自动加载器）
• 执行 bower install 以获取我的资产
• 执行gulp 构建，它缩小并连接 css / javascript（我们不使用资产）
• 执行我的数据库创建工作
• 执行单元测试

归档

构建完成后，我使用“Compress Artifacts”插件将构建的工件归档，没有 vendor、node_modules 和 bower_components 文件夹作为 zip 文件。

部署

我结合使用“Promoted builds”插件和“Publish over SSH”插件：如果我想通过构建“上线”，我通过 SSH 将工件（我的 zip 文件）发布到我的实时系统在名为staging_dir 的目录中。文件上传后，我执行一些 SSH 命令：

• 将实时系统设置为维护模式
• 在我的staging_dir中解压工件zip
• 在实时系统上执行composer install（与构建期间的配置相同）
• （bower install 和 gulp 构建不是必需的，因为我们使用在构建期间创建的资产）
• 迁移数据库
• 将当前实时系统文件移动到backup 文件夹
• 从staging_dir 复制文件
• 将实时系统设置为“生产”模式（禁用维护模式）

最佳做法？

我现在想收集一些部署的最佳实践：

• 您是否愿意将vendor 文件夹转移到实时系统而不是再次执行composer install？
• 资产呢？您是在 bower install 和 gulp 再次构建实时系统还是使用已发布的资产？
• 在执行实时促销时如何处理密码？
• ...其他我忘记了。

Answer 1

我和几个同事处理这个问题已经有一段时间了。当我们开始时，很难找到关于这个主题的好帖子。这就是为什么我想分享我们发现对我们“最好”的工作。

项目详情

我们的一个客户有一个大而重的平台来管理他的业务流程（类似于 ERP 和 CRM）。该平台最初是使用 Symfony 2 开发的，现在我们已经升级到 Symfony 3。为了确保一切正常，该项目有大量的测试用例。我们还使用：

1. Doctrine Migrations 所以我们可以在必要时安全地更新生产服务器上的数据库。
2. 平
3. 鲍尔
4. 资产
5. PHPUnit
6. 吉特
7. 詹金斯

测试

一旦有人提交到我们的 git 服务器，一个钩子会让 Jenkins 知道并触发构建。作业成功完成后，我们手动触发部署。这是通过登录到客户的机器并触发我们开发的脚本来完成的。

部署

我们过去的处理方式与您相同 - 在 jenkins 完成工作后上传存档。然而，这被证明是非常有问题的，因为在某些情况下存档可能会被破坏（即由于 jenkins 实例和生产服务器之间的网络连接问题）。此外，将文件从我们的服务器上传到客户端的服务器也花费了相当长的时间。这就是为什么我们决定使用 git 并从那里提取必要的版本。事实证明，使用 git 更可靠，并确保您在客户端拥有项目的绝对副本。此外，回滚到以前的版本只是一个git checkout :)

因为我们大多数人已经有使用ant 和php 的经验，所以我们决定使用Phing 并创建一个构建脚本并自动执行大部分常规任务。在构建脚本中，我们添加了我们一直运行的大部分常见任务，例如安装、升级、清除缓存、安装资产等。然后我们在每个生产服务器上都提供了这个脚本。

一旦 jenkins 构建作业成功并且我们手动发布并标记了产品版本，我们将通过 SSH 在客户端机器上运行 phing update（此步骤可能是自动化的，但有意 不是由于某些项目要求）。该命令的作用是：

1. 从我们的 git 服务器获取最新的标记版本
2. 如果当前版本latest标记版本（带有哈希19a6d9）继续下一步
3. phing maintenance:on（将平台设置为离线模式）
4. git fetch origin 19a6d9
5. git checkout 19a6d9
6. phing composer:install
7. phing database:upgrade（运行几个命令，包括数据库备份和doctrine:migrations:migrate）
8. phing assets（运行bower install、assetic命令并将所有js/css编译成one.css和one.js）
9. phing cache:clean
10. phing maintenance:off（打开平台）

我们的phing update 任务也被trycatch 包围，如果更新阶段遇到问题，它会自动进入回滚阶段。它是通过phing rollback PREVIOUS_VERSION 命令完成的：

1. git checkout PREVIOUS_VERSION - 将 fs 恢复到之前的 git 版本
2. phing composer:install
3. phing database:rollback PREVIOUS_VERSION
4. phing assets
5. phing report（报告升级到我们的问题跟踪器时出现问题，并附有日志文件）

回答您的问题

1. 您是否愿意将bower_components 和vendor 文件夹转移到实时系统，而不是再次执行bower install 和composer install？

   • 我会选择bower install 和composer install，因为在第一次之后，您将已经缓存了所有内容。每次下一次运行几乎是瞬时的，或者至少比通过 ftp 一次又一次地重新上传所有资产快得多。这可能会为您节省一些带宽，最重要的是 时间。如果您选择执行与我类似的设置，您可能希望避免 compiling Jenkins 实例上的 js/css，因为您将在 prod 服务器上执行此操作。

2. 您在进行现场促销时如何处理您的密码？

   • 不确定您在问什么？

结论

设置主要取决于您的项目需求、可用资源（即 vps、共享主机、git、ssh 等）和您的发布过程。如您所见，我们的部署与您所做的略有不同。这不会让它变得坏也不会好 - 它只是适合我们的需求。如果你已经拥有的东西对你有用并解决了你所有的问题——你应该坚持下去并尝试优化它。如果你刚刚开始，这是你应该最小心的：

1. 完整...备份！有一个生产文件系统的备份很好，但你也应该有一个数据库的备份。在您的项目的开发过程中，您可能会拥有更改数据库的新功能。其中一些更改可能向后不兼容。因此，请务必备份所有内容，否则您最终可能会在没有数据库的情况下进行 fs 备份，从而无法回滚。

2. 回滚 - 创建一个脚本，执行将项目回滚到以前版本的所有必要步骤。如果您承受着很大的压力或事情对时间很敏感，您可能会无意中犯错误并破坏备份或其他东西...因此请编写一个脚本来为您完成此操作。

3. 在本地或在测试机器上测试部署过程，以确保在实际生产服务器上执行之前一切正常。

我希望这可以帮助您找到发布和部署过程的最佳解决方案。如果您碰巧找到了更好的解决方案，请将其作为答案发布 - 这一定会有所帮助！