python - para - ¿Debo agregar los archivos de migración de Django en el archivo.gitignore?

python django gitignore (10)

Cita de los documentos de 2018, Django 2.0. (dos comandos separados = hacer makemigrations y migrate )

La razón por la que hay comandos separados para hacer y aplicar migraciones es porque comprometerás las migraciones a tu sistema de control de versiones y las enviarás con tu aplicación; no solo facilitan su desarrollo, sino que también pueden ser utilizados por otros desarrolladores y en producción.

https://docs.djangoproject.com/en/2.0/intro/tutorial02/

¿Debo agregar los archivos de migración de Django en el archivo .gitignore ?

Recientemente he estado recibiendo muchos problemas de git debido a conflictos de migración y me preguntaba si debería marcar los archivos de migración como ignorados.

Si es así, ¿cómo haría para agregar todas las migraciones que tengo en mis aplicaciones y agregarlas al archivo .gitignore ?

Citando de la documentación de migraciones de Django :

Los archivos de migración para cada aplicación viven en un directorio de "migraciones" dentro de esa aplicación, y están diseñados para ser comprometidos y distribuidos como parte de su base de código. Debería hacerlos una vez en su máquina de desarrollo y luego ejecutar las mismas migraciones en las máquinas de sus colegas, sus máquinas de preparación y, finalmente, sus máquinas de producción.

Si sigue este proceso, no debería tener ningún conflicto de fusión en los archivos de migración.

Para mitigar cualquier problema que tenga actualmente, debe especificar qué repositorio o rama tiene la versión autorizada de los archivos de migración, y luego usar el mecanismo de atributos de git para especificar la estrategia de fusión "nuestra" para estos archivos. Esto le dirá a git que siempre ignore los cambios externos a estos archivos y prefiera la versión local.

Haga caso omiso de las migraciones, si tiene bases de datos separadas para el entorno de desarrollo, preparación y producción. Por dev. propósitos Puede usar la base de datos sqlite local y jugar con migraciones localmente. Te recomendaría crear cuatro ramas adicionales:

Maestro: limpie el código nuevo sin migraciones. Nadie está conectado a esta rama. Utilizado solo para revisiones de código
Desarrollo - desarrollo diario. Empujar / tirar aceptado. Cada desarrollador está trabajando en sqlite DB
Cloud_DEV_env: entorno remoto de nube / servidor DEV. Tire solo. Mantenga las migraciones localmente en la máquina, que se utiliza para la implementación del código y las migraciones remotas de la base de datos de Dev
Cloud_STAG_env: entorno remoto STAG en la nube / servidor. Tire solo. Mantenga las migraciones localmente en la máquina, que se utiliza para la implementación del código y las migraciones remotas de la base de datos Stag
Cloud_PROD_env: entorno remoto de nube / servidor DEV. Tire solo. Mantenga las migraciones localmente en la máquina, que se utiliza para la implementación del código y las migraciones remotas de la base de datos Prod

Notas: 2, 3, 4: las migraciones se pueden mantener en repositorios, pero debe haber reglas estrictas para fusionar las solicitudes de extracción, por lo que decidimos buscar una persona, responsable de las implementaciones, por lo que el único que tiene todos los archivos de migración: nuestra implementación -er. Mantiene las migraciones remotas de la base de datos cada vez que tenemos cambios en los Modelos.

La solución que se usa habitualmente es que, antes de que algo se fusione con el maestro, el desarrollador debe realizar los cambios remotos. Si hay un conflicto en las versiones de migración, debería cambiar el nombre de su migración local (la remota ha sido ejecutada por otros desarrolladores y, potencialmente, en producción), a N + 1.

Durante el desarrollo, podría estar bien simplemente no confirmar las migraciones (sin embargo, no agregue un ignorar, simplemente no lo add ). Pero una vez que haya entrado en producción, los necesitará para mantener el esquema sincronizado con los cambios del modelo.

Luego debe editar el archivo y cambiar las dependencies a la última versión remota.

Esto funciona para las migraciones de Django, así como para otras aplicaciones similares (sqlalchemy + alambic, RoR, etc.).

No puedo imaginar por qué tendrías conflictos, a menos que estés editando las migraciones de alguna manera. Eso generalmente termina mal: si alguien pierde algunas confirmaciones intermedias, entonces no se actualizará desde la versión correcta y su copia de la base de datos se dañará.

El proceso que sigo es bastante simple: cada vez que cambia los modelos de una aplicación, también realiza una migración, y luego esa migración no cambia ; si necesita algo diferente en el modelo, entonces cambia el modelo y confirma un nueva migración junto con tus cambios.

En proyectos greenfield, a menudo puede eliminar las migraciones y comenzar de cero desde cero con una migración 0001_ cuando la libera, pero si tiene un código de producción, entonces no puede (aunque puede reducir las migraciones en una sola).

No.

He pasado por esto muchas veces y no puedo, por mi vida, encontrar un caso en el que necesitemos migraciones en el repositorio.

A mi modo de ver, el registro definitivo del esquema es models.py . Si fusiono un cambio y alguien más lo tira, todo será correcto cuando ejecuten makemigrations y migrate . No es necesario definir cuál es la estrategia de "la nuestra" para las migraciones.

Si necesitamos retroceder, revertimos los models y migramos. Todo bien, sin problemas, nunca.

No se queja de que ya existe un campo, etc.

Me pregunto si alguien puede darme un caso específico en el que sea una ventaja para mí tener que fusionar los archivos de migración de otro desarrollador antes de poder trabajar. Sé que los documentos dicen que debería hacerlo, así que supongo que es así. Pero nunca me he encontrado con uno.

¿Nadie?

Puedes seguir el siguiente proceso.

Puede ejecutar makemigrations localmente y esto crea el archivo de migración. Confirme este nuevo archivo de migración para repositorio.

En mi opinión, no debes ejecutar makemigrations en producción. Puede ejecutar migrate en producción y verá que las migraciones se aplican desde el archivo de migración que confirmó desde local. De esta manera puedes evitar todos los conflictos.

EN ENV LOCAL , para crear los archivos de migración,

python manage.py makemigrations python manage.py migrate

Ahora confirme estos archivos recién creados, algo como a continuación.

git add app/migrations/... git commit -m ''add migration files'' app/migrations/...

EN PRODUCTION ENV , ejecute solo el siguiente comando.

python manage.py migrate

Siente que necesitaría ajustar su flujo de trabajo de git , en lugar de ignorar los conflictos.

Idealmente, cada nueva característica se desarrolla en una rama diferente y se fusiona con una solicitud de extracción .

Las relaciones públicas no pueden fusionarse si hay un conflicto, por lo tanto, quién necesita fusionar su función necesita resolver el conflicto, incluidas las migraciones.

Tener un montón de archivos de migración en git es desordenado. Solo hay un archivo en la carpeta de migración que no debe ignorar. Ese archivo es init .py, si lo ignora, python ya no buscará submódulos dentro del directorio, por lo que cualquier intento de importar los módulos fallará. Entonces, la pregunta debería ser cómo ignorar todos los archivos de migración, excepto init .py. La solución es: Agregar ''0 * .py'' a los archivos .gitignore y hace el trabajo perfectamente.

Espero que esto ayude a alguien.

Respuesta corta Propongo excluir las migraciones en el repositorio. Después de la fusión del código, simplemente ejecute ./manage.py makemigrations y ya está todo listo.

Respuesta larga No creo que deba poner los archivos de migraciones en el repositorio. Echará a perder los estados de migración en el entorno de desarrollo de otra persona y otros entornos de producción y escenario. (Consulte el comentario de Sugar Tang para ver ejemplos).

En mi punto de vista, el propósito de las migraciones de Django es encontrar brechas entre los estados del modelo anterior y los nuevos estados del modelo, y luego serializar la brecha. Si su modelo cambia después de la fusión del código, puede simplemente hacer makemigrations para descubrir la brecha. ¿Por qué desea fusionar manualmente y con cuidado otras migraciones cuando puede lograr lo mismo automáticamente y sin errores? La documentación de Django dice:

Ellos * (migraciones) * están diseñados para ser mayormente automáticos

; por favor mantenlo así. Para fusionar las migraciones manualmente, debe comprender completamente lo que otros han cambiado y cualquier dependencia de los cambios. Eso es un montón de gastos generales y propenso a errores. Entonces el archivo de modelos de seguimiento es suficiente.

Es un buen tema en el flujo de trabajo. Estoy abierto a otras opciones.