7.1 简单部署流水线
7.1.1 简单的产品研发流程
（历史，无意义）
7.1.2 初始部署流水线
持续集成六步提交法阶段
- 提交构建：编译代报，代码规范静态扫描和5个不同的自动化单元/集成测试用例集合，使用自动触发机制。
- 次级构建：包含两个并行自动化功能呢测试集任务，分别用于windows/ie 和linux/firefox 浏览器。
- UAT部署
- UAT结果：测试人员手工验证完成后，标记为通过
- 性能测试
- 内部体验：企业内部体验
- 外部体验：企业外部用户体验
-
上传发布
image.png
7.1.3 流水线执行状态解析
开发人员每次代码提交都会出发一次部署流水线，测试人员只从通过刺激构建的那些版本那种选择包含新功能的版本进行UAT部署，并进行测试。完成后出发UAT结果。
image.png
7.2 部署流水线的设计与使用
7.2.1 流水线的设计原则
- 一次构建，多次使用：一次成功构建的制品，应该被后续流水线直接使用，而不是重新再次构建。
- 与业务逻辑松耦合：部署流水线工具与具体的部署构建业务相分离。将部署流水线平台工具视为任务的调度者、执行者、记录者，它只需知道部署流水线中各种任务出发与调度流程，而不必知道我们如何构建和部署软件。
- 并行化原则：尽可能地考虑并行化
- 快速反馈优先：在资源不足的情况下，部署流水线应该让那些提供快速反馈的任务尽早执行
- 重要反馈优先：对于反馈机制，不能因为其执行慢，就放到后面执行。
7.2.2 团队协作纪律
- 立即暂停原则 ：指当部署流水线运行时，某个环节一旦出了问题导致执行失败，团队应该立即停下手中的任务，安排人员着手修复，而不是访问不管。并且在问题被修复前，禁止其他人提交新的代码。
- 安全审计原则：角色协作时，如果要传递代码或软件包，那么它们应该来自受控环境。受控环境指对该环境的任何操作均被审计，并且在该环境中的任何组件（如源代码，二级制代码包）均已通过审计。每个部署流水线实例的任何环节均应使用部署流水线所提供的制品，其产生的任何产物也应该接受受控管理。
7.3 部署流水线平台的构成
7.3.1 工具链总体架构
image.png
唯一授信源：为部署流水线提供原材料（即代码和第三方组件），也用于保存部署流水线运行过程中的产物。图7-5中底布的三个灰色方框就是唯一授信源。
部署流水线平台：连接授信源，调度不同任务，完成整个交付流程运作，并能够展示所有部署流水线进展与历史。
基础支撑服务层：构建，测试，部署，环境管理
7.3.2 平台应当具备的基本能力
- 部署流水线平台，其关注点时软件自身的价值流动效率，包含从代码提交到部署上线的全流程活动信息，能够准确展现部署流水线各环节的状态，并且在不增加团队负担的情况下自动收集各环节生产的衡量数据，并对价值流动的效率进行度量。比如度量某一功能从开发到交付到客户手中的时间长度。
- 平台需要追溯能力，对事件的追溯能力（各种操作审计），对部署流水线产物的追溯能力(部署流水线的任意产物，其对应的源，构建脚本，依赖版本等），并且需要对历史版本进行重新构建的能力。
7.3.3 工具链建设策略
略，小公司，开源即可，中型公司，部分定制，大公司，自研或二次开发。
7.4 基础支撑服务的云化
7.4.1 基础支撑服务的协作过程解析。
image.png
7.4.2 编译构建管理服务
image.png
7.4.3 自动化测试服务
image.png
7.4.4 软件部署管理服务
略过
7.4.5 基础环境管理服务
略过
7.5 制品库的管理
分类：临时、正式、外部企业
管理原则：
- 每个制品都应该又唯一标识，并且连同其来源，组成部件以及其用途，一起保存为该制品的元信息。
- 所有制品都可以追溯指源头。
- 无论何时何地，通过制品唯一标识，任何人从制品库获取的制品都时相同的。
