What gold! The essential piece of your logic is here:
> Enforce a development process that ensures that (roughly speaking) all > database changes result in a new column, and where the old cannot be > removed until a later update cycle. All migrations populate the new column. I assume that "enforce" is a software engineering management thing, not clever CI/CD code. To change a column, you essentially do it in two steps: - Create new column with migrations, and do a release to the environment. - Drop old column with migrations, and do a release to the environment. If you are only dropping an old column, it might go like this: - Drop the old column from the model, but not from the database (e.g. assure that makemigrations has not been run), test and deploy. - Add the migration that does away with the old column - test and deploy. Personally, I have a similar career trajectory, but from systems programming in C/C++ to software architect for webapps. Understanding C/C++ and Linux gave me a capability of working with both developers and system guys. I think it was in 2013 that I did the presentation that started to kill Adobe ColdFusion (which I didn't want to learn). I instead the next 6 years getting all of our applications moved to Django, now we are in transition to Python 3.6 and Django 2.2, with our first cloud system coming up. On your slow cloud builds, I have an architecture that may help. The basic idea is easy to explain: - Do system provisioning through ansible roles - Install all the roles needed for all of your stacks when you build the AMI, but only run some of them, e.g. the basics. - If your build time in the cloud takes too long, the architecture assures you can easily pivot to prebaking more into the AMI, but you are not assuming you will have to. Of course, you still cannot go to milliseconds. But it allows you to trade building ahead of time and building during bring-up to nearly your hearts content. Even the role that knows how to install a Python webapp is already on the AMI. -- 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/0799c1b8-04cc-424e-a08d-f124eab03ce7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
