部署流水线是软件交付过程中的一种可视化呈现方式，展示了从代码提交、构建、部署、测试到发布的整个过程，为团队提供状态可视化和即时反馈。
部署流水线的设计原则和使用
设计原则
- 一次构建，多次使用：流水线应该只有一次构建任务，所生成的制品应该直接用于流水线的后续阶段，不能重复构建；如果触发了下游流水线，下游流水线也应该使用该制品。只有这样才能保证制品的质量随着流水线的前进而增加。
- 与业务逻辑松耦合：应该与具体的部署构建业务相分离，不应该为了方便实现而将构建和部署过程相耦合，例如将部署的脚本保存在流水线中。
- 并行化原则：在设计中应该尽可能考虑并行化，降低持续集成的时间。
- 快速反馈优化：应该让那些提供快速反馈的任务尽早执行，例如将一些执行较快的测试用例放在流水线前面。
- 重要反馈优先：对于反馈机制，不能只因其执行速度慢，就把它放在后面执行，例如，软件包的安装测试，虽然运行速度比单元测试速度慢，但其反馈更加真实有价值，也应该放到流水线前面执行。
团队协作纪律
- 立即暂停原则：当部署流水线运行时，某个环节一旦出了问题导致执行失败，应该立即停下手中的任务，安排人员着手开始修复它，而不是放任不管，并且禁止除问题修复这个问题之外的其他代码合入。；
- 安全审计原则：角色协作时，如果要传递代码和软件包，应该来自受控环境（该环境的一些操作均被审计，并且该环境中的任何组件都已通过审计），任何环节都应使用部署流水线提供的制品，并产生的任务产物也应该接受受控管理。例如，不允许测试人员私自拉取代码构建包进行测试，不允许开发人员通过即时通讯工具传递软件包。
部署流水线平台的构成
部署流水线的构成
- 唯一受信源：部署流水线的基础，为其提供原材料，包括代码和第三方组件，也保存其产物；应该对信息之间的关联关系进行持久化；任何环境安装和运行的二进制安装包，均来自于该制品库，也能够找到对应的代码和依赖的二进制包；满足审计要求，任何的需求、缺陷和争议，均能通过审计找到根因。
- 部署流水线平台：通过一定的形式连接受信源与不同基础服务，并能够协调和调度不同的任务，完成整个交付流程的运作，并能够展示所有部署流水线进展和历史信息。
- 基础支撑服务层：由多种专门工具组成，提供软件的构建、测试和部署等基础能力。
制品库的管理
制品库是部署流水线的企业受信源之一，也是企业信息安全管理中很重要的一个节点。
分类
| 制品库 | 企业内部-临时 | 企业内部-正式 | 企业外部 |
|---|---|---|---|
| 软件包库 | A | B | X |
| 镜像库 | C | D | Y |
- 临时软件包A：存储企业内部团队开发生成的所有软件包，该仓库二进制软件包不能被直接部署在生产环境；可以被清理。
- 正式软件包B：存储那些经过部署流水线验证，被确认能够且将发布到生产环境（或用户）手中的软件包；需要一直被保存，直至退市。
- 外部软件库X：不是由企业自身团队管理和维护，但是在企业研发自己的软件产品的过程中所用到的软件制品，从互联网或第三方机构获得。
管理原则
每个制品都应该由唯一的标识，并且连同其来源、组成部件以及用途等，一起保存为该制品的元数据；所有制品都可以追溯至源头；即使制成品给删除了，可以根据其保存在制成品中的元信息描述，重新构建生成与原来相同的制品。
为开发者构建自助式工具
提倡建设DevOps工具链，应该坚决从开发工程师的工作场景出发，构建起强大的DevOps工具，不仅是生产环境的运维工具，而且是整个工作流程中的业务软件监控工程基础设施，包括：
- 基础的研发流程自助平台
- 数据自助平台，包括监控数据和业务数据
- 用于业务快速试错的实验测量平台
