我们正在与在 Scrum 环境中工作的交付团队一起交付核心系统的彻底重写。由于团队规模的原因，我们现在分成了两个 Scrum 团队，他们的目标是每天集成代码。每当测试团队部署到我们的系统测试环境(通常每天)时，我们都会拆除数据库并重新填充所有引用数据 - 这是为了确保测试基线。
这种方法的问题在于，当一个测试团队正在等待部署修复程序而另一个测试团队正在测试执行中时，我们会严重影响我们的速度。为了尝试解决这个问题，我们提出了以下建议:
- 创建另一个测试环境(成本相当昂贵)，此外，我们仍然会遇到延迟，因为团队中的一名测试人员仍然无法部署他们的修复程序。
- 仅用于代码部署的选项(避免数据库拆除)。
我们尝试鼓励团队跨职能，并鼓励测试人员帮助测试人员找出阻碍部署的人，但这并不总是可行。我们还希望任务的完成时间约为 1-2 天，因此我们无法轻易分解项目的持续时间。
其他人在他们的环境中采用了哪些方法？
最佳答案
不要拆除并重新开始，而是考虑一种“进化”数据库的方法，通过将每个更改制定为“增量脚本”，这会进行结构更改(添加表、重命名列等)并迁移数据.
我已经使用过这种方法几次，当它得到应用时，它取得了巨大的成功 - 使团队和每个开发人员的行动速度显着加快。
如果有兴趣，我有一篇博客文章，其中描述了我的一项努力:http://dearjunior.blogspot.se/2008/05/version-of-data-in-database.html
如果你想深入了解，我推荐"Refactoring Databases"
我们走得最远的团队开发了一大堆 bash 脚本来管理一切。然而，现在也有一些简洁的框架。我们已经开始使用dbmaintain这实际上与我们自己开发的非常相似。
我强烈推荐这种方法。
[更新]我刚刚发现软件工程电台运行了 podcast episode就在几个月前讨论过这个话题。
关于database - 敏捷——数据库部署，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11080931/