在复杂的分支系统中迁移数据库 [英] Database migrations in a complex branching system
问题描述
在我们当前的开发工作流程中，我们引入了数据库迁移（使用 Ruckusing ）来让我们的开发人员'db模式同步。它工作的很好，使用起来非常简单，但现在我们已经切换到git作为VCS，我们正面临数据库版本控制系统中的下一个问题。
检出分支时这已经发展了一段时间，可能会发生这样的情况：数据库模式已经从我来自的分支架构中分离出来了。这在某些情况下导致数据库冲突。从逻辑上讲，我们似乎需要根据之前的分支来运行迁移，但这可能会变得非常复杂，并且会确实遇到一些人遇到的问题。据我所知，没有一个数据库迁移系统是支持分支的??
当切换到我们可能需要运行的功能分支时，增加了复杂性一些迁移，而其他下来...从技术上来说这似乎不可能使用我们目前的dbmigration脚本，有没有任何理智的选择？在一个非常活跃和分支的开发系统中，是否有任何首选的数据库迁移工作？增量迁移真的很烂。在像你这样的复杂环境中，它确实不起作用。你可以使它适用于简单的分支模式，但对于任何复杂的事情来说，这将是一场噩梦。
我现在使用的系统采用了不同的方法：我们无法进行增量迁移，但只能从基线重建数据库。在初始开发期间，该基线是一个空数据库，在维护期间，它是活动数据库的副本（从转储中恢复）。我们只有一堆SQL和XML脚本，我们将这些脚本应用于基线以获取当前系统（实质上是迁移，但不旨在以增量方式运行）。更新或切换分支非常简单：核对数据库，加载转储以建立基线，运行脚本。
这个过程并不像运行很少有迁移，但速度很快。花费足够长的时间，你可以去喝一杯咖啡，但是没有足够的时间去享用午餐。
巨大的优势在于，从nucking数据库开始意味着过程是完全独立于历史的，所以它不需要知道或关心跨越分支，及时回溯或其他任何事情。
当你发布一个版本在活着的时候，你显然做的事情略有不同：因为系统已经在基线（基线被定义为实时系统的状态！），所以您不会加载数据库或加载转储。您只需运行脚本。在此之后，做一个新的转储，作为开发的新基准。
In our current development workflow we have introduced database migrations (using Ruckusing) to keep our developers' db schema's in sync. It works great, is pretty straightforward in use but now we have switched to git as VCS we are facing the next problem in our database versioning system.
When checking out a branch that has been in development for some time it might happen that the database schema has diverged alot from the schema in the branch i'm coming from. This causes database conflicts in some cases. Logically it seems that we need to run migrations depending on the branch we were on previously but that can get complex really fast and will run into problems with some people for sure. And as far as i know there isn't a db migration system that is branch-aware??
Added complexity comes when switching to a feature branch we might need to run some migrations up while other down ... technically this seems impossible using our current dbmigration scripts, are there any sane alternatives? Are there any preferred ways of working with database migrations in a very active and branched development system?
I think the whole idea of incremental migrations is pretty rotten, really. In a complex environment like yours, it really doesn't work. You could make it work for simple branch patterns, but for anything complicated, it will be a nightmare.
The system i'm working with now takes a different approach: we have no ability to make incremental migrations, but only to rebuild the database from a baseline. During initial development, that baseline was an empty database, and during maintenance, it's a copy of the live database (restored from a dump). We just have a pile of SQL and XML scripts that we apply to the baseline to get a current system (migrations, essentially, but not designed to be run incrementally). Updating or switching branches is then very simple: nuke the database, load a dump to establish the baseline, run the scripts.
This process is not as quick as just running a few migrations, but it's quick enough. It takes long enough that you can go and get a cup of coffee, but not long enough to get lunch.
The huge advantage is that starting by nuking the database means the process is completely history-independent, so it doesn't need to know or care about crossing branches, going back in time, or anything else.
When you take a release live, you obviously do things slightly differently: you don't nuke the database or load a dump, because the system is already at the baseline (the baseline is defined as the state of the live system!). You just run the scripts. And after that, make a fresh dump to be used as a new baseline for development.
这篇关于在复杂的分支系统中迁移数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
