五步走战略建立良好的持续交付流程

在Caylent[1]，我们相信成功实施DevOps的关键之一就是持续交付（CD）和持续部署都可以完全自动化。在你的IT团队中实现完整的CD可以让你感受到DevOps生态系统所提供的许多优势，同时可以确保你的团队可以快速迭代、快速发布代码并减少错误。

通过2017年DevOps状态报告[2]的调查结果，我们可以看到：凭借CD和DevOps的强大功能，高效IT团队可以比低效团队更频繁部署代码（差距约46倍）。此外，你还将获得如下优势：

更快的恢复：快24倍（较之于低效团队）

更快的交付时间：从开始code到交付的时间更短（较之于低效团队）

更低的故障率：只有0-15％的出错概率（较之于低效团队的31-45％）

为什么需要持续交付？

CD旨在通过快速，可持续，小批量地部署高质量的代码来显著降低上线发布风险。这个概念符合持续集成（Continuous Integration）的原则，重点在于帮助你的团队轻松应对部署。

一个非常有趣的理论是CD也被证明能够积极地提升你团队的幸福感和敬业度。

简而言之，更好的工作流程=高质量的代码=高质量的产品=开心的客户=开心的IT团队。

持续交付 VS 持续部署

两者之间的差异很小，而且通常这些术语可以互换使用。只有在进行分级或预生产时才进行持续交付的手动验收测试。此时，产品所有者将手动merge代码并将代码推送到生产。

Docker是如何改进CD的？

Docker使我们能够构建和分发不可变的组件，以便通过测试，预生产和生产来保留完全相同的构建组件。与Chef、Puppet或其他通用服务器构建器相比，Docker允许用户先构建然后推送到服务器，而Chef和Puppet用户必须实时构建和修改服务器。一旦构建完成，Docker允许你完整地移动管道中的组件。

这种优势提高了组件的稳健性，降低了生产流水线中故障和堵塞的风险。构建一个不可改变的组件还允许我们在本地、QA、预发布或生产环境重复测试镜像。回滚只需几秒钟，而不是几分钟，部署工作快速简单。最重要的一点是，Docker进一步将服务器配置从应用程序部署中分离出来——代码与配置解耦。

5个步骤

那么如何使用Docker来增强CD呢？Caylent的最佳实践可以分解为以下5个步骤：

在可能的情况下，尽量一次性构建你的软件包。然后通过你的CD管道移动你的不变的组件，从一个仓库到另一个仓库进行测试。在迁移过程中，利用Docker的标记系统来管理你的镜像，从而获得最高的部署稳定性。

将代码、数据库迁移和基础架构更改解耦为各自独立推送。保持它们分开，同时也让你的代码块尽可能小。

在每个环境中以完全相同的方式运行你的部署类型，并至少在一个与生产镜像相同的环境中运行。使用Docker中的环境参数并在运行时传递环境变量，这样不会大幅改变组件。考虑将这些更改视为基础架构级别的更改。

作为容器构建过程的一部分——运行测试，并自动执行所有部署的测试，旨在将构建和测试结合在一起，以保持日志文件的完整性和易读性。如果构建失败，它将保留在循环中，而不是被push到下一个环境。

保持你的stacks和环境类似。如果你正在生产站点上运行大量的Web stacks，这可能在开发和staging过程中会遇到困难，但是你的内容交付网络（CDN）、代理和缓存等内容都应该在staging中进行复制。

虽然Docker可以很容易地使用CD部署代码，但重要的是要遵循这些最佳实践来正确构建、测试和部署，而不是随心所欲，想怎么来怎么来。

在下篇博客中，我们将介绍Docker持续发布的四种主要部署类型。