Re: No Downtime Code Releases

[Fred Stluka]

Ben, I minimize downtime as much as possible by doing things in advance like copying all of the new files to a staging area on the PROD system, automatically inserting PROD passwords, running collectstatic, dumping the DB in case of problems, etc.  Then, I put up the maintenance page, quickly rsync the new files into place, run migrations, and hide the maintenance page. We used to shoot for releases with no downtime by copying the *.py files into place, and letting Django notice and re-load the *.pyc files automatically, but we ran onto some strange issues sometimes.  Seems like Django continued to use some of the cached *.pyc files for a while. It's worked out better to always delete all *.pyc files before rsyncing the *.py files into place, and to always restart the Apache server just before hiding the maintenance page, so we're sure everything gets reloaded cleanly. This has also been a good idea as we've added more caching: - Template files - Fully assembled pages - DB data - etc. Hope this helps, --Fred Fred Stluka -- mailto:f...@bristle.com -- http://bristle.com/~fred/ Bristle Software, Inc -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates. On 4/19/16 12:12 PM, Avraham Serour wrote: I don't think you would gain anything by separating your models to a different repository, what are you trying to gain here? if you put a maintenance page when doing migrations it won't matter if the models are from a different package or not. you could still run migrations on a live system, you just should take into account that there could still be parts of the system using something is not there yet/anymore so you should break migrations into 2 whenever you are adding or removing something. when adding a model or field you should first run the migrations and only after that deploy the new code using the new model/field when removing something you should first stop using it and then migrate. you could plan your deployment/releases and know in advance if you are either adding or removing something and never add and remove in the same release meaning commit and deploy the model and only after that commit the code using the new model or you can checkout the code on the side and runs migrations using this separate env, this way you could add a new model and use it in the same commit. for removing you can just do it backwards. Avraham On Tue, Apr 19, 2016 at 3:38 AM, <bliyan...@rentlytics.com> wrote: Hey, I have two issues I'm looking at solving at work, and I'm looking for a couple suggestions as to how other people have solved this.  The two things are: * scale out their django installation to allow for smaller releases (I'm thinking microservices, but it could also be internal django apps or who knows what else) * minimizing the impact of migrations during releases (aka we want to be able to release in the middle of the afternoon Currently we put up a maintenance page whenever we are doing database operations (aka migrations).  This seems like a recommended best practice. One way I was thinking about addressing this issue was to break all of our models out into a separate repo.  That way we'd only need to deploy migrations when the models themselves have deployed.  For code that needs the models, we could pip install the repo as an app and away we go.  Likewise it seems like I could break up different parts of our app via a similar strategy. Does this seem viable?  How have other people solved this kind of problem? Thanks, -Ben -- 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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/e5fd0359-9e8b-4cce-b3e1-4880951a2a8e%40googlegroups.com. 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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/CAFWa6tLHi%2BcnsvxheusPSx1EeVdfAt-ntS%2BkDs5bbG0%2BFYc3hQ%40mail.gmail.com. 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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/5716820F.8000208%40bristle.com. For more options, visit https://groups.google.com/d/optout.