如何在使用功能分支时使用Flyway [英] How to use Flyway when working with feature branches

问题描述

我们最近开始使用功能分支来处理我们处理的每个故事。这些是独立的，我们的项目经理然后决定哪些故事将组成一个版本。这意味着我们确实知道故事最初投入生产的确切顺序。

We have recently moved to using feature branches for each story we work on. These are as independent as possible, and our project manager then decides which stories will make up a release. This means that we do know the exact order in which stories will go into production initially.

在Flyway有一个标准的方法来处理这个问题吗？我已经阅读了FAQ，它讨论了如何对生产数据库的改变是线性的，这是正确的。然而，我不知道团队成员如何决定什么版本号给他们的迁移，而他们在他们的功能分支。此外，我们需要在发布之前合并到我们的集成分支和master时手动重命名迁移文件。

Is there a standard way of dealing with this in Flyway? I have read the FAQ which discusses how the change to the production database will be linear, which is correct. However I'm not sure how team members would decide what version numbers to give their migrations while they are working on their feature branch. Also we would need to manually renames the migration files when we merge to our integration branch and master before the release.

推荐答案

具有与您将获得的版本号相同的迁移scrtipts：

You cannot have migration scrtipts with the same version number as you will get:

找到多个迁移版本'xyz' ...）

Found more than one migration with version 'x.y.z' (Offenders: SQL ...)

这里是一个解决方法我建议：多个开发人员正在使用相同的版本，说 1.0 但是不同的功能。我想你正在使用一些问题跟踪器，为每个问题添加ids，如 FOO-16 。当开发人员处理该问题时，迁移脚本称为 V1.0.16__my_greatest_feature.sql 。这种方式（假设每个功能/分支都有自己的问题）没有冲突。

Here is a workaround I suggest: multiple developers are working on the same version, say 1.0 but on different features. I guess you are using some issue tracker that adds ids to each issue, like FOO-16. When a developer works on that issue, the migration script is called V1.0.16__my_greatest_feature.sql. This way (assuming each feature/branch has its own issue) there are no collisions.

此外，我假设数据库迁移脚本是independentnt和不重叠，这不是这样的情况下，你会有问题，而将一切都合并到一个稳定的版本。

Also I am assuming that database migration scripts are independnt and non-overlapping, but if this is not the case you'll have problems while merging everything to a stable release.

因此在一个稳定的版本中，你有几个迁移脚本， c $ c> V1.0.16 ， V1.0.27 ， V1.0.101 FOO-16 ， FOO-27 和 FOO-101 被选中） - 飞行不会在乎。所有未使稳定版本 1.0 （例如 V1.0.35 ）的所有功能都应重命名为目标下一个主要版本（例如 V1.1.35 ）。

So in a stable release you have several migration scripts with gaps, e.g: V1.0.16, V1.0.27, V1.0.101 (if FOO-16, FOO-27 and FOO-101 were chosen) - Flyway won't care. All the features that didn't make it to a stable release 1.0 (e.g. V1.0.35) should be renamed to target next major release (e.g. V1.1.35).

这篇关于如何在使用功能分支时使用Flyway的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！