团队或应用程序规模是否会影响发布过程？这得看情况。让我们想象一下一家只有一个小团队的初创公司。在这种情况下，团队通常会制作一个功能，然后发布它。现在，让我们想象一个大型项目，例如一个银行应用程序，有许多团队在处理它。 在这种情况下，可能应该有一个流程、发布周期，也许还应该有一些官僚机构。没有它，就会出现混乱。 那么，什么时候可以明确为您的应用程序设置这样的流程呢？ 在本文中，我将分享我为 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 开发和软件工程的一般内容。 在推特上关注我 也发布 在这里

This story contains new, firsthand information uncovered by the writer.

Read My Stories

該音頻是用故事的原始語言製作的！

Release Train解决了移动应用开发中的哪些问题？

About Author

註釋

標籤

这篇文章刊登在

Related Stories

架构师指南：构建 AI/ML 数据湖参考架构

成功云迁移的完整指南：策略和最佳实践

比特币 UTXO 模型，为独特的生态系统提供动力

扬帆起航：利用数据湖开发生产级 RAG 应用程序

架构师指南：构建 AI/ML 数据湖参考架构

成功云迁移的完整指南：策略和最佳实践

比特币 UTXO 模型，为独特的生态系统提供动力

扬帆起航：利用数据湖开发生产级 RAG 应用程序

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps