流水线设计实践摘要

在DevOps实践中，团队对流水线的理解常常偏差，要么建立过多流水线，要么只用一个流水线处理所有情况。流水线设计应基于业务场景，并考虑到开源工具搭建的流水线需要更精细的安排，比如商业平台通常已经集成了设计理念。

流水线设计原则

• 确定变量：识别哪些变量在构建或部署时需要改变，如构建参数、代码地址等，避免硬编码。
• 规范命名：标准化流水线变量和命名，方便团队理解和快速复制流水线。
• 一次构建，多次部署：避免重复打包，支持多套环境配置和构建版本标签。
• 步骤标准化/原子化：标准化如Docker构建、Helm部署等步骤，根据业务需要组装流水线。
• 快速失败：将不稳定或耗时短的步骤放在流水线前面，提高反馈速度。

设计流水线的步骤

设计流水线时，应逐步实施，从单一步骤到完整流程，确保与业务需求和团队节奏匹配。应对价值流进行建模，自动化构建、部署、测试和发布过程。

流水线的分层

根据产品形态、团队构成和分支策略的不同，流水线设计应基于实际业务场景，这是衡量工程实践成熟度的关键。

DevOps流水线设计的最佳实践

1. 提交构建流水线：适用于个人开发阶段，提供快速质量反馈。
2. 集成验收流水线：团队级别流水线，适用于团队共享的环境。
3. 部署测试流水线：由测试工程师针对提测版本使用的自动化流水线。
4. 多组件集成流水线：当产品由多个组件组成时，用于集成打包。
5. 单功能流水线：适用于与代码变更无关的场景，如漏洞扫描、自动化测试等。
6. 全功能（持续交付）流水线：包含需求、代码构建、测试和部署环境的自动化流水线，适用于快速发布服务。

流水线运转全景图

在日常开发中，研发工程师每天至少提交一次代码，因此流水线每天多次启动。并非所有提交都会经历完整的流程，流水线会根据各个阶段的门禁验证确保最终交付的软件质量。

低代码和无代码的注意事项

了解更多

想要了解更多内容？

查看原文：你以为搞个流水线每天跑，团队就在使用CI/CD实践了？

文章来源：

DevOps在路上

扫码关注公众号