更快的恢复:快24倍(较之于低效团队)
更快的交付时间:从开始code到交付的时间更短(较之于低效团队)
更低的故障率:只有0-15%的出错概率(较之于低效团队的31-45%)
在可能的情况下,尽量一次性构建你的软件包。然后通过你的CD管道移动你的不变的组件,从一个仓库到另一个仓库进行测试。在迁移过程中,利用Docker的标记系统来管理你的镜像,从而获得最高的部署稳定性。
将代码、数据库迁移和基础架构更改解耦为各自独立推送。保持它们分开,同时也让你的代码块尽可能小。
在每个环境中以完全相同的方式运行你的部署类型,并至少在一个与生产镜像相同的环境中运行。使用Docker中的环境参数并在运行时传递环境变量,这样不会大幅改变组件。考虑将这些更改视为基础架构级别的更改。
作为容器构建过程的一部分——运行测试,并自动执行所有部署的测试,旨在将构建和测试结合在一起,以保持日志文件的完整性和易读性。如果构建失败,它将保留在循环中,而不是被push到下一个环境。
保持你的stacks和环境类似。如果你正在生产站点上运行大量的Web stacks,这可能在开发和staging过程中会遇到困难,但是你的内容交付网络(CDN)、代理和缓存等内容都应该在staging中进行复制。
http://caylent.com/
https://puppet.com/blog/2017-state-devops-report-here