¿Usó un ORM para la capa de acceso a datos? Sé que Doctrine viene con una API de migración que permite el cambio de versión hacia arriba y hacia abajo (en caso de que algo salga mal con la nueva versión).
Fuera de cualquier marco o consideración de ORM, una secuencia de comandos rápida minimizará la ralentización (o el tiempo de inactividad si el proceso es demasiado largo).
En mi opinión, preferiría una interrupción de acceso al sitio web de 30 segundos con una página de información, que obtener un tiempo de interupción más corto pero obteniendo errores visibles o no mostrarlos en absoluto. Si los tiempos de interrupción son importantes, es mejor hacerlo de noche o cuando hay menos tráfico.
Todo esto se puede hacer en una secuencia de comandos (o, al menos, lanzado por una línea commande), cuando nos gustaría hacer este tipo de scripts que incluimos en un script de shell:
- poner la aplicación en modo de espera (temporal página estática): puede usar .htaccess redirigir o lo que sea aplicable a su aplicación/entorno del servidor.
- svn udpate (o switch) para el código fuente y actualización de activos
- cachés vacíos, limpieza de archivos temporales, etc.
- reconstruir clases generadas (Symfony específica)
- estructura de base de datos de actualización con ALTER CREATE querys/TABLE
- si es necesario, migrar datos de estructura antigua a la nueva: dependiendo de lo que ha cambiado en la estructura, que pueden requerir ir a buscar los datos antes alterando la estructura de DB, o usa tablas tmp.
- si todo salió bien, elimine la página temporal. Actualización realizada
- si algo salió mal, muestre un mensaje rojo al operador para que pueda ver lo que sucedió, intente repararlo y luego quite la página de espera con la mano.
El script debe hacer controles en cada pasos y detener un primer error, y que debe ser detallada (pero concisa) acerca de lo que lo hace en todos los pasos, así que puede fijar la aplicación más rápida si algo tiene que salió mal . Lo mejor sería un script recuperable (error en el paso 2 - detener el proceso - reparación manual - recuperar en el paso 3), nunca me tomé el tiempo para implementarlo de esta manera.
Si funciona bastante bien pero este tipo de script debe ser probado intensivamente, en un entorno lo más cercano posible al de producción. En general desarrollamos este tipo de scripts localmente, y prueba de ellos en la misma plataforma del tha del env producción (sólo diferentes caminos y DB)
Si la página de espera no es una opción, puede ir whithout pero hay que asegurar que los datos y la integridad de la sesión de los usuarios. Como ejemplo, use LOCK en las tablas durante la actualización/transferencia de datos y use bloqueos exclusivos en archivos modificados (SVN creo)
Podría haber otras soluciones mejores, pero es básicamente lo que uso y hace el trabajo por nosotros. El principal inconveniente es que ese tipo de script tuvo que ser reescrito en cada lanzamiento principal, esto me incita a buscar otras opciones para hacer esto, pero ¿cuál? Me alegraría que alguien aquí tuviese una alternativa mejor y más simple.
¿Está solicitando una solución para implementar una actualización de su base de datos y código al mismo tiempo? ¿Tiene algo "complicado" como el almacenamiento en caché? Si configura todo su sitio en el "Modo de mantenimiento" y le dice a los usuarios que actualmente no pueden iniciar sesión, ¿podría ejecutar sus sentencias SQL ALTER y cargar el código al mismo tiempo? ¿Cuántos rps estamos hablando? ¿Alguien notará un tiempo de inactividad de unos pocos segundos en las primeras horas de la mañana? – jlindenbaum
Umum, entiendo tu punto ... ... creo que puedo organizar horas de mantenimiento – Tattat