团队或应用程序规模是否会影响发布过程？这得看情况。让我们想象一下一家只有一个小团队的初创公司。在这种情况下，团队通常会制作一个功能，然后发布它。现在，让我们想象一个大型项目，例如一个银行应用程序，有许多团队在处理它。

在这种情况下，可能应该有一个流程、发布周期，也许还应该有一些官僚机构。没有它，就会出现混乱。

那么，什么时候可以明确为您的应用程序设置这样的流程呢？

在本文中，我将分享我为 Dodo Pizza 应用程序（Android 和 iOS）实施 Release Train 的经验，以及我们团队实施 Release Train 时遇到的问题。

如果您是一个快速增长的 Android 或 iOS 项目的 Team Lead/Tech Lead，并且您尚未管理发布流程，我希望我们的经验能够对您有所帮助。

过去是怎样的

2021 年，我们已经在团队中使用基于主干的开发 (TBD) 方法。我们通过功能切换、分解任务以及运行单元和 UI 测试来覆盖代码。我们的功能分支寿命不长，而且我们有 CI 工作。

发布过程非常简单：谁准备好推出其功能，就推出它。

理想场景

我们的分支工作流程大致如下。几个团队（灰色、蓝色、橙色和绿色）致力于不同的功能。由于我们是根据 TBD 进行工作的，因此每个功能都可以通过多个连续的分支来实现。

例如，灰色团队用 4 个步骤制作了他们的功能，蓝色和橙色团队用 1 个步骤制作了他们的功能，绿色团队用了 2 个步骤制作了他们的功能。

当团队完成一项功能后，他们可以推出一个版本。例如，如果蓝队完成了一项功能，他们可以发布版本。然后，橙色团队将完成一个功能并发布另一个版本。

正如当时看来，我们拥有完美的流程。在某种程度上它运作良好，但所有美好的事物都会结束。

出了问题：艰难、拥挤、不可预测

长毛象

我们遇到的第一个问题是版本开始积累大量功能并变得太大。

团队并不总是希望立即发布他们的功能。发布和回归过程非常耗时，需要 3-4 天。因此，如果您的功能很小且不紧急，您并不总是能够自己发布它，因为其他团队可能很快就会发布它，并且它会包含在该版本中。大致看起来是这样的：

这是一个相当脆弱的安排，尤其是当团队数量开始增长时。许多团队开发了许多小功能，每个新版本中的新代码总量变得巨大。当有人要发布他们的大功能时，他们必须同时发布一整只猛犸象。

猛犸象释放导致：

• 延迟回归；

• 回归错误的风险较高；

• 在生产中出现错误的风险更高。

我们需要做到这一点，以便即使示例中的蓝色和橙色团队不想发布，发布也会以某种方式完成。

瓶颈

每个团队都是独一无二的，每个功能都是不同的。有时，事情发生的方式是几个团队大约在同一时间完成他们的功能。在这种情况下，有很多“等我，我明天早上合并它，我保证！”四处走动。

最终，这样的瓶颈导致了：

• 释放后变成猛犸象；

• 延迟发布会对发布团队的计划产生负面影响，尤其是在满足其他人的需求的情况下。

我们需要做出两个关键的改变：

1. 发布团队不需要等待任何人；

   
   

2. 其他每个团队都应该知道下一个版本预计何时发布。

缺乏可预测性

想象一下，蓝色团队制作了一个小功能，并期望橙色团队很快发布它。但出了点问题，橙色团队由于自身的一些问题也没有推出该版本。

结果，蓝色团队告诉业务部门，该功能很快就会投入生产，但事实证明还不够快。因此，无法预测该功能何时投入生产。

这并不意味着蓝队不负责任。如果他们有一个超级重要或紧急的功能，那么他们当然会自己发布。但在其他情况下，无法准确判断该功能何时可供用户使用。

正如您所猜测的，我们经常遇到此类问题。我们需要能够准确地判断客户何时可以在生产中获得某个功能，无论其大小或紧急程度如何。所有这三个问题（庞大的版本、瓶颈和缺乏可预测性）都是密切相关且相辅相成的。

然而，其中最基本和最重要的可能是缺乏可预测性。它会产生其他问题。

发布列车

我们已经受够了；是时候做出改变了。发布列车应该可以帮助我们做到这一点。

术语“发布列车”有不同的含义：计划的发布过程，或管理发布过程的专门团队。在这里，我们要谈谈预定的发布过程。

我喜欢 Martin Fowler 在“管理源代码分支的模式”一文中描述的 Release Train 的方式，以及Thoughtworks 在其技术雷达中给出的定义（也许它也属于 Martin）。

这就是我们为自己定义 Release Train 的方式：

发布列车是协调团队之间发布的过程。所有版本都按固定的时间表进行，无论功能是否准备就绪。火车不等人。如果迟到了，就得等下一班了。

让我们用几个使用颜色编码的团队的例子来分解它。

解决猛犸象问题

发布列车按计划进行，并不取决于谁将哪些内容合并到主分支中。在下面的示例中，将发布蓝队和橙队的功能。剩下的就等下一趟车了。我们可以再等一段时间，但那样我们就会得到一头猛犸象。

解决瓶颈

同时，发布列车可以帮助我们更高效地规划工作。假设蓝队原本计划稍后完成一个功能。但由于每个人都知道发布日期，因此他们可以稍微重新安排计划以尽早完成该功能。

或者，相反，他们可以意识到他们肯定不会准时搭乘下一趟火车，因此他们可以安全地完成该功能，因为他们知道整个时间表。

在下面的示例中，蓝色团队想要发布并在发布之前合并所有更改。否则，可能会出现瓶颈。

最重要的是，Release Train通过设计为我们提供了可预测性。

这些例子对某些人来说似乎是显而易见的，但我们在问题出现时就解决了它们。当发布没有问题时，我们就不再使用 Release Train。当问题不断积累时，我们意识到时机已到。

如何在您的团队中实施发布训练

我们做的第一件事是编写RFC 。 RFC 既指流程本身，也指许多公司在开始项目之前使用的设计文档。有些专门使用 RFC，有些使用 ADR，有些只是用更通用的术语“设计文档”来称呼它们。

在 Dodo Engineering，我们同时使用 RFC 和 ADR。

我们的 RFC 流程如下所示：

1. 我们起草了一份RFC文件；

   
   

2. 我们进行了小组讨论，收集意见，进行调整；

   
   

3. 然后将 RFC 传达给更广泛的群体；

   
   

4. 然后我们实施了它；

   
   

5. 之后，我们收集反馈、跟踪指标并评估结果。

我们的发布系列的 RFC 文档的结构如下：

• 发布序列流程的描述；

• 涉及哪些团队，他们正在做什么；

• 日程安排是什么；

• 指标。

在起草RFC时，我们参考了其他公司的经验：

• 天空扫描仪
• 声云
• 蒙佐
• Facebook

第一次实施

首先，我们提出了这个过程：

• 每周发布；

• 周三早上创建一个发布分支；

• 完成回归，并在周五将应用程序发送以供审核；

• 周一开始发布该版本。

• 发布团队：

  • 来自其中一个功能团队的 1 名 iOS 和 1 名 Android 开发人员；

  • 质量保证工程师2名。

    
    

• 周三创建一个新的发布分支；

• 提前一个季度制定时间表，指示每个团队何时轮到发布。一个季度后聚在一起并延长日程。

从原理上讲，我们的发布列车如下所示：

一切并不顺利

一个月后，我发现虽然第一次体验感觉很棒，

• 每周进行一次回归并在周五之前完成确实很困难；

• 没有时间进行修补程序，但它们有时会发生。

2021 年，我们的回归测试平均需要 3-4 天。 2022 年，我们设法将其缩短到 2-3 天，但有时会超出这个时间范围。我们继续通过 e2e 测试覆盖回归案例，但尚未达到 100% 的覆盖率。我们在每个平台上的回归案例覆盖率分别约为 70% 和 60%。

由此得出的结论是，只要回归测试需要几天时间才能完成，那么每周运行一个发布周期可能会很不舒服。

最终答案

我们最终转向了两周的发布周期，发布列车现在看起来像这样：

• 每两周发布一次；
• 周三早上创建一个发布分支；
• 回归，并在周五将应用程序发送以供审核；
• 周一开始发布该版本。

• 发布团队：

  • 来自其中一个功能团队的 1 名 iOS 和 1 名 Android 开发人员；

  • 质量保证工程师2名。

    
    

• 提前一个季度制定时间表，指示每个团队何时轮到发布。一个季度后，聚在一起并延长日程。
• 逐步推出版本；
• 如果需要的话，现在我们有时间的话就进行修补程序；
• 一周后的周三，创建一个新的发布分支。

如果一切按计划进行，流程如下：

这一切看起来就像每周一个周期，除了有足够的时间进行潜在的修补程序。这是扩展回归测试的样子：

也没什么大不了的；甚至还有时间进行修补程序。

新流程如何影响可预测性？

我们的主要目标是提高可预测性。它可以分为两部分：

1. 申请什么时候发布；
2. 我的功能将进入哪个版本？

我们回答了“什么时候发布？”的问题。通过实施发布列车流程。现在，每个团队都能够回答“我的功能最终会在哪个版本中发布？”的问题。他们在计划和评估功能时独立地进行。

以前，不可能确定，因为另一个团队可能会或可能不会发布该版本。现在，一切都取决于该团队自己的规划。

为了进一步证实这一点，我们对移动开发人员、质量检查和产品经理进行了调查，并提出了其他问题：

• 下一个版本什么时候发布？ （100%回答了这个问题）。

• Release Train 是否帮助您规划团队合作？ （75% 的回答是肯定的，但有些人甚至在没有发布列车的情况下也完美地预测了他们的工作）。

Release Train 还帮助我们解决了代码冻结和发布冻结的问题。除了除夕夜（例如 9 月 1 日和一些节假日）之外，我们还经历了几个这样的日子。现在，有了发布列车，我们不必通过创建发布分支、回归测试等来适应这些日期。按计划发布工作；我们稍后会在商店里打开它们。

对指标的影响

除了解决问题之外，我们还测量指标。我们来看看主要的。

交货时间

我们衡量的第一个重要指标是发布的交付时间承诺。

这就是图表的样子。我用箭头标记了我们开始发布列车流程的时间点。

该图显示交货时间下降到六天左右。六天是长还是短？

谷歌基准测试

有Google 针对此指标的基准，但主要用于后端。根据其规模，他们将其分为以下几类：

• 精英：不到一个小时
• 高：1小时至1周
• 中期：1周至6个月
• 低：6个月或以上

我认为，对于标准移动应用程序，交付周期理想情况下应为发布周期长度的一半。这相当于每天合并一个任务到主分支中。也就是说，如果发布周期是 14 天，那么 Lead Time 的目标应该是 7 天。

每次回归的错误

我们跟踪的另一个指标是每次回归的错误数量。它描述了候选版本的稳定性。如果上一个版本是很久以前的版本，那么我们可能创建了很多可能包含大量错误的新代码，并且我们可能会花费更多时间进行回归和修复。

在某一时刻，这个指标减少到了三个错误。具体数字并不那么重要，但总体而言，您可以看到趋势有所下降。

更多指标

我将简要讨论发布系列中还监控了哪些指标。

• 无崩溃。我们始终关注这个指标。有一种假设认为，由于我们试图将回归纳入更严格的时间范围，因此它会下降。还好，没有发生掉落。

• 我们想知道频繁（每周）发布是否会对客户流失和删除应用程序产生影响。结果，我们没有检测到任何影响。

实施、改进

我们喜欢当前的流程，因为我们认为它已经实现了目标。我们也知道如何进一步改进它：

• 我们继续致力于自动化回归，使其更简单、更快。

• 到目前为止，我们已经省略了工作自动化的部分（分支脚本），但这也将是未来的一个重要增长点。

• 我们的应用程序在 20 个国家/地区运行，我们需要将应用程序翻译成多种不同的语言。有一个内部服务可以实现此目的，但开发人员仍然必须在发布之前手动参与此过程。自动化这个过程可能会进一步改善发布周期。

概括

虽然我们规模相对较小，但我们不需要发布列车。当我们面临无法预测版本、版本大小和数量的事实时，我们决定实施版本列车。起初，我们尝试了每周发布周期，但由于回归耗时，我们不得不切换到两周发布周期。从那时起我们就一直这样生活。

现在，我们对发布有了可预测性，并且指标显示出积极的动态。我们计划通过 e2e 测试增加回归案例的覆盖范围，自动化分支机构的工作流程，并优化翻译流程。

我希望这篇文章和我们的经验会对您有所帮助，特别是如果您已经遇到过类似的问题并且它们让您思考发布过程。

非常感谢您阅读我的文章。我希望你喜欢它。如果您有任何问题或建议，请在评论中给我留言，我一定会阅读！

和在推特上关注我。通常，我会发布有关 Android 开发和软件工程的一般内容。

也发布在这里