持续交付管理

《持续交付 发布可靠软件的系统方法》读书笔记

实现持续交付不仅仅是买些工具，做一些自动化的工作。它依赖于交付过程中所涉及的每个人的协作，来自行政管理层的支持，以及基层人员的改进意愿。

持续交付不仅仅是一种新的交付方法论。对依赖于软件的业务来说，它是一个全新的范例。要想知道为什么，需要研究公司治理核心中一种根本的张力（tension）。

CIMA 把企业治理（enterprise governance）定义为“由董事会（board）和执行管理层行使的一系列职责和实践，其目的是提供战略方向，以确保达成业务目标，风险被合理地管理起来，并验证组织的资源被可靠地使用了。”企业治理更关注于符合度（conformance），即遵从性、保障、监管、责任和透明管理，而业务治理（business governance）更关注业务和价值创造的执行度（performance）。

通过确保交付团队能得到应用程序在类生产环境上的不断反馈，是部署流水线达成“执行度”这个目标的方法和手段。部署流水线使交付流程更加透明，来帮助团队达成符合度。

使用本书中提到的实践后，即使开发复杂软件的大型组织也可以快速且可靠地交付新版本了。也就是说，不仅业务部门可以从投资中得到快速回报，而且还能减少风险，消除因较长的开发周期（甚至更糟，最终交付的软件无法满足其业务目标）所产生的机会成本。像精益制造业一样，没有频繁交付的软件就是仓库中的库存。它已经花钱制造完了，却还没有为你赚钱，实际上保管它也是花钱的。

配置与发布管理成熟度模型

这个模型的最终目标是组织改进，想得到的结果如下：

• 缩短生产周期，以便能更快地为组织交付价值，增加利润。
• 减少缺陷，以便可以提高效率，在技术支持工作上花更少的成本。
• 提高软件交付生命周期的可预测性，让计划更有效。
• 具有采用和遵守任何必要的法律规章的能力。
• 具备有效发现和管理软件交付相关风险的能力。
• 通过更好的风险管理和交付更少缺陷的软件来减少成本。

我们相信，这个成熟度模型可以作为一个指南，帮助你收获所有这些产出。

项目生命周期

每个软件开发项目都是不同的，但不难从中抽取出共同元素。尤其是，我们可以抽象出一个软件交付的生命周期。

与每个团队一样，每个应用程序都有自己的叙事弧线。团队组建与磨合常常会经历五个阶段：

• 创建期（forming）
• 风暴期（storming）
• 规范期（norming）
• 运转期（performing）
• 调整/重组期（mourning/reforming）

同样，软件也会经过几个阶段。初步可包含以下阶段：

• 识别阶段（identification）
• 启动阶段（inception）
• 初始阶段（initiation）
• 开发和部署阶段（development and deployment）
• 运维阶段（operation）

风险管理流程

风险管理是一个过程，它确保：

• 项目的主要风险已经被识别。
• 已有适当的缓解策略对这些风险进行管控。
• 在整个项目过程中，持续识别和管理风险。

风险管理过程应该有如下几个关键特征：

• 一个项目团队汇报项目状态的标准结构。
• 项目团队依赖标准，定期更新进度状态。
• 有一个信息展示板，让程序经理（program manager）可以跟踪当前状态，并查看所有项目的趋势。
• 项目外的人员定期对项目进行审计，确保风险被有效地管理起来了。

风险管理过程应该在启动阶段结束之前就开始了，并在初始阶段结束时进行重新审视，然后在整个开发和部署阶段中定期进行审视。

分析任何项目，可以从下面这些问题出发：

1. 如何跟踪项目进度？
2. 如何防止缺陷？
3. 如何发现缺陷？
4. 如何跟踪缺陷？
5. 怎么知道一个用户故事做完了？
6. 如何管理环境？
7. 如何管理配置项，比如测试用例、部署脚本、环境和应用程序配置、数据库脚本和外部库？
8. 演示可工作功能的频率是怎样的？
9. 做回顾会议的频率是怎样的？
10. 运行自动化测试的频率是怎样的？
11. 如何部署软件？
12. 如何构建软件？
13. 对运营团队来说，如何确保发布计划是可行的且可接受的？
14. 如何确保风险问题列表是及时更新的？

这些问题并不是一种规范，这一点非常重要，因为每个团队都要有一定的灵活性根据他们的具体需求来选择合适的流程。

常见的交付问题

不频繁的或充满缺陷的部署

花很长时间部署某个构建版本，而且部署过程很脆弱。

较差的应用程序质量

交付团队无法实施有效的测试策略。

缺乏管理的持续集成工作流程

不适当的构建过程管理。

较差的配置管理

环境不是专属的，应用程序无法用自动化过程可靠安装。

符合度与审计

许多大公司都必须遵守其所在行业的法规。

文档自动化

很多公司坚信，文档是审计的关键。我们的想法有些不同。让你按照某种方法做事的那张纸无法保证你真的是那么做的。

自动化脚本就是一份必须遵守的部署流程文档。强制使用这些脚本，你就要确保它们是时时更新的，并且部署流程是完全按照你指定的方式执行的。

加强可跟踪性

我们通常需要能够跟踪变更的历史，从生产环境中部署过哪些版本，到这些版本在源代码库中的版本号。

在筒仓中工作

大型组织常常会按职能不同被划分成多个部门。很多组织会有独立团队负责部署、测试、运营、配置管理、数据管理和架构。在规范的环境中，许多重要活动都要受到审查，审计人员和安全团队的任务就是确保该组织不会受到法律风险或任何形式的安全漏洞的危胁。

变更管理

在一个规范的环境中，对于构建、部署、测试和发布过程中的某些环境需要审批，这常常是必要的。尤其是，手工测试环境、试运行环境和生产环境总是在严格的访问控制之下，以便确保只能通过组织制定的变更管理流程对它们进行修改。

这看上去像是不必要的官僚作风，但是实际研究表明，使用这种做法的组织中，其 MTBF（Mean Time Between Failures，平均失败时间）和 MTTR（mean time to repair，平均修复时间）更短。

小结

对于每个项目的成功来说，管理都是至关重要的。良好的管理所创建的流程令软件更高效地交付，同时确保风险被适当地管理，规章制定被严格遵守。

我们的构建和发布成熟度模型的目标是改进组织的执行度。它让你可以识别交付实践效率是什么状态，并且为如何改进提供了建议。