可视化 Debug ：Path to Production

在你们公司里，当你们想上线一个新的功能时，需要怎么做才能上线到生产环境？若是没有 Path to Production 的相关知识，那么，我的答案就是这样的：

• Local。在本地完成 A 功能的开发，提交代码到 Git 服务器上
• Dev。CI 检测 Git 服务器的变化，运行构建。构建成功后，自动部署。
• QA。在 Dev 环境完成联调后，部署到 QA 环境进行详尽测试。
• ST/UAT。在完成这次上线的功能后，在 ST/UAT 环境上，进行上线前的验收测试。
• Production。审批，上线。

看上去没有问题，这是一份相关合适的“标准” 答案，然而它可能一点儿用处也没有——因为大家都是这么做的。可是同样一个功能，从开发到上线，有的项目只需要几个小时，有的项目却需要几周。隔壁的小公司，和我们的流程完全一样啊，为什么它们的上线如此的快。为什么呢？无非就是流程。

于是乎，若以这种方式来定义我们的上线流程，怕就不再是那么合理了。我们的流程中，省略了相当多的东西。

为什么上线如此的长？

不同的公司，不同的组织，不同的团队，对于 to Production 都有自己所需要的流程以及规范。在各自的公司和组织里，它们拥有各自对于软件的生命周期的定义。它们起源于一些基本的定义，诸如：

我们所熟知的 local -> dev -> qa -> st/uat -> prod 便是这样的几个不同的关卡，每个关卡都由不同的人来守卫。这个守卫的人，便是对这次行为负责的人。在向 QA 环境部署时，需要 Dev 对质量负责；在向 ST 环境部署时，需要 QA 对之前的内容负责；在部署到生产环境时，需要所有的人对它负责。

正是由于不同的公司，对于这些关卡规范的不同，导致了“同样的代码” 在不同的公司里会有不同的上线周期。如同样是一个部署到 UAT 环境，在 A 项目里，可以由开发人员直接触发，而在 B 项目里，则需要先拥有测试用例等，才能部署到 UAT 环境。若是情况紧急（紧急修复一个 bug），还需要相关的项目的负责人，开上个会议，才能部署到 UAT 环境。这样的情形，也适用于上线过程，需要一级一级的审批，才能进入最后的上线流程。

除去软件质量的相关原因，我们会发现相关的上线流程也特别的长。可为什么流程会这么长呢，到底是什么因素导致了每次上线的周期特别长呢？所以，我们就需要去 Debug 为什么需要这么长的时间。在那之前，让我们先看看一张图：

它便是上线流程的一种可视化形式： Path to Production ，其用途在于：

• 找到项目上线的痛点和瓶颈，如某个审批人经常不在，审批的时间太长
• 拥有一份完整上线文档，帮助团队成员了解项目。
• 有针对性地优化上线过程中的问题。
• ……

那么，问题来了：

什么是 Path to Production ？

Path to Production，来源于精益，旨在通过可视化的方式来展示项目的上线流程，并优化过程中的瓶颈问题。它类似于我们使用 CI（持续集成）时的 Pipeline。传统的 Pipeline 的 gate 可以通过代码定义一些标准，由测试不能挂，测试覆盖率不能低于多少，打包不能失败等等。而这些 Pipeline 则是分别由开发人员、测试人员、运维人员、项目负责人等等来负责把控的。

对应的，在这个过程中：流程（Process）、人（People）、工具（Tooling）、产物（Artifacts） 都是我们的关注点：

• Process，即上线需要多少流程。从提交代码开始，运行持续集成，部署到 Dev 环境等等。
• People，即过程中需要哪些人来参与。如需要开发人员提交代码，需要测试人员进行 QA 环境部署，需要项目经理等高级领导进行上线审批等。
• Tooling，即需要使用哪些工具来完成上线。如托管代码的 Git 服务器，运行构建的持续集成工具，提交上线申请的相关工具等等。
• Artifacts，即过程中产出的产物。如生成的应用包，QA 生成的测试报告等等。

随后，我们从相关的流程中，梳理出每个部分（流程）的持续时间、痛点，来查找优化空间。

如何做 Path to Production？

方法论说了这么多，要做起来倒也不难——其实，我们所需要的是：知道有这么一个东西的存在。然后：

1. 绘制出基本的四个部分，即 Process、People、Tooling、Artifacts
2. 使用便利贴，将相应的流程整理出来
3. 重复第二步，直到真正完成

如下是一个相应的示例：

4.列出每个流程的时间长度和痛点，并看是否有办法解决

维护 Path to Production

Path to Production 是一份需要不断更新的文档，为些我们需要：

• 变更时，及时更新它
• 使用可视化出 Path to Production，如白板
• 上线时，可视化当前行走的步骤

对于复杂的项目来说，如一个项目可能有多个版本，那么它需要使用类似于看板的方式来维护。

在每个阶段，都由相应的人来跟踪和维护。当发生状态更新的时候，及时更新状态到看板上。

结论

可视化的文档是最好的文档。