当谈到 Scrum 交付时，人们通常期望在冲刺结束后执行发布。 这意味着在向客户成功演示后直接进行。
但我一直想知道这怎么会是一种自动的期望。 特别是如果您考虑以下可能必须在之前或同时发生的活动。
- 在冲刺中开发并完成所有故事。 有些可能会更快完成，但大多数时候，故事会在冲刺结束前完成。 甚至在演示演示之后，也可以在此处打开。
- 对冲刺内容执行所有计划的测试，以确保要发布的代码已准备好生产。
- 在发布之前赶上发现的错误并及时修复它们。
- 确保部署管道更新为最新内容，并且管道本身可以可靠地执行。
- 在所有相关环境上运行管道，从代码和数据的角度将它们带入最新状态。
- 准备发布说明并与客户沟通发布的影响以及之后究竟会发生什么变化。
- 如果相关，与其他并行 scrum 团队同步，以确保相关内容同时发布。 不应遗漏任何内容以确保您的发布内容按预期工作。
- 最重要的是，完成所有的 Scrum 仪式。 不仅与当前 sprint 相关，还与下一个 sprint 的目标相关（例如，故事细化会议）。
现在想象冲刺有两周。
自行发布活动需要时间和人员才能完成。 但不能带太多。 冲刺的最后一天紧接下一个冲刺的第一天，循环将再次开始。
每次冲刺后发布的期望看起来仍然如此自动吗？
发布内容处理
如果 sprint 中的所有流程都是自动化的，则有可能仅“扣动扳机”并在每个 sprint 结束时将最新的代码版本安装到生产环境中。 问题是我从未体验过scrum团队如此完美的状态。
如果在一些小民营企业真的是这样，我真羡慕他们。 但企业界的现实情况是，scrum 团队无法达到那种成熟度。 相反，发布过程通常与耗时的活动相关联，这些活动会影响到大部分后续冲刺，从内容和所有指标的角度影响该冲刺。 发布只是团队中没有人愿意经历的压力行为。
所以我在发现处理发布的下一个最佳方案之后。
结论是让每一个 sprint 都成为 Release Sprint。 这就是它的意思。
下一个版本的单独代码版本
这是关于处理 GIT 存储库中的单独分支。 解决同一个问题的方法有很多种，而且所有方法都可以成功。 但出于本文的目的，我将让事情变得简单，以展示该方法及其影响。
为了尽可能低地影响正在进行的开发活动，重要的是将下一个版本的内容分离到一个单独的分支中。 我们称之为发布分支。 有了这个，将解决以下问题：
- 开发团队可以继续活动并在不中断的情况下合并到主分支的新故事中。
- 发布内容不会受到来自 scrum 团队的意外代码修改的影响。
- 测试活动可以在隔离空间中执行。 这里只介绍解决测试所需的改动。
- 由于发布管道只会将发布分支中的内容部署到生产环境中，因此我们对要发布的内容有一个清晰的流程和完全控制。 对 Git 分支的一些意外提交不会破坏已经测试过的代码，这是不可能发生的。
因此，只需将下一个版本的内容放在一边，让它达到稳定状态，为发布做好准备。
安排发布时间，以便它们重复工作
我放弃了在每个冲刺完成后进行发布的雄心壮志。 很明显，这将没有工作的机会。 至少没有这样的副作用：
- 影响下一个冲刺开发内容，
- 无法稳定发布内容，
- 赶上所有必需的测试活动等。
因此，目标是在每两个 sprint 结束时执行一次发布。 这意味着以下内容：
- 发布将始终包含来自最后两个已经完成的冲刺的故事。 由于发布是在当前（活动冲刺）中执行的，因此该冲刺内容尚未包含在发布中。
- 有一个完整的冲刺时间来完成必要的测试活动和错误修复。
- 发布所有者有足够的时间在非发布冲刺中收集与发布相关的信息（测试用例、发布说明等）。 这样，他们基本上可以独立运作，并让开发团队的其他成员继续致力于新故事。
- 如果发现 bug，Release owner 可以快速与具体的开发人员联系以修复问题并返回到当前的 sprint 内容。 因此，应该始终从团队的能力中分配一定百分比的时间来支持此错误修复。 随着时间的推移，究竟能发现多少。
很明显，用户不会在最新版本中获得最新的冲刺内容。 但随着时间的推移，这将变得无关紧要。 无论如何，在每个第二个冲刺之后，他们将在每个下一个版本中获得两个内容冲刺。
这看起来像是快速交付满意度和在没有重大干扰的情况下跟上 scrum 活动之间的一个很好的折衷。
执行发布部署
当测试、错误修复和流水线准备活动成功完成后，执行生产流水线并完成向生产的发布是一个非常简单的过程。
由于它是从一个独立的分支部署的，这基本上是一个不被注意和不可见的活动。 没有人需要知道。 如果是这样的话，这是发布部署的最佳可能实现。
一个先决条件是创建可靠的自动化 DevOps 管道。 不仅用于部署到生产环境，还用于部署到所有其他较低级别的环境。 这可能包括开发、沙箱、测试、质量保证、性能环境等。这应该是一次单击即可为每个环境部署所有解决方案。
发布不应该是痛点或压力。 或者每个人都害怕并为那一天做一个星期的噩梦。 不——相反，如果根本没有人注意到这一点，那么这是成功发布的最佳标志。
将发布分支合并回开发分支
发布分支现在包含一些特殊的内容，这些内容在常规的持续开发分支中是不存在的。 它与测试期间实施的所有修复有关。 此内容需要合并回开发分支，以确保即使在下一个版本发布后修复也会保留在那里。
此时，最新的 Release Branch 用作紧急准备重新部署的生产代码。 如果在生产部署后不久需要解决紧急的高优先级问题，则可以使用此分支。 使用此代码并在其中实施修复很简单。 这仍然是当前生产代码的精确副本，没有任何新的未发布内容。
最后，一旦新的测试期开始，可以删除之前的发布分支并用新的分支替换。 新的再次创建为当前开发分支的副本。
建立定期发布
现在我们有了 😀——一个接近发布的可靠过程。 唯一缺少的是承诺保持正常。 在这种情况下，每隔一秒冲刺后。
通过保持规律性，我们实际上奠定了基础，使其更容易完成，主要是因为：
- 如果发布时间不太长，则没有太多新内容可以安装到生产环境中。 增量很小并且被认为是稳定的。
- 现在这么多的新内容意味着不会有大量的测试活动和测试用例创建。 减少与利益相关者的沟通、协议调用和协作，了解所有需要重新验证的内容。 他们也会同意，自上次发布以来不久。 因此，此操作不太重要。
- 团队会习惯这个循环； 随着时间的推移，它将自然成为团队的一部分。
- 作为副作用，开发和测试环境经常会刷新数据。 无论如何，每个新的测试周期都需要这样做。 因此，这不仅仅是另一项预定的活动。 相反，一个已经是既定流程一部分的行动。 这种视角的改变对团队的气氛影响很大。 有人不会相信这一点。
结论
本章总结了我之前关于 Scrum 生命周期主题的帖子。 此外，它还涉及在现实生活中被证明有效的方法。
通常，团队以敏捷方式开始并错误地做很多事情。 然后他们最终进化，并开始以不同的方式做事。 本系列可以帮助他们中的一些人更快地进行此更改。
这种发布方法既不是唯一可行的方法，也不是没有问题。 这些仍然存在，团队必须处理它们。 然后改进可能的事情，忘记没有意义的事情。
但据我所知，这种方法虽然简单，但证明了改变是可能的。 从混乱、不可预测的冲刺到更稳定的交付，定期发布，人们可以依赖和计划。 而且它不需要特殊的、高度复杂的方法——只需要简单的规则和遵循计划的意愿。
