In a modern Continuous Delivery environment, it's expected that there is an
automated process for deploying code, and therefore performing database
migrations. This is all straightforward.
I haven't been able to find any good solutions for automatic rollback
though. The main problem that I see is that there is (AFAIK) no easy way to
definitively know which migrations to unapply to roll back to the previous
verison. If you try to rollback from the new N+1 version, you have the
migrations, but no recording of the previous version's state. If you
rollback from the previous N version, you don't have the new migration
files to do the DB rollback.
What I'd really like is a way of recording a 'db migration checkpoint'
which could be generated per-release (or whenever else you care to
checkpoint your migration state), and would say something like `v1:
{app1:0002,0003, app2: 0004}, v2: {app1:0004, app2: 0005, 0006}`, thus
letting me roll back all of the migrations in the v2 deploy with a single
command.
Does anyone have suggestions or references here? I may try rolling the
above solution if there is no prior art, but I want to avoid reinventing
the wheel here, as it seems that this issue must have been hit by many
other users before me.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/6cafecca-2c71-4a6f-b93b-fe3e64847bc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
