持续交付2.0：云原生持续交付

内容简介：持续交付2.0：云原生持续交付

《 持续交付 》提出了一系列贯穿整个软件交付生命周期的最佳实践。但它成书的年代（2010年）云计算尚未得到广泛应用，尤其在软件开发过程中的应用非常有限。如果站在今天的技术水平和对云计算的理解水平基础上回顾《持续交付》的内容，我们有可能提出一组全新的、原生于云环境的持续交付实践。

软件发布的反模式

《持续交付》中列举了软件发布过程中的一些反模式，这些在行业中常见的不佳实践使软件发布过程容易出错，使软件发布的风险和压力增大。这些与可靠的发布过程相对应的常见的反模式包括：

• 手工部署软件 。靠详尽的发布文档来描述发布步骤及每个步骤中易出错的地方，靠手工测试来确认发布后的应用程序是否运行正确。不自动化的部署过程既不可重复也不可靠，会在调试部署错误的过程中浪费很多时间。
• 开发完成之后才向类生产环境部署 。开发团队认为“开发完成了”，才第一次把软件部署到类生产环境（比如试运行环境）。假如应用程序是全新开发的，第一次将它部署到试运行环境时可能会非常棘手。
• 生产环境的手工配置管理 。通过专门的运维团队来管理生产环境的配置，如果需要修改一些东西，就由这个团队登录到生产服务器上进行手工修改。经常导致部署到生产环境时就失败，尽管多次部署到试运行环境都非常成功。

在云计算的背景下，我们可以看得更远一步：这些反模式如果在今天的研发团队中仍然出现，背后反映的是这支研发团队还不会利用云计算提供给他们的便利能力。

• 手工部署软件 => 软件发布形态和流程不标准 。因为软件的发布形态多种多样（JAR、WAR、RPM、DEB……），因为软件的功能与配置不解耦，所以才会需要手工部署。而发布形态和发布流程的不标准，背后的原因是计算资源稀缺，需要复用服务器。
• 部署到类生产环境太晚 => 开发环境与生产环境不统一 。因为开发和测试用的环境与生产环境有很大差异，才会出现部署到类生产环境时的种种困难。开发环境与生产环境的不统一，背后的原因也是计算资源稀缺，生产环境昂贵，无法做到随需可得。
• 生产环境手工配置管理 => 环境管理情况复杂 。因为环境需要长期使用且不断升级，才有了对环境进行管理的需求。环境需要长期使用和升级，背后的原因是计算资源缺乏弹性，不需要的时候不能随意丢弃。

对于这些反模式，《持续交付》提出的解决办法是“将几乎所有事情自动化”。但在当时的技术水平下，由于软件发布的形态和流程不标准、开发/测试环境和生产环境不统一、环境管理情况复杂，“将发布流程自动化”在每个团队的具体做法都不同，因此持续交付的水平高度依赖于团队的能力与觉悟。《持续交付》也只能苦口婆心地劝说“如果需要执行这个流程数十次的话，就不是那么容易的事了”，而且“不需要把所有的东西一次性地全部自动化……随着时间的推移，最终你可以、也应该将所有环节全部自动化”。

但如果在软件的开发过程中充分利用云计算的弹性能力，这些反模式有可能被根除，而不必由每个开发团队重复地尝试通过自动化来缓解。

部署流水线

《持续交付》提出了“部署流水线”的概念（如下图）。“随着某个构建逐步通过每个测试阶段，我们对它的信心也在不断提高。当然，我们在每个阶段上花在环境方面的资源也在不断增加，即越往后的阶段，其环境与生产环境越相似。”

在充分利用了云计算的情况下，部署流水线会有两方面的改变：

1. 不存在“所用环境与生产环境的相似度增加”的情况，从提交阶段开始（甚至在此之前的开发阶段），所有环境都与生产环境是一致的。
2. 由于不需要根据项目拥有的计算资源来定制各个环境与生产环境的相似度，这个部署流水线不再是一个需要由开发团队来实现的概念模型。部署流水线可以是标准的、一致的，开发团队只需要定义自己这个软件的生产环境即可。

《持续交付》中提倡整个部署流水线“只生成一次二进制包”，并且在各个验证步骤之间传递二进制包。只生成一次二进制包的实践是非常必要的，因为“出于审计的目的，确保从二进制包的创建到发布之间不会因失误或恶意攻击而引入任何变化是非常关键的”。但实际的项目中经常出现二进制包非常庞大、在各个步骤（及各个环境）之间传递二进制包很费时的情况，这也是导致一些项目最终仍然退回到每个步骤重新构建二进制包的原因：增量的编译和构建可能比通过网络传递整个二进制包还省时。

如果构建的产物是容器镜像，所有运行时环境都从云上获得，那么实际上不存在传递二进制包的过程。每个验证步骤都用指定版本的容器镜像搭配对应的配置，启动一个新的运行时环境后，在云上的运行时环境中执行（自动的或手工的）验证即可。

持续集成

尽管《持续交付》说“选择并安装好持续集成 工具 之后，只要再花几分钟的时间配置一下就可以工作了”，但实际上很少有哪个项目的持续集成实施会如此顺利。例如当“发现在运行持续集成工具的机器上缺少一些必需的软件和设置”时，《持续交付》提出的建议是“将接下来你所做的工作全部记录下来，并放在自己项目的知识共享库中……并将重建全新环境的整个活动变成一个自动化的过程”。实际上，这是一件需要高度技能水平和纪律性的事，拥有这两者的技术领导者（Tech Lead）很罕见，希望每个开发团队都有这样一名技术领导者坐镇是个奢侈的梦想。

而且，持续集成环境与开发环境仍然是有区别的，这个区别很可能是由于计算资源的限制。《持续交付》中说，“你可以很有把握地说：‘只要是在与持续集成一模一样的环境上，我的软件就可以工作。’”。然而问题就在于大多数情况下，开发环境与持续集成环境不是一模一样。这也是为什么持续集成必须集中式地进行，需要有“铃声和口哨”来及时发现构建失败，并且“要让持续集成能够发挥作用……整个开发团队就必须有高度的纪律性”。

在充分利用云计算的情况下，开发一类软件（例如“Java微服务”或“ReactNative移动应用”）所需的环境和部署流水线可以由少数几名优秀的技术领导者来标准化，开发团队不需要再操心如何配置一个持续集成环境的问题。

并且正如《持续集成将死》一文中所说，云的弹性能够使每个人、每次构建都使用标准的类生产环境，因此持续集成没有必要发生在一个中心化的“持续集成工具”上。由于持续集成的“集成”这个动作在代码进入团队代码库 之前 发生，很多的提醒和纪律变得不必要了：构建失败就不能提交代码，于是确保构建成功成了每个开发人员自己的事，不能把不成功的构建扔给团队去处理。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• GitOps-云原生的持续交付
• GitOps | 一种云原生的持续交付模型
• 应用交付老兵眼中的 Envoy, 云原生时代下的思考
• 应用交付老兵眼中的Envoy, 云原生时代下的思考
• Choerodon猪齿鱼 Agent——基于GitOps的云原生持续交付模型
• 代码只在交付时有价值，开发者发表软件定义交付宣言

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。