由于系统具有许多依赖项，目前我们正在将整个应用程序链一起部署到生产环境中。
我们的 Scrum 团队基于业务主题，以确保每个 Sprint 结束时每个用户故事都具有真正的业务价值，因此经常发生用户故事需要在多个应用程序中进行更改的情况。
我们有几个 Scrum 团队，在同一个系统上工作。从逻辑上讲，我们最终会在一个巨大的验收和（半自动化）回归测试中对所有内容进行验收测试。
但是，在生产环境中大刀阔斧地推出非常耗时、容易出错并且不再可扩展......（或者是吗？）通过持续部署，我们希望让团队能够自助服务推出生产，因此企业可以根据需要推出功能，而不是基于 IT 计划。
但是我们如何设法推出分布在多个代码库上的更改（代码、数据库脚本）并找到策略来处理应用程序之间的依赖关系？
进行可扩展的持续部署的策略是什么？以及如何过渡到这一点？
你怎么看？
【问题讨论】：
标签： deployment integration agile scrum continuous
（这是一个大问题中的很多问题。）
但我会参考持续交付书http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/
编辑： （正如评论你已经读过这本书） 您可能已经提出了一些建议，但对于其他有类似问题的人：
但是对于您实际要求的相互依赖的自动部署策略，我没有可靠的解决方案：|
【讨论】：
没有单一的灵丹妙药可以解决您的问题，但 Kwatee (http://www.kwatee.net) 可以朝着正确的方向大步前进。如果需要，Kwatee 可以在多个服务器上处理分布式/协作应用程序，并且可以使用部署前和部署后操作来处理触发先决条件数据库升级脚本等。您还可以为各种部署环境（dev、test、prod）配置参数。 Kwatee 有一个 Web 界面，使配置变得容易，但您可以通过将它（通过 python CLI 命令或 Ant 任务）包含在持续集成工具中来获得所有世界中最好的。
【讨论】：
我使用 CruiseControl 进行持续集成。它很容易设置，因此，每当有人将某些东西检查到主干时，就会触发构建和自动回归测试。如果构建或测试失败，自上次构建以来提交代码的所有开发人员都会收到一封电子邮件，其中包含可能的罪魁祸首修订列表。破坏构建（虽然不是回归测试）的开发人员必须在第二天带来甜甜圈。
您用于持续集成和测试的特定工具可能取决于您的语言和平台，但概念是相同的。见http://cruisecontrol.sourceforge.net/
希望对你有帮助。
【讨论】：
我在这里回答了一个非常相似的问题：Best-practice for continuous integration and deployment
这可能值得一试。
【讨论】：
我可能会误解，但我认为您所说的是整个系统的验收测试很难，您希望每个 Scrum 团队都能够提升自己的重量？我认为即使每个 Scrum 团队都可以进行一些测试，如果不经过发布前的系统测试阶段就无法发布。换句话说，系统测试是必须的，但可以调整频率，前提是每个组件可以用替代的依赖项单独测试。如果独立的测试和小规模测试可以由单独的 Scrum 团队完成，那么系统测试可以每 2 到 3 个 sprint 完成一次，其中测试人员的重点是系统测试，而测试人员更多地关注错误修复。
【讨论】：