CI/CD最佳实践

实现持续集成最重要的是确保所有源代码、配置文件、脚本、库和可执行文件都在控制范围内，每一次修改都有迹可循，并通过更频繁地共享、较小的更新来实现多次更改。每当开发人员将新增代码提交至主干，自动化测试就会被触发，相关反馈将实时提交至团队所有成员，从而确保团队在相同的基础上工作，加深团队内部协作，降低集成大型复杂变更的合并难度。

这一举动往往会在执行初期受到习惯于在分支中工作的开发人员的抵制，因此，形成协作而非争执的团队文化和氛围是至关重要的。

CI/CD流水线通过为开发人员提供更改内容的快速反馈来避免构建方向出错，并将主干维持在持续可发布的状态，以有效解决突发问题。

为避免因语法错误、依赖项丢失等低级错误导致构建失败，开发人员应在部署迭代内容前先在本地进行初始测试。理想情况下，团队成员应人手一套与CI/CD流水线相同的脚本，以避免重复工作；切不可互相指责，应相互协作、改进CI/CD流水线。

传统开发流程的常见错误是：为每个开发阶段都单独创建一个新的构建。在不同环境下重构软件是一个高风险行为，可能导致此前所有测试结果失去意义。

应用CI/CD流水线时，应将相关变量、身份验证参数、配置文件等信息版本化存储于中央存储库中，相同的构建只需也只应部署一次，保证每一个构建阶段的建设可靠性。

CI/CD较为依赖自动化测试，但不能因测试的便利性而滥用资源。CI/CD的目的是快速形成反馈循环，实现更快速、更可靠的软件交付，有时需要在测试覆盖率与性能中做出取舍。

在流程开始时，最好先运行测速最快的部分，以便尽快获得反馈。自动化测试的第一步通常是单元测试，可覆盖较广范围并标识因迭代更新而出现的问题。单元测试后会进入自动化集成或组件测试，以测试不同代码之间的交互部分是否存在问题。在最后的手动测试或验收测试前，还可进行更为复杂的自动化测试——如GUI（Graphical User Interface，图形用户界面）测试、性能和负载测试、安全测试等。此外，测试人员应重点关注最易受迭代更新影响而出现问题的模块，从而提升测试效率。

长时间运行后，随环境变更的配置会导致同一个测试内容出现不同结果，而维护静态环境不仅存在成本问题，还会导致测试速度变慢，影响发布进程。

测试人员可以使用容器进行环境托管并运行测试，并使用“基础设施即代码”（Infrastructure-as-Code，IaC）的方法来编写步骤脚本，轻松实现新增迭代内容的环境启动与关闭。为使环境扩展更为轻松并确保一致性，测试人员可以在需要时构建多个并行测试。

在确保CI/CD流水线已具备可靠性、高效性及安全性之后，所有开发步骤都应根据流水线执行，切不可因时间紧迫或改动较小就掉以轻心，导致出现原本完全可以避免的问题，影响交付进度。

为识别流水线存在的潜在问题和可改进部分，开发人员应分析CI/CD工具所收集的指标，具体方式如下：

比较每周、每天或每小时触发的构建数量，用以深入了解流水线基础设施的使用方式是否合理、是否需要扩大或缩小规模和负载阈值；

持续跟踪部署速度并监控其耗时，判断需进行性能优化的时间点；

根据自动化测试统计到的数据来确定并行化测试的受益领域；

通过测试结果判断易被忽略的部分，提升测试覆盖率。

作为DevOps实践的重要组成部分，构建有效的CI/CD流水线不仅能通过“人人都有贡献”来提升共同责任感，从而打破开发团队、测试团队和运维团队之间的隔阂，还能够提升团队内部协作动力、强化团队凝聚力。

此外，高度信任、可靠的工作环境还有利于团队成员头脑风暴、输出更多优质内容，形成软件交付和持续改进的良性循环。