feat: Support auto rollback #87
Description
Been thinking a lot about how:
- migrations can be processed automatically on server start
- rollbacks can be processed automatically on server stop
Right now, this package already supports running migrations automatically on server starts because the lock file prevents two servers running the migrations at the same time, this locking is also somewhat useful for automatic rollbacks. However, in the case of automatic rollbacks, the old server would need to understand which migrations the new server required rolling back. See example timeline below.
| Time | Server | Action | Version | Migration | Desired Migrations | Processed Migrations | Available Migrations |
|---|---|---|---|---|---|---|---|
| 1 | A | Start | 1 | Up: [1] | [1] | [] | [1] |
| 2 | B | Start | 2 | Up: [2] | [1, 2] | [1] | [1, 2] |
| 3 | A | Stop | 1 | Down: [] | [1, 2] | [1, 2] | [1] |
| 4 | C | Start | 1 | Up: [] | [1] | [1, 2] | [1] |
| 5 | B | Stop | 2 | Down: [2] | [1] | [1, 2] | [1, 2] |
This shows that:
- stopping a server runs the down function on undesired processed migrations
- starting a server runs the up function on desired unprocessed migrations
Starting a server would store the "available migrations" on the server as the "desired migrations" in the database that holds the state of the migrations.
Note that multiple servers starting at the same time on the same version causes no issues because of the migration lock table which ensures that migrations and rollbacks can only occur on one server at a time. This setup does however assume that old servers are only stopped once new servers have started.
Where old servers on newer versions have been stopped before new servers on older versions were started, it's possible to start up a new new server on the newer version once the new servers on the older server have started, then stop the new new server to get the automatic rollback.
For local development I'd probably recommend having code that recreates the database, runs migrations, and creates "seed data" in the database. For testing, again I'd probably recommend recreating the database and running migrations before all tests, then clearing the database contents before each test, then seeding only the required data for each test case. These recommendations avoid the need for rollbacks, this is important to avoid in local development because only one machine/container is used and migrations may only exist on certain branches.