4

目前，由于系统具有许多依赖关系，我们正在将整个应用程序链一起部署到生产环境中。

我们的 Scrum 团队基于业务主题，以确保每个 Sprint 结束时每个用户故事都具有真正的业务价值，因此经常发生，用户故事需要在多个应用程序中进行更改。

我们有几个 Scrum 团队，在同一个系统上工作。从逻辑上讲，我们最终会在一个巨大的验收和（半自动化）回归测试中对所有内容进行验收测试。

但是对生产进行大规模部署非常耗时，容易出错并且不再可扩展......（或者是吗？）通过持续部署，我们希望使团队能够自助服务部署到生产，所以企业在需要时推出功能，而不是基于 IT 计划。

但是，我们如何设法推出分布在多个代码库上的更改（代码、数据库脚本）并找到一种策略来处理应用程序之间的依赖关系？

具有可扩展持续部署的策略是什么？你如何过渡到这一点？

你怎么看？

4

5 回答 5

2

没有单一的灵丹妙药可以解决您的问题，但 Kwatee ( http://www.kwatee.net ) 可以朝着正确的方向走很长一段路。如果需要，Kwatee 可以在多个服务器上处理分布式/协作应用程序，并且可以使用部署前和部署后操作来处理触发先决条件数据库升级脚本等。您还可以为各种部署环境（dev、test、prod）配置参数。Kwatee 有一个 Web 界面，可以让配置变得简单，但是通过将它（通过 python CLI 命令或 Ant 任务）包含在一个持续集成工具中，您可以获得所有世界中最好的。

于 2012-02-09T17:54:22.553 回答
2

（这是一个大问题中的很多问题。）

但我会参考持续交付书http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912/

编辑：（正如评论你已经读过这本书）一些你可能已经做过的建议，但对于其他有类似问题的人：

但是对于您实际要求的相互依赖的自动部署策略，我没有可靠的解决方案：|

于 2012-02-09T17:05:30.660 回答
0

我可能会误解，但我认为你所说的是整个系统的验收测试很难，你希望每个 Scrum 团队能够提升自己的重量吗？我认为即使每个 Scrum 团队都可以进行一些测试，如果不经过发布前的系统测试阶段就无法发布。换句话说，系统测试是必须的，但可以调整频率，前提是每个组件都可以用替换的依赖项单独测试。如果独立的测试和小规模测试可以由单独的 Scrum 团队完成，那么系统测试可以每 2 到 3 个 sprint 完成一次，其中测试人员的重点是系统测试，而测试人员更多地关注错误修复。

于 2012-02-11T16:29:19.463 回答
0

我在这里回答了一个非常相似的问题：持续集成和部署的最佳实践

这可能值得一试。

于 2012-02-10T04:54:37.610 回答
0

我使用 CruiseControl 进行持续集成。它很容易设置，因此，每当有人将某些东西检查到主干时，就会触发构建和自动回归测试。如果构建或测试失败，自上次构建以来提交代码的所有开发人员都会收到一封电子邮件，其中包含可能的罪魁祸首修订列表。破坏构建（尽管不是回归测试）的开发人员必须在第二天带来甜甜圈。

您用于持续集成和测试的特定工具可能取决于您的语言和平台，但概念是相同的。见http://cruisecontrol.sourceforge.net/

希望能帮助到你。

于 2012-02-09T16:46:18.490 回答