敏捷开发和代码发布

Question

你是否了解任何为代码发布创建的敏捷流程？敏捷的主要主题之一是频繁发布，每个公司/客户都会有自己的测试/批准流程来控制代码发布。大多数情况下，这些流程会减缓“频繁发布”的步伐。

目前，我们有一个基于专有工具的工作流程。需要代码推广的团队需要创建一个推广请求到最终的UAT服务器之一。一旦完成此操作并进行测试，某些客户、技术/非技术经理需要批准，然后进入生产部署阶段。同时没有任何冲刺计划会议或类似的东西。

你使用过哪种适用于代码发布的敏捷流程呢？

- ring bearer

---

此问题不属于本站的范围，因如 What topics can I ask about here? 所定义。还请参阅：What types of questions should I avoid asking? 您可以尝试在 其他 Stack Exchange 站点上提问，或许 [pm.se] 或 [softwareengineering.se] 可以帮得上忙。无论您打算在哪个站点发布问题，请务必仔细阅读其关于主题的帮助中心页面。 - Makyen

Answer 1

为什么工作流程在进行时没有任何冲刺计划会议？给你的存储库打上标签，直接开始下一个版本发布。如果需要对候选版本进行错误修复，请从标签分支并修复它们。批准工作流程和最终用户验收测试不应涉及或延迟开发团队。(如果你实际上使用的是Git或Mercurial，则请原谅非分布式SCM术语。）

如果您采用Scrum这样的敏捷过程，则发布输出为“可发布软件”，而不是“已发布软件”。如果发布到生产环境有一定的开销，那么可以并行进行。我应该补充说，大部分测试应该是作为Sprint的一部分进行的——也许您需要重新审查在您的周期中什么时候进行测试？

- David M

---

“可发布的(releasable)”与“已发布的(released)”是一个非常好的观点。开发人员应该创建可发布的软件，而管理者、QA以及其他利益相关者将决定是否真正发布某个可发布版本。你永远不应该害怕分叉来修复错误，然后再合并修复内容。 - Mike DeSimone

Answer 2

如果你在测试“大”版本时遇到问题，那么你的发布周期就太长了。发布的基本原则是经常性地发布小版本。如果你遇到问题，并且你只发布一些不需要长时间测试的小功能集合，那么瓶颈在于你的发布工程团队，他们的瀑布式批准流程需要改变。

在整个开发过程中都要发布到一个共同的开发环境，而在开发过程中，还要在QA环境中进行发布。 在sprint结束时将完成（已测试）的功能发布到参考环境进行演示。

每当产品所有者想发布时，就发布到生产环境中。错误的风险不应该是一个问题，因为错误不应该与发布的频率有任何关联，实际上更多的发布应该意味着更少的风险和更少的错误。测试应该在sprint期间进行，而不是之后。如果某个功能没有完全测试或可能存在错误，则它还没有完成，不应该进行演示，更不应该发布到生产环境中。

最终，发布到生产环境应该是产品所有者的决定。政治化的瀑布式发布工程流程几乎从不会使错误远离生产环境，它只会使错误出现的时间变得更晚。管理人员在表格上打上“ok”勾选框并不会使有错误的代码远离客户的视线。频繁地在开发过程中发布到QA环境才能达到这一点。测试不应该成为发布工程周期的一部分，而应该成为开发周期的一部分。

- user177800

---

"测试不应该成为发布工程周期的一部分，而应该成为开发周期的一部分。" - 那么UAT或预生产客户测试呢？在我看来，它们在发布过程中扮演重要的角色。 - ring bearer

用户验收测试和最终用户客户测试与功能和集成测试不同。最终它只应该确认产品负责人在履行其职责。产品负责人应在生产之前测试和接受任何功能。UAT和最终用户客户测试不应该是发现系统中错误的过程。它应该最多找到他们要求但规定错误的事情。 - user177800

+1，但你似乎忽略了一个事实，即后续版本需要更长时间进行测试，因为每个版本都必须执行回归测试。希望这是自动化的，因此很快，但必须承认这一点。 - Randolpho

如果您在编写代码时构建测试，则回归测试是自动的，并且如果在随后的迭代中不断进行，则不会影响发布。 - user177800

Answer 3

这取决于你的产品有多重要。当你说“发布”时，是指将生命关键软件推向医院吗？还是一个休闲游戏网站？

如果你的工作是生命关键或者至关重要的，敏捷开发可能不适合你。在这种情况下，你可能需要在部署之前进行更正式的测试。

如果你从事的是非生命关键的网站开发（通常比较好），那么你就可以有一些错误的自由。这有助于你更快地迭代和重新发布。

对于这种完美适用于敏捷开发的产品，让开发人员自行测试，让客户看到结果，然后尽快向一小群用户（希望是随机选择的活跃用户——走廊测试）推出——如果是小事情，甚至可以推给整个用户群体。在 Web 服务上，你可以快速完成这个过程并修复它，而不会经历太多痛苦。

- dionyziz

---

敏捷过程不是关于发布有bug的软件并更快地修复它们，而是根本不发布有bug的软件。 - user177800

你几乎把敏捷开发等同于牛仔编码！ - ring bearer

@戒指承载人：有区别吗？ :p - Randolpho

这个答案完全错误，敏捷开发可以并且已经被用于生命关键应用程序。 - Pascal Thivent