Introduction
Evolving databases has been one of the major challenges for software development. Often times, regardless of our software development methodology, the database follows a different change management process. Despite our best efforts, few tools and practices have been able to change that. The tools of the past have been GUI centric, proprietary for a particular database and/or carried a steep license cost. Yet, at the end of the day they suffered from the same challenges.
Recently, a few tools arrived and changed all of that. They did so by embracing simplicity and a few simple rules for database evolution to follow. A couple of good examples are Rails Migrations and dbdeploy. Both tools are similar in purpose, but quite different in implementation. The MyBatis Schema Migration System draws from both and seeks to be the best migration tool of its kind.
Goals
To achieve a good database change management practice, we need to identify a few key goals.
Thus, the MyBatis Schema Migration System (or MyBatis Migrations for short) seeks to:
- Work with any database, new or existing
- Leverage the source control system (e.g. Subversion)
- Enable concurrent developers or teams to work independently
- Allow conflicts very visible and easily manageable
- Allow for forward and backward migration (evolve, devolve respectively)
- Make the current status of the database easily accessible and comprehensible
- Enable migrations despite access privileges or bureaucracy
- Work with any methodology
- Encourages good, consistent practices