I'm interested to hear more about how this works when you have multiple developers working in parallel on several branches. What you describe sounds like it would only work in a very linear development model.
If you mean "multiple" to be "more than a dozen", then yeah, you're right that you might need to think harder. For small projects though (which could be defined as "anything small enough to conceivably work with an ORM"), it works great.
I guess that one necessary assumption is that your shop doesn't have a strong requirement for Code Ownership (in capitals). Since anybody can change the schema, and thus the object model, anybody needs to be able to propagate out their changes as far as necessary to keep the tests running and the build unbroken.
it's not about code ownership or problems with who is or is not allowed to touch the schema. the problems come from things like even numbering the migrations, keeping track of dependencies between migrations and the order they need to be applied in, possibly needing to rollback certain migrations, etc.
That's actually the problem that this system addresses. Each change script has from and to versions, so it's dead simple to move from one schema version to another. So when you go to roll out to production, your build will notice that it needs to go from version 104 to 116, and will run the script 104-105, 105-106, etc. until the version number is where it belongs.
Basically, you can know with certainty that you can move from any numbered version to another by simply running the intervening scripts.
I understand that part, that's what I meant about it working in a linear fashion. What happens when two developers both start with schema 104 and develop in parallel? Which one of them becomes schema 105?
Ah. Since the scripts are under source control, it's simply a matter of resolving conflicts when you check in.
But then, since you'll generally have a continuous build is running on 5 minute intervals, it's pretty rare to have two independent schema changes in the same script.
Only one migration can be applied to a database at a time, so the migrations will need to be arranged sequentially at some point. With the scheme above, I guess this involves lots of file renaming...
