《持续交付：发布可靠软件的系统方法》第1章 软件交付的问题

第1章 软件交付的问题

介绍

• 从“决定做某种修改”到“该修改结果正式上线”的这段时间称为周期时间（cycle time）。对任何项目而言，它都是一个极为重要的度量标准。1Implementing Lean Software Development 第59页
• 真正缺少的是一本讨论如何把各方面（包括配置管理、自动化测试、持续集成和部署、数据管理、环境管理以及发布管理）融合在一起的书
• 我们的目标是提供一个整体方案，并给出这个方案涉及的各种原则。我们会告诉你如何在自己的项目中使用这些实践
• 支持部署流水线的生态系统，包括：让增量开发成为可能的技术；高级版本控制模式；基础设施、环境和数据的管理；治理（governance）

1.1　引言

• 我们将专注于构建、部署、测试和发布过程，因为相对于软件生产全过程的其他环节来说，这部分内容的论著较为稀少
• 本书的中心模式是部署流水线。从本质上讲，部署流水线就是指一个应用程序从构建、部署、测试到发布这整个过程的自动化实现
• 部署流水线的示例如图所示

• 对于应用程序的配置、源代码、环境或数据的每个变更都会触发创建一个新流水线实例的过程。流水线的首要步骤之一就是创建二进制文件和安装包，而其余部分都是基于第一步的产物所做的一系列测试，
• 部署流水线的目标有三个
  • 它让软件构建、部署、测试和发布过程对所有人可见，促进了合作
  • 它改善了反馈，以便在整个过程中，我们能够更早地发现并解决问题
  • 它使团队能够通过一个完全自动化的过程在任意环境上部署和发布软件的任意版本

1.2　一些常见的发布反模式

• 对于大多数项目来说，在整个过程中，发布时的风险是比较大的。在许多软件项目中，软件发布是一个需要很多手工操作的过程

1.2.1　反模式：手工部署软件

• 对于现在的大多数应用程序来说，无论规模大小，其部署过程都比较复杂，而且包含很多非常灵活的部分。许多组织都使用手工方式发布软件，
• 这种反模式的特征如下
  • 有一份非常详尽的文档，该文档描述了执行步骤及每个步骤中易出错的地方
  • 以手工测试来确认该应用程序是否运行正确
  • 在发布当天开发团队频繁地接到电话，客户要求解释部署为何会出错
  • 在发布时，常常会修正一些在发布过程中发现的问题
  • 如果是集群环境部署，常常发现在集群中各环境的配置都不相同，比如应用服务器的连接池设置不同或文件系统有不同的目录结构等
  • 发布过程需要较长的时间（超过几分钟）
  • 发布结果不可预测，常常不得不回滚或遇到不可预见的问题
  • 发布之后凌晨两点还睡眼惺忪地坐在显示器前，绞尽脑汁想着怎么让刚刚部署的应用程序能够正常工作
• 随着时间的推移，部署应该走向完全自动化，将应用程序部署到开发环境、测试环境或生产环境的人来说，应该只需要做两件事
  • 挑选版本及需要部署的环境
  • 按一下“部署”按钮

1.2.2　反模式：开发完成之后才向类生产环境部署

• 我们的对策就是将测试、部署和发布活动也纳入到开发过程中，让它们成为开发流程正常的一部分

1.2.3　反模式：生产环境的手工配置管理

• 本书描述的关键实践之一就是配置管理，其责任之一就是让你能够重复地创建那些你开发的应用程序所依赖的每个基础设施
• 不应该允许手工改变测试环境、试运行环境和生产环境，而只允许通过自动化过程来改变这些环境
• 我们也应该有能力在部署出错时，通过同一个自动化过程将系统回滚到之前的版本

1.2.4　我们能做得更好吗

• 软件发布能够（也应该）成为一个低风险、频繁、廉价、迅速且可预见的过程。这些实践在过去的几年中已经被使用，并且我们发现它们令很多项目变得非比寻常

1.3　如何实现目标

• 我们的目标是尽快地向用户交付有用的可工作的软件
• 速度是至关重要的，因为未交付的软件就意味着机会成本。软件发布之时就是投资得到回报之时。本书有两个目标
  • 找到减少周期时间（cycle time）的方法。周期时间是从决定进行变更的时刻开始，包括修正缺陷或增加特性，直至用户可以使用本次变更后的结果
  • 快速交付也是非常重要的，因为这使你能够验证那些新开发的特性或者修复的缺陷是否真的有用
• 因此，尽快地交付软件很重要，保证一定的质量是基础
• 对于频繁地自动化发布来说，反馈是至关重要的
• 关于反馈的三个标准是很有用的：
  • 无论什么样的修改都应该触发反馈流程
  • 反馈应该尽快发出
  • 交付团队必须接收反馈，并依据它作出相应的行动

1.3.1　每次修改都应该触发反馈流程

• 一个可工作的软件可分成以下几个部分：可执行的代码、配置信息、运行环境和数据。如果其中任何一部分发生了变化，都可能导致软件的行为发生变化。所以我们要能够控制这四部分，并确保任何修改都会被验证
• 每次提交都对应用程序进行构建并测试，这称作持续集成

1.3.2　必须尽快接收反馈

• 快速反馈的关键是自动化。对于实现完全自动化过程来说，唯一的约束条件就是你能够使用的硬件数量
• 对于整个流水线中提交阶段，测试有如下特征
  • 运行速度快
  • 尽可能全面，即75%左右的代码覆盖率
  • 如果测试失败的话，表明应用程序有严重问题，无论如何都不能发布
  • 尽可能做到环境中立

1.3.3　交付团队必须接收反馈并作出反应

• 参与软件交付过程的所有人（包括开发人员、测试人员和运维人员、数据库管理员、基础设施的专家以及管理者）都应该参与到这个反馈流程中，这是至关重要的
• 想要能够根据反馈来调整行动，就要对信息进行广播。使用一个大且可视的仪表盘（并非一定要电子的），或者其他通知机制对于确保反馈送达到每一个人是极为重要的。这个仪表盘应该随处可见，而且至少每个团队的屋中都应放置一个

1.3.4　这个流程可以推广吗

• 书中的很多东西都来自于精益思想和哲学。精益制造的目标是确保快速地交付高质量的产品，它聚焦于消除浪费，减少成本。多个行业的实践已经证明，精益制造可以节省大量成本和资源，带来高质量的产品，缩短产品上市时间

1.4　收效

1.4.1　授权团队

• 团队成员可以更好地控制工作节奏，从而改进工作质量，这就会让应用程序的质量得以提高。他们之间的协作更加有效，无用的交互更少，可以更高效地工作，因为不需要花太多的时间等待可用的版本

1.4.2　减少错误

• 当我们说配置管理时，指的是让你识别并控制一组完整信息的流程与机制，这些信息包括每个字节和比特
• 通过积极地管理在版本控制库中的所有可能变动的内容，比如配置文件、创建数据库及其模式的脚本、构建脚本、测试用具，甚至开发环境和操作系统的配置，我们让计算机来做它们擅长的所有事情，
• 当所有的配置信息都放在版本控制系统中以后，接下来就要消除“中间人”了，即让计算机直接使用这些配置信息，而不是再通过手工输入的方式来进行软件配置

1.4.3　缓解压力

• 绝大多数经历过项目发布的人都会认为，当项目越监控发布日期，就越能感觉到压力。如果接下来的发布只需要单击一下按钮，而且只需要等上几分钟，甚至几秒钟就能完成。即使发生了非常糟糕的事情，只要花上相同的几分钟或几秒钟就把刚部署的内容恢复到从前的老样子压力就会小很多

1.4.4　部署的灵活性

• 理想情况下，只要安装机器或虚拟镜像，然后配置一些与具体运行环境相关的特定选项。然后，你就可以使用自动化过程准备好新的部署环境，并选择指定的应用程序版本进行部署

1.4.5　多加练习，使其完美

• 最好的策略就是无论部署到什么样的目标环境，都使用相同的部署方法。不应该有特殊的QA部署策略，或者一个特殊的验收测试或生产部署策略。在每次以同一种方式部署应用软件时，也是验证我们的部署机制是否正确的时机
• 只有一种环境可以有多变性，那就是开发环境。对这种开发环境的部署流程要求太严格是没有必要的

1.5　候选发布版本

• 在传统软件开发方法中，通常以较长时间的验证过程来确保软件满足质量要求并实现了全部功能需求，之后才确定能够发布的候选版本

每次提交代码都可能产生一个可发布的版本

• 如果在软件开发中的某个任务令你非常痛苦，那么解决痛苦的方法只有更频繁地去做，而不是回避。因此，我们应该频繁做集成，事实上应该在每次提交修改后都做集成

1.6　软件交付的原则

1.6.1　为软件的发布创建一个可重复且可靠的过程

• 这种可重复性和可靠性来自于以下两个原则
  • 几乎将所有事情自动化
  • 将构建、部署、测试和发布软件所需的东西全部纳入到版本控制管理之中
• 软件部署包括三件事
  • 提供并管理你的软件所需要的运行环境，这包括硬件配置、所依赖的软件、基础设施以及所需的外部服务
  • 将你的应用程序的正确版本安装在其之上
  • 配置你的应用程序，包括它所需要的任何数据以及状态
• 硬件是无法纳入版本控制的，但利用廉价的虚拟化技术和像Puppet这样的工具，这类支撑过程也可以全部自动化

1.6.2　将几乎所有事情自动化

• 你不需要把所有的东西一次性地全部自动化。你应该看一下在构建、部署、测试和发布过程中，哪个环节是瓶颈。随着时间的推移，最终你可以，也应该将所有环节全部自动化

1.6.3　把所有的东西都纳入版本控制

• 将构建、部署、测试和发布的整个过程中所需的东西全部保存在某种形式的版本存储中，包括需求文档、测试脚本、自动化测试用例、网络配置脚本、部署脚本、数据库创建、升级、回滚和初始化脚本、技术文档等

1.6.4　提前并频繁地做让你感到痛苦的事

• 这是最通用的原则，也是最有启发性的。在软件交付这个领域，它可能是最有用的一个启发式原则，我们所说的一切都可以归结到这一点上
• 如果创建应用程序的说明文档是你的痛点，那么每开发一个功能时就应写好文档，而不是留到最后一起写。把一个功能的说明文档也作为“DONE”的一个验收条件，并尽可能自动化这个过程

1.6.5　内建质量

• 交付团队必须执行铁一般的纪律：一旦发现缺陷，就要马上着手修复
• “内建质量”还有另外两个推论
  • 测试不是一个阶段，当然也不应该开发结束之后才开始。如果把测试留在最后，那就为时晚矣，因为可能根本没有时间修复那些刚被发现的问题
  • 测试也不纯粹或主要是测试人员的领域。交付团队的每个人都应该对应用程序的质量负责

1.6.6　“DONE”意味着“已发布”

• 对于一些敏捷交付团队来说，“DONE”意味着软件已经部署到生产环境上。对于软件项目来说，这是一种理想状态
• 对于那些第一次发布的软件系统来说，它可能需要一段时间才能达到“让外部用户真正从该软件身上获益”的状态。因此，我们可以暂且退让一步，只要某个功能在类生产环境上向客户代表做过演示，并且客户代表试用之后就认为是完成了

1.6.7　交付过程是每个成员的责任

• 从一个新项目的开始就要保证团队成员能够一起参与到发布程序的过程当中，以保证他们有机会频繁且有规律地进行交流。比如建立一个系统，在这个系统上，每个人都可以一眼就知道应用程序所处的状态，比如其健康状况、各种构建版本、构建通过了哪些测试、它们可被部署到的环境的状态
• DevOps运动的焦点和我们这本书的目标一致：为了更加快速且可靠地交付有价值的软件，鼓励所有参与软件交付整个过程中的人进行更好的协作。[aNgvoV]

1.6.8　持续改进

• 交付过程中，整个团队应该定期坐在一起，召开回顾会议，反思一下在过去一段时间里哪些方面做得比较好，应该继续保持，哪些方面做得不太好，需要改进，并讨论一下如何改进。每个改进点都应该有一个人负责跟踪，确保相应的改进活动能够被执行。这就是众所周知的戴明环：计划-执行-检查-处理（PDCA）

1.7　小结

• 传统上，软件发布过程充满压力。通过采用自动构建、测试和部署技术，可获得很多益处