DevOps 文字培训

应如何设计 DevOps 持续交付和部署流水线？

在许多组织中，很可能也包括你的组织，开发人员在独立的代码分支上各自编写代码。这种工作方式看似能提高开发人员的个人生产力，却会损害团队的整体生产力。

独立的代码分支让你难以合并多名开发人员的代码。要集成各段代码、让它们协调运行，并向客户交付功能和价值，通常需要多名开发人员参与，进行大量返工，并解决早该解决的冲突。

缺少持续集成，挑战会更大

讽刺的是，正因为合并代码是开发周期中艰难又令人疲惫的工作，大多数开发团队往往等到把应用交给集成测试或用户验收测试人员之前才合并代码，导致问题更加严重。他们把集成成功和共同编写的代码的质量全都交给质量保证团队。这种做法令人难以置信，也恰好解释了项目为何延误、预算赤字为何飙升、团队士气和积极性为何受损、组织为何无法实现目标和履行承诺，以及全球企业为何每年在预算外和计划外的 IT 工作上浪费约 6000 亿美元。也可以说，这些钱花在了 IT 返工和临时解决办法上……

基于主干（主代码分支）的开发如何帮助你？

解决这一挑战的方法是采用基于主干（主代码分支）的开发，结合持续集成和测试自动化。基于主干的开发是一种源代码版本控制的分支模式，开发人员在称为“主干”的单一分支上协作编写代码，并避免建立其他长期存在的开发分支。

基于主干的开发是实现持续集成，并进一步实现持续交付的关键。开发人员每天多次将变更提交到主干，就很容易满足持续集成的核心要求：每位成员每 24 小时至少向主干提交一次。这能确保代码库随时可按需发布，帮助团队实现持续交付。

持续集成使你能按更小批次交付处于可部署状态的代码

此外，开发人员频繁提交代码，可以缩小开发和交付批次，提高质量，也更容易解决问题与冲突。每天提交代码并持续集成，会促使团队分小批次编写可部署且有实际价值的代码，同时保持持续集成与持续交付框架的完整性。共用源代码存储库中的更新，也给你和团队成员提供了快速协调、决策和反馈的渠道。

每次提交代码时，持续集成框架都会对依赖发生变更的模块或受其影响的功能运行自动化测试用例。如果有任何功能被破坏，提交者就负责修复该次提交。这是最高优先级。为确保团队其他成员能继续把工作集成到主干，此刻没有什么比它更重要。在有问题的提交迅速得到修复或回滚之前，禁止向主干的该模块提交其他代码，以保护主干的稳定性和可靠性。

如果你不同意这项主要的 DevOps 原则，需要回答一个问题：为什么要把新代码添加到一个已经存在错误的模块中？

你可能有合理的理由，但请务必避免积累技术债务，也避免在临时解决办法上叠加新的临时解决办法。

门禁式提交为基于主干的开发增加一层保障

DevOps 团队也可以使用门禁式提交来进一步提高质量，为主干增加一层保障。

每次开发人员尝试提交代码时，都会先运行自动化测试来验证代码。验证通过后，代码才会正式提交到主干。

在软件工程价值流的每个阶段都使用类似生产的环境

许多 IT 组织的另一个典型难题是，生产环境与预生产环境（开发、集成和测试环境）不一致。操作系统、数据库、第三方工具及 API 的配置、版本和补丁级别可能不同。自己编写的代码的不同版本也可能散落在各个生产和预生产环境中。预生产与生产环境中的 JVM 版本即使只有微小差异，也可能决定整个生产部署的成败。如果无法完全掌控环境、不知道里面有什么，就永远无法知道它们会产生什么结果。

将环境管理纳入日常软件开发和交付

因此，预生产系统理应是生产系统的副本。你需要使团队能够按需自动创建自助式环境，以便在类似生产的环境中安全完成日常软件工程任务。

组织的 IT 价值流既通过软件代码提供价值，也通过代码运行的环境提供价值。开发和运维专家都需要认识到，IT 价值流有两个同样重要的组成部分：

1. 构建软件的代码，这些软件为内部和/或外部客户创造价值。
2. 构建预生产环境和生产环境的代码，这些环境用于托管软件。

使用单一事实来源（主干）管理软件和环境
（即采用基础设施即代码（IaC））

采用 DevOps 后，构建预生产环境和生产环境的任务已纳入主干，这最直接体现了基础设施即代码（IaC）的定义。过去，各自为政的运维团队几乎不了解环境要托管的软件细节。如今，开发和运维专家会共同构建基础设施即代码。

为确保软件代码与环境代码得到同等重视，请使用单一事实来源（主干）存储软件和环境的代码。

为了能够构建全部预生产和生产系统及部署流水线，包括持续集成和交付框架，你和团队应将软件代码、所需的配置、脚本以及构建端到端交付链所需的一切内容存入版本控制系统。若想永久修改某个环境的配置，请修改环境构建脚本。这样下次 DevOps 团队成员创建环境时，就不用从头再做一遍。

大部分详细文档很快就会过时，因此投入精力使环境构建脚本保持最新显然更划算。主要原因是，如果无法自助按需创建环境，云基础设施就只是又一个利用不足的托管平台，DevOps 计划也只是又一次未能充分发挥作用的流程改进尝试。你应能通过版本控制系统创建完整的生产及预生产环境。在 DevOps 中，重建环境比修复环境更方便、更快捷。环境不再允许手动变更，只能使用代码和配置重建、配置和启动环境。

你需要新的完成定义（DoD）

持续交付框架和部署流水线已正常运行，接下来需要重新制定“完成定义（DoD）”。

只有与任务相关的客户功能和收益满足下列条件时，任务才应标记为“已完成”：

• 通过自动或一键流程从主干创建；
• 在类似生产的环境中通过自动化测试；
• 在类似生产的环境中完成演示；
• 已可部署，最好是已通过自动或一键流程部署到正在运行的生产环境。

总结

采用 DevOps 后，代码集成成为日常工作的一部分。项目结束前无需再为集成等候。开发人员、运维团队和信息安全专家在软件工程生命周期内就反复演练工作成果的部署，这无疑提高了正式上线顺利进行的可能性。

采用持续集成后，还可获得其他好处，包括提高业务吞吐量、改善软件和环境稳定性、提高工作满意度，以及为内部和外部客户提供更优质的服务。