持续交付10-部署流水线

部署流水线

部署流水线:是一种软件自动化交付流程.采取一种更完整的端到端的方法来交付软件,即一键式部署.让团队可以同时得到软件功能和部署流程两个方面的快速反馈.
通过一键式部署,可以明确的知道某个部署环境部署的软件版本,出现的问题,关键度量指标(周期时间,吞吐量,代码质量等).所有人都可看任何他想使用的东西;看这个发布流程,从而改善反馈循环,识别,优化并解决瓶颈.从而实现更高质量和相对低成本与风险来创建,测试和部署复杂系统.

部署流水线阶段:

1. 提交阶段.从技术角度判断是是可执行的,包括了代码编译和单元测试,组件测试
2. 自动化验收阶段.从功能和非功能角度上判断为可执行的.从系统行为上看,它满足用户的需求和规范
3. 手工测试阶段.从产品角度判读是系统是满足需求的.并进行需求探索和易用性判断.
4. 发布阶段.可部署到不同环境,可实际交付.

最基本的部署流水线:

1. 提交阶段会进行编译,运行单元测试,执行代码分析,创建二进制包,放入制品库;
2. 验收阶段进行验收测试,最好将测试分组,并行执行
3. 发布阶段将制品库中二进制文件部署到不同环境,进行非功能性验收测试,手工测试阶段.不同的角色拥有不同环境权限,可以操作不同环境的部署.

解决什么问题

持续集成加速了开发问题的反馈,从而保障了以发布软件处于可发布状态.它关注开发团队的代码是否可编译成功以及是否通过单元,组件和验收测试.但是手工测试和后续发布流程依旧存在问题:

1. 构建和运维团队一直在等待说明文档和缺陷修复
2. 测试人员等待好的版本构建
3. 新功能开发完几周后,开发团队才能收到缺陷报告
4. 开发快完成时才发现软件架构无法满足该系统的一些非功能需求

从开发到部署需要的时间越长,就会导致软件处于无法部署状态,它存在缺陷的可能性就越高.

怎么做

• 流水线的实践

下面是常用的流水线实践:

1. 只生成一次二进制包.要求代码和配置分离,根据环境来动态选择配置文件.避免重复进行提交阶段处理;避免版本编译结果不一致.造成后续阶段执行浪费.
2. 对不同环境采用同一部署方式.将变动的和不变动的东西分离,环境部署脚本应该是固定的,实际环境的具体配置是可变的,这样可以兼顾主体流程一致,同时还不失灵活性.
3. 对部署进行冒烟测试.确认依赖服务(数据库,消息总线,外部服务)已经运行,且配置生效.
4. 向生产环境的副本中部署.要求开发,测试环境尽量和生产环境一致,避免环境差异造成部署失败.环境主要包括:
   1. 基础设施相同,网络拓扑和防火墙配置等
   2. 操作系统配置及其补丁相同
   3. 应用程序所用技术栈
   4. 应用程序数据状态已知且有效.数据迁移情况
5. 每次变更都要立即在流水线中传递.如果验收阶段和部署阶段执行的速度较快,可以采用每次提交都触发提交阶段构建的方式;如果后续流程比较慢,可以采用标签进行批量修改构建的方式;来缩小提交阶段和后续阶段的执行速度差异.保障流水线的构建频率.
6. 只要有环节失败,就停止整个流水线.要求是有故障立即处理,防止积压.但是当前执行环节要执行完毕.这样可以最大效率的利用当前环节验证已有异常.

各阶段流水线实践:

• 提交阶段

目标是剔除不适合生产环境的构建.这个阶段应该尽量快速,因为保障开发速度.执行时间最好在5分钟以内,不超过10分钟.具体内容:

1. 编译代码
2. 运行提交测试,一般是单元测试,一些需要提前发现的测试也可以在这里进行
3. 执行代码分析.收集测试覆盖率,重复代码质量,圈复杂度,耦合度,编译警告数量,代码风格等.根据你的实际情况判断这些标准是否满足打包需要.
4. 创建二进制包
5. 为后续环境进行环境准备

提交阶段通过就被看作候选发布版本.通过该阶段开发就可以继续其他需求开发.

• 验收阶段

因为单元测试和底层API是紧耦合的,所以它无法进行组件测试和依赖测试.这时就需要验收测试从全局角度来验证功能是否实现.这个阶段的验收测试是功能验收测试.它也是一个回归测试套件,确认修改是否引入了回归缺陷.整个团队都是验收测试的所有者,如果验收测试失败,相关人员要立即去解决.开发人员本地必须可以运行验收测试,便于出问题进行复现解决.

• 后续的测试阶段

验收阶段完成其实基本上就代表二进制文件可以部署到生产环境.实际上一个严谨产品还需要进行人工测试(探索性,易用性,演示),和非功能验收测试,这样才能保障产品从可用到易用的转变.

1. 人工测试.测试人员可以获取所有已经验收测试的二进制文件,自主选择要部署的文件到测试环境.
2. 非功能测试.容量,安全性.具体验收标准具有一定的主观性.

• 发布准备

每次生产发布都有风险,因为可能服务无法运行甚至是造成脏数据.解决方式:

1. 所有人共同创建并维护一个发布计划.内容明确,节奏可控,便于问题定位.
2. 尽可能多的进行自动化.避免人为操作失误.
3. 类生产环境经常做发布流程演练.熟悉流程和调试方案
4. 具备中途撤销发布的能力
5. 作为升级和撤销过程的一部分,制定配置迁移和数据迁移的策略

核心点:

1. 自动部署和发布.这包括了两部分,1要具备应用所处环境的控制权,包括自动化环境准备和管理,最佳配置管理,虚拟化等;2不断演练,获取最优实践.
2. 变更的撤销.通过自动化部署和版本回滚策略来解决人为失误和功能缺陷问题.版本回滚策略的实现有两种方式:
   1. 金丝雀发布.同时运行现有版本和新版本,进行试运行,有问题立即停止新版本,处理异常数据.
   2. 从头重新部署旧版本.需要撤销流程和部署流程,增量部署流程,回滚流程具备同级价值.对于自动化级别要比较高.
3. 在成功的基础上构建.

具体实践如下:

1. 对价值流建模,创建也给可工作的简单框架;梳理整个部署流程的价值流图.具体流程设计,进行哪些处理,执行节点,耗时,权限管理,是否有分支或组件,如何集成.初步建立时可以只搭个框架,便于后续直接使用即可;
2. 将构建和部署流程自动化;流程如下:
   1. 监控版本库,有提交就触发构建
   2. 通过单元测试后生成二进制文件,并放入制品库.
   3. 对制品库中文件进行功能验收测试
   4. 通过验收测试的进入自动化部署环节
   5. 选择部署环境后,将二进制文件和配置整合部署到该环境
   6. 进行冒烟测试验证配置正确后,进行非功能测试,人工测试
3. 将单元测试和代码分析自动化;
4. 将验收测试自动化;前期就要进行,便于提前了解非功能需求.便于追查随机问题,难以发现的问题.
5. 将发布自动化;

部署流水线的演进

流水线随着项目的迭代也会发生变化,如果项目拆解为微服务,流水线应用使用组件方式进行构建,最后再进行聚合操作.要点:

1. 你不需要一次性实现整个流水线.应该时增量式实现.如果有人工操作的部分,就在流水线中为它创建一个占位符.记录每个手工执行的耗时情况,评估是否会称为瓶颈点.
2. 部署流水线是最重要的统计数据来源.流程开始,结束时间,每个阶段修改的内容,部署周期,每个阶段耗时.这样就可以全局观测部署流程,便于找出瓶颈点.
3. 流水线也需要迭代,不断更新.

流水线还需要一个度量指标

• 应用价值度量指标

周期时间:从决定做某个特性开始,到交付给用户的时间.它是全局度量指标.知道评估指标后,系统的优化点如下:

1. 识别系统约束
2. 确保供应.确保最大限度提高约束流程产出
3. 协调其他环节产出.尽量通过自动化来弥补约束限制
4. 为约束环节扩容.
5. 重复以上流程

其他指标:

1. 自动化测试覆盖率
2. 代码库的特性.重复代码量,圈复杂度,输入耦合度,输出耦合度,代码风格等
3. 缺陷数量
4. 交付速度.即团队交付可工作,已测试并可以使用的代码的速率
5. 每天提交到版本库的次数
6. 每天构建次数
7. 每天构建失败次数
8. 每次构建花费时间