你准备好持续交付（CD）了吗？

持续交付（CD, Continuous delivery）就是说每次提交代码时立即构建，并可以将构建部署到生产环境中，本文将分享一些持续交付相关的方法和经验。
 

自动化（Automation）

自动化对于完善的CD管道来说必不可少，我们理应尽可能的用自动化取代手动工作以获得最大利益。

过去，我们的开发团队可能在将代码发布到生产环境之前一般会做测试，其中一些可能是手动的，一些则是自动的。但在持续交付的情况下，每次提交都要进行代码测试，因此最好的办法就是“自动化一切可自动化的东西”，并且不应仅限于开发团队。

软件中所有重要部分的自动化都是必要的——

• 测试（Tests） - 单元测试、集成测试、UI测试、回归测试、性能测试...
• 数据库的安装、备份和恢复
• 产品及其依赖项的安装和测试
• 代码文档和用户文档

根据我们的产品不同，可能还会有很多其他可自动化的部分，例如基于云计算的产品，可以自动配置基础架构。
 

经常提交、尽快提交（Commit often, Commit soon）

CD流程的第二个重要基础是“经常提交、尽快提交”的能力，在交付软件时，快速的反馈周期可以带来极大的不同。

然而不幸的是，大爆炸开发方法和部署（Big bang development approach and deployments）仍是业界的常态。用这种方式，每隔几个月、一次性发布大量代码到生产环境中很常见。

而在代码中引入大量更改并将其部署到生产系统中可能会产生意外后果。很难确切地知道出了什么问题，而且诊断起来很困难。以这种方式更新的大型系统很难恢复到工作状态，因为您无法轻松回滚。

持续交付要求您经常将更改与主分支集成。每次更改代码时，请将更改推送到版本控制。

如果我们没有整天commit，一般无法确切知道我们的commit如何适应系统的其他部分，或者它是否已经破坏了任何东西。如果我们使用的是版本控制系统，开发人员可以切换到过去任何给定时间点的代码。

频繁提交的另一个积极结果是我们可以更快地获得有关项目状态的反馈，我们很快就会发现某个解决方案走错了方向，而如果出现问题，我们只需要调试一些潜在的部分。另外，不要忘了有意义的提交备注很重要！

当开发人员长时间彼此孤立地工作时，实现CD几乎是不可能完成的任务。在大公司中，持续数月的开发周期并不罕见。当开发工作以这种方式发生时，在开发阶段结束时需要进行大量测试，这也就意味着在相当长的一段时间里，我们无法了解应用是否正常工作。

避免这种不确定性需要开发人员经常commit他们的工作，尽快让更改对其他人可用。在大型团队中，这一点很重要，这使得合并冲突和由大型提交引起的其他问题变得不那么频繁且更易于解决。
 

开发和运维（Developers and Operations）

先进的软件开发公司一般都至少遵循了Agile/Scrum方法的一部分。例如，Scrum的一个仪式是团队每天进行讨论：昨天做了什么、今天要做什么以及有什么困难，这么做的目的是让整个团队了解正在进行的工作。

提高开发团队生产环境知识的一种简单方法是让运维工程师参加，让开发团队能够更好地了解运维所做的工作。

从长远来看，我们需要DevOps，避免开发和运维成为两个孤岛。
 

生产环境（Production Environment）

CD的最后边界是部署到生产环境中。对于生成代码库的每次提交，不需要进行生产部署，但每个构建都需要生产就绪。

大多数开发团队对实际生产环境、硬件和软件的规范、配置、安全规则等了解不多，甚至根本无法访问生产环境。

改善这种情况需要采取的第一步，是建立一个尽可能接近真实生产环境的临时环境。
 

打破一体化（Breaking Monoliths）

有效实施CD的常见障碍是克服一体化架构代码库的“迟缓”，缓慢的构建、脆弱的代码库、复杂的代码和架构是一些常见的问题。

常见的方法是重新构建整个系统，但一般方法会涉及到大量的时间、资源和资金，以及技术挑战。

对于那些不专注于软件开发的公司来说，要获得管理层的批准要困难得多，因为这需要额外的预算和精力分配到可能只是微不足道的边际收益的事情上。

对于其他更注重软件的公司而言，从长远来看，重新构建整个解决方案可能是最好的方法。

我们建议的入门方法是将代码库拆分为多个存储库，每个存储库都集中在整个产品的较小子集上。这些较小的存储库中的每一个都应该是自包含的，它们应该有自己的构建脚本、测试等。

如此一来，CD流程可以更快实现，而无需对系统进行彻底“检修”。从长远来看，应使用微服务架构方法将这些单独的存储库进一步细分为更小的部分。

https://www.tuicool.com/articles/BbmIviE