Hi, May both of you try to implement "blue-green deployments", and switch only if all tests are OK. You may also be interested in running a test deployment in a testing environment prior to production. Don't know of a solution integrated into django.
On Friday, April 14, 2017 at 2:26:51 PM UTC-4, Andrew Godwin wrote: > > Hi Paul, > > I have tried this in the past, but it's basically an unsolvable problem in > the generic case. Databases do not take well to snapshotting or changing > schema, and some operations are naturally irreversible. If you find a way > that works well, I suggest you write it up so others can learn from it! > > Andrew > > On Fri, Apr 14, 2017 at 10:33 AM, <[email protected] <javascript:>> wrote: > >> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/django-users/6cafecca-2c71-4a6f-b93b-fe3e64847bc2%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/362cbdc0-9dee-4c1b-a68d-b671eed49336%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
