问敏捷和代码发布

EN

为什么在工作流程进行时没有任何形式的sprint计划会议？标记您的存储库，并立即开始下一个版本。如果您需要对候选版本进行bug修复，请从标记分支并修复它们。审批工作流程和最终的UAT测试不应涉及或延迟开发团队。(如果您实际使用的是Git或Mercurial之类的东西，请原谅非分布式SCM术语。)

如果你采用像Scrum这样的敏捷过程，那么发布输出是“可发布的软件”而不是“已发布的软件”。如果你有将产品发布到生产中的开销，那么它可以并行发生。我应该补充的是，大多数测试都应该作为sprint的一部分--也许你需要重新审视一下在你的周期中到底做了什么测试？

如果你在测试“大”版本时遇到问题，那么你的发布周期太长了。发布的基本原则通常是==较小的版本。如果你有问题，并且你只发布了一小部分功能，不需要很长时间来测试，那么你的发布工程团队就是瓶颈，他们的瀑布审批流程需要改变。

在冲刺期间发布到公共开发环境，在冲刺期间发布到QA环境。

在sprint结束时发布到参考环境中，仅演示已完成的(和测试的)功能。

在产品所有者需要的时候发布到生产环境中。

bugs的风险不应该是一个问题，因为bug不应该与发布的频率有任何关联，实际上，更多的发布实际上应该意味着更少的风险和更少的bug。测试应该在冲刺期间进行，而不是在之后。如果一些东西没有经过充分的测试，可能有buggy，那么它就不是done，不应该进行演示，更不用说发布到生产环境中了。

最终发布到生产应该是产品所有者的呼声。政治化的瀑布发布工程流程几乎永远不会将bug排除在生产之外，它只是让展示更晚而不是更早。经理在表单上勾选"ok“复选框并不能使有buggy的代码远离客户的视线。在开发过程中频繁发布到QA将会。测试不应该是发布工程周期的一部分，它应该是开发周期的一部分。

这取决于您的产品的任务关键度。所谓“发布”，你是指将你的生命关键软件发布到医院吗？或者它是一个休闲游戏网站？

如果您的工作是任务关键型或生命关键型的，那么敏捷可能无法为您工作。在这种情况下，您可能需要在部署之前进行更多的正式测试。

如果你在一个不是关键任务的网站上工作(这通常比不工作要好！)，你可以自由地成为一个有一点buggy的网站。这可以帮助您更快地迭代，并一次又一次地重新发布。

对于这种产品，敏捷非常适合，让开发人员测试自己，让客户看到结果，然后尽快向一小群用户(希望是随机选择的活跃用户--走廊测试)推出--如果这是一件小事，甚至是对整个用户群。在web服务上，您可以快速完成此操作，并且无需经历太多痛苦即可修复它。