Deployment 在scrum方法中如何处理部署过程？

我们正在使用scrum方法开发一个复杂的系统，其中包括一周的Sprint和一个由6名开发人员组成的团队

当在开发分支上测试和集成更改时，我们不断更新每个开发人员机器上的源代码，并且开发人员每天将更改集成到测试公共服务器上

但生产系统非常关键，任何问题或停机都会造成大量的美元损失，而且部署过程缓慢、困难且微妙。即使对系统更改进行了测试，甚至将其部署到测试服务器，当我们试图大量发布整个星期的进度时，有时也会出现问题。因此，我们选择了在一周的开发完成并部署到测试服务器之后进行先前的部署过程。我们在测试服务器上对整个星期的更改运行全功能测试，然后将每周工作组发布到预生产服务器，然后有时一切正常，但有时在部署过程或发布的更改中出现一些新问题，然后我们计划高度精细的生产过程，并在第二天晚上执行，避免客户工作的任何停机时间

现在，我们正在与客户进行讨论，因为他辩称这不是scrum，因为他没有在scrum日获得sprint结果，而是在三天后。但是很明显，在sprint完全完成之前，我们无法启动预发布和发布过程，因此，第二天，然后系统的复杂性和关键性迫使我们将部署过程保护到最高层，客户的生产使用也需要一些特殊的操作排程

我们是否在违反scrum准则？scrum方法的部署过程在哪里？scrum适合这个项目吗

部署过程是缓慢、艰难和微妙的

当部署过程困难时，往往意味着组织部署的频率较低。如果他们部署的频率降低，那么发布就会变得更大、更困难、更关键。这往往意味着更不愿意发布

这种消极循环对敏捷不利，因为它意味着组织难以应对变化

你能做的最好的事情就是尝试通过改进发布过程来打破这个循环。这可能很困难，而且会消耗时间和资源，但好处是巨大的

如果您可以自动化发布，那么您就可以降低风险。随着风险的降低，更频繁的释放成为可能。频繁发布意味着发布的大小会减少，如果需要，您可以快速修复bug

频繁发布也会让客户更开心，因为他们有更多的机会提供反馈。他们给予的反馈越多，产品就越快成为他们想要的

---

也许一个好的开始是自动化您当前对公共测试服务器的发布。一旦你已经这样做了一段时间，你应该有信心在生产中使用相同的过程。

巴纳比有一个理想的答案。同时，一种可能性是在每个sprint中都有一个重复的故事，以发布前一个sprint中批准的故事。根据，一个团队只在“每个冲刺结束时交付（a）‘完成’产品的潜在可发布增量”。关键词是“潜在”。除了你面临的问题，我所在的公司每季度只发布一次，因为这是客户想要的。如果您的客户希望在每一个sprint中发布一个版本，这很好，但是指南中没有任何内容要求在同一个sprint中发布故事

---

为了根据评论进行澄清，让我们假设一个团队正在使用传统的开发测试阶段生产架构。客户将在该阶段（如果不是在演示仪式之前）审查变更。接受的故事进入发行版，作为下一个sprint中重复出现的“发行”故事的一部分转移到Prod。

huhmm。。。但是，由于客户无法测试结果，发布增量的反馈不能包含在本冲刺结束时的scrum会议中，scrum有效吗？