自动部署对敏捷开发至关重要吗？

Question

我问，因为我的团队以前是尝试来“做”scrum。我们进行了为期两周的冲刺，但没有与这些冲刺一起发布！还有其他几个原因，但一个重要的原因是部署时间太长而且太复杂，不能经常这样做。

Answer 1

你回答了自己的问题：如果部署时间太长，不能经常完成，你不能进行短迭代，你不能随时发送代码，你无法演示进展迭代的结束等等。因此，在您的上下文中，没有自动部署是一个主要障碍应该很早就被识别和删除（通过检查和改编）。

现在回到问题。自动部署是否至关重要？好吧，正如所暗示的，我会说这取决于上下文：一个带有简单直接的手动部署过程的项目可能会使用它。自动部署是一个好习惯吗？我是这么认为的：自动化流程通常更快，更不容易出错，人们显然不会在做一些可自动化的事情上增加很多价值（参见Three Strikes And You Automate）。

Answer 2

我会说是的，这是一种必不可少的做法。如果部署过于复杂并且花费的时间太长，则会遇到更大的问题。我想你应该解决这个问题。你有时必须这样做。做可以随意构建的工作只能帮助你的项目。

能够声称“敏捷”标签并不重要;拥有自动化，不干涉，可重复的构建是重点。

Answer 3

至关重要，不，你可以在没有它的情况下离开，但是，正如你发现的那样，你必须手动做的一切都会减慢你的周期时间。

您的目标应该是尽可能自动化，构建，部署，回归测试等等，这样您就不会有不必要的延迟。

没有发布的sprint的想法是......有趣......一个。我不能说我曾经见过以前尝试过的那样： - ）

Answer 4

您必须清楚地区分两件事：可交付的产品增量和实际的货件。首先是你的团队应该为每个sprint产生什么，第二个是如果它具有商业意义可能会发生的事情。

换句话说：团队生成的每个sprint必须是一个完全正常工作的代码，这是你开发的新代码。它应该是完全构建和测试的 - 这就是为什么要进行自动测试和构建环境的原因。但是，是否应该将每个sprint部署到生产服务器以及这是否应该是自动的，这与开发过程本身无关。

如果要求您在每个sprint中部署到实时生产服务器（无论如何都是非常好的事情），那么自动化它可能是有意义的，但是这个过程是完全自动还是不应该不是阻碍您的团队在每个sprint中生成完整工作代码的能力。