On Feb 10, 2016 12:50 AM, "Tobias Dacoir" <falc...@gmail.com> wrote: > > We've build a small web application using Django 1.8 over the past couple of months and we are going live with version 1.0 soon (one last closed beta test is coming up). > So far we have deployed it on an Ubuntu VM (in Azure) using Apache / Nginx and a local MySQL Server. > > I've already found some good tutorials on how to properly set it up ( http://rogueleaderr.com/post/65157477648/the-idiomatic-guide-to-deploying-django-in#disqus_thread ) however what I am mising now is how to handle updates to our code. > > For our development server we have a git hook that automatically deploys new commits to the server. However that often requires manual interaction - running manage.py makemigrations etc. Sometimes Django also does not pick up our changed models and we have to manually fiddle with the Database in order to get it back running. We even had times where we lost all our data since it was easier to just start with a new database. >
You need to fix your deployment process before going live. What are you doing where Django doesn't catch changed models? That's a red flag for me. Either you're doing something strange with your models, your code is not updating the way you think it is, or you've uncovered a bug in Django and should report it. You shouldn't need to run 'makemigrations' anywhere but in your development environment. Are your migrations carried through as part of your Git hook update? It sounds like they aren't. If your development servers are seeing database changes, your production servers should probably get those same changes in most cases. Squashing migrations should be performed in development before the final updated deployment package is out together and then sent to production after testing. I'd recommend setting up test servers which are clones of your production servers (maybe even including a snapshot of your live data). Your changes on your development servers should be tested on the test servers, including the deployment process. Git alone may not be enough to complete a deployment (probably not a lot of control in a failure scenario), but something like Fabric may help. There are lots of ways to deploy though. Many use mass configuration managers like CFEngine, Puppet, Chef, and Ansible. > Obviously this can't happen once we are live and obviously we want downtime to be as small as possible. So is there any guide on how to update code of a live, deployed Django application? > Depends on the available infrastructure. For a single server, you'll incur downtime for shutting down the web service, applying migrations, and bringing things back online. If you have a load balancer in use, you may be able to pull out a single real server and update it, and put it back with little or no interruption. Obviously you'll have to account for existing session and shared databases among servers in that case. If your database changes are something simple like adding columns or tables that aren't referenced in existing code, you may be able to perform the migration live, then update the code, and reload the web server process, incurring minimal, if any, downtime. Really depends on what your DB changes are. I would hope that with a 1.0 non-beta release that your DB structure would remain stable, though. Test, test, test! Backup, backup, backup! -James -- 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/CA%2Be%2BciViVX730QiFkTCMWW3jSOj%2B_PVJFWbP9jJX8%2BmX-KUvBw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
