关于 Scrum 交付的思考：超越冲刺末的发布
在敏捷开发中，人们常常期望在每个冲刺结束后立即发布软件。这意味着在成功向客户演示后，紧接着将代码部署到生产环境。然而，这种看似理所当然的期望是否真的合理呢？特别是当考虑到发布前或同时需要进行的各项活动时，我们或许应该重新审视这种观点。
- 冲刺期间开发并完成所有用户故事。虽然有些故事可能较早完成，但大多数情况下，它们会在冲刺结束前不久完成。甚至在演示之后，可能还会存在一些遗留问题需要处理。
- 对冲刺中的所有内容进行详尽的测试，以确保即将发布的代码质量足够高，可以投入生产。
- 在发布前，及时修复测试中发现的缺陷。
- 确保部署管道是最新的，并且管道本身可以可靠运行。
- 在所有相关环境中执行部署管道，从而更新代码和数据到最新状态。
- 编写发布说明，并向客户沟通本次发布带来的影响和具体变更。
- 如果涉及多个团队，需要与其他并行开发的 Scrum 团队同步，以确保相关内容同时发布。不应有任何遗漏，以确保发布内容按预期运行。
- 最后，完成所有的 Scrum 例行活动。不仅要完成当前冲刺的活动，还要规划下个冲刺的目标（例如，用户故事细化会议）。
现在，假设一个冲刺的周期为两周。发布活动本身需要时间和人力才能完成，而且不能占用太多时间。因为冲刺的最后一天紧接着下一个冲刺的第一天，一个新的循环即将开始。在这种情况下，每次冲刺结束后都进行发布的期望似乎是否过于理想化了？
发布内容处理的挑战
理论上，如果所有流程都是自动化的，那么在每个冲刺结束时，只需一键就可以将最新代码版本部署到生产环境。但现实情况是，很少有 Scrum 团队能够达到如此完美的状态。也许一些小企业能够做到这一点，但在大型企业中，Scrum 团队通常无法达到如此高的成熟度。相反，发布过程往往伴随着耗时的活动，这些活动会影响到后续的冲刺，从而影响到整个团队的节奏和效率。因此，发布往往被视为一种压力巨大的行为，团队成员通常并不愿意经历。
因此，我一直在寻找处理发布的最佳方案。最终的结论是，将每个冲刺都视为“发布冲刺”。
为下一个版本创建独立的代码分支
在 Git 存储库中，可以使用单独的分支来管理发布内容。当然，解决这个问题有很多方法，而且很多方法都能成功。为了简化说明，我将介绍一种比较直接的方法，并阐述其影响。
为了尽可能减少对正在进行的开发活动的影响，最重要的是将下一个版本的内容隔离到单独的分支中。我们将此分支称为“发布分支”。通过这种方式，我们可以解决以下问题：
- 开发团队可以继续进行开发活动，并将新的用户故事合并到主分支中，而不会受到干扰。
- 发布内容不会受到团队意外代码更改的影响。
- 可以在隔离的环境中执行测试活动。 只需要包含解决测试问题所需的变更。
- 由于发布管道只会将发布分支中的内容部署到生产环境中，因此我们可以清晰地控制要发布的内容。对 Git 分支的意外提交不会破坏已经测试过的代码。
因此，通过将下一个版本的内容放在单独的分支中，并使其达到稳定状态，我们可以为发布做好更充分的准备。
规划定期发布，使其更有效
我放弃了在每次冲刺结束后都进行发布的想法。很明显，这种做法在实际工作中是行不通的。它会导致以下问题：
- 影响下一个冲刺的开发内容。
- 无法稳定发布内容。
- 难以完成所有必要的测试活动。
因此，我的目标是每两个冲刺执行一次发布。这意味着：
- 发布内容始终包含前两个已完成冲刺的用户故事。由于发布是在当前活动冲刺中执行的，因此该冲刺的内容不会包含在发布中。
- 团队拥有一个完整的冲刺周期来完成必要的测试和修复缺陷。
- 发布负责人有足够的时间在非发布冲刺中收集与发布相关的信息（例如，测试用例、发布说明等）。这样，他们就可以相对独立地工作，而开发团队的其他成员则可以专注于新的用户故事。
- 如果发现缺陷，发布负责人可以快速联系相关的开发人员进行修复，并将其返回到当前冲刺中。因此，团队应该始终分配一定比例的时间来支持缺陷修复，并随着时间的推移，逐渐了解哪些缺陷需要修复。
显然，用户不会在最新版本中获得最新的冲刺内容。但随着时间的推移，这并不重要。无论如何，在每隔一个冲刺之后，他们都可以在下一个版本中获得两个冲刺的内容。这似乎是在快速交付价值和不严重影响 Scrum 活动之间的一种良好折衷。
执行发布部署
当测试、缺陷修复和管道准备工作成功完成后，执行生产管道并完成发布应该是一个非常简单的过程。由于它是从一个独立的分支部署的，所以基本上是一个不引人注意的活动。没有人需要知道。如果可以做到这一点，那么这就是发布部署的理想状态。一个前提条件是，创建可靠的自动化 DevOps 管道。不仅用于部署到生产环境，还用于部署到其他较低级别的环境，如开发、沙箱、测试、质量保证和性能环境等。理想情况下，应该能够通过单击按钮来为每个环境部署所有解决方案。
发布不应该是一个痛点或压力。或者让每个人都为此感到害怕和担忧。 相反，如果没有人注意到发布，那么这才是成功的最好标志。
将发布分支合并回开发分支
发布分支包含一些在常规开发分支中不存在的内容，即在测试期间所做的修复。为了确保这些修复在下一个版本发布后仍然存在，我们需要将这些修复合并回开发分支。
此时，最新的发布分支可以用作生产环境的紧急回滚代码。如果在生产部署后不久需要解决紧急的高优先级问题，则可以使用此分支来快速修复。因为它是当前生产代码的精确副本，没有任何新的、未发布的内容。
最后，一旦新的测试期开始，就可以删除之前的发布分支并用新的分支替换。新的发布分支是当前开发分支的副本。
建立定期发布
现在我们已经有了一个可靠的发布流程。接下来，我们需要做的就是坚持定期发布，例如每隔一个冲刺发布一次。
通过保持规律性，我们实际上为顺利完成发布奠定了基础，因为：
- 如果发布时间间隔不太长，则需要部署到生产环境的新内容不会太多，增量很小并且被认为是稳定的。
- 新内容不多，意味着测试活动和测试用例的创建不会太多。 减少了与利益相关者的沟通、协议调用和协作，了解所有需要重新验证的内容。他们也会同意，因为距离上次发布的时间并不长。因此，此次操作不会那么重要。
- 团队会习惯这种节奏，随着时间的推移，它将自然而然地成为团队工作的一部分。
- 作为副作用，开发和测试环境的数据也会定期刷新。无论如何，每个新的测试周期都需要这样做。因此，这不仅仅是一项额外的工作，而是已经成为既定流程的一部分。这种视角的改变对团队氛围有很大的影响。
结论
本文总结了我之前关于 Scrum 生命周期主题的文章，并介绍了一种在实践中证明有效的方法。
通常，团队在采用敏捷开发时会犯一些错误。但随着时间的推移，他们会逐渐改进，并开始以不同的方式做事。本系列文章旨在帮助他们更快地完成这种转变。
这种发布方法不是唯一的方法，也不是完美的。它仍然存在一些问题，团队必须处理这些问题，并不断改进那些可以改进的地方，并放弃那些没有意义的事情。
据我所知，这种方法虽然简单，但证明了改变是可能的。它可以帮助团队从混乱、不可预测的冲刺过渡到更稳定的交付，定期发布，从而建立信任和信心。而它并不需要特殊的或高度复杂的方法，只需要简单的规则和遵循计划的意愿。