背景
我正在为一个由大约 4 名程序员和 4 名设计师组成的小型 Web 团队创建一个新的开发流程，未来团队的发展潜力明显。我们的产品是一个中央应用程序，为我们设计和托管的客户网站提供支持。
以前，我们都通过 FTP 在开发服务器上工作，只有一个开发数据库。它“工作”了一段时间，但我们正在朝着一个新的方向前进，所以是时候让我们的流程成熟起来了。
我们使用 Percona Server 5.5，但这应该与数据库无关，以保持低成本。
目标：
我正在考虑为数据库开发创建一个持续集成 (CI) 流程，并考虑以下内容：
- 开发人员拥有数据的本地副本来运行开发代码
- 能够将数据库结构回滚到以前的变更集
- 能够区分新功能架构更改与架构设计修复更改
- 能够在本地修改数据库结构以进行测试
初始概念
我在下面使用 SVN 和 LiquiBase 勾勒出了一个过程，尽管它完全删除了#4.
- 从主干创建一个“开发”分支
- 中央“开发”数据库服务器运行“开发”分支
- 本地开发人员被设置为开发分支的奴隶（
#1上面提供）- liquibase 变更集定期提交到开发分支，该分支执行提交后挂钩以更新中央开发数据库（这将渗透到作为该开发服务器的从属运行的本地计算机）（liquibase 在
#2上面提供）- 当功能或模式修复准备好进行质量检查时，DBA（我）会将开发分支中的适当更改合并到主干中。此操作将创建一个 sql 脚本以应用于临时数据库服务器。
- 暂存服务器应该反映 TRUNK，它应该具有与生产相同的结构，以及 QA 中的更改
- 在登台服务器上执行 sql 脚本后，对更改进行一些 QA。
- 如果一切看起来都不错，请标记结构。这将生成由 DBA 手动在生产环境中运行的 .sql 脚本（如果需要，可用于非高峰时段）
此过程要求所有开发人员运行相同的“开发”分支，这意味着在任何给定时间只有一个版本的数据库模式（不确定我是否想要这个）。
这也意味着对模式的任何更改都无法在本地进行测试，如果操作不当，可能会影响其他开发人员。在我们的环境中，开发人员可能会添加新表，但很少修改现有结构。作为 DBA，设计修复由我完成。但是无法在本地测试修复程序是我对该过程的最大阻碍。
如何调整上述过程以允许本地开发，同时仍保持相对最新的数据副本（由我提议的过程中的复制提供）？我不需要数据是最新的，即使是上周。
*通过“工作”，我的意思是它就足够了，但它是一个 PITA。
管理环境
我认为您绝对不想被迫使用单个数据库版本。您拥有足够多的开发人员，您将不可避免地拥有多个开发工作流，并且要求将补丁应用到独立于开发工作流的当前生产环境。
您可以使用 Liquibase 或手动过程来生成补丁脚本以升级版本。我建议从手动过程开始，并在补丁上使用模式比较工具进行 QA。对一个非常复杂的数据库进行干净、自动化、透明的同步有点空想。
您的中央数据模型可以保存在您喜欢的任何系统中。我使用了从繁琐的企业存储库工具到创建表脚本的所有东西。创建表脚本可以很好地与普通的源代码控制工具（例如 subversion）配合使用，并且并非所有存储库工具都能很好地进行版本控制。
无论您使用什么作为主数据模型存储库，您都需要一个相当干净的机制来从该模型部署环境。它的结构应该使部署到环境很容易。您还需要一种机制来从一个已发布版本修补到下一个版本。
我做了什么
我过去在管理开发环境时做过以下事情。它不是特别高科技，但它适用于版本控制和自动构建，因此可以轻松地将环境部署到特定版本，并且维护大量环境非常实用。
维护中央存储库：这可以是保存在版本控制系统中的一组数据库创建脚本，或者是数据建模工具中的存储库模型。任你选。这个模型应该有一个构建机制，允许从脚本中推出一个环境，而无需大量的人工干预。
如果您有很多参考数据，您将需要一个加载机制。根据您的操作方式，您可以将其保存在数据库或一组文件中。文件的优点是它们也可以从与您的代码库相同的版本控制系统进行版本控制和标记。源代码控制存储库中的一堆 CSV 文件和批量加载器脚本可以很容易地做到这一点。
部署开发环境的一种选择是备份生产数据库并修补到适当的版本，并让开发人员可以将它们恢复到开发环境中。
使其易于部署：与任何 CI 构建过程一样，数据库应该可以通过单个脚本进行部署。设置它以便数据库连接可以参数化，或者脚本与位置无关并且可以通过连接运行。
补丁脚本：您需要从每个发布的版本前滚和可能回滚脚本。
从存储库模型构建测试环境：这可确保在与存储库不同步的环境上的开发在测试中被捕获。
测试部署过程：自动修补脚本，但是它们被创建应该是可测试的。模式比较工具对此非常有用，即使您不使用它们来生成补丁脚本。
使用您测试过的存储库模型构建参考环境
使用生产版本的备份或基于当前发布版本的构建创建冒烟测试环境。
针对冒烟测试环境运行补丁脚本。
使用模式比较工具将冒烟测试环境与参考环境进行比较。补丁脚本应该导致两个数据库相同，因此您可以调查任何差异。
我喜欢这个过程的地方
这有点重量级，旨在部署到相当官僚和不透明的生产环境中。但是，它具有以下优势：
开发人员可以在需要的地方进行修补。
可以容纳多个分支和开发流。
部署脚本本身可以以可重复的方式进行测试。这对于关闭部署混乱非常有帮助，因为可以证明可重复性。
架构比较工具提供部署本身的 QA。
测试总是针对预期发布的内容进行，这将发现环境不同步引起的问题。
基于存储库模型和补丁脚本的部署意味着不受控制的垃圾不会意外地从开发环境迁移到生产环境。
尽管通常需要手动准备和测试部署补丁脚本，但许多过程都可以自动化。
环境便宜且易于部署，无需费力。
开发人员被迫制作一个适合简单构建和部署过程的系统。
开发人员被迫学习基本的数据库管理任务，但测试和生产环境不会出现新手错误。
它如何满足您的要求
开发人员拥有数据的本地副本来运行开发代码
部署脚本或数据库映像意味着他们可以从任何可用版本设置环境。
能够将数据库结构回滚到以前的变更集
，再次按部署脚本排序。通过 DDL 或通过受控过程创建的测试数据库备份映像，开发人员可以为您拥有的任何特定版本提供环境。
能够将新功能架构更改与架构设计修复更改
分开 可以在 svn 树的单独分支中维护通用版本的补丁。如果将数据库备份用作参考环境，则它们需要存储在与源代码控制项目的分支具有相同文件夹结构的某个位置。
能够在本地修改数据库结构以进行测试
简单的部署过程允许开发人员进行修补，轻松地将环境恢复到本地状态，或者调出参考环境进行比较并进行更改集。