这个问题出现在我正在合作的开发团队中，我们无法真正达成共识：
Should changes to the database be part of the CI script?
假设您正在使用的应用程序涉及数据库。我想是的，因为这是整合的定义。如果您不包含部分应用程序，那么您实际上并未测试集成。相反的论点是，CI服务器是确保基本项目设置有效的地方 - 实质上是构建最新版代码的原始结帐。
是否有CI的“最佳实践”文档可以回答这个问题？对于那些对CI充满热情的人，这个问题是否存在争议？
Martin Fowler's opinion on it:
一个常见的错误是不要在自动构建中包含所有内容。 构建应该包括从中获取数据库模式 存储库并在执行环境中启动它。
答案 0 :(得分：2)
所有代码（包括数据库架构和预先填充的表值）都应受源代码控制和持续集成的约束。我见过许多使用源代码控制的项目 - 但不是在DB上。相反，有一个主数据库实例，每个人都在同一时间进行更改。这使得无法进行分支，也无法重新创建系统的早期状态。
我非常喜欢使用Visual Studio 2010 Premium的数据库架构处理功能。它使数据库模式成为项目结构的一部分，在源代码控制下具有主模式。可以在项目外创建一个新的数据库。将自动生成升级脚本以将现有数据库提升到新架构。
对于没有VS2010 Premium或类似工具的数据库，正确地进行变更管理最多是痛苦的 - 如果可能的话。如果您没有该工具支持，我可以理解您的同事希望将数据库保留在CI之外。如果您在争论将数据库包含在CI中时遇到问题，那么可能首先获得数据库工作的descen工具集？一旦拥有了正确的工具，将数据库包含在CI中就是一个自然的步骤。
答案 1 :(得分：0)
如果您没有真正的集成，则没有持续集成。这意味着运行软件所需的所有组件必须是CI的一部分，否则您有一些比源代码控制更复杂的东西，但没有真正的CI优势。
如果CI中没有数据库，则无法回滚到特定版本的应用程序，也无法在真实，完整的环境中运行测试。
这当然不是一个容易的主题。在我工作的项目中，我们使用需要与源代码更改一起签入的alter脚本。这些脚本在我们的测试数据库上运行，以确保不仅当前构建的正确性，而且还可以升级/降级一个版本的上/下，并且更新过程本身不会弄乱任何东西。我相信这是比删除和重新创建整个数据库更好的解决方案，它允许您逐步升级数据库，并允许您在某种测试环境中使用数据库 - 包括数据，用户等。 / p>