可视化优化上线流程：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？
方法论说了这么多，要做起来倒也不难——其实，我们所需要的是：知道有这么一个东西的存在。然后：
- 绘制出基本的四个部分，即 Process、People、Tooling、Artifacts
- 使用便利贴，将相应的流程整理出来
- 重复第二步，直到真正完成
如下是一个相应的示例：
4. 列出每个流程的时间长度和痛点，并看是否有办法解决
维护 Path to Production
Path to Production 是一份需要不断更新的文档，为些我们需要：
- 变更时，及时更新它
- 使用可视化出 Path to Production，如白板
- 上线时，可视化当前行走的步骤
对于复杂的项目来说，如一个项目可能有多个版本，那么它需要使用类似于看板的方式来维护。
在每个阶段，都由相应的人来跟踪和维护。当发生状态更新的时候，及时更新状态到看板上。
结论
可视化的文档是最好的文档。
网站声明：如果转载，请联系本站管理员。否则一切后果自行承担。
- 上周热门
- 银河麒麟添加网络打印机时，出现“client-error-not-possible”错误提示 1448
- 银河麒麟打印带有图像的文档时出错 1365
- 银河麒麟添加打印机时，出现“server-error-internal-error” 1151
- 统信桌面专业版【如何查询系统安装时间】 1073
- 统信操作系统各版本介绍 1070
- 统信桌面专业版【全盘安装UOS系统】介绍 1028
- 麒麟系统也能完整体验微信啦！ 984
- 统信【启动盘制作工具】使用介绍 627
- 统信桌面专业版【一个U盘做多个系统启动盘】的方法 575
- 信刻全自动档案蓝光光盘检测一体机 483
- 本周热议
- 我的信创开放社区兼职赚钱历程 40
- 今天你签到了吗？ 27
- 信创开放社区邀请他人注册的具体步骤如下 15
- 如何玩转信创开放社区—从小白进阶到专家 15
- 方德桌面操作系统 14
- 我有15积分有什么用? 13
- 用抖音玩法闯信创开放社区——用平台宣传企业产品服务 13
- 如何让你先人一步获得悬赏问题信息？（创作者必看） 12
- 2024中国信创产业发展大会暨中国信息科技创新与应用博览会 9
- 中央国家机关政府采购中心：应当将CPU、操作系统符合安全可靠测评要求纳入采购需求 8
