在实践中，很多团队对于DevOps 流水线没有很透彻的理解，要不就创建一大堆流水线，要不就一个流水线通吃。实际上，流水线的设计和写代码一样，需要基于“业务场景”进行一定的设计编排，特别是很多通过“开源工具”搭建的流水线，更需要如此（商业的一体化平台大部分已经把设计思想融入自己产品里了）。
- 流水线的设计与分支策略有关
- 流水线的设计与研发活动有关
清晰的代码结构，标准的环境配置，原子化的流水线任务编排，再加上团队的协作纪律，和持续优化的动作，才是真正的践行CI/CD实践
流水线设计原则
1. 确定好变量
- 哪些是构建/部署需要变化的，比如构建参数，代码地址，分支名称，安装版本，部署机器IP等，控制变化的，保证任务的可复制性，不要写很多hardcode进去
2. 流水线变量/命名的规范化
- 标准化的命名，有助于快速复制；有意义的流水线命名，有助于团队新成员快速了解
3. 一次构建，多次部署
- 一次构建，多次部署（多套环境配置+多套构建版本标签）；杜绝相同代码重复打包
- 相似技术栈/产品形态具备共性，通过以上原则可以抽取复用脚本，良好的设计有助于后续的可维护性！
4. 步骤标准化/原子化
- 比如docker build/push, helm build/deploy, Maven构建等动作标准化，避免重复性写各种脚本逻辑
- 根据业务场景组装，例如. 提测场景，每日构建场景，回归测试场景
5. 快速失败
从零开始设计流水线
流水线分步骤实施, 从 “点” 到 “线” 结合业务需要串起来，适合自己团队协作开发节奏的流水线才是最好的。
- 对价值流进行建模并创建简单的可工作流程
- 将 构建 和 部署 流程自动化
- 将 单元测试和 代码分析 自动化
- 将 验收测试 自动化
- 将 发布 自动化
流水线的分层
由于产品本身的形态不同，负责研发的团队人员组成不同，代码的版本管理分支策略不同，使用的部署流水线形式也会各不相同，所以基于实际业务场景设计流水线是团队工程实践成熟的重要标志。