在项目迭代的过程中，数据库结构常常需要跟随业务需求的变化做出调整，尤其在迭代的初期阶段，加一个字段减一个字段的需求更是家常便饭。在小型团队中，往往是负责开发功能模块的程序员在完成本地开发环境数据库的变更后，直接到生产环境中更新数据库结构。

这样的工作方式虽然看起来很轻松，但却可能给你的团队带来不小的麻烦。

首先，是团队成员之间数据库环境的同步问题。为了使团队中的其他开发者及时了解数据库环境的变化，你不得不在每一次修改数据表结构后，都告知整个团队你对当前数据库所做的变更，并确保所有人正确更新了他们开发环境中的数据库。

另外，变更数据库的程序员还需要同时对可能存在几个环境负责，如测试环境，项目展示环境（UAT）等都需要一一进行更新，靠人手动去维护成本高，速度慢，并且容易出错。在持续交付已经逐渐成为软件开发标准流程的今天，再继续这样的做法实在不够敏捷的。

不过幸运的是，现在我们已经有了成熟的方案来应对这样的麻烦。既然我们可以通过版本控制的方式让代码同步变得更加轻松，那为什么我们不用同样的方式来管理数据库的变更呢？这就是 Database Migrations。下面我将以Doctrine Migrations为例，来说明我们应当如何解决这样的问题。

• 安装

  composer require doctrine/migrations
  
  

  Doctrine Migrations 提供了两种调用方式供你选择。一个是注册命令行工具, 另外，你也可以选择直接使用 Doctrine Migrations可执行文件(.Phar)， migrations.phar 默认会从当前目录下的 migrations-db.php 中读取数据库配置文件。

  

• 常用命令

  migrations：generate //生成变更脚本文件
  
  migrations：migrate  //更新到最新版本
  
  migrations：migrate prev  //回滚到前一个版本
  
  migrations：migrate YYYYMMDDHHMMSS  //更新到指定版本
  
  

  生成脚本的文件名格式为Version+时间戳，内容由 up 和 down两个方法组成，以便数据库可以在多个版本之间自由切换。另外， Doctrine Migrations 数据库操作的方法由 Doctrine DBAL 提供，详细用法查阅 Doctine DBAL 文档即可。

  

• 实现原理

执行 migrations：generate 时，Doctrine Migrations 会在当前环境的数据库中创建一张数据表用于保存当前数据库的版本。当执行 migrations：migrate 时， 工具会在其目录中查找是否有更新的脚本，如果有则执行它。

最后，使用Migrations工具维护数据库版本最重要的一点在于 永远不要手动修改数据库中的表结构。其实在很多开发框架（如：Symfony，Laravel）中，都集成了DB Migrations工具，利用这样的工具，我们能够以脚本化的方式来管理数据库的变化，并且将这些变化纳入到代码版本控制中。当我们将新的代码同步到其他环境时，我们只需要在更新代码后执行Migration脚本，就能将这次提交内产生的数据库变换同步到当前环境中。甚至我们可能并不需要手动来执行这行命令，在发布项目后，项目构建工具会自动帮助我们执行命令，把数据库更新到最新的版本。