cómo minimizar el tiempo de inactividad de la aplicación al actualizar la base de datos y la aplicación ORM

Question

Actualmente ejecutamos una solución de comercio electrónico para una empresa de ocio y viajes. Cada vez que tenemos un lanzamiento, debemos bajar el sitio de comercio electrónico a medida que actualizamos el esquema de la base de datos y el código de acceso a los datos. Estamos utilizando un ORM personalizado, donde cada entidad de datos es responsable de sus propias operaciones CRUD. Esto se logra al generar dinámicamente el SQL en función de los atributos en la entidad de datos.

Por ejemplo, la entidad de datos para una dirección sería ...

[tableName="address"] 
public class address : dataEntity 
{ 
    [column="address1"] 
    public string address1; 
    [column="city"] 
    public string city; 
} 

Por lo tanto, si añadimos una nueva columna a la base de datos, hay que actualizar el esquema de la base de datos y también actualizar los datos entidad.

Como puede esperar, los empresarios no están muy contentos con esta interrupción ya que afecta su flujo de caja. Las personas de operaciones no están contentas, ya que tienen que lidiar con un tiempo de alta presión cuando la base de datos y las aplicaciones se actualizan. Los programadores están molestos porque constantemente están metidos en problemas por el sistema heredado que heredaron.

¿Alguna de ustedes personas inteligentes tiene alguna sugerencia?

Answer 1

La primera respuesta es obviamente, no use un ORM. Solo los programadores de aplicaciones piensan que son buenos. Aprender SQL como todos los demás :)

OK, así que volvamos a la realidad. Lo que le impide restringir todos los cambios de esquema para que sean solo adiciones. A continuación, puede actualizar el esquema de base de datos en cualquier momento que desee, y solo instalar la aplicación recompilada hasta que se actualice el horario de seguridad (a las 6 a.m.). Si debe eliminar cosas, realice los pasos al revés: instale la nueva aplicación sin cambiar el esquema y luego elimine los bits del esquema.

Siempre va a tener un momento de alta presión a medida que despliega los cambios, pero al menos puede hacerlo mejor si lo hace en 2 piezas más fáciles de comprender. Sus DBA estarán bien con la actualización del esquema para la aplicación existente.

La desventaja es que tiene que estar mucho más organizado, pero eso no es malo cuando se trata de servidores de producción y debería estar realmente organizado al respecto actualmente.

Answer 2

Respaldar este escenario agregará una complejidad significativa a su entorno y/o proceso y/o aplicación.

Puede ejecutar un proceso de actualización complejo donde su código de aplicación es lo suficientemente inteligente como para ejecutarse correctamente tanto en el esquema anterior como en el nuevo esquema al mismo tiempo. Luego puede actualizar la aplicación primero y el esquema segundo. Un tercer paso puede ser migrar cualquier dato, que una vez más, la aplicación debe poder trabajar. En ese caso, solo necesita "desempolvar" la aplicación por el tiempo que lleva actualizarla, lo que podría ser segundos, dependiendo de la cantidad de archivos y equipos involucrados en la actualización.

En la mayoría de los casos, es mejor dejar la aplicación/entorno/proceso simple y vivir con el centro de la ciudad durante un tiempo lento del día/semana/mes. Prácticamente todas las aplicaciones deben ser "eliminadas" de vez en cuando para "programar regularmente el mantenimiento".