nodes – ¿Cómo eliminar correctamente un módulo en un entorno por etapas?

Pregunta:

Algunos módulos tienen rutinas de desinstalación. Lo que normalmente elimina las tablas de base de datos para ese módulo, las variables de la tabla de variables y las configuraciones regionales introducidas por ese módulo. Estas rutinas viven en el .install de ese módulo.

Por lo tanto, no se pueden ejecutar sin que ese módulo esté presente. Así que aquí están nuestros pasos actuales. Mi pregunta es: ¿se puede hacer esto de forma más sencilla y eficaz? Digamos que elimino el módulo foo_bar.

  1. En el RCS, prepare una nueva versión, donde:
    • Se eliminan todos los CSS y las modificaciones de temas que usan o se compilan sobre foo_bar.
    • Se eliminan todos los CSS y las modificaciones de temas para los módulos que dependen de foo_bar.
  2. Empuje ese lanzamiento a la aceptación. Pruebe la desinstalación (de admin / modules) con una copia muy reciente de la base de datos de producción.
  3. Si todo va bien, implemente la nueva base de código en producción y deïnstall foo_bar y sus dependencias allí. Esto invocará la desinstalación en los distintos módulos, limpiando la base de datos.
  4. En RCS (git), prepare una nueva versión en la que el código se elimine realmente.
  5. Implemente eso para que sea aceptado donde probamos si nada dependió accidentalmente de esto (algunos módulos desagradables o funciones de tema incluyen archivos directamente de otros módulos. En particular, CSS, JS o archivos de imagen).
  6. Si se acepta, implemente la nueva versión en producción. La producción ahora tiene una base de datos limpia y una base de código limpia .

El problema que no veo cómo resolver es que esto siempre necesita dos lanzamientos. Dado que en Drupal una versión requiere que el sitio esté fuera de línea, esto significa dos veces el tiempo de inactividad solo para eliminar un módulo. También requiere dos procedimientos de liberación que, en entornos de alojamiento profesional, pueden resultar muy costosos, llevar mucho tiempo o resultar frustrantes.

Si eliminamos el módulo de la base de código en la primera iteración, no podemos ejecutar los ganchos de desinstalación, manteniendo muchas pelusas en la base de datos; no solo unas pocas tablas, sino principalmente variables y configuraciones regionales. Si no eliminamos el módulo de la base de código, eso significa que la base de código crecerá con código obsoleto y sin usar; esto no genera una sobrecarga de rendimiento, pero hace que el mantenimiento del código sea cada vez más difícil.

Como tratas con esto?

[editar: nota agregada acerca de que la implementación es un procedimiento difícil, a menudo]

Respuesta:

Tenga mucho cuidado de mantener su base de datos y su código sincronizados; como menciona en su pregunta, los módulos que se desinstalarán deben permanecer en la base del código hasta que sus ganchos de desinstalación se ejecuten en la base de datos en vivo. Esta es una limitación de Drupal que un flujo de trabajo de git pull por sí solo no va a resolver.

Recomendaría que en lugar de intentar ajustar su proceso, busque formas de reducir el tiempo de inactividad requerido para procesar sus actualizaciones. Recomendaría configurar un entorno de preparación multisitio de ying / yang para resolver este problema. nb no he utilizado los scripts contenidos en el enlace anterior; es posible que desee configurar las cosas de manera diferente, siguiendo la misma idea de que puede intercambiar sus sitios en vivo y de escenario durante la implementación.

Continúe siguiendo el mismo procedimiento que describió en su pregunta con los siguientes ajustes:

una. Sincroniza desde el desarrollo al escenario (yang) como de costumbre. Pruebe realizando una desinstalación de los módulos que se eliminarán, seguida de la eliminación del código, etc. anula & c. eliminado, etc., según sea necesario. Quizás solo se necesiten dos referencias.

B. Cuando la prueba esté completa y aceptada, restaure el código en el escenario (yang) al estado de vivo (ying).

C. Prepare el sitio en vivo (ying) para su actualización desactivando la capacidad de cualquier usuario para cambiar el contenido del sistema. Una actualización de sql a la tabla de permisos generalmente funcionará aquí. En este punto, los usuarios aún podrán leer contenido en el sitio en vivo, pero obtendrán un error de permiso denegado si intentan actualizar el contenido. (Si está bien, tal vez podría cambiar el controlador de permiso denegado para imprimir un aviso apropiado de que la función no está disponible temporalmente).

D. Ahora empuje la base de datos en vivo (ying) a la base de datos de etapa (yang), excluyendo la tabla de permisos de la actualización.

mi. Repita el paso a. de nuevo. Si tiene sus hashtags a mano, debería ser fácil restaurar el estado donde existen los módulos que se eliminarán, ejecutar los ganchos de desinstalación en la base de datos y luego retroceder al estado del código donde se fusionan sus elementos del paso 1 de nuevo en.

F. Ahora está listo para intercambiar ying y yang. Haga esto ajustando sus directivas de configuración de Apache. Tenga en cuenta que si /etc/init.d/apache restart , es posible que se /etc/init.d/apache restart algunas conexiones, pero la /etc/init.d/apache reload permitirá un intercambio limpio.

gramo. Live es ahora 'yang'; la tabla de permisos no se modifica aquí, por lo que los usuarios pueden crear contenido. Si automatiza los pasos e. y f., el tiempo no disponible debería ser muy bajo.

h. Empuje live (yang) de regreso al escenario (ying), tanto en el código como en la base de datos, o empuje desde el desarrollador, según sea necesario. Ahora tiene un entorno limpio listo para su próxima iteración.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım