敏捷和代码发布

Question

您知道为代码发布创建的敏捷过程吗？敏捷的主题之一是频繁发布，每个公司/客户都有自己的测试/审批流程来控制代码发布。大多数时候这些都会减缓“频繁发布”的速度

目前，我们拥有基于专有工具的工作流程。需要代码促销的团队需要为其中一个最终的UAT服务器创建促销请求。一旦完成，一旦测试完成，某些客户，技术/非技术经理需要批准，然后进入生产部署阶段。同时没有冲刺计划会议或类似的任何事情。

什么是适合您的代码发布流程（敏捷）？

Answer 1

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

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

Answer 2

如果您在测试“大”版本时遇到问题，那么您的发布周期就会很长。发布的基本原则通常是==较小的版本。如果您遇到问题并且您只发布了不需要很长时间进行测试的少量功能，那么您的发布工程团队就是瓶颈，他们的瀑布审批流程需要更改。

在sprint期间全部发布到公共开发环境，在sprint期间发布到QA环境。

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

产品所有者想要的时候发布到生产。

错误的风险不应成为问题，因为错误不应与版本的频率有任何关联，实际上更多的版本实际上意味着风险更小，错误更少。测试应该在期间进行，而不是之后。如果某些东西没有经过全面测试并且可能有问题，那么它就不会完成而且不应该进行演示，更不用说了。

最终发布到生产应该是产品所有者致电。一个政治化的瀑布式发布工程流程几乎永远不会将错误从生产中剔除，它只是让这个节目更晚出现而不是更快。管理人员在表单上勾选一个“确定”的复选框并不会让错误的代码远离客户的眼睛。在开发过程中经常发布QA。测试不应该是发布工程周期的一部分，它应该是开发周期的一部分。

Answer 3

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

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

如果您在一个非关键任务的网站上工作（而且这通常比不上好！），您可以自由地成为一个小小的车。这有助于您更快地迭代并重复发布。

对于那种敏捷非常适合的产品，让开发人员自己测试，让客户看到结果，然后尽快启动给一小组用户（希望随机选择的活跃用户 - 走廊测试） - - 如果这是一件小事，甚至是整个用户群。在Web服务上，您可以快速完成此操作并修复它，而不会经历太多痛苦。