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

我这样问是因为我的团队以前试图“做”scrum。我们有两周的冲刺，但没有发布与这些冲刺！这还有其他几个原因，但其中一个主要原因是部署时间太长，太复杂，无法频繁执行。

我想说是的，这是一种基本做法。如果部署太复杂、耗时太长，那么问题就更大了。我认为你应该解决这个问题。你得找个时间做。做这项工作，使其能够随意构建，这只能帮助您的项目

---

能够宣称“敏捷”的标签并不重要；拥有一个自动化的、无需动手的、可重复的构建是关键。

至关重要，不，你可以不使用它，但是，正如你所发现的，你必须手动完成的所有事情都会减慢你的周期时间

您应该尽可能地实现自动化，包括构建、部署、回归测试等等，这样您就不会受到不必要的延迟

---

没有发布的sprint的想法是。。。有趣的。。。一个。我不能说我以前见过这种尝试：-）

你回答了你自己的问题：如果部署时间太长，就不能频繁地进行部署，也不能进行短迭代，你不能随时发布代码，也不能在迭代结束时演示进度，等等。因此，在你的上下文中，没有自动部署是一个主要障碍，应该尽早发现并消除（通过检查和调整）

---

现在回到问题上来。自动部署是一个关键实践吗？正如所暗示的，我认为这取决于上下文：一个具有简单而直接的手动部署过程的项目可能会接受它。自动部署是一种好的做法吗？我认为是这样的：自动化流程通常更快，更不容易出错，而且人类显然不会在做可以自动化的事情时增加太多价值（另请参见）。

您必须清楚地区分两件事：可交付的产品增量和实际装运。首先是你的团队应该在每一次冲刺中产生什么，其次是如果它有商业意义的话可能会发生什么

换句话说：团队在每次sprint中产生的内容必须是一段完整的工作代码，是您开发的任何内容的新增量。它应该被完全构建和测试——这就是为什么如果您要这样做，那么自动测试和构建环境是必须的。然而，是否应该在每次sprint时将其部署到生产服务器上，以及是否应该将其自动化，这是完全不同的事情，与开发过程本身无关

---

如果您需要在每个sprint中部署到live production server（当然这是一件非常好的事情），那么自动化它可能是有意义的，但是无论这个过程是否完全自动化，都不应该妨碍您的团队在每个sprint中生成完全工作的代码

不，没有“尝试”。做还是不做？：-）你能澄清一点吗：你真的是指自动部署还是自动构建，或者两者兼而有之？@Pascal当然！我确实是指具体的部署。至少我们的构建是自动化的。谢谢你的澄清。但这并没有真正改变我的答案：）到目前为止，所有人的答案都很好！非常感谢。哈哈，是的，好像不太好用。我们有sprint计划会议的开销，但没有任何好处。