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 deployed in my non-model repos, I would skip putting up the maintenance page. Most of our db changes are to accommodate back-end data warehousing. The other/additional way I was thinking about spliting our app up was separating the backend processes from our front end API's that primarily deal with security and authorization. The security and authorization models do not change very often, so an app that only deals with that part would not need to restart very often. That said, there are a couple models that we need to run that that are shared with our back-end processes. Having those models split out would potentially let us pip install them into a separate service. However it sounds like you guys are saying there are other concerns--namely flushing the pyc files. I'm not exactly sure this is relevant to me since we are using heroku, and an entire new server/slug is deployed when we do a code release. It's not clear to me if that slug deployment would drop connections or cause other kinds of problems. On Tuesday, April 19, 2016 at 9:13:30 AM UTC-7, 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, <bliy...@rentlytics.com <javascript:>> > 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...@googlegroups.com <javascript:>. >> To post to this group, send email to django...@googlegroups.com >> <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/e5fd0359-9e8b-4cce-b3e1-4880951a2a8e%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-users/e5fd0359-9e8b-4cce-b3e1-4880951a2a8e%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 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/ac5251d4-f382-43ca-9250-c08ba60eebfc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
