如何为小型Web团队设置本地数据库开发过程？

背景

我正在为一个由约4位程序员和4位设计师组成的小型Web团队创建一个新的开发过程，并有望在未来发展该团队。我们的产品是一个中央应用程序，可为我们设计和托管的客户网站提供支持。

以前，我们都通过FTP在开发服务器上使用单个开发数据库进行工作。有效” ^*了一段时间，但我们正在进入一个新的发展方向，所以它是成熟的时间我们的进程。

我们使用Percona Server 5.5，但这应该是数据库不可知的，其思想是保持低成本。

目标：

我正在考虑为数据库开发创建一个持续集成（CI）流程，请注意以下几点：

1. 开发人员拥有本地数据副本以针对其运行开发代码
2. 能够将数据库结构回滚到以前的变更集
3. 能够将新功能架构更改与架构设计修订更改分开
4. 能够在本地修改数据库结构以进行测试

初始概念

我已经在下面使用SVN和LiquiBase勾勒出了一个过程，尽管它完全删除了#4。

• 从主干创建一个“开发”分支
• 中央“开发”数据库服务器从“开发”分支运行
• 本地开发人员被设置为开发分支的奴隶（#1上面提供）
• liquibase变更集定期提交给开发分支，该分支执行提交后挂钩以更新中央开发数据库（它将滴流到作为该开发服务器的从属服务器运行的本地计算机）（liquibase #2上面提供了）
• 当功能或模式修订准备好进行质量检查时，DBA（我）将把适当的更改从开发分支合并到主干中。此操作将创建一个SQL脚本以应用于暂存数据库服务器。
• 登台服务器应反映TRUNK，该结构应与Production具有相同的结构，以及质量检查中的更改
• 在登台服务器上执行sql脚本后，请对更改进行一些质量检查。
• 如果一切看起来不错，请标记结构。这将生成.sql脚本，以供DBA在生产环境中手动运行（如果需要，请在非高峰时间运行）

此过程要求所有开发人员都在同一个“开发”分支下运行，这意味着在任何给定时间仅存在一个数据库模式版本（不确定我是否需要此版本）。

这也意味着对模式的任何更改都无法在本地进行测试，如果操作不当，可能会影响其他开发人员。在我们的环境中，开发人员可能会添加新表，但很少修改现有结构。作为DBA，设计修复工作由我完成。但是无法在本地测试修复程序是我最大的困扰。

如何调整上述过程以允许本地开发，同时仍保持数据的相对最新副本（如我建议的过程中的复制所提供的那样）？我不需要直到上周的最新数据。

管理环境

我认为您绝对不想被迫进入单个数据库版本。您拥有足够的开发人员，因此不可避免地会有多个开发工作流，并且要求将补丁应用于独立于开发工作流的当前生产环境。

您可以使用Liquibase或手动过程来生成补丁脚本以升级版本。我建议从手动过程开始，然后使用模式比较工具对补丁进行质量检查。非平凡的数据库的干净，自动化，透明的同步有点乌托邦式的。

您可以将中央数据模型保存在任何您喜欢的系统中。我已经使用了繁琐的企业存储库工具中的所有内容来创建表脚本。创建表脚本可以与诸如Subversion之类的普通源代码控制工具很好地配合使用，并且并非所有存储库工具都能很好地进行版本控制。

无论使用什么作为主数据模型存储库，都需要一种相当干净的机制来从该模型部署环境。它的结构应易于部署到环境中。您还需要一种从一个发行版本修补到下一个版本的机制。

我做了什么

过去，在管理开发环境时，我已经做了以下工作。它不是特别高科技，但是可以进行版本控制和自动构建，因此可以轻松地将环境部署到特定版本，并且保留大量环境是很实际的。

维护中央存储库：这可以是版本控制系统中保存的一组数据库创建脚本，也可以是数据建模工具中的存储库模型。随便你吧。该模型应具有一种构建机制，该机制允许在无需大量人工干预的情况下从脚本中推出环境。

如果您有大量参考数据，则需要一种加载机制。根据您要执行的操作，可以将其保存在数据库或一组文件中。文件的优势在于，它们也可以从与您的代码库相同的版本控制系统中进行版本控制和标记。源代码控制存储库中的一堆CSV文件和批量加载器脚本可以很容易地做到这一点。

部署开发环境的一种选择是获取修补到适当版本的生产数据库的备份，并使开发人员可以使用它们来还原到开发环境中。

易于部署：与任何CI构建过程一样，该数据库应可从单个脚本进行部署。进行设置，以便可以对数据库连接进行参数化，或者脚本与位置无关，并且可以仅通过连接运行。

补丁程序脚本：您将需要前滚，并且可能需要回滚每个已发布版本中的脚本。

从存储库模型构建测试环境：确保与存储库不同步的环境上的开发会在测试中陷入困境。

测试部署过程：自动补丁脚本，但是创建后，应该是可测试的。模式比较工具对此非常有用，即使您不使用它们来生成补丁脚本也是如此。

• 使用您针对其测试的存储库模型构建来创建参考环境

• 使用生产版本的备份或基于当前发行版本的版本创建烟雾测试环境。

• 针对冒烟测试环境运行补丁脚本。

• 使用架构比较工具将烟雾测试环境与参考环境进行比较。修补程序脚本应导致两个数据库相同，因此您可以调查任何差异。

我喜欢这个过程

这有点重量级，旨在部署到相当官僚和不​​透明的生产环境中。但是，它具有以下优点：

• 开发人员可以根据需要进行修改。

• 可以容纳多个分支和发展流。

• 部署脚本本身可以以可重复的方式进行测试。因为可以证明可重复性，所以这对于关闭部署混战非常有帮助。

• 模式比较工具对部署本身进行质量检查。

• 总是针对预期发布的内容进行测试，这将捕获由于环境不同步而引起的问题。

• 基于存储库模型和补丁脚本的部署意味着不受控制的垃圾不会意外地从开发环境迁移到生产环境。

• 尽管通常需要手动准备和测试部署补丁脚本，但是许多过程可以自动化。

• 环境价格便宜，易于部署，而不必费力。

• 开发人员被迫制作适合简单构建和部署过程的系统。

• 开发人员被迫学习基本的数据库管理任务，但是测试和生产环境不受noob错误的影响。

如何满足您的要求

1. 开发人员拥有本地数据副本，可以针对
   
   这些数据运行开发代码。部署脚本或DB映像意味着他们可以从任何可用版本中建立环境。

2. 能够将数据库结构回滚到以前的变更集，
   
   再次按部署脚本排序。通过DDL或测试通过受控过程创建的数据库备份映像，开发人员可以将环境升级到您拥有的任何特定版本。

3. 能够区分新功能的架构更改与架构设计修订更改
   
   ，可以在svn树的单独fork中维护对通用版本的补丁。如果将数据库备份用作参考环境，则需要将它们存储在与源代码管理项目的分支具有相同文件夹结构的位置。

4. 能够在本地修改数据库结构以进行测试
   
   简单的部署过程使开发人员可以进行修补，并轻松地将环境还原到本地状态，或者调出参考环境进行比较并进行更改集。