Una guía para principiantes para implementar cambios en el modelo de Django en producción

Puede encontrar muchos artículos en Internet sobre cómo implementar un proyecto Django en producción por primera vez. Pero, ¿qué debe hacer cuando su proyecto ya está en producción y durante las implementaciones necesita garantizar la consistencia de los sistemas relacionados y, al mismo tiempo, la continuidad de su producto?

¿Qué es la producción?

La producción es un complejo de software y hardware que está disponible para los usuarios finales. Incluye servidores, máquinas virtuales y contenedores con software estable instalado.

Hay muchos requisitos para la producción. Sin embargo, en este artículo, nos centraremos en la eficiencia y la continuidad.

La eficiencia es una garantía de que el producto hará lo que se supone que debe hacer.

La continuidad es garantía de un trabajo eficiente durante el uso de este producto.

Es decir, si un intento de inicio de sesión siempre devuelve un error, esto es falta de eficiencia. Pero, si un usuario rara vez recibe dicho error, entonces esto es una violación de continuidad.

Datos iniciales

Se utilizan varios contenedores, máquinas virtuales o servidores en producción según la arquitectura.

No considero la situación en la que solo un proceso está trabajando en un servidor en producción, ya que es similar al entorno de desarrollo habitual.

Esquema de producción

En general, la mayoría de las veces se encuentra con el esquema con varios contenedores. Se accede a ellos a través de un balanceador. Puede haber más de un equilibrador. Desde los contenedores, se accede a una base de datos, pero puede haber varias bases de datos, incluidas las fragmentaciones y las réplicas. También pueden acceder a corredores como Kafka y otros servicios. Otros servicios también pueden intercambiar información de alguna manera con backends.

Cambios Simultáneos en Código y Base de Datos

Por ejemplo, consideremos solo cambios en el código y una base de datos.

Los cambios que se pueden hacer en el código para que esto afecte a una base de datos y viceversa:

1. Agregar/eliminar una tabla.
2. Añadir/eliminar una columna.
3. Cambiar el nombre de una columna o tabla.
4. Cambiar el tipo de columna.
5. Cambie los atributos (índice) de la columna (NULO, único, predeterminado).

También puede agregar disparadores y funciones, cambiar el esquema y mucho más. Sin embargo, los enfoques generales para aplicar esto a la producción se muestran en estos mismos ejemplos.

Ejemplo detallado

Si necesita agregar un modelo (tabla) a una aplicación localmente en el entorno de desarrollo, debe hacer lo siguiente:

1. Agregue una clase a un modelo de Django.
2. Llame al comando: python manage.py makemigrations .
3. Luego: python manage.py migrate .
4. Y solo después de eso, reinicie la aplicación.

Pero en producción, hay muchas instancias de su aplicación, git y un proceso separado para ejecutar migraciones.

No suele tener acceso directo a Prod. Y esto es bueno Por ejemplo, el flujo podría verse así.

En tal esquema, las migraciones se ejecutan primero. Luego, uno por uno, los pods se reinician.

En tal arquitectura, siempre puede haber una situación en la que se hayan realizado migraciones, pero el código en producción no haya cambiado.

Entonces las cápsulas están siendo reemplazadas. Algunas instancias tienen código nuevo, otras tienen el anterior.

Además, si realiza migraciones cuando se completa el reemplazo del pod, se producirá una situación diferente: el código en el servidor se actualiza, pero la base de datos no.

Ambas situaciones implican algún período de tiempo en el que la base de datos y el código son inconsistentes.

Afortunadamente, Django no comprueba la coherencia. Sin embargo, la ausencia de los elementos necesarios da lugar a excepciones.

Son:

1. La presencia de una clase en el modelo en el código, pero su ausencia en la base de datos.
2. La presencia de un campo en la clase en el código, pero la ausencia del mismo en la base de datos.
3. Diferentes nombres de tablas y columnas en el código y la base de datos.
4. Diferentes tipos de datos en el código y la tabla.
5. Valores por defecto, NULL, y otras diferencias, si se trata de usarlos
6. Otras diferencias que la base de datos no espera cuando se accede desde el código

Soluciones

La migración debe realizarse antes de cambiar el código cuando esto implica:

1. Agregar una tabla
2. Agregar una columna
3. Agregar la capacidad de insertar NULL en el campo

La migración debe realizarse después de cambiar el código cuando esto implica:

1. Quitar una mesa
2. Quitar una columna
3. Eliminando la capacidad de insertar NULL en el campo

El cambio de nombre se realiza en varios pasos:

1. Crear un nuevo campo o tabla
2. Adición de sincronización de un campo o tabla nuevo y antiguo
3. Copiar datos históricos si es necesario
4. Comenzar a usar un nuevo campo o tabla
5. Eliminación de un campo o tabla antiguo junto con la sincronización

Todo esto parece complicado. Pero mira los esquemas dados arriba. En la producción de múltiples pods, durante la implementación, siempre sucede que parte del código funciona con el esquema de base de datos anterior mientras que otra parte funciona con el nuevo. Esto puede resultar en excepciones.

Por lo tanto, los algoritmos básicos para trabajar con modelos de Django no funcionan cuando se trata de producción. Los cambios deben implementarse en varios pasos según la arquitectura del código y el flujo de CI/CD utilizado en un caso particular.

Sin embargo, al realizar cambios, siempre puede guiarse por lo que espera el código al enviar solicitudes a la base de datos. Además de los casos estándar, puede haber varias excepciones y obstáculos que requieren ingenio para encontrar una solución.

En los próximos artículos, describiré en detalle algunos de los casos mencionados aquí.