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

Question

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

构建

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

归档

构建后,我存档文物构建的没有vendor,node_modules并bower_components使用"文件夹作为一个zip文件压缩文物 "插件.

部署

我使用" Promoted builds "插件和" Publish over SSH "插件组合:如果我想用构建"上线",我通过SSH将工件(我的zip文件)发布到我的实时系统中的一个目录中staging_dir.文件上传后,我执行一些SSH命令:

• 将实时系统设置为维护模式
• 解压缩我的文件拉链 staging_dir
• 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. Phing
3. 鲍尔
4. Assetic
5. PHPUnit的
6. 混帐
7. 詹金斯

测试

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

部署

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

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

一旦jenkins构建工作成功并且我们手动发布并标记了产品版本,我们就可以phing update通过SSH在客户端的计算机上运行(这一步可能是自动化的,但故意不是由于某些项目要求).这个命令的作用是:

1. 从我们的git服务器获取最新的标记版本
2. 如果当前版本< 最新标记版本(带有哈希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一次又一次地重新上传所有资产快得多.这可能会节省你的带宽,最重要的是节省时间.如果您选择对我的设置进行类似的设置,您可能希望避免compilingJenkins实例上的js/css,因为您将在prod服务器上执行此操作.

2. 在执行实时促销时如何处理密码？

   • 不确定你在问什么？

结论

设置主要取决于您的项目要求,您可用的资源(即vps,共享主机,git,ssh等)和您的发布过程.如您所见,我们的部署与您正在进行的部署略有不同.这不会使它变坏或变好 - 它只是满足我们的需求.如果你已经拥有的东西为你工作并解决了你所有的问题 - 你应该坚持下去并尝试优化它.如果你刚刚开始这是你应该最小心的:

1. 全部 ...... 备份!备份生产文件系统很棒,但您还应备份数据库.在项目的开发过程中,您可能拥有更改数据库的新功能.其中一些更改可能是向后不兼容的.因此,请确保备份所有内容,否则您最终可能会在没有数据库的情况下使用fs备份,因此无法回滚.

2. 回滚 - 创建一个脚本,该脚本执行将项目回滚到先前版本的所有必要步骤.如果你承受很大的压力或事情是时间敏感的,你可能会无意中犯错并打破备份或其他东西......因此,制作一个脚本来为你做这件事.

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

我希望这可以帮助您找到最适合您的发布和部署过程的解决方案.如果您碰巧找到了更好的解决方案,请将其作为答案发布 - 这肯定会有所帮助!