你以为搞个流水线每天跑，团队就在使用CI/CD实践了？
在实践中，很多团队对于DevOps 流水线没有很透彻的理解，要不就创建一大堆流水线，要不就一个流水线通吃。实际上，流水线的设计和写代码一样，需要基于“业务场景”进行一定的设计编排，特别是很多通过“开源工具”搭建的流水线，更需要如此（商业的一体化平台大部分已经把设计思想融入自己产品里了）。
- 流水线的设计与分支策略有关
- 流水线的设计与研发活动有关
清晰的代码结构，标准的环境配置，原子化的流水线任务编排，再加上团队的协作纪律，和持续优化的动作，才是真正的践行CI/CD实践
流水线设计原则
1. 确定好变量
- 哪些是构建/部署需要变化的，比如构建参数，代码地址，分支名称，安装版本，部署机器IP等，控制变化的，保证任务的可复制性，不要写很多hardcode进去
2. 流水线变量/命名的规范化
- 标准化的命名，有助于快速复制；有意义的流水线命名，有助于团队新成员快速了解
3. 一次构建，多次部署
- 一次构建，多次部署（多套环境配置+多套构建版本标签）；杜绝相同代码重复打包
- 相似技术栈/产品形态具备共性，通过以上原则可以抽取复用脚本，良好的设计有助于后续的可维护性！
4. 步骤标准化/原子化
- 比如docker build/push, helm build/deploy, Maven构建等动作标准化，避免重复性写各种脚本逻辑
- 根据业务场景组装，例如. 提测场景，每日构建场景，回归测试场景
5. 快速失败
从零开始设计流水线
流水线分步骤实施, 从 “点” 到 “线” 结合业务需要串起来，适合自己团队协作开发节奏的流水线才是最好的。
- 对价值流进行建模并创建简单的可工作流程
- 将 构建 和 部署 流程自动化
- 将 单元测试和 代码分析 自动化
- 将 验收测试 自动化
- 将 发布 自动化
流水线的分层
由于产品本身的形态不同，负责研发的团队人员组成不同，代码的版本管理分支策略不同，使用的部署流水线形式也会各不相同，所以基于实际业务场景设计流水线是团队工程实践成熟的重要标志。
1. 提交构建流水线（个人级）
适用场景：每名研发工程师都创建了自己专属的流水线（一般对应个人的开发分支），用于个人在未推送代码到团队仓库之前的快速质量反馈。
注意：个人流水线并不会部署到 团队共同拥有的环境中，而是仅覆盖个人开发环节。如图所示，虚线步骤非必选
2. 集成验收流水线（团队级）
适用场景：每个团队都根据代码仓库（master/release/trunk）分支，创建产品专属的流水线，部署到 团队共同拥有的环境中e.g. dev）。
注意：如图所示，虚线步骤非必选，根据情况可通过 启动参数true/flase 跳过执行，自动化测试仅限于保证基本功能的用例。
3. 部署测试流水线（团队级）
适用场景：每个团队的测试工程师都需要专门针对提测版本的自动化部署/测试流水线，部署到团队共同拥有的环境中（e.g. test）.
注意：如图所示，该条流水线的起点不是代码，而是提测的特定版本安装包；虚线步骤非必选，根据情况可通过 启动参数true/flase 跳过执行 或 裁剪。
4. 多组件集成流水线
适用场景：如果一个产品由多个组件构建而成，每个组件均有独自的代码仓库，并且每个组件由一个单独的团队负责开发与维护，那么，整个产品 的部署流水线的设计通常如下图所示。 集成部署流水线的集成打包阶段将自动从企业软件包库中获取每个组件最近成功的软件包，对其进行产品集成打包
5. 单功能流水线
适用场景：适用于和代码变更无关的场景，不存在上面步骤复杂的编排 (也可通过上述流水线的 启动参数进行条件控制，跳过一些步骤)
6. 全功能（持续交付）流水线
适用场景：需求、代码构建、测试、部署环境内嵌自动化能力，每次提交都触发完整流水线，中间通过人工审批层次卡点，从dev环境,test环境,stage环境一直到 prod环境。 常适用于快速发布的 PASS/SASS服务，对团队各项能力和流程制度要求较高，支持快速发布（策略）和快速回滚（策略）
流水线运转全景图
团队研发工程师每人每天都会提交一次。因此，流水线每天都会启动多次。当然并不是每次提交的变更都会走到最后的“上传发布” 。 也不是每次提交都会走到UAT 部署，因为开发人员并不是完成一个功能需求后才提交代码，而是只要做完一个开发任务，就可以提交。每个功能可能由 多个开发任务组成，研发工程师需要确保即使提交了功能尚未开发完成的代码，也不会影响已开发完成的那些功能。
制品经过一个个质量卡点，经历各种门禁验证，最终交付给客户 可以工作的软件