DevOps 流水线简介及最佳实践 | 实践篇
DevOps 流水线简介及最佳实践 | 实践篇
概述
在上一篇《DevOps 流水线介绍及最佳实践-1 理论篇 》的文章中，我们主要对 DevOps 相关的概念、设计和构建流水线的基本原则及常见的流水线工具进行了介绍。
但是在实践过程中，发现有不少团队对 DevOps 流水线的理解并不是很透彻。主要体现在以下一些方面：
- CI/CD 流水线只是简单的替换人工的编译、打包和部署；
- 创建很多零散的流水线各自为战，没有结合业务场景和管理需求合理的组织或串联各条流水线；
- 创建一条从头到尾通吃的流水线。
实际上，我在设计流水线时，跟写代码是类似的，是需要基于具体的业务场景、具体的研发管理过程进行设计编排，才能更好的为团队服务，发挥流水线的作用。特别是哪些通过各种开源工具集集成的流水线平台，更需要特别注意并进行精心的设计。当然如果使用上商业化的产品就省心多了，流水线的很多理念已经融入到产品平台里了。
端到端的闭环（开源）工具链集成方案
2
流水线设计
对于流水线，在实际项目组，我们如何去设计和实践我们的流水线呢？通常情况下，流水线的任务和流程设计，是跟具体业务、研发管理流程、分支策略环境管理等有密切关系，但总结团队实际落地过程中，影响最大的是以下两个方面：
- 流水线的任务和流程设计与项目的具体分支策略有关系
不同的分支，服务不同的人员，也有不同的流水线任务与之相对应。比如：对于功能特性开发 feature 分支，是面向开发者个人，我们需要建立一条对应的流水线来保证 feature 分支的代码的质量；对于集成分支 release 分支，是面向团队的，我们也需要建立一条对应的流水线来保证 release 分支的代码质量。
一个典型的 gitlab 分支模型图和流水线规划
- 流水线的任务和流程设计与项目的具体研发活动也有关系
不同的研发过程管理活动，对流水线的设计也有很大影响。比如单元测试、自动化测试、制品晋级等任务，应该放在哪条流水线上？放在哪个环节呢？就需要结合实际的情况来确定来。
一个典型的研发过程活动和 DEV 部署流水线的核心任务
对于一个好的 CI/CD 流水线的实践来说，通过是具备清晰的代码结构、标准的环境配置、原子化的流水线任务编排、团队的协作纪律和持续优化的等特性。
3
从零开始设计和实现流水线
流水线的实施步需要结合项目的业务和管理情况，先从简单到复杂，从点到线，分步骤的实施。将零散的流程和节点串联起来，形成一个完整有序的合业务流程，形成适合团队自己协作和开发节奏的流水线并持续优化改进。通常步骤如下：
- 对价值流进行分析和整理，形成内部端到端的，完整的、有序的、可落地实施的工作流程
- 分析整个工作流程中可以通过流水线自动串联的任务和环节
- 将代码编译、构建、打包和部署环节通过流水线实现自动化
- 将单测和代码分析环节通过流水线实现自动化
- 将测试验收环节通过流水线实现自动化
- 将发布环节通过流水线实现自动化
红色部分可以通过流水线实现自动化操作
3.1
流水线的设计的实践
由于业务形态不同、研发管理过程不同、研发团队不同、分支策略不同、不同阶段的目标要求不同等因素，就会导致不同团队使用的流水线形式也会不同，所以没有最好的流水线，只有适合自己团队的流水线。所以结合实际的业务场景和诉求设计适合的流水线是一个团队/组织在工程实践上走向成熟的一个重要特征。根据不同的分支或分支对象、不同的任务可以分别创建不同的流水线。
提交构建流水线
- 目标用户：开发人员
- 对应分支：feature/bug 功能开发特性分支
- 主要作用：为每位开发人员创建一条专属的流水线，用于保障 feature 分支（个人）代码在推送到集成分支（团队级）之前的的代码质量。当将本地 feature 分支代码提交到远程 feature 分支时，会触发该流水线执行，并对代码质量进行检查。如果有问题会及时反馈相关开发及时处理
- 执行时长：要求快速反馈结果，一般控制在几分钟左右
- 参考示例：
集成流水线
- 目标用户：团队成员（面向团队-自动）
- 对应分支：master/release/trunk 等集成/主干分支
- 主要作用：创建团队/产品专属的公共流水线，用于保障集成/主干分支代码的质量，随时可用
- 参考示例：
测试验收流水线
- 目标用户：测试人员
- 对应分支：N/A
- 主要作用：为测试工程师创建一条专门针对提测版本的自动化部署/测试验收的流水线。确保进行人工测试前，提测的制品是经过自动化测试验证的。需要注意的是该流水线部署的是从制品库拉取特定提测的部署包，而不是从某条分支的代码构建而来的。
- 参考示例：
日构建流水线
- 目标用户：团队成员（面向团队-自动）
- 对应分支：feature/master/release/trunk 等分支
- 主要作用：为提高流水线的构建和效应速度，对一些耗时长的任务会单独出创建相关的流水线，比如：
- 针对某个环境的漏洞扫描
- 针对大量自动化案例的全量测试
- 针对某个已部署环境的自动化测试
- 定时清理任务等等
- 参考示例：
多组件部署流水线
- 目标用户：测试/运维人员
- 对应分支：N/A
- 主要作用：在当前的微服务架构下，产品的验收或生产部署，可能会涉及多个微服务组件的同时发布和联调验证。整个产品的部署流水线的设计通常会具有编排能力，按需指定每次需要部署的制品进行发布。
- 参考示例：
全功能流水线
- 目标用户：开发者
- 对应分支：master/trunk 等主干分支
- 主要作用：需求、代码构建、测试、部署等环节全部在一条流水线中实现。每次提交代码都触发完整的流水线，不同环境的部署和验证过程加入相应的人工审卡点，从 DEV 环境、TST 环境、STG 环境一直到 PRD 环境全流程通过一条流水线完成。对团队各项能力和流程制度要求较高，支持快速发布（策略）和快速回滚（策略）
- 参考示例：
4
常见的流水线实践
4.1
流水线的实践和案例分析
以下是一些常见的流水线实践和案例分析：
- 代码集成和构建：使用流水线工具将开发人员提交的代码自动集成到共享代码仓库，并进行自动化构建。可以通过编译、打包等步骤将代码转化为可执行文件或库。
- 自动化测试：使用流水线工具运行各种自动化测试，包括单元测试、集成测试、性能测试等。可以通过测试报告等方式，及时发现和解决问题。
- 部署和发布：使用流水线工具将软件自动部署到生产环境或其他测试环境。可以通过灰度发布、蓝绿部署等策略，确保部署的可靠性和稳定性。
- 监控和报警：使用流水线工具集成监控工具，实现自动化的监控和报警。可以通过监控指标和日志，及时发现和解决问题。
4.2
最佳实践和经验总结
在设计和构建流水线时，可以参考以下最佳实践和经验：
- 尽早集成和测试：尽量将开发人员的代码尽早集成到共享代码仓库，并进行自动化测试。这样可以及早发现和解决问题，提高交付质量。
- 配置和环境的管理：将配置和环境的管理纳入流水线中，以确保不同环境的一致性和可重复性。
- 可视化和监控：通过可视化界面和监控工具，实时监控流水线的运行状态和结果。可以通过仪表盘、报表等方式，方便团队成员进行查看和分析。
- 持续改进和反馈：持续改进流水线的效率和质量。定期回顾流水线的运行情况，并根据反馈和需求进行调整和优化。
5
总结
本文介绍了 DevOps 流水线设计的影响因素，从零开始设计和构建相关的 DevOps 流水线案例介绍，最佳实践和经验总结。大家可以参考借鉴，并结合自己团队的实际情况、业务场景和诉求规划和设计适合的流水线，并不断优化完善。
“DevOps 时代”公众号诚邀广大技术人员投稿
点击阅读原文，更多精彩