在实践中，许多团队关于DevOps 流水线没有很透彻的理解，要不就创立一大堆流水线，要不就一个流水线通吃。实际上，流水线的规划和写代码相同，需求根据“事务场景”进行必定的规划编列，特别是许多通过“开源工具”建立的流水线，更需求如此（商业的一体化平台大部分已经把规划思想融入自己产品里了）。
- 流水线的规划与分支战略有关
- 流水线的规划与研制活动有关
明晰的代码结构，规范的环境装备，原子化的流水线使命编列，再加上团队的协作纪律，和持续优化的动作，才是真正的饯别CI/CD实践
流水线规划准则
1. 确定好变量
- 哪些是构建/布置需求改变的，比如构建参数，代码地址，分支称号，安装版别，布置机器IP等，操控改变的，保证使命的可仿制性，不要写许多hardcode进去
2. 流水线变量/命名的规范化
- 规范化的命名，有助于快速仿制；有意义的流水线命名，有助于团队新成员快速了解
3. 一次构建，屡次布置
- 一次构建，屡次布置（多套环境装备+多套构建版别标签）；根绝相同代码重复打包
- 相似技能栈/产品形状具有共性，通过以上准则能够抽取复用脚本，良好的规划有助于后续的可保护性！
4. 过程规范化/原子化
- 比如docker build/push, helm build/deploy, Maven构建等动作规范化，防止重复性写各种脚本逻辑
- 根据事务场景拼装，例如. 提测场景，每日构建场景，回归测验场景
5. 快速失利
- 尽或许把不稳定的，耗时短的过程 放在流水线的最前面，假如把一个稳定的过程放在前面，而且耗时几十分钟，后边的某个过程挂了，反馈周期就会变长
从零开始规划流水线
流水线分过程实施, 从 “点” 到 “线” 结合事务需求串起来，适合自己团队协作开发节奏的流水线才是最好的。
- 对价值流进行建模并创立简略的可作业流程
- 将 构建 和 布置 流程主动化
- 将 单元测验和 代码剖析 主动化
- 将 检验测验 主动化
- 将 发布 主动化
流水线的分层
因为产品本身的形状不同，负责研制的团队人员组成不同，代码的版别办理分支战略不同，运用的布置流水线形式也会各不相同，所以根据实际事务场景规划流水线是团队工程实践成熟的重要标志。
- DevOps流水线规划的最佳实践
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 布置，因为开发人员并不是完结一个功用需求后才提交代码，而是只需做完一个开发使命，就能够提交。每个功用或许由 多个开发使命组成，研制工程师需求确保即使提交了功用没有开发完结的代码，也不会影响已开发完结的那些功用。
制品通过一个个质量卡点，阅历各种门禁验证，最终交付给客户 能够作业的软件
