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