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 > <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/CAFWa6tLHi%2BcnsvxheusPSx1EeVdfAt-ntS%2BkDs5bbG0%2BFYc3hQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
