《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（四） 基础设施

《持续交付2.0 业务引领的DevOps精要》 要点摘录与总结（四） 基础设施

前面3篇文章介绍了持续交付的概念，实施持续交付三大板块中的组织机制和软件架构，而最后一个板块则是基础设施。基础设施部分是产品研发过程中最基础的工作。

这部分涵盖持续交付部署流水线及其工具设计原则，以及建立该流水线和优化所需关注的五大领域，分别是，业务需求协作流程、分支与配置管理、构建与环境管理、自动化测试管理，以及部署发布与监控管理。这部分内容相当细节，我并不想在此展开。此外，此部分和目前流行的DevOps有大量共同的内容。

部署流水线

为实现“谁构建，谁运营”，企业对于DevOps工具的建设，应该坚决从开发工程师的工作场景出发，为其构建强大的DevOps工具。不仅是生产环境的运维工具，而且是整个工作流程中的业务软件监控工程基础设施，它包括:

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

关于部署流水线，书中介绍了团队设计和使用部署流水线的原则，以及企业定制开发私有部署流水线工具链的设计要点和工具平台的能力要求。同时，还对四大基础支撑服务（编译构建服务、自动化测试服务、部署管理服务及基础环境服务）的逻辑组件进行了简要介绍。同时，还介绍了三大受信源（需求管理仓库、源代码仓库和制品库）之间的关联关系，以及对它们的管理要求。书中列举了几个不同的产品场景以及相应的部署流水线设计方案。

要想让部署流水线发挥最大的作用，研发团队需要尽可能遵守以下5条原则。

1. 任何软件包的取用皆须通过受控源，各角色之间禁止通过私有渠道（如电子邮件、即时通信工具等）获取。
2. 尽可能将一切流程自动化，并持续优化执行时间。
3. 每次提交都能够自动触发部署流水线。
4. 尽可能地少用手动触发方式。
5. 必须执行立即暂停原则（stop the line）

业务需求协作管理

业务需求协作管理一章具体阐述了产品版本周期准备期、交付期的重点内容，以及需求拆分带来的收益与随之而来的固定成本。如果无法降低这些固定成本，那么很难收获更大的价值。为了能够真正获得拆分带来的收益，在做需求拆分时就要尽可能遵守 INVEST原则（INV<EST）为了帮助读者更好地掌握拆分技术。书中总结了五大拆分技法，以及每个用户故事应该包含的7个组成部分。需求分析与管理的方法与工具有很多，用户故事地图、用户故事树和依赖关系图是较为常见的需求梳理工具。另外，书中还介绍了迭代过程中提高团队协作的工具与方法，包括共享时间表、回顾会议、持续集成和故事验证。

分支与配置管理

关于版本控制系统，如果不是有能力自定义自己代码仓库功能特性的大厂，个人强烈建议使用git，可以节省很多不必要的时间。如果还在使用svn等传统工具的团队，应尽快迁移到git中，git有提供非常方便的工具，方便svn用户做迁移，提交记录等信息都能比较好的迁移到git中。关于分支与配置管理，书中分析了各种分支策略的优点和挑战。目前的发展趋势是:软件发布频率越来越高，发布周期越来越短。硅谷顶级互联网公司多采用“主干开发”或高频的 GitHubFlow分支模式。一个企业到底选择哪种分支策略，需要根据团队的具体情况来决定。如果相关的配套条件（如软件架构、人员能力和工具平台的成熟度）不足，那么，盲目提高发布频率、缩短发布周期会造成不必要的损失。

“持续交付2.0”提倡鼓励持续集成的分支策略，因此，选择分支模式的原则有以下几条。

1. 分支越少越好，最好只有一条主干。
2. 分支生存周期越短越好，最好在3天以内。
3. 在业务允许的前提下，发布周期越短越好。

持续集成

本书还花了一章的篇幅讲述了持续集成的起源，团队实施持续集成的原则，介绍了持续集成6步提交法，以及快速建立团队持续集成实践的5个步骤。

需要注意的是，并不是安装部署了一个持续集成服务器，每天用它进行自动化编译打包，就说明团队正在使用持续集成实践。要真正做到持续集成，获得最大的持续集成收益，需要做到以下6点：

1. 主干开发，频率提交代码。
2. 每次提交都是完整有意义的工作。
3. 提交构建阶段在10分钟之内完成。
4. 提交构建失败后，立即修复；且其他人不得在修复之前提交代码。
5. 应该在10分钟内修复失败，否则回滚引起失败的代码。
6. 自动化构建成功后，团队对软件质量比较有信心。

自动化测试

对交付频率的要求越高，希望前置周期越短，自动化测试就越为重要。书中阐述了软件快速交付对自动化测试的4项基本要求，即快速、便捷、可信和及时。为了能够做到这4点，需要以分层的自动化测试金字塔为指导合理设计自动化测试的实施策略，从而增加自动化测试的收益。对自动化测试的实践管理来说，有5条重要原则：

1. 自动化测试用例运行次数越多，平均成本越低，收益就越大。
2. 自动化测试用例之间应该尽可能相互独立，互不影响。
3. 在质量有保障的前提下，自动化测试用例的数量越少越好。
4. 遗留代码的自动化测试编写应该从代码热区开始。
5. 自动化测试用例从测试金字塔的中间层开始补充，投入产出比最高。

软件配置管理

良好的软件配置管理是打造持续交付部署流水线、加速持续验证环的基础支撑。
本书讨论了软件配置管理的3个核心原则。

1. 对一切进行版本管理。
2. 共享唯一受信源。
3. 标准化与自动化。

可以用下面5个问题来验证检查你是否对一切都做了版本管理。

1. 产品源代码和测试代码是否放入了版本控制系统。
2. 软件应用的配置信息是否放入了版本控制系统。
3. 各类环境的系统配置是否放入了版本控制系统。
4. 自动化的构建和部署脚本是否放入了版本控制系统。
5. 软件包是否进行了版本管理。

另外，也可以用下面两个问题来检查软件配置管理是否做得足够好。

1. 只要从源代码仓库中检出产品源代码仓库，就可以一键式自动化地构建出完整软件包吗？
2. 在没有他人的帮助下，任何团队成员都可以一键式自动化搭建出一套应用软件系统，用于体验产品新功能吗？

低风险发布

本节讨论了如何在快速部署发布的情况下通过多种技术手段降低风险，如开关技术、数据库迁移技术、蓝绿部署、金丝雀（灰度）发布、抽象分支以及暗部署等。并且强调，即便没有使用开关，假如团队能够一直使用“小步完整的代码提交”策略，也可以比较容易地做到将缺陷快速回滚。
在一些业务场景下，我们的确无法直接高频地对外发布软件。但是，如果我们能够使用本章介绍的方法持续向预生产环境进行发布与部署，就可以尽早获得软件的相关质量反馈，从而减少正式发布后的风险。如果我们能够将每次发布的平均成本降低到足够低，那么将会直接改变团队的产品研发流程。

监测与决策

生产环境的监测范围包括3个层次，它们分别是“基础监测”“应用监测”和“业务监测“。尽管根据每一层次的特点，监测数据的采集方式有所不同，但是其处理流程基本一致。每个监测体系都包括数据收集、上报、整理、分析、展现与决策这几个环节。而对监测系统能力的衡量有3个维度，即数据的准确性、全面性与及时性。而抽样能力是提高监测灵活性、节约资源、提升用户体验的一种有效方法。
告警处理是研发人员和运维人员的常规工作但是，如果告警过多也会成为工作中的困扰，降低工作产出。因此，我们应该不断对告警点的设置与阈值计算方式进行优化，从而尽可能提升有效告警率。一旦告警成立，就需要启动问题处理流程。这个流程的最后两个环节“根因分析”和“根源解决”，是学习型组织的重要特征。
随着发布频率的提高，测试场景的复杂性提高，越来越多的团队开始找寻方法在生产环境上进行软件测试，这被称为测试活动右移。这种右移目前多发生于展示性软件，这类软件出错后的成本和影响相对较少。而对那些交易性软件或回收成本较高的软件来说，测试左移的趋势也比较明显。
右移的测试主要有两种类型。一是将测试用例在生产环境上自动运行。二是混沌工程，即通过注入“问题”，发现生产环境的潜在稳定性问题。 Netflix公司开发了一系列破坏性测试工具（Simian Army）可以促使工程师在软件设计与开发之时，就提前考虑各种失败的可能性，这被称为“为失败而设计（Design for Failure），从而提高生产环境的软件服务稳定性，为用户提供更好的服务体验。
当收集到真实的数据反馈以后，我们就可以用来印证我们在价值探索环中所提出的假设或目标，并通过主动关联分析，最终确定是继续进行更多的试验，还是重新再选择一条新的“路”。

后续章节

后续三个章节主要是实战案例的分析，分别代表不同类型的公司、不同大小的团队以及不同的软件产品特点。本书作者带领读者深入案例现场，了解当时状况，分析问题，并提出解决思路。由于是案例解析，此次不再摘录要点。