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