作为Capital One的软件工程师，我为我们的商业银行开发了新的应用程序。我和我的团队最近以银行关系经理和分析师的网络应用程序的形式构建了一个数据管理工具。该团队包括两名软件工程师，四名数据分析师和科学家，以及一名产品经理。我们在原型设计的前五个月中进行了交叉协作，以定义满足用户分析需求的数据库模式。

在此期间，我的技术主管和我决定探索模式迁移工具，以便在我们设计数据库时简化开发。我们为数据库确定的是Flyway。 Flyway是一个开源数据库迁移工具，使开发人员能够将版本控制实践应用于他们的数据库。虽然我们查看了其他几个架构迁移工具，但这个工具似乎最适合我们的特定用例。

为什么我们需要架构迁移工具？

架构迁移和工具的好处
随着敏捷方法的发展并在21世纪初被广泛采用，对模式迁移工具的需求变得更大。允许数据库设计随着应用程序的发展而发展的技术允许工程师更有效地迭代软件。

在此期间，数据库迁移工具越来越受欢迎。架构迁移为数据库添加版本控制功能。迁移是逐步管理的，并且是可逆的。 Flyway等工具可以在处理多个环境（例如dev，test和prod）或切换分支时阻止数据库模式不匹配。它们允许开发人员从头开始重新创建数据库，这在创建新环境时很有用。迁移工具可确保应用程序将以数据库的当前状态运行。例如，这可以防止开发人员遇到列未找到错误。

Flyway概述

Flyway对数据库所做的更改称为迁移。在Flyway中，迁移有两种类型;它们可以是版本化的也可以是可重复的，版本化是最常见的。

版本化迁移具有版本，描述和校验和，并且按顺序应用一次。可重复迁移具有描述和校验和，并在每次校验和更改时重新应用。当需要更改数据库的模式时，开发人员会添加SQL脚本，通常位于db / migrations目录中。

将Flyway指向数据库后，它开始扫描应用程序的文件系统以进行迁移。它第一次运行第一次迁移时，会创建一个名为schema_version的表，其中包含多个列，包括版本，描述，脚本和校验和。该表用于跟踪数据库的状态。迁移根据其版本号进行排序并按顺序执行。

应用每个迁移后，schema_version表会相应更新。每次Flyway扫描应用程序的文件系统进行迁移时，它都会查询schema_version表以查看数据库所处的版本，并相应地升级数据库。

可用但未应用的迁移称为挂起迁移。

我们的用例的优点

使用迁移工具的最大优点是，它确保始终使用数据库的匹配状态提供软件版本。这对我们的产品尤其重要，因为我们快速迭代并且需要能够快速，自信地部署功能以收集用户反馈。

将Flyway集成到现有项目中很简单，因为设置所需的配置很少。该过程中的最小步骤包括通过在配置文件conf / flyway.conf中指定url，username和password将工具指向数据库。

Flyway严格的迁移规则强制执行纪律，因此也是最佳实践。这可以类似于禁用git中的force push。严格的规则Flyway强制执行与在部署到环境后保持SQL文件不可变的做法一致。由于我们的团队致力于遵循最佳软件工程实践，因此Flyway适合我们的产品。

作为对数据库迁移工具缺乏经验的人，Flyway易于学习且易于使用。以增量方式捕获所有架构迁移。 API公开了六种基本方法 - 迁移，清理，信息，验证，基线和修复。 （您可以在此处了解有关这些命令的更多信息）。这些方法使我们的团队能够将Flyway集成到我们的CircleCI部署命令中。

最后，Flyway既灵活又强大 - 它只需几个简单的命令即可修改列名，并将数据从一列传输到另一列。

 

我们的用例的缺点

如前所述，Flyway在迁移文件更改方面非常严格。在签入之后更改迁移并不容易。更改文件的内容或名称可能会导致每台具有该文件先前版本的计算机上的迁移失败。

即使需要进行简单的更改（例如调整字段名称），通常也需要新的迁移脚本。作为我的技术主管和我快速迭代，我们发现自己每周都会添加Flyway Scripts。这导致我们的迁移文件夹中存在过多的文件。在我们的原型设计的前五个月中，我们的应用程序仅部署到开发环境中，几乎不需要在我们的应用程序中逐步保留微小的模式更改。

值得一提的是，可以编辑以前执行的迁移，但只有高级用户才能这样做，因为它需要更新schema_version表中的行以调整校验和值。
当团队成员在不同分支上并行工作时，版本号可能会发生冲突。有一些过程可以解决此问题，例如使用版本号的时间戳而不是整数，并设置选项outOfOfOrder = true。

撤消迁移（例如删除先前迁移中添加的列）可能会非常棘手，并且通常需要开发人员创建数据备份。

 

我们应用的结果

事后看来，如果我们稍后在应用程序和数据库设计成熟时将其集成，我的团队可以更好地利用Flyway。为了在原型设计的第一阶段实现快速迭代，我认为我们的双人工程团队只需要一个定义初始模式的SQL文件，一个模拟数据文件和一个用于加载我们的表的脚本就足够了。模拟数据集。

使用这种方法，我们可以通过修改git分支中的初始模式和模拟数据文件来更改模式。在每次合并以构建或部署到环境之后，通过CircleCI启动的步骤，数据库将使用模式和模拟数据集进行转储，拆除，重新创建和重新加载。我认为Flyway可以最好地应用于存在多个环境的应用程序中，并且围绕数据库更改的决策的波动性较小。

Flyway是一种有价值的工具，许多优点都超过了它们的缺点。在我们的产品开发过程中，它确保我们的应用程序始终以数据库的匹配状态运行。从我们的主分支中提取更改时，遇到数据库不匹配错误的风险几乎为零。我们的迁移文件夹也是历史记录;我们的团队能够跟踪我们的数据库设计随时间的变化。

作为我的技术主管，我与我们团队的数据科学家合作，提供数据库状态的透明度是关键。在我们的CICD平台的帮助下，每次迁移的部署导致我们几乎没有停机时间。

Flyway是我使用迁移工具的第一次经历，它被证明可以有效地管理数据库的状态。如果在正确的阶段集成到应用程序中，它有可能更加强大。

 

原文 : https://medium.com/capital-one-tech/database-migrations-with-flyway-16b6478e55a6