我在Jenkins服务器上管理几个Symfony 2/3项目，我正在将这些项目部署到一个实时服务器上。
构建
- 使用git插件 checkout
- 删除数据库（如果存在）
- 正在执行
composer install（生产模式，优化自动加载器） - 执行
bower install以获取我的资产 - 执行一个
gulp构建，它缩小并连接css / javascript（我们不使用assetic） - 执行我的数据库创建工作
- 执行单元测试
归档
构建完成后，我使用“Compress Artifacts“插件将构建的构件存档为一个zip文件，其中不包括vendor、node_modules和bower_components文件夹。
部署
我将“Promoted builds“插件和“Publish over SSH“插件组合使用：如果我想“上线”一个构建，我会通过SSH将构件（我的zip文件）发布到我的实时系统中一个名为staging_dir的目录中。
- 将实时系统设置为维护模式
- 解压缩我的
staging_dir中的工件zip - 在实时系统上执行
composer install（与构建期间的配置相同） - （
bower install和gulp构建不是必需的，因为我们使用在构建期间创建的资产） - 迁移数据库
- 将当前的实时系统文件移动到
backup文件夹 - 从
staging_dir复制文件 - 将实时系统设置为“生产”模式（禁用维护模式）
最佳实践？
现在，我想收集一些部署的最佳实践：
- 您是否希望将
vendor文件夹传输到实时系统，而不是在那里再次执行composer install？ - 那么资产呢？您是再次在实时系统上构建
bower install和gulp，还是使用已发布的资产？ - 在执行实时促销时，您如何处理您的密码？
- ......其他我已经忘记的事情。
1条答案
按热度按时间pinkon5k1#
我和几个同事已经处理这个问题有一段时间了。当我们开始的时候，很难找到关于这个主题的好帖子。这就是为什么我想分享我们发现的对我们“最好”的帖子。
项目详情
我们的一个客户有一个庞大的平台用于管理其业务流程（类似于ERP和CRM）。该平台最初是使用Symfony 2开发的，现在我们已经升级到Symfony 3。为了确保一切正常工作，该项目有大量的测试案例。我们还用途：
1.鲍尔
1.阿塞蒂奇
1.Git
1.Jenkins
测试
一旦有人提交到我们的git服务器，一个钩子就会通知Jenkins，并触发一个构建。一旦任务成功完成，我们就手动触发部署。这是通过登录到客户端机器并触发我们开发的脚本来完成的。
部署
我们过去的做法和你一样--在Jenkins完成工作后上传存档。然而，因为在某些情况下归档文件可能会损坏（例如，由于jenkins示例和生产服务器之间的网络连接问题）。此外，从我们的服务器向客户端的服务器上载文件所花费的时间也相当长。这就是为什么我们决定使用git并从那里提取必要的版本。使用git被证明是更可靠的，并确保您在客户端拥有项目的绝对副本。而且，回滚到以前的版本只需要一个
git checkout：）因为我们大多数人都有使用
ant和php的经验，所以我们决定使用Phing，并创建一个构建脚本，自动化大多数常规任务。在构建脚本中，我们添加了大多数经常运行的常见任务，如安装、升级、清除缓存、安装资产等。然后，我们在每个生产服务器上都提供了此脚本。一旦jenkins构建工作成功，并且我们已经手动发布并标记了产品版本，我们将通过SSH在客户机上运行
phing update（这一步本可以自动执行，但由于某些项目需求，我们故意没有执行）。1.从我们的git服务器获取最新的标记版本
1.如果当前版本〈最新标记版本（带有散列
19a6d9），则继续下一步phing maintenance:on（将平台设置为脱机模式）git fetch origin 19a6d9git checkout 19a6d9phing composer:installphing database:upgrade（运行几个命令，包括数据库备份和doctrine:migrations:migrate）phing assets（运行bower install、assetic命令并将所有js/css编译为one.css和one.js）phing cache:clean个phing maintenance:off（打开平台）我们的
phing update任务也被trycatch包围，如果更新阶段遇到问题，它将自动进入回滚阶段。这是通过phing rollback PREVIOUS_VERSION命令完成的，该命令执行以下操作：git checkout PREVIOUS_VERSION-将文件系统恢复到以前的git版本phing composer:install个phing database:rollback PREVIOUS_VERSION个phing assets个phing report（这将报告升级到我们的问题跟踪器时出现问题，并附带日志文件）回答您的问题
bower_components和vendor文件夹传输到活动系统，而不是在那里再次执行bower install和composer install？bower install和composer install，因为在第一次运行之后，你已经缓存了所有的内容。下次运行几乎是瞬间的，或者至少比通过ftp一次又一次地重新上传所有的内容要快得多。这可能会保存你一些带宽，最重要的是节省时间。如果你选择做一个和我类似的设置，您可能希望避免在Jenkins示例上使用compilingjs/css，因为您将在prod服务器上执行此操作。结论
设置主要取决于您的项目需求、可用资源（即vps，共享主机，git，ssh等）和您的发布过程。如您所见，“我们的部署与你们的略有不同。这并不意味着它是好是坏--它只是符合我们的需要。如果你们已经拥有的东西对你们有用，并且解决了你们所有的问题--”你应该坚持使用它，并尝试优化它。如果你刚刚开始，这是你应该最小心的：
1.完整...备份！对生产文件系统进行备份是非常好的，但是你也应该有一个数据库的备份。在你的项目开发过程中，你可能会有一些新的特性改变了数据库。其中一些改变可能是向后兼容的。所以一定要备份所有的东西，否则你可能最终会有一个没有数据库的文件系统备份，从而无法回滚。
1.回滚--创建一个脚本，它可以完成所有必要的步骤，将项目回滚到以前的版本。如果你有很大的压力，或者事情是时间敏感的，你可能会无意中犯下错误，破坏备份或其他事情...因此，创建一个脚本，它可以为你做这件事。
1.在本地或测试计算机上测试部署过程，以确保在实际的生产服务器上执行之前一切都能正常工作。
我希望这能帮助你找到你发布和部署过程的最佳解决方案。如果你碰巧找到了更好的解决方案，请把它作为答案贴出来--它肯定会有帮助的！