| 2022-04-12
引子
在半个月前，有一篇文章讨论了「用累积流图发现团队运行问题」。
在接下来的一个迭代中，团队执行了文中所指出的如下建议。
- 每个迭代少安排一些开发工作量。为了每个迭代都很平滑，开发人员也要参与 下一迭代的需求准备工作。
- 安排多个时间点进行质量验收，例如，每周三和周五。可组织PD，交付经理（如有必要，甚至是开发人 员）及时对已完成的需求进行质量验收。
- 发现 Bug ，尽早修复，尽早验收。
有同学问，为什么开发人员也要参加需求分析工作。我在《持续交付2.0》的第六章已经进行了阐述，如下图所示。
今天要说的是：即使我们执行了上述建议，成果如下。
后一迭代的累积流图如下：
在后一个迭代中，团队成员都积极遵守约定，尽早进行验收。
产品质量有所提高，迭代中的风险也较可控，迭代结束之前几天的加班情况有所减少。
但是，仍旧未达到我们的预期。
这是为什么呢？
通过参加团队的每日站会，认真听项目进展，以及每个成员说出他们每日遇到的阻塞问题，和讨论的解决方案，你就可以找到答案，即：环境准备和使用流程出了问题。
对话的模式
- 产品验收人员：昨天的XX需求没法验收，因为 M 模块（就是一个微服务）还没有部署到 SIT（System Integration Test，系统集成环境）
- 子领域 B ：你提的 Bug 并不是 Bug，是因为在 N 模块没有把最新代码更新到 UAT（User Accecptance Test，预生产环境T）
- 子领域 C ：我这部分已经开发完了，但是 子领域 D 的模块还没有准备好，所以无法验收。
- 子领域 D ：我开发的功能被外部团队的一个依赖项阻塞了，他们说，需要再等两天，他们才能把功能发布。
- 子领域 A ：我们的服务是在开发网，与生产网不通，无法直接使用子领域 D 提供的服务，需要换个新方案，已经讨论完了，正在开发中。
- 子领域 C ：你提的 Bug 是因为子领域的 P 模块发布了一个新版本，带进琮一个 Bug。
- 子领域 A ：你提的 Bug 并不是 Bug，因为原来的需求中，数据接口格式是 XXX，代码实现的时候发现那样走不通，所以现在的数据接口格式是 YYY，你改一下再试试。
「复杂的」微服务系统
这是一个采用了微服务架构的集成性平台软件。其系统逻辑结构如下图所示：
注：
上图并不包含类假于服务发现之类的公共标准依赖服务，以及更底层的数据库基础设施服务等。
图中的外部依赖全部为业务依赖，即：需要这些依赖服务提供业务输出。
- 主要有四个子领域协同。
- 六个子系统。
- 十多个微服务。
- 服务部署需要跨两个网络(开发网和生产网)。
- 每个子系统需要分别与其它软件平台集成。
「复杂的」测试环境
由于这个系统中的几个子应用分别部署于开发网和生产网， 所以，其系统的相关测试环境也需要横跨两个网络。
因为有一些外部依赖服务只能放在生产网，另一些外部依赖服务只能放在开发网， 所以，即便是以测试为目的建立的环境，也需要横跨两个网络。
如下图所示：
因环境准备工作量巨大而「凑合着向前推进」
项目初期，开发团队保持原有的旧式工作习惯，自己拉一个特性分支，并将这个分支上正在开发的代码部署到 SIT 环境中，进行开发调试。也有的团队成员使用 UAT 环境进行调试。
再加上前面提到的两个「复杂」，导致很难知道 SIT 和 UAT 环境的状态到底是什么样的？每个模块部署的是什么版本？
研发流程在一开始并没有对如何使用这些环境给出明确的流程定义与规范。
因为没有测试人员，没有人对各类环境负责。所以直到几个迭代后才发现，
大家都声称自己开发完了需求，但是需求却无法验收，或验收因各种原因导致验收不能过。
解决方案
既然知道了问题的根源，解决方案也非常明确，那就是建立标准的 SIT ， UAT 和 Prod 环境定义，并且将其变成自动化部署，并能够自动化地进行环境健康检查。
虽然解决方案明确，但由于各种各样的奇怪问题，这个环境梳理和准备工作花了各子团队两周的时间。
环境 Ready 的质量标准
什么是环境 Ready？当在这套环境（SIT 和 UAT ）中，各子领域系统部署后，不但可以一起运行起来，还能够顺利提供该集成平台应具备的能力，从而顺利完成每次代码变更后的验证工作。
由于 SIT 和 UAT 环境上既有人工验证，也有自动化测试在执行。所以，必须做好测试数据隔离，让两者不互相干扰才行。
自动化机制保障。这么多团队成员相互协同，代码变更频率不可能一致，所以，不可能花费时间去协调自动化测试用例何时执行。只能通过自动化机制来保障互不干扰。一旦出现冲突，也可以通过对自动化机制的修订来解决，而不是每次都需要人力介入协商解决。
短时间内自动化重建。当该环境因测试数据、代码变更被破坏以后，还能够在短时间内重新恢复。
只有这样，才有可能让「几十名开发工程师一起交付有质量保障的集成平台」。
若想一键创建（修复）SIT和UAT环境，可能还需要一段时间才能搞定。
结论
想要持续交付，任何产品在写第一行代码时，就应该考虑可测试性。
- 架构是否支持易测试；不只是生产环境上的可测试，而是各个环境的可测试性。
- 开发环境和测试环境如何可以自动化准备。
- 自动化测试所用的环境和手工测试所用的环境如何隔离管理。
- 服务于不同目标和不同人的各类测试环境如何隔离，避免相互干扰。
这就是《持续交付 2.0 》第五章「支持持续交付的软件系统架构」中所要求的「易测试性」。
所以，为了在正式上线之前在测试环境上的质量验证，你必须对软件系统架构设计进行一些修改。即保证不影响生产环境的安全运行，也不影响上线前的质量验证速度。
在做系统设计时，最后这一点很少被系统架构师所考虑，而它正是会直接影响软件交付速度的一个关键点。 它是达成「持续交付」状态的关键所在。