部署流水线是对软件交付过程的一种可视化呈现方式，展现了从代码提交、构建、部署、测试到发布的整个过程，为团队提供状态可视化和及时反馈。
部署流水线的设计与使用：
流水线的设计原则：
一次构建，多次使用
与业务逻辑松耦合
并行化原则
快速反馈优先：让那些提供快速反馈的任务尽早执行
重要反馈优先：例如：软件安装包的安装测试应放到单元测试前面
团队协作纪律：
立即暂停原则：当部署流水线运行时，某个环节一旦出了问题导致执行失败，团队应该立即停下手中的任务，安排人员着手修复它，而不是放任不管。并且，在问题被修复之前，除因修复这个问题而提交代码以外，禁止任何人再向代码库提交新的代码变更
安全审计原则：角色协作时，如果要传递代码或软件包，它们应该来自受控环境。受控环境是指对该环境的一切操作均被审计，并且在该环境中的任何组件均已通过审计。
部署流水线平台的构成：
工具链总体结构：
唯一受信源：需求/缺陷管理仓库，代码仓库，制品库
部署流水线平台
基础支撑服务层
平台应具备的基本能力：
能够准确展现部署流水线各环节的状态，并在不增加团队负担的情况下自动收集各环节产生的衡量数据，并对价值流动的效率进行度量
要具备可追溯能力
对历史构建进行重建的能力
基础支撑服务的云化：
编译构建管理服务：构建的任务管理、调度、构建集群管理及构建执行器
任务管理服务包括两个子服务，一个是接收子服务，一个是通知子服务。
接收服务是指从开发者个人或者部署流水线（或持续集成服务器）从其发送构建任务请求，记录构建请求的相关信息（请求者、请求任务内容与类型），并将其加入待构建队列中
通知服务是指从以构建完成任务列表中取出相关信息，及时通知任务发起人有关构建任务的结果信息
调度服务
负责从待构建任务列表中，根据一定的调度算法选择构建任务，并将其发送到相应的构建机上执行构建
集群管理服务
负责对各类构建环境的管理，包括编译各类构建环境的建立与销毁、环境的状态管理（繁忙、空闲、失去连接）
执行器
执行构建任务的代理，在集群中有很多个执行器，甚至一个计算节点可以有多个执行器。每个执行期需要根据接收到的信息从对应的代码仓库URI检出代码，并根据要求进行编译构建。当构建任务完成之后，根据任务信息将指定的产物放到构建描述中指定的位置（通常为企业的制品库），并向调度服务汇报执行结果。执行器本身并不真正执行任务，而是调用专门的构建工具来执行
自动化测试管理服务：测试任务管理服务、测试用例调度服务、测试集群管理服务
测试用例调度服务
根据一定调度算法从任务管理服务中选择测试任务执行
有两种工作模式：
顺序执行测试用例：将所有测试用例分配到符合测试条件的一台测试设备上执行
并行执行测试用例：将测试用例分成数个子集，将其分发到多台测试设备上执行
软件部署管理服务：
负责接受来自不同方的部署请求，分别从制品库中获得指定软件包，从代码仓库中获取部署脚本与配置文件，并根据其中的部署描述，将该软件包分发到指定运行的节点上，将其正确安装后，启动服务。
基础环境管理服务：
为构建管理服务，测试管理服务、部署管理服务提供环境准备、管理和监控服务
企业制品库的管理：
制品库的分类：
临时软件包库A：企业内部的临时软件包库用于存储企业内部团队开发的通过部署流水线生成代码的所有软件包
正式软件包库B：正式软件包库用于存储那些经过部署流水线验证，被确认能够且将要被发布到生产环境（或用户手中）的软件包
外部软件包库X：外部软件包库是指该软件包的源代码不是由企业自身团队管理和维护，但是企业在研发自己的软件产品过程中所用到的软件制品。
临时镜像库C、正式镜像库D、外部镜像库Y
制品库的管理原则：
每一个制品应该有唯一标识，并且连同其来源、组成部件以及用途等，一起保存为该制品的元信息
所有制品都可以追溯至源头，包括临时制品库中的制品。
多种多样的部署流水线：
多组件的部署流水线
个人部署流水线
为开发者构建自助式工具：
“谁构建，谁运营”：让开发工程师承担一部分技术运营的责任，有利于大大提高服务质量
企业对于DevOps工具的建设，应该坚决从开发工程师的工作场景出发，为其构建强大的DevOps工具
基础的研发流程自助平台，如各类运行环境（构建、测试、生产）的自助平台
数据自助平台（包括三层监测数据）
用于业务快速试错的实验测量平台
针对移动设备，建立用户触达平台
想让部署流水线发挥最大作用，研发团队应遵守以下5条原则：
1.任何软件包的取用皆需通过受控源，各角色之间禁止通过私有渠道获取
2.尽可能将一切流程自动化，并持续优化执行时间
3.每次提交都能够自动触发部署流水线
4.尽可能地少用手动触发方式
5.必须执行立即暂停原则
第七章：部署流水线原则与工具设计
发布时间 2023-07-26 14:37:45作者: 城南以南123