Blog

Blog

PHODAL

如何优化上线流程——Path to Production

可视化 Debug :Path to Production

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

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

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

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

为什么上线如此的长?

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

活动 描述
命名生命周期的阶段 环境映射到阶段
定义状态 状态是用户定义的值,例如“已通过”或“已存档”
添加门 门(gate)是一种机制,可确保项目无法部署到阶段/环境中,除非它们具有门指定状态

我们所熟知的 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 ?

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. 重复第二步,直到真正完成

如下是一个相应的示例:

活动 stage 1 stage 1 stage 1 stage 1 stage 1 stage 1 stage 1 stage 1 stage 1
Process 提交代码 运行 CI 部署到 Dev 环境 运行 E2E 测试 手动测试 部署到 ST/UAT 手动测试 上线申请 上线
People Dev Dev Dev Dev Dev 项目 QA 业务 QA 业务 QA PM
Tooling Git & GitHub Jenkins Jenkins Jenkins - Jenkins - 邮件 -
Artifacts 代码 持续集成结果 - 测试报告 测试报告 - 邮件结果 -

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

维护 Path to Production

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

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

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

Kanban

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

结论

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


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签