I'd also recommend against splitting your models into a separate repo.
There's a decent article on migrations without downtime
here: http://pankrat.github.io/2015/django-migrations-without-downtimes/
Essentially "don't run your migrations at the same time as you deploy" and
"split deployment/mi
I wouldn't recommend tying your repository structure to your deployment
needs. Put that in the deployment script instead. You can see if any
migrations are pending with manage.py migrate --list
On Wed, Apr 20, 2016 at 1:59 PM, wrote:
> My thought process for separating the models into a separate
My thought process for separating the models into a separate repo is
something like this:
I am predominately putting up our (heroku) maintenace page when migrations
are run
If the models are in separte repo, I only need to run migrations when that
repo is deployed. If migrations are not deploy
This can help you.
https://medium.com/@healthchecks/deploying-a-django-app-with-no-downtime-f4e02738ab06#.dmyf7lk8y
El martes, 19 de abril de 2016, 3:37:19 (UTC+2), bliy...@rentlytics.com
escribió:
>
> Hey,
>
> I have two issues I'm looking at solving at work, and I'm looking for a
> couple sugg
On Wednesday, April 20, 2016 at 3:19:59 AM UTC+5:30, Avraham Serour wrote:
>
> you can easily do code reloading with uwsgi graceful reload, no user will
> ever know you reloaded your application, no need to juggle, I mean you
> aren't using mod_wsgi or anything like that right?
>
mod_wsgi in d
Also, you don't need to restart Apache / nginx or whatever, or delete the
pyc files, just reload uwsgi / gunicorn.
On Tue, Apr 19, 2016 at 6:48 PM, Avraham Serour wrote:
> you can easily do code reloading with uwsgi graceful reload, no user will
> ever know you reloaded your application, no need
you can easily do code reloading with uwsgi graceful reload, no user will
ever know you reloaded your application, no need to juggle, I mean you
aren't using mod_wsgi or anything like that right?
On Tue, Apr 19, 2016 at 10:07 PM, Fred Stluka wrote:
> Ben,
>
> I minimize downtime as much as possi
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 pu
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
9 matches
Mail list logo
