部署流水线原则与工具设计简述

部署流水线原则与工具设计简述

简单的部署流水线

简单的产品研发流程

• 以服务器/代理（server/agent）架构，服务器和客户端各自独立启动运行
• 服务器和代理的代码（包括自动化测试代码）全部保存于同一个代码仓库
• 产品研发团队的总人数保持在12人左右
• 迭代周期为一周
• 团队使用进行持续集成与持续交付实践
• 每两个迭代将试用版部署到公司内部的公共服务器上进行试用，一周后再将该版本交付给该产品的试用企业，进行外部用户的早期体验
• 开发人员需要编写所有自动化单元测试用例与功能自动化测试用例，并维护他们。单元测试的行覆盖率在75%~80%波动

初始部署流水线

概述

• 第一阶段是“提交构建”，包括七个并行自动化任务，分别是编译打包、代码规范静态扫描和5个不同的自动化单元/集成测试用例集合，使用自动触发机制。产品的自动化集成测试也使用单元测试框架编写，并在提交构建阶段与单元测试一起执行
• 第二阶段是“次级构建”，包括两个并行自动化测试功能测试集任务，分别运行于两类不同的环，并且两个环境中所用的测试用例集相同。使用自动触发机制
• 第三个阶段是“UAT部署”，将软件包部署到手工UAT环境（用户验收环境，User Acceptance Environment）
• 第四个阶段是“UAT结果”，测试人员手工验证完成后，将其标记为“验收通过”
• 第五个阶段是“性能测试”，就是做自动化性能测试
• 第六个阶段是“内部体验”，就是将Alpha版本部署到企业内部服务器，给内部其它团队试用
• 第七个阶段是“外部体验”，就是将Bata版本发给外部的企业用户体验
• 第八个阶段是“上传发布”，就是上传版本。将确定的商业发布版本上传到指定服务器，供用户登录产品网站自行下载

补充

• 第三阶段（UAT部署）由测试工程师手工触发。在已经通过次级构建阶段的那些构建中，选择一个被测版本，向UAT环境部署软件包，用于手工验收测试，当通过了验收测试，则测试人员手工触发第四个阶段，系统自动标记该版本为已测试通过版本
• 第五阶段的性能测试也是手工触发

部署流水线的设计与使用

流水线的设计原则

一次构建，多次使用

• 当某个部署流水线的一次运行实例构建出制品（如二进制包），如果需要，它就应该直接被用于该流水线后续阶段的构建过程，而不是在后续阶段中被再次重复构建
• 如果该流水线实例触发了下游流水线，并且下游流水线也使用该制品，那么部署流水线工具应该确保它来自上游部署流水线的同一个实例

与业务逻辑松耦合

• 部署流水线工具应该与具体的部署构建业务相分离
• 不应该为了方便实现自动化，而将软件的构建和部署过程与所选择的部署流水线工具紧耦合
• 例如将一些软件部署时所用的脚本或所需信息由部署流水线平台保存。相反，我们应该提供单独的脚本，并将其放入该产品的代码仓库中，这样可以轻松对这些脚本的修改进行跟踪和审核
• 部署流水线平台工具视为任务的调度者、执行者和记录着，它只需要知道部署流水线中各种任务触发与调度流程，而不必要知道我们如何构建和部署软件

并行化原则

• 在部署流水线的设计中，尽可能考虑并行化。如此一来，整体的反馈时间就会大幅缩短

快速反馈优先

• 在资源不足的情况下，部署流水线应该让那些提供快速反馈的任务尽早执行。优先执行那些运行速度快的自动化测试验证集合，而将那些执行较慢、消耗资源较多的自动化验证集合放在后面执行

重要反馈优先

• 将更加真实有价值的反馈也应放到流水线前面来执行，不能因为其执行速度慢，就把它放在后面执行

团队协作纪律

立即暂停原则

• 立即暂停原则是指当部署流水线运行时，某个环节一旦出了问题导致执行失败，团队应该立即停下手中的任务，安排人员着手开始修复它，而不是放任不管
• 在问题被修复之前，除因修复这个问题而提交的代码以外，禁止其他人再向代码仓库提交新的代码变更

安全审计原则

• 受控环境是指对该环境的一切操作均被审计，并且该环境中的任何组件（如源代码、二进制代码包或者已安装的程序）均已通过审计
• 每个部署流水线示例的任何环节均应使用部署流水线所提供的制品，其产生的任何产物也应该接受受控管理

部署流水线平台的构成

工具链总体架构

• 第一部分是“唯一受信源”，它是部署流水线的基础，为部署流水线的运行提供原材料（即代码和第三方组件），也用于保存部署流水线运行过程中的产物
• 第二部分是部署流水线工具本身，负责各种任务的调度与结果同意展现，通过与其它专项工具或系统相互协作，完成整个交付流程
• 第三部分是基础支撑服务层，由多种专门工具组成，提供软件的构建、测试和部署等基础能力

基础支撑服务的云化

建立自己的云化基础支撑服务，以便支持公司内部的大规模持续交付实践，并鼓励使用统一平台和工具，在提升交付效率的同时，也提高资源利用率，降低管理成本

分析

• 基础支持服务的协作过程解析
• 编译构建管理服务
• 自动化测试管理服务
• 软件部署管理服务
• 基础环境管理服务

企业制品库的管理

制品库的分类

软件包

• 企业内部，临时包、正式包
• 企业外部，发布包

镜像库

• 企业内部，临时镜像、正式镜像
• 企业外部，发布镜像

制品库管理原则

• 每一个制品都应该有唯一标识，并且连同其来源、组成部分以及用途等，一起保存为该制品的元信息
• 所有制品都可以追溯至源头，包括临时制品库中的制品
• 任何人从制品库中获取的制品都是相同的
• 制品库中的制品本身被删除或丢失，那么可以根据其保留在制品库中的元信息描述，通过原有部署流水线再次生成与原来相同的制品

多种多样的部署流水线

多组件的部署流水线

• 每个组件均有独自的代码仓库，并且每个组件由一个单独的团队负责开发与维护，每个组件的部署流水线成功以后，都能触发下游的产品集成部署流水线
• 这个集成部署流水线的集成打包阶段将自动从企业软件包库中获取每个组件最近成功的软件包，对其进行产品集成打包，并触发集成部署流水线的后续阶段

个人部署流水线

简述

• 为每名工程师都创建自己的专属的部署流水线，用于个人在未推送代码到团队仓库之前的快速质量反馈。个人部署流水线并不会部署到团队共同拥有的环境中，而是仅覆盖个人开发环节
• 通过部署流水线提供的模板功能克隆一份团队部署流水线，将其它阶段全部删除，仅保留前面两个阶段，即“提交构建”和“次级构建”的内容
• 令这个部署流水线监听工程师自己的代码仓库代码变化，并自动触发。每当个人仓库代码更新时，都会自动触发其个人专属的部署流水线

个人部署流水线

• 该部署流水线与团队部署流水线共享构建和测试集成环境。由于这些环境是统一管理的，因此能确保任何时刻，每个人的构建与自动化测试环境均与团队所属的环境一致
• 保证每名工程师都能利用更强大的测试资源，加快个人验证的速度
• 个人部署流水线运行的测试用例与团队部署流水线前两个阶段的验证集合相同，相比团队部署流水线出现构建失败，更容易定位问题。例如遗漏文件未提交

部署流水线的不断演进

为开发者构建自助式工具

简述

• 为了实现“谁构建，谁运营”，企业对于DevOps工具的建设，应该坚决从开发工程师的工作场景出发，为其构建强大的DevOps工具
• 不仅是生产环境的运维工具，而且是整个工作流程中的业务软件监控工程基础设施
• 当我们以这种思路来建设基础工具平台，组织才能成为由多个真正自驱动、自服务的业务导向型全功能团队的学习型组织

DevOps工具集包括

• 基础研发流程自助平台。如各类运行环境（构建、测试、生产）的自助平台
• 数据自助平台（包括三层检测数据）
• 用于业务快速试错的实验测量平台
• 针对移动设备，建立用户触达平台