Continuous integration 对数据库的更改是否应始终作为CI的一部分？

这个问题是在与我合作的开发团队中提出的，我们无法真正达成共识：

对数据库的更改是否应作为CI脚本的一部分？

假设您正在使用的应用程序涉及数据库。我认为是的，因为这是整合的定义。如果您没有包括应用程序的一部分，那么您就没有真正测试您的集成。相反的论点是，CI服务器是确保基本项目设置正常工作的地方——本质上是构建最新版本代码的原始签出

是否有CI的“最佳实践”文档可以回答这个问题？这是那些热衷于CI的人争论的话题吗

一个常见的错误是没有在自动构建中包含所有内容。 构建应该包括从数据库中获取数据库架构 存储库并在执行环境中启动它

---

如果没有真正的集成，就没有持续集成。这意味着运行您的软件所需的所有组件都必须是CI的一部分，否则您就有了比源代码管理更复杂的东西，但没有真正的CI好处

如果CI中没有数据库，则无法回滚到应用程序的特定版本，也无法在真实、始终完整的环境中运行测试

这当然不是一个容易的话题。在我工作的项目中，我们使用

alter

脚本，这些脚本需要与源代码更改一起检入。这些脚本在我们的测试数据库上运行，以确保不仅当前构建的正确性，而且可以升级/降级一个版本，并且更新过程本身不会弄乱任何事情。我相信这是比删除和重新创建整个数据库更好的解决方案，它让您有一个一致的路径来逐步升级数据库，并允许您在某种测试环境中使用数据库-数据、用户等。

所有代码，包括数据库模式和预先计算的表值都应该受到源代码控制和持续集成的约束。我已经看过很多使用源代码管理的项目，但在DB上没有。取而代之的是一个主数据库实例，在这个实例中，每个人都在同时进行更改。这使得不可能进行分支，也不可能重新创建系统的早期状态

我非常喜欢使用VisualStudio2010 Premium的功能来处理数据库模式。它使数据库模式成为项目结构的一部分，使主模式受源代码控制。可以在项目之外创建一个新的数据库。将自动生成将现有数据库提升到新架构的升级脚本

---

在没有VS2010 Premium或类似工具的情况下，正确地对数据库进行更改管理充其量是痛苦的——如果可能的话。如果您没有工具支持，我可以理解您的同事希望将DB排除在CI之外。如果您对在CI中包含DB存在争议，那么首先为DB工作获取descen工具集可能是一种选择？一旦有了合适的工具，在CI中包含DB是很自然的一步。

我认为在没有工具的情况下进行DB迁移有很多选择。FluentMigrator、增量升级脚本等。斯科特·艾伦（K Scott Allen）有一系列关于这一点的文章。