Drupal配置迁移详细讨论

因为drupal的开源、强大、安全等很多优点，因此被业界广泛接受，应用也越来越广范了，可能很多phper会遇到drupal的迁移与配置的问题，现在本人根据自己的经验把这个问题记录下来，供大家参考。

Drupal 配置迁移是什么？很多 Drupaller 对这个话题感到无所适从，新人工作之初并不会意识到这个问题的存在，而意识到这个问题的朋友也不确定怎样正确地进行配置迁移。本文就围绕 Drupal 配置迁移的原因、方式/方法及相关模块较为系统地聊聊这个话题。

如果你被以下问题困扰，仔细阅读本文将会对你有所助益

修改了一些站点配置（如站点名称、标语或任何存在于variables表中的变量值），怎么一次性部署到线上？怎么跟踪每次的修改记录？（大部分情况下你是不是直接在线上修改了:D）

在开发环境中页面布局进行了调整，修改了区块的配置（如位置、显示条件）和内容，怎么样才能快速地部署到线上（是不是手动一个一个去调整，把做过的事情重新再做一遍——这样很无趣，也很费时，还容易遗漏和出错，尤其是当这些配置之前是由其它人配置的，想要再准确地复现将会非常困难）

在开发环境中添加了几个新的字段、内容类型、输入格式、Wysiwyg配置或者视图，不想在线上再手动操作，点鼠标点到手发麻，又应该怎么办？

开发过程中需要大量实际数据，不能直接在线上操作，如何把实际数据从线上迁移到开发环境中？

……

为什么 Drupal 要做配置迁移？

大家都熟悉传统的Web开发，主要工作都是面对代码，不管是PHP、CSS、HTML或JS，几乎所有的工作都是在文件中完成。如果要更新或升级某些功能，做好备份后上传修改过的文件就能完成，So Easy!

对Drupal而言，配置迁移就不那么简单了，因为文件迁移只是 Drupal 配置迁移的一小部分，Drupal 中大部分的配置存在于数据库中。而因为线上环境的数据库时刻在变化，要把开发环境中一部分数据库的内容更新到线上而又不影响线上的内容，可不是一件容易的事。

Drupal将配置存在于数据库中是经常被Drupal老手们诟病的问题之一——最大的缺点是你不能简单地迁移数据库中的某些值或对其实行版本控制，当然这样设计的优点在于方便开发人员进行研发，以及方便使用者通过界面（而不需要修改代码）非常快速地对功能进行调配。（再一次，Drupal选择了灵活性而牺牲了其它东西）

在D8之前，Drupal没有统一的标准来规范大家应该如何存储各自己的配置数据，不同模块的配置格式和存储方式并不相同，因此也就无法通过某种特定的方式一次性迁移出所有配置数据。

（D8开始实施配置管理系统了，从此对配置的管理有了统一的规范和标准，可参见《Drupal 8 配置管理机制及新特性简介》）

而另外一点造成Drupal的配置迁移成为一个难点话题的原因在于，D8之前，Drupal的配置和内容混合存储在数据库中，很难将两者分离开，如果只是通过覆盖数据库的方式来进行操作，无法做到只改变配置而不触及内容，反之亦然。

因为设计上的原因，使得Drupal的配置迁移成了一个难点，针对于它的工作流程和解决方案也就成了一个独立的、不可回避的且颇有意思的话题。

目前有关Drupal配置迁移的处理方式已经非常成熟，D8之前的配置迁移可以参考本文，D8的配置迁移大家去学习其配置管理系统的知识并熟练运用即可。虽然D8之前没有官方统一的标准配置管理体系，但D8配置管理体系的很多理念与本文提及的各种配置迁移方式是相同的，因此学习本文也将会使之后了解D8的配置管理系统变得更为容易一些。

加强 Drupal 配置迁移自动化的优点

相信有很多朋友在做 Drupal 开发时会先在本地做一次，然后到测试环境或生产环境再做一次。当然这也不失为一种方式，对小站点的功能部署还能适用，但对于在线下进行了几周甚至几个月的工作量，再重复做一次的代价可是相当大的——前提还要是每个人都记得整段时间都按什么顺序做了什么配置。

如果大家希望更轻松、更准确、更高效、更简单地完成配置迁移的任务，不妨学会如何让配置迁移更为自行化。

以下是通过各种工具进行自动化配置迁移的一些主要优点：

减轻工作量——大量配置的部署真的可以点鼠标点到手发麻，将大量点击操作简化为上传文件会轻松很多；
降低错误率——人往往是出错的主要原因，让代码来记忆第一步操作可以大大降低出错机率；
版本控制——能够记录每一次配置的变更状况与时间，同时也更容易将配置恢复到某个时间点的备份；
快速部署——站点经不起长时间离线，将数周及数月的更新在数分钟基本数秒钟之内完成会有很爽的成就感；
……
 

Drupal 常见的配置迁移情况

之所以要谈配置迁移，是因为Web项目至少会有两个环境，即工程师的本地开发环境，和在线运行的生产环境。而通常情况下，标准的Web项目会涉及“开发-测试-线上”，即流行的 Dev-Stage-Prod 模型（也有称Dev-Stage-Live），复杂点的情况还会再加上一个QA环境。也正因为如此，才出现了配置迁移的需要。

在后文中，我们将以 Dev-Stage-Prod 环境模型为来了解 Drupal 的配置迁移方式及方向。因为这正好代表了我们平时的工作流程——工程师在各自的本地进行开发，然后部署到测试环境集中测试，反复修正最后再部署到线上。

Drupal 需要迁移哪些内容以及如何迁移

了解了需要迁移的原因，我们再看看需要迁移的内容。正如前面所说，Drupal 中不同的配置有不同的迁移方式，使用对的工具和对的方法能够达到事半功倍的效果。

迁移项	存储位置	迁移方式
模块、主题	模块、主题文件中	直接上传文件
环境变量	数据库中	结合 Features 结合 Strongarm 模块打包到文件，然后上传
视图、编辑器、内容类型、字段、区块	数据库中	使用 Features 及 Features Extra 等模块打包到文件，然后上传
*术语、用户等配置依赖内容	数据库中	可使用 Features, UUID 及 UUID Features 等模块打包到文件，然后上传。 但建议先添加到线上环境，然后将数据库下载到本地进行开发会更简单，详见下方

不要感觉要记很多东西似的，这里帮你整理一下 —— Drupal 的配置无非就是存在于文件和数据库中，存在文件中的配置很好处理，直接上传就行。而对于存在于数据库中的配置呢？很简单 —— 先转化成文件，然后上传文件。

在举例说明不同配置迁移的最佳实践前，建议大家一定记住下图——代码（配置）由下往上，数据库（内容）由上往下——这是团队协作的基本铁律，以便确保文件和数据库都是由新往旧的方向部署，从源头减少冲突的发生。

 （很多人在协作时会问这样的问题，说“我在线上修改了视图的配置，然后线下更新了视图的配置文件，这样要怎么更新呢？”这就是典型因为协作流程不规范而产生的人为冲突，一旦按照规范能够约束文件（配置）、数据库（内容）的更新方向，这类问题基本上便不会出现了。）

回到文章开头提到的几个问题，现在再来看看这些配置迁移流程建议：

站点配置或其它变量迁移 – 使用 Features 模块，结合 Strongarm 模块将要跟踪的变量打包到文件中，然后按 Dev->Stage->Prod 的方向进行更新部署
区块配置迁移 – 使用 Features 模块，结合 Features Extra 模块，将区块的配置及内容打包到文件中，然后按 Dev->Stage->Prod 的方向进行更新部署
内容类型、字段、视图、输入格式、编辑器配置等 – 使用 Features 模块（必要时结合Strongarm）将配置打包到文件中，然后按 Dev->Stage->Prod 的方向进行更新部署
内容数据的更新 – 使用 Backup and Migrate 模块或其它方式导出线上环境的数据库，并按 Prod->Stage->Dev 的方向进行内容更新
 

Drupal 配置迁移小结

现在看来，Drupal的配置迁移无非是两部分的内容，一部分已经存在于文件（如模块、主题）中的内容，直接上传文件进行更新即可；另一部分存在于数据库中的部分配置（或内容），即通过Features及其它相关模块先将配置导出到文件中，再按更新文件的操作进行即可。

别看关于 Drupal 配置迁移好像写了不少，主要便是掌握 Features 模块的用法和流程，稍加练习几次就会发现真是非常简单。

教程地址：

欢迎转载！但请带上文章地址^^