团队或应用程序规模是否会影响发布过程？这得看情况。让我们想象一下一家只有一个小团队的初创公司。在这种情况下，团队通常会制作一个功能，然后发布它。现在，让我们想象一个大型项目，例如一个银行应用程序，有许多团队在处理它。 在这种情况下，可能应该有一个流程、发布周期，也许还应该有一些官僚机构。没有它，就会出现混乱。 那么，什么时候可以明确为您的应用程序设置这样的流程呢？ 在本文中，我将分享我为 Dodo Pizza 应用程序（Android 和 iOS）实施 Release Train 的经验，以及我们团队实施 Release Train 时遇到的问题。 如果您是一个快速增长的 Android 或 iOS 项目的 Team Lead/Tech Lead，并且您尚未管理发布流程，我希望我们的经验能够对您有所帮助。 过去是怎样的 2021 年，我们已经在团队中使用基于主干的开发 (TBD) 方法。我们通过功能切换、分解任务以及运行单元和 UI 测试来覆盖代码。我们的功能分支寿命不长，而且我们有 CI 工作。 发布过程非常简单：谁准备好推出其功能，就推出它。 理想场景 我们的分支工作流程大致如下。几个团队（灰色、蓝色、橙色和绿色）致力于不同的功能。由于我们是根据 TBD 进行工作的，因此每个功能都可以通过多个连续的分支来实现。 例如，灰色团队用 4 个步骤制作了他们的功能，蓝色和橙色团队用 1 个步骤制作了他们的功能，绿色团队用了 2 个步骤制作了他们的功能。 当团队完成一项功能后，他们可以推出一个版本。例如，如果蓝队完成了一项功能，他们可以发布版本。然后，橙色团队将完成一个功能并发布另一个版本。 正如当时看来，我们拥有完美的流程。在某种程度上它运作良好，但所有美好的事物都会结束。 出了问题：艰难、拥挤、不可预测 长毛象 我们遇到的第一个问题是版本开始积累大量功能并变得太大。 团队并不总是希望立即发布他们的功能。发布和回归过程非常耗时，需要 3-4 天。因此，如果您的功能很小且不紧急，您并不总是能够自己发布它，因为其他团队可能很快就会发布它，并且它会包含在该版本中。大致看起来是这样的： 这是一个相当脆弱的安排，尤其是当团队数量开始增长时。许多团队开发了许多小功能，每个新版本中的新代码总量变得巨大。当有人要发布他们的大功能时，他们必须同时发布一整只 。 猛犸象 猛犸象释放导致： 延迟回归； 回归错误的风险较高； 在生产中出现错误的风险更高。 我们需要做到这一点，以便即使示例中的蓝色和橙色团队不想发布，发布也会以某种方式完成。 瓶颈 每个团队都是独一无二的，每个功能都是不同的。有时，事情发生的方式是几个团队大约在同一时间完成他们的功能。在这种情况下，有很多“等我，我明天早上合并它，我保证！”四处走动。 最终，这样的瓶颈导致了： 释放后变成猛犸象； 延迟发布会对发布团队的计划产生负面影响，尤其是在满足其他人的需求的情况下。 我们需要做出两个关键的改变： 发布团队不需要等待任何人； 其他每个团队都应该知道下一个版本预计何时发布。 缺乏可预测性 想象一下，蓝色团队制作了一个小功能，并期望橙色团队很快发布它。但出了点问题，橙色团队由于自身的一些问题也没有推出该版本。 结果，蓝色团队告诉业务部门，该功能很快就会投入生产，但事实证明还不够快。因此，无法预测该功能何时投入生产。 这并不意味着蓝队不负责任。如果他们有一个超级重要或紧急的功能，那么他们当然会自己发布。但在其他情况下，无法准确判断该功能何时可供用户使用。 正如您所猜测的，我们经常遇到此类问题。我们需要能够准确地判断客户何时可以在生产中获得某个功能，无论其大小或紧急程度如何。所有这三个问题（庞大的版本、瓶颈和缺乏可预测性）都是密切相关且相辅相成的。 然而，其中最基本和最重要的可能是缺乏可预测性。它会产生其他问题。 发布列车 我们已经受够了；是时候做出改变了。 应该可以帮助我们做到这一点。 发布列车 术语“发布列车”有不同的含义： ，或管理发布过程的 。在这里，我们要谈谈预定的发布过程。 计划的发布过程 专门团队 我喜欢 Martin Fowler 在“ ”一文中描述的 Release Train 的方式，以及 给出的定义（也许它也属于 Martin）。 管理源代码分支的模式 Thoughtworks 在其技术雷达中 这就是我们为自己定义 Release Train 的方式： 发布列车是协调团队之间发布的过程。所有版本都按固定的时间表进行，无论功能是否准备就绪。火车不等人。如果迟到了，就得等下一班了。 让我们用几个使用颜色编码的团队的例子来分解它。 解决猛犸象问题 发布列车按计划进行，并不取决于谁将哪些内容合并到主分支中。在下面的示例中，将发布蓝队和橙队的功能。剩下的就等下一趟车了。我们可以再等一段时间，但那样我们就会得到一头猛犸象。 解决瓶颈 同时，发布列车可以帮助我们更高效地规划工作。假设蓝队原本计划稍后完成一个功能。但由于每个人都知道发布日期，因此他们可以稍微重新安排计划以尽早完成该功能。 或者，相反，他们可以意识到他们肯定不会准时搭乘下一趟火车，因此他们可以安全地完成该功能，因为他们知道整个时间表。 在下面的示例中，蓝色团队想要发布并在发布之前合并所有更改。否则，可能会出现瓶颈。 最重要的是，Release Train 。 通过设计为我们提供了可预测性 这些例子对某些人来说似乎是显而易见的，但我们在问题出现时就解决了它们。当发布没有问题时，我们就不再使用 Release Train。当问题不断积累时，我们意识到时机已到。 如何在您的团队中实施发布训练 我们做的第一件事是编写 。 RFC 既指流程本身，也指 在开始项目之前使用的设计文档。有些专门使用 RFC，有些使用 ADR，有些只是用更通用的术语“设计文档”来称呼它们。 RFC 许多公司 在 Dodo Engineering，我们同时使用 RFC 和 ADR。 我们的 RFC 流程如下所示： 我们起草了一份RFC文件； 我们进行了小组讨论，收集意见，进行调整； 然后将 RFC 传达给更广泛的群体； 然后我们实施了它； 之后，我们收集反馈、跟踪指标并评估结果。 我们的发布系列的 RFC 文档的结构如下： 发布序列流程的描述； 涉及哪些团队，他们正在做什么； 日程安排是什么； 指标。 在起草RFC时，我们参考了其他公司的经验： 天空扫描仪 声云 蒙佐 Facebook 第一次实施 首先，我们提出了这个过程： 每周发布； 周三早上创建一个发布分支； 完成回归，并在周五将应用程序发送以供审核； 周一开始发布该版本。 发布团队： 来自其中一个功能团队的 1 名 iOS 和 1 名 Android 开发人员； 质量保证工程师2名。 周三创建一个新的发布分支； 提前一个季度制定时间表，指示每个团队何时轮到发布。一个季度后聚在一起并延长日程。 从原理上讲，我们的发布列车如下所示： 一切并不顺利 一个月后，我发现虽然第一次体验感觉很棒， 每周进行一次回归并在周五之前完成确实很困难； 没有时间进行修补程序，但它们有时会发生。 2021 年，我们的回归测试平均需要 3-4 天。 2022 年，我们设法将其缩短到 2-3 天，但有时会超出这个时间范围。我们继续通过 e2e 测试覆盖回归案例，但尚未达到 100% 的覆盖率。我们在每个平台上的回归案例覆盖率分别约为 70% 和 60%。 由此得出的结论是， 每周运行一个发布周期可能会很不舒服。 只要回归测试需要几天时间才能完成，那么 最终答案 我们最终转向了两周的发布周期，发布列车现在看起来像这样： 每两周发布一次； 周三早上创建一个发布分支； 回归，并在周五将应用程序发送以供审核； 周一开始发布该版本。 发布团队： 来自其中一个功能团队的 1 名 iOS 和 1 名 Android 开发人员； 质量保证工程师2名。 提前一个季度制定时间表，指示每个团队何时轮到发布。一个季度后，聚在一起并延长日程。 逐步推出版本； 如果需要的话，现在我们有时间的话就进行修补程序； 一周后的周三，创建一个新的发布分支。 如果一切按计划进行，流程如下： 这一切看起来就像每周一个周期，除了有足够的时间进行潜在的修补程序。这是扩展回归测试的样子： 也没什么大不了的；甚至还有时间进行修补程序。 新流程如何影响可预测性？ 我们的主要目标是 。它可以分为两部分： 提高可预测性 申请什么时候发布； 我的功能将进入哪个版本？ 我们回答了“什么时候发布？”的问题。通过实施发布列车流程。现在，每个团队都能够回答“我的功能最终会在哪个版本中发布？”的问题。他们在计划和评估功能时独立地进行。 以前，不可能确定，因为另一个团队可能会或可能不会发布该版本。现在，一切都取决于该团队自己的规划。 为了进一步证实这一点，我们对移动开发人员、质量检查和产品经理进行了调查，并提出了其他问题： 下一个版本什么时候发布？ （100%回答了这个问题）。 Release Train 是否帮助您规划团队合作？ （75% 的回答是肯定的，但有些人甚至在没有发布列车的情况下也完美地预测了他们的工作）。 Release Train 还帮助我们解决了代码冻结和发布冻结的问题。除了除夕夜（例如 9 月 1 日和一些节假日）之外，我们还经历了几个这样的日子。现在，有了发布列车，我们不必通过创建发布分支、回归测试等来适应这些日期。按计划发布工作；我们稍后会在商店里打开它们。 对指标的影响 除了解决问题之外，我们还测量指标。我们来看看主要的。 交货时间 我们衡量的第一个重要指标是 。 发布的交付时间承诺 这就是图表的样子。我用箭头标记了我们开始发布列车流程的时间点。 该图显示交货时间下降到六天左右。六天是长还是短？ 谷歌基准测试 有 ，但主要用于后端。根据其规模，他们将其分为以下几类： Google 针对此指标的基准 精英：不到一个小时 高：1小时至1周 中期：1周至6个月 低：6个月或以上 我认为，对于标准移动应用程序，交付周期理想情况下应为发布周期长度的一半。这相当于每天合并一个任务到主分支中。也就是说， 。 如果发布周期是 14 天，那么 Lead Time 的目标应该是 7 天 每次回归的错误 我们跟踪的另一个指标是每次回归的错误数量。它描述了候选版本的稳定性。如果上一个版本是很久以前的版本，那么我们可能创建了很多可能包含大量错误的新代码，并且我们可能会花费更多时间进行回归和修复。 在某一时刻，这个指标减少到了三个错误。具体数字并不那么重要，但总体而言，您可以看到趋势有所下降。 更多指标 我将简要讨论发布系列中还监控了哪些指标。 无崩溃。我们始终关注这个指标。有一种假设认为，由于我们试图将回归纳入更严格的时间范围，因此它会下降。还好，没有发生掉落。 我们想知道频繁（每周）发布是否会对客户流失和删除应用程序产生影响。结果，我们没有检测到任何影响。 实施、改进 我们喜欢当前的流程，因为我们认为它已经实现了目标。我们也知道如何进一步改进它： 我们继续致力于自动化回归，使其更简单、更快。 到目前为止，我们已经省略了工作自动化的部分（分支脚本），但这也将是未来的一个重要增长点。 我们的应用程序在 20 个国家/地区运行，我们需要将应用程序翻译成多种不同的语言。有一个内部服务可以实现此目的，但开发人员仍然必须在发布之前手动参与此过程。自动化这个过程可能会进一步改善发布周期。 概括 虽然我们规模相对较小，但我们不需要发布列车。当我们面临无法预测版本、版本大小和数量的事实时，我们决定实施版本列车。起初，我们尝试了每周发布周期，但由于回归耗时，我们不得不切换到两周发布周期。从那时起我们就一直这样生活。 现在，我们对发布有了可预测性，并且指标显示出积极的动态。我们计划通过 e2e 测试增加回归案例的覆盖范围，自动化分支机构的工作流程，并优化翻译流程。 我希望这篇文章和我们的经验会对您有所帮助，特别是如果您已经遇到过类似的问题并且它们让您思考发布过程。 非常感谢您阅读我的文章。我希望你喜欢它。如果您有任何问题或建议，请在评论中给我留言，我一定会阅读！ 和 。通常，我会发布有关 Android 开发和软件工程的一般内容。 在推特上关注我 也发布 在这里
