Drupal数据库部署策略？

Question

以下为所需翻译内容：What's best Drupal deployment strategy? 中的引用：

数据库比较棘手；对于最初的发布，清理开发 / 测试数据库并将其推送到生产环境最为简单，但是在进行增量数据库更新时，如果生产环境中的用户也在生成内容，则会出现一些问题。

我想了解如何解决这个问题？目前我在本地机器上获取现有数据库的完整副本，将其提交到Subversion，然后部署整个数据库。目前该文件大小为15兆字节，每次都必须上传整个文件（我认为Subversion视其为全新文件，因为每次变化都很多）。

所以，我的问题实际上是：

1. 除了更少地提交，我还能通过什么方式来减小我的数据库大小？
2. 是否有其他方法可以保持我的数据库和服务器数据库同步？特别是考虑到用户将一直发布新数据？

- rockstardev

Answer 1

有没有其他的方法可以保持我的数据库和服务器数据库同步？特别是考虑到用户会一直发布新数据？

我们有一个庞大的分布式团队和编辑部门，因此部署数据库是不可行的。

为了解决这个问题，我们广泛使用更新函数。我们有一个没有实际代码的模块，用于更新设置。每当开发人员进行配置更改时，他们都会在这个模块中编写一个更新函数，当运行时，它将在其他开发DB、暂存DB和生产DB上进行相应的更改。

存在一些问题，特别是跨依赖性问题（如果人们在多个模块中编写更新函数），并且编写管理界面相对较小的更改可能需要花费时间。Install profile api 可以帮助解决这个问题。

例如：

function mysite_update_6000() {
  install_include(array('user'));
  $editor_rid = install_add_role('editor');
  install_add_permissions(DRUPAL_ANONYMOUS_RID, array('do something'));
  install_add_permissions($editor_rid, array('do something', 'administer nodes'));
  return array();
} 

将会添加一个角色并分配一些权限给它。这样做可以将所有更改保存在代码中，因此无需尝试迁移和同步数据库。

还有一个migration模块，可能有助于此，它记录表格的更改并将其保存到更新函数中。这不应与用于内容迁移的drupal.org migrate模块混淆。

我们已经取得了一些成功，但也遇到了一些问题，使用了features模块，它可以帮助迁移功能。

- Jeremy French

---

+1 - 使用“虚拟”模块允许自定义更新功能是个好主意。 - Henrik Opel

@Jeremy：我觉得你的方法非常有趣，因为功能模块并不适用于所有事情。但是我想知道，作为Drupal管理员，您如何管理编写所有种类的更新代码。例如，我启用了所有翻译/本地化相关模块，然后在所有菜单中创建了菜单项的翻译版本。您会从哪里查找要编写更新函数的代码？ - Sumeet Pareek

Answer 2

对于较小的项目，我们仍然采用类似于您目前流程的方法，即通过阻止所有具有编辑权限的用户来锁定实时实例以只读方式，然后转储数据库，上传到一个阶段实例，在那里执行所有需要的更新，一旦满意结果，我们将阶段实例切换为下一个实时版本。但即使对于小实例而言，这也是痛苦的，远非一个好的解决方案。

在两个更大的项目中，我们和Jeremy一样陷入了同样的困境，即整个设置过于复杂，无法部署完整的数据库转储，特别是因为我们不能承受将实例锁定为只读模式来进行一些更新。

对于这些，我们在一定程度上使用了偏头痛（另请参见此相关讨论）。它不是Drupal模块，而是一个Python脚本，我们对其进行了一些调整以适应我们的需求。它旨在创建具有某种结构的转储，将用户提供的内容与设置和其他内容分开，从而允许更有选择性的更新和分阶段策略。但是，由于Drupal数据库结构更多或少是混乱的（特别是缺乏引用完整性强制执行），因此在添加新模块时使用此方法需要不断调整，并且风险很高，因为需要确保仅转储/更新一致的表集。

我们尝试通过使用自定义模块的更新功能来最小化需要“批发”转储/更新操作的需求，并且我喜欢Jeremy French的建议，即添加一个“虚拟”模块，仅用于添加其他设置的更新功能！

总的来说，目前更新/迁移Drupal实例非常麻烦，我希望未来版本中会有更一致的解决方案，尽管我可以看到，鉴于当前的数据库架构和大量具有个体附加项的自定义模块，想出一个通用方法是很困难的 :/

---

PS: 备份和迁移 是一个 Drupal 模块，似乎采用了与 Migraine 脚本类似的方法，但我还没有使用过它。

- Henrik Opel

Answer 3

Henrik和Jeremy对部署状态给出了很好的答案。我也听说过Capistrano（ruby）被成功地使用。DrupalCampLA Case Study描述了他们使用的部署机制（包括Capistrano），并且据说下载包中包括他们的部署脚本。

如果你想将数据库转储的大小最小化，请确保将其调整为排除缓存和监视表。备份和迁移默认情况下会显示哪些表是值得忽略的。

- Grayside

---

+1 建议另外一个选择 - 我之前没有听说过 Capistrano，但它看起来很有前途，值得一试。 - Henrik Opel

Answer 4

最好的方法是将所有更改保留在代码中，并使用功能模块等工具将更改推送到暂存和/或生产环境。

在开发过程中需要付出更多的工作，这是事实，但如果您与一群拥有自己数据库的人一起工作，或者想要轻松地将更改推送到生产环境，features绝对是正确的选择。

- Karel