Database migrations are a tool created to work better with databases, especially under agile development. Instead of having a database with a "fixed" schema, which is deployed rarely by merging manually with tools like Redgate's SQL Compare, variations are stored in numbered SQL files as schema or data changes. In this way, they can be applied automatically in continuous deployment, and still be accurate, instead of having complex "big-bang" deployments which are manual and costly.
The dotnet-core environment offers migrations via Entity Framework, which is great. However, it leaves out in the cold those of us who can't use core yet, or do not want to use EF. It is also true that there are plenty of other migration tools written in other languages, but they are often integrated and in any case, did not feel "native" enough for us.
Therefore we spent a little time building our own migration tool which is fast, simple and opinionated: Badgie Migrator. We are announcing its open source release today so there can be a good and reliable migrator for dotnet.
If you want to try it out you can simply add it as an integrated tool with
dotnet tool install -g Badgie.Migrator. Clearly, it is after all a dotnet-core tool but it only needs the core runtime in order to run, and it will work with any dotnet project. In fact, it will work with any platform or language. At the moment we support Postgres and Sql Server, but adding a new database is simple and can done with an hour of coding. If you want to support another databse, can you add a PR so everyone benefits?
Here are a few more features. We treat the migrations as an historical sequence of changes that happen to the database. As such, there is no concept of "up" and "down" migrations. Both are simply changes to the database, which only progresses in one direction in history. To further clarify this: the changes are treated as immutable. Once you ran one, there is no concept of "undo" -- in order to achieve that you need to create a new migration that performs the opposite change. While this might seem awkward to those of you that are used to the up/down pattern, having a clear history of what happened and every database follow exactly the same history is incredibly reliable.
Another important feature, which is not enforced but strongly recommended, is that all changes be idempotent. They need to apply their change once and once only. Applying it mutliple times should not have any effect. We do keep track of what was run inside a small table in the database, but being sure that applying a change can do no harm is something that builds a lot of confidence, especially when continuously deploying.
Furthermore, we do check the CRC (in fact, as simple MD5) of the contents of each migration to ensure that no one changes history by modifying the scripts. Why are we obsessed by this? Imagine you have 10 developers and someone pushes a migration. Three of the developers run it instantly, and the CI runs it on staging. Now someone changes the same migration. CI runs the new migration and is now in an unpredictable state since the new version is meant to run on the pre-migration version of the DB. Of course, immutability will often make this work anyways. However, imagine 4 developers who did not run the first version now run the second version. Now developers have out of sync schemas among themselves and with the build server. This is bad!
This is why this won't happen with Badgie Migrator. When the new version of the same migration is "caught" by the build server, it breaks the build. The offending developer can now revert the build and add a proper second change as needed, or, in some cases, the new version can be manually forced. After all our system is supposed to help you, not prevent you from doing your job.
Badgie Migrator is a simple but opinionated tool. It's open to the community and we would like to make it successful. Use it. Abuse it. File bugs. Add patches. We welcome all! At Badgie we will always support Open Source.
About Badgie. Badgie is the world's premier developer gamification system, We aim to improve the whole development experience to bring positive feedback in the sea of negativity in which developer live. While Badgie 6–8 weeks away from MVP release, please sign up below to receive weekly progress reports and be one of the first to get in our beta!
A software engineer & Stack Overflow alumnus. Co-founder of Badgie. I write about software development, coding, architecture and team leadership. I also speak at conferences worldwide.
Software engineers go crazy for the most ridiculous things. We like to think that we’re hyper-rational, but when we have to choose a technology, we end up in a kind of frenzyRead more…