什么是 CI/CD? | 实现更快更好的软件交付

【云原生】什么是 CI/CD ? | 摆平交付障碍的 CI/CD

在前文中我们看到了 CI/CD 如何解决了软件交付中的一些常见问题，但 CI/CD 的诞生更是为了解决软件交付中最为本质、最为核心的问题，那么这些隐藏在冰山底下的问题是什么呢？

隐藏在冰山下的本质问题？

这其实也是在问软件交付中最为根本的目标是什么。

软件交付的目标

交付的一个重要目标是速度。交付的速度是至关重要的，其中的一个重要原因就是我们需要验证新开发的功能或者修复的缺陷是否真的有用。在软件开发前，用户会根据自身有限的经验猜测哪些功能是需要的、哪些缺陷是需要修复的，所以用户提出的需求往往不一定合理有用。直到用户真正使用软件之前，这些全是未经过验证的假设。如果交付的时间过长，那么最后纠正所带来的成本就越高，这也是为什么要提高交付速度并且建立有效反馈环的原因。

交付的另一个重要目标是确保质量。软件交付的速度固然重要，但软件的质量更是基础。我们所交付的软件应该至少满足它的业务目的，在此之上我们应该在能力范围内尽可能交付质量足够高的软件，给客户带来价值。

综合以上两点，软件交付中最为根本的目标可以归纳为以一种高效、快速、可靠的方式交付高质量且有价值的软件。

目标：更快、更好

为了实现这一目标我们又该怎么做呢？

解决方案：自动化+频繁交付

针对这一目标我们的解决方案是频繁且自动化地发布软件，这也正是 CI/CD 的核心思想。

首先为什么实现自动化是必要的呢？

如果构建、部署、测试和发布流程不是自动化的，那它就是不可重复的。由于软件本身、系统配置、环境以及发布过程的不同，每次做完这些活动以后，其结果可能都会有所不同。如果每个步骤都是手工操作，那么出错的机会很大，而且无法确切地知道具体都做了什么。这意味着整个发布过程无法得到应有的控制来确保高质量。而实现自动化则可完美规避这些问题。

其次频繁交付软件的重要性又体现在哪里呢？

如果能够做到频繁发布，那么每个发布版本之间的差异会很小。这会大大减少与发布相关的风险，且更容易回滚，从而提升交付的速度与质量。

频繁且自动化地发布软件只是一种宏观上的解决问题的思想和方法，我们在具体实践时又该怎么做？应该遵循什么样的原则呢？

频繁且自动化交付软件应遵循的原则

1. 每次修改都应该进行反馈

软件可看做由四个部分组成：可执行的代码、配置信息、运行环境和数据。修改其中任何一部分，都有可能导致软件的行为发生变化。所以我们要能够控制这四部分，对每次修改进行反馈，尽可能地测试每一次变更。

需要控制的四大部分

• 可执行代码

当修改了源代码后，可执行代码当然也就会随之发生变化。因此每当修改源代码后，都要进行构建和测试。为了能够控制这个流程，构建可执行代码并对其进行测试都应该是自动化的。每次提交都对应用程序进行构建并测试，这称作持续集成。之后的部署活动中都应该使用这个构建并测试后的可执行代码，无论是部署至测试环境，还是生产环境。此外，如果应用软件需要编译，应该确保在所有需要可执行代码的地方都使用在构建流程中已生成的这个，而不是再重新编译一次生成一个新的。

• 配置信息

对环境的任何修改都应该作为配置信息来管理。无论在什么环境下，对于应用程序配置的变更都应该被测试。如果用户自己安装软件的话，任何可能的配置项都应该在各种具有代表性的环境上测试。

• 运行环境

如果需要修改该应用程序所要被部署的运行环境，那么整个系统都应该在修改后的环境中进行测试。这包括对操作系统配置、该应用程序所依赖的软件集、网络配置，以及任何基础设施和外部系统的修改。

• 数据

如果是数据结构发生了变化，这些变化也同样要经过测试。

反馈时应做到

在检测到变化后，我们需要对变化进行反馈，尽可能地测试每一次变更，这些测试通常至少包括下面的检测：

• 创建可执行代码的流程必须是能奏效的。这用于验证源代码是否符合语法。
• 软件的单元测试必须是成功的。这可以检查应用程序的行为是否与期望相同。
• 软件应该满足一定的质量标准，比如测试覆盖率以及其他与技术相关的度量项。
• 软件的功能验收测试必须是成功的。这可以检查应用是否满足业务验收条件， 交付了所期望的业务价值。
• 软件的非功能测试必须是成功的。这可以检查应用程序是否满足用户对性能、 有效性、安全性等方面的要求。
• 软件必须通过了探索性测试，并给客户以及部分用户做过演示。这些通常在一个手工测试环境上完成。此时，产品负责人可能认为软件功能还有缺失，我们自己也可能发现需要修复的缺陷，还要为其写自动化测试来避免回归测试。

2. 反馈速度要快

反馈的速度也是关键。为了做到快速接受反馈，如果是手工人力来做就有着很大弊端。首先手工操作会花更长的时间，可能引入更多的错误，并且无法审计。另外，持续做手工构建、测试和部署非常枯燥而且有重复劳动，与人力资源利用率的准则相悖。我们应该将人力释放出来做更有价值的工作，将那些重复性的体力活交给机器来做。

要实现快速反馈，正确合理的做法是实现自动化。整个自动化流程里包含了全面的自动化测试套件，经过多轮测试后我们对软件更有信心。如果这些测试失败了，这个构建版本就不会再进入后续阶段。

为了确保对变更的快速反馈，此外我们还要注意开发软件的流程，特别是如何使用版本控制系统和如何组织代码。开发人员应该频繁提交代码到版本控制系统中，像管理大规模团队或分布式团队那样，将代码分成多个组件。在大多数情况下，应该避免使用分支。

3. 对反馈迅速做出反应

当我们捕捉到变化并收到反馈时，应该及时对反馈做出反应，根据反馈来调整行动。在这个过程中应该做到：

全员参与：参与软件交付过程的所有人（包括开发人员、测试人员和运维人员、数据库管理员、 基础设施的专家以及管理者）都应该参与到这个反馈流程中，这是至关重要的。如果这些人无法到每天都在一起工作，就一定要常常碰头并一起探讨如何改进软件交付的流程。对于快速交付高质量的软件来说，基于持续改进的过程是非常关键的。迭代过程有助于为这类活动建立规律性，例如每个迭代至少开一次回顾会议，在会上每个人都应参与讨论如何在下一个迭代中改进交付过程。

信息广播：想要能够根据反馈来调整行动，就要对信息进行广播。使用一个大且可视的仪表盘，或者其他通知机制对于确保反馈送达到每一个人是极为重要的。

纪律与计划：当需要采取行动时，整个团队有责任停下他们手中的事情，来决定接下来采取哪些行动。在完成此事之后，团队才能继续自己的工作。

通过实现自动化和频繁交付软件，我们实现了软件的更快更好的交付，获得了很多益处，我们将能够验证变化，重现各种环境中的部署过程，在很大程度上减少产品出错的机会。由于发布过程本身已不再是一个障碍，我们可以部署软件变更，从而更快地获得商业利益，也让软件发布不再是一个充满压力的过程。在本系列的下一篇文章中，我们将了解到 CI/CD 所带来的更多意想不到的好处。

神州数码企业业务集团：什么是CI/CD? | CI/CD 带来的好处3 赞同 · 0 评论文章

---

参考文献：Jez HumBle，David Farley，《持续交付——发布可靠软件的系统方法》

（部分图片来自网络，如有侵权，立即删除）