Cómo manejar las migraciones en CI de una aplicación django

Tenemos un entorno de continuous integration con git para una aplicación django.

Algunas veces necesitamos hacer modificaciones a nuestros models y migrar los cambios en el db (pre / pro).

En nuestro gancho hacemos:

python manage.py migrate 

Que obtiene las migraciones previamente creadas en nuestro entorno de desarrollo local y las aplica. Pero me he dado count de que a veces migrar pregunta por la interacción del usuario. ES DECIR:

migraciones (desarrollo local)

 (project-name-develop)lostcitizen@project-name:~/dev/project-name/project-name.git$ ./manage.py makemigrations Did you rename publication.writer to publication.author (a ForeignKey)? [y/N] y Migrations for 'publications': 0017_auto_20151117_1050.py: - Rename field writer on publication to author 

migrar (remoto)

 (project-name-develop)lostcitizen@project-name:~/dev/project-name/project-name.git$ ./manage.py migrate Skipping creation of NoticeTypes as notification app not found Operations to perform: Synchronize unmigrated apps: landing, about, publications, [...] Synchronizing apps without migrations: Creating tables... Running defernetworking SQL... Installing custom SQL... Running migrations: Rendering model states... DONE Applying publications.0016_auto_20151116_1650... OK Applying publications.0017_auto_20151117_1050... OK The following content types are stale and need to be deleted: publications | hashtag Any objects related to these content types by a foreign key will also be deleted. Are you sure you want to delete these content types? If you're unsure, answer 'no'. Type 'yes' to continue, or 'no' to cancel: yes 

Mi pregunta es cómo manejar esto para que sea "seguro" para la implementación automatizada. Puedo hacerlo manualmente, pero quería abstraer esto del rest del flujo de trabajo de los desarrolladores.

Creo que no es posible solicitar la interacción del usuario en un git hook, así que pensé en usar esto:

 yes | python manage.py migrate 

Pero no creo que sea seguro usarlo. ¿Qué piensas?

Saludos,

Los commands de Django tienen un conmutador --noinput para ayudar con esta situación. Migrar también lo admite (ver python manage.py migrate --help)

Puede usar la opción --noinput para suprimir cualquier --noinput usuario:

 python manage.py migrate --noinput 

Esto elegirá la opción más segura para cada request.