因为设计上的原因，使得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 中不同的配置有不同的迁移方式，使用对的工具和对的方法能够达到事半功倍的效果。