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