Estrategias de actualización de producción para Jitterbit App Builder

Introducción

Actualizar App Builder significa instalar una nueva versión de la plataforma en tu entorno de App Builder, incluyendo cualquier actualización requerida a la base de datos Vinyl (la base de datos subyacente de App Builder). Dado que una actualización cambia tanto el tiempo de ejecución de tu aplicación como su esquema de base de datos simultáneamente, planificarla cuidadosamente te ayuda a detectar problemas de compatibilidad temprano y mantener el tiempo de inactividad predecible.

El mejor enfoque es validar una versión de la plataforma en un entorno que no sea de producción primero. Mantén al menos una topología de entorno dual (desarrollo y producción), o una topología de tres entornos (desarrollo, QA y producción) siguiendo el enfoque de 3 niveles, para que puedas probar versiones de la plataforma, migraciones de esquema de base de datos y lógica de aplicación personalizada antes de que lleguen a producción. Se desaconseja fuertemente ejecutar un único entorno de solo producción, ya que no deja ningún entorno para detectar problemas antes de que afecten a los usuarios.

Esta página enumera los requisitos previos para actualizar y luego detalla el proceso en tres pasos:

1. Paso 1: Actualizar y validar desarrollo y QA
   Actualiza la versión de la plataforma en tus entornos de desarrollo y QA y valídala allí.

2. Paso 2: Actualizar producción
   Elige una estrategia para actualizar el entorno de producción: una actualización in situ o una implementación Blue/Green.

3. Paso 3: Verificar la actualización
   Asegúrate de que la actualización fue exitosa.

Si solo mantienes un entorno de producción, consulta Implementaciones de entorno único (solo producción) para obtener orientación sobre cómo adaptar los pasos a continuación.

Requisitos previos

Antes de ejecutar una actualización de plataforma en cualquier entorno, completa lo siguiente, en orden:

1. Congelación de código: Instituye una congelación de código en todos los entornos. No inicies nuevo desarrollo de características de aplicación hasta que la actualización de la plataforma esté completa en todos los entornos.

2. Sincronización del esquema de base de datos: Asegúrate de que los esquemas de base de datos personalizados (tablas, columnas, vistas y procedimientos almacenados) estén sincronizados entre desarrollo, QA y producción. La desviación de esquema entre entornos puede causar que la actualización de la plataforma o la lógica de la aplicación fallen de manera impredecible. Consulta Gestión de versiones para ver cómo App Builder rastrea y reproduce cambios de esquema en todos los entornos.

3. Verificación de requisitos del sistema: Verifica que el entorno host cumpla con los requisitos del sistema para la versión de destino, en sistemas operativos, tiempos de ejecución de contenedores y motores de base de datos.

4. Copias de seguridad de base de datos, archivos y carpetas: Inmediatamente antes de iniciar el mantenimiento, haz lo siguiente:

   • Realiza una copia de seguridad de la base de datos Vinyl (requerida) y cualquier base de datos de aplicación que sufra cambios físicos o de esquema (altamente recomendado).

   • Mantén una copia del archivo de versión anterior (.tar.gz o .zip), o la carpeta de aplicación anterior en sí, en el host. Cualquiera de los dos te permite revertir rápidamente: reextrae el archivo o intercambia la carpeta anterior nuevamente en su lugar.

   • Preserva el siguiente contenido del directorio de aplicación de App Builder al reemplazar binarios de aplicación o actualizar directorios:

     • appsettings.json: Retiene la configuración de nivel de aplicación.

     • Connection.xml: Retiene las cadenas de conexión y parámetros de la base de datos backend.

     • data: Contiene archivos de aplicación almacenados localmente, como PDF generados, cargas de archivos y otros archivos adjuntos de documentos almacenados en el directorio de App Builder.

     • keys: Contiene las claves de cifrado de datos utilizadas para descifrar credenciales almacenadas, cadenas de conexión y datos de aplicación. Perder esta carpeta hace que los datos cifrados sean permanentemente ilegibles.

     • Archivo de licencia (vinyl.lic): Evita errores de licencia al iniciar.

5. logs: Retiene registros de eventos del sistema, registros de diagnóstico y pistas de auditoría.

Una vez que se cumplan estos requisitos previos, continúa con Paso 1: Actualizar y validar desarrollo y QA.

Paso 1: Actualizar y validar desarrollo y QA

Antes de actualizar producción con cualquiera de las estrategias, actualiza la versión de la plataforma en desarrollo y QA y valídala ahí. Esto permite que los desarrolladores y usuarios empresariales detecten problemas de compatibilidad mientras el cambio aún no llega a producción, independientemente de la estrategia que elijas más adelante para la actualización de producción.

Actualizar la base de datos de desarrollo o QA (opcional)

Como precaución adicional, restaura una copia nueva de la base de datos de producción en desarrollo o QA antes de actualizar esos entornos:

• Restaurar a desarrollo para una ejecución de prueba de migración: Esto permite que los desarrolladores prueben actualizaciones de esquema contra datos reales de producción, detecten conflictos específicos de datos temprano y midan el tiempo de ejecución para planificar la ventana de tiempo de inactividad de producción.

• Restaurar a QA para Pruebas de Aceptación del Usuario (UAT) realistas: Esto garantiza que los usuarios empresariales realicen UAT contra escenarios auténticos de datos de producción.

Actualizar el entorno de desarrollo y realizar pruebas de humo

Actualizar primero el entorno de desarrollo permite que los desarrolladores validen la nueva versión de la plataforma contra la lógica real de la aplicación y corrijan cualquier problema de compatibilidad antes de que lleguen a QA o producción.

1. (Opcional) Actualiza la base de datos de desarrollo, siguiendo la orientación anterior.

2. Actualiza el tiempo de ejecución de App Builder y la base de datos en desarrollo.

3. Realiza pruebas de humo en la instancia actualizada, enfocándote en las siguientes áreas:

   • Procesos empresariales principales: La lógica empresarial a menudo depende de funciones a nivel de base de datos, generación dinámica de SQL o procedimientos almacenados. Una actualización de versión puede cambiar cómo se ejecutan las consultas de base de datos, así que valida tus rutas principales.

   • Conexiones de fuentes de datos e integraciones: Las actualizaciones de plataforma a menudo incluyen controladores de base de datos actualizados, conectores Conectividad Abierta de Base de Datos (ODBC) o Conectividad de Base de Datos Java (JDBC), o requisitos de autenticación revisados. Verifica que todas las fuentes de datos remotas se conecten y consulten correctamente.

   • Elementos de interfaz de usuario y experiencia de usuario (temas, HTML, CSS, diseños): Las actualizaciones de plataforma pueden cambiar estructuras internas del Modelo de Objetos del Documento (DOM) o selectores de elementos predeterminados. Los estilos personalizados y las anulaciones pueden romperse si las clases estructurales o los selectores cambian.

   • Código personalizado (widgets de interfaz de usuario, complementos, JavaScript personalizado): El código personalizado conlleva el mayor riesgo durante una actualización, ya que el control de calidad de Jitterbit no puede probar código escrito fuera de la plataforma principal. Prueba todos los componentes interactivos de la interfaz de usuario para confirmar que sus API u objetivos DOM no han cambiado.

   • Seguridad, roles y permisos a nivel de fila: Las versiones de plataforma a veces actualizan la lógica de evaluación de seguridad o filtros de seguridad a nivel de fila. Verifica que los roles de usuario, reglas de suplantación y políticas de acceso a datos se comporten como se espera.

   • Eventos programados, trabajos en segundo plano y colas: Confirma que las tareas automatizadas se activen y se ejecuten hasta completarse, ya que los cambios en la configuración del servicio en segundo plano pueden afectarlas.

   • Notas de la versión de la plataforma: Revisa las notas de la versión de App Builder para deprecaciones, cambios importantes y cualquier paso posterior a la actualización requerido.

4. Si los desarrolladores encuentran problemas de compatibilidad durante las pruebas de humo, realiza las correcciones necesarias en desarrollo, luego crea un paquete de versión para implementar las correcciones en QA y producción.

Actualizar QA y realizar UAT

Con el entorno de desarrollo validado, este paso lleva QA a la misma versión de plataforma, implementa las correcciones realizadas durante el desarrollo y brinda a los usuarios de negocio la oportunidad de aprobar antes de tocar producción.

1. (Opcional) Actualiza la base de datos de QA, siguiendo la orientación anterior.

2. Actualiza el runtime de App Builder y la base de datos en QA.

3. Implementa el paquete de versión que contiene las correcciones exportadas desde desarrollo. La instalación de un paquete de versión requiere un tiempo de inactividad adicional breve para las aplicaciones afectadas.

4. Realiza UAT completo para validar la funcionalidad de la aplicación y obtener la aprobación de implementación.

Una vez que desarrollo y QA se actualicen y validen, continúa con Paso 2: Actualizar producción.

Paso 2: Actualizar producción

Con desarrollo y QA actualizados y validados, y tu paquete de versión listo, elige una de las siguientes estrategias para la actualización de producción:

• Actualización in situ: Aplica la actualización de plataforma directamente a producción durante una ventana de mantenimiento. Recomendado para topologías estándar de desarrollo, QA y producción.

• Implementación Blue/Green: Actualiza una copia paralela de producción (Green) mientras el entorno activo (Blue) continúa sirviendo a los usuarios, luego cambia el tráfico una vez que Green se verifica. Recomendado para entornos críticos que requieren tiempo de inactividad mínimo.

La siguiente tabla compara las dos estrategias:

Actualización in situ

Recomendado para topologías estándar de desarrollo, QA y producción utilizando una ventana de mantenimiento programada. Esta estrategia aplica la actualización de plataforma directamente a la infraestructura activa de producción, una vez que la versión ya se ha actualizado y validado en desarrollo y QA.

Para comenzar, aplica la actualización de plataforma y las correcciones validadas en desarrollo y QA a producción durante tu ventana de mantenimiento programada. Sigue estos pasos:

1. Detén Internet Information Services (IIS), servicios de aplicación o contenedores en producción para detener el tráfico entrante.

2. Realiza una copia de seguridad de las bases de datos de producción y preserva los archivos principales enumerados en Requisitos previos.

3. Actualiza el runtime de la aplicación para tu entorno:

   • AWS: Implementa el nuevo paquete de aplicación o actualiza la etiqueta de imagen objetivo, siguiendo Instalar App Builder en AWS.

   • Azure: Actualiza la etiqueta de imagen del contenedor o el paquete de aplicación, siguiendo Instalar App Builder en Microsoft Azure.

   • Docker: Actualiza la etiqueta de imagen en docker-compose.yml, manteniendo los montajes de volumen que persisten keys, logs, data, Connection.xml y appsettings.json, luego extrae e reinicia los contenedores. Consulta Actualizar a App Builder en Docker.

4. Google Cloud Platform (GCP): Implementa la nueva etiqueta de imagen de contenedor en Cloud Run, Google Kubernetes Engine (GKE) o Compute Engine.

5. Windows/IIS: Sigue Upgrade App Builder on Microsoft Windows, que cubre la restauración de Connection.xml, appsettings.json y la carpeta keys, además de otorgar al grupo de aplicaciones de IIS control total sobre los directorios data, logs y keys.

6. Inicia los servicios para poner en línea la plataforma actualizada.

7. Implementa el paquete de versión que contiene las correcciones validadas en desarrollo y QA. Ten en cuenta el breve tiempo de inactividad adicional que esto requiere.

8. Completa las verificaciones en Paso 3: Verificar la actualización, borra los cachés de la aplicación y reabre el entorno a los usuarios.

Revertir una actualización in situ

Si la actualización de producción falla o introduce problemas críticos, sigue estos pasos para revertir la producción a su estado anterior a la actualización.

1. Detén los servicios de la aplicación, IIS o contenedores.

2. Restaura la base de datos Vinyl y las bases de datos de la aplicación desde las copias de seguridad anteriores a la actualización.

   Advertencia

   Restaurar copias de seguridad de bases de datos revierte cualquier actividad del usuario o transacción registrada después de la actualización.

3. Revierte el tiempo de ejecución de la aplicación:

   • Windows/IIS: Reemplaza el directorio de la aplicación con la carpeta de copia de seguridad preservada, o extrae nuevamente el archivo de versión anterior, manteniendo intactos keys, logs, data, Connection.xml, appsettings.json y el archivo de licencia.

   • Docker o contenedores en la nube (AWS, GCP, Azure): Revierte a la etiqueta de versión anterior en tu archivo compose, Cloud Run, GKE o configuración de App Service, luego vuelve a implementar.

4. Inicia los servicios y realiza verificaciones básicas antes de reabrirle el entorno a los usuarios.

Implementación Blue/Green

Recomendada para entornos de producción críticos que requieren alta disponibilidad y ventanas de mantenimiento mínimas.

Blue/Green es una estrategia de implementación para la fase de producción de tu ciclo de vida. No reemplaza las pruebas en entornos que no son de producción: completa los requisitos previos y el Paso 1: Actualizar y validar desarrollo y QA antes de iniciar un cambio Blue/Green en producción. (Esto no aplica si estás adaptando Blue/Green para una implementación en un solo entorno.)

Esta estrategia actualiza Green mientras Blue permanece en línea, luego realiza el cambio una vez que Green se verifica. Espera un tiempo de inactividad mínimo, limitado a la sincronización final de la base de datos y al cambio de DNS o balanceador de carga.

Para comenzar, aprovisiona el entorno Green. Green debe existir como un entorno independiente, configurado como Blue pero sin servir tráfico en vivo, antes de que puedas actualizar y validar la nueva versión en él. Sigue estos pasos:

1. En Blue, antes de clonar, agrega una entrada de sitio para Green para que Green no herede la redirección de Blue. Selecciona Security Providers > More > Sites, haz clic en + Site y crea una entrada con la URL de Green, dejando Default y Redirect sin marcar. Una vez que Green se clona desde Blue, las solicitudes a la propia URL de Green coinciden con esta entrada en lugar de recurrir a la entrada predeterminada habilitada para redirección de Blue. (Consulta Sites and aliases para obtener más información sobre esta función).

2. Aprovisiona Green como un clon completo de Blue, incluida su base de datos Vinyl en ese momento (con sus claves de cifrado actuales, historial de flujos de trabajo, historial de trabajos y registros).

3. Actualiza Connection.xml, appsettings.json y las variables de entorno de Green para que apunten a la instancia de base de datos Green durante el staging, no a la base de datos Blue en vivo.

{
  "Site": {
    "Url": "https://localhost:5001",
    "Default": true,
    "Redirect": false,
    "Aliases": [
      {
        "Url": "https://localhost:5000"
      }
    ]
  }
}

A continuación, aplica la actualización a Green y valídala contra datos de producción. En este punto, los usuarios a los que Blue sigue sirviendo no se verán afectados. Sigue estos pasos:

1. Clona las bases de datos de producción a Green.

2. Aplica la actualización de plataforma, las actualizaciones de contenedores y las migraciones de bases de datos en Green.

3. Implementa el paquete de lanzamiento que contiene las correcciones validadas en desarrollo y QA.

4. Si tus aplicaciones ejecutan trabajos en segundo plano que envían notificaciones por correo electrónico, desactiva esos trabajos o ajusta la configuración del servidor SMTP en Green durante la validación, para evitar que se envíen correos electrónicos duplicados a los usuarios mientras Blue sigue activo.

5. Completa la validación y las verificaciones de estado en Green mientras Blue continúa manejando el tráfico en vivo.

Ahora que Green está completamente validado, es hora de sincronizar los últimos cambios de producción y cambiar el tráfico en vivo de Blue a Green:

1. Pausa las operaciones de escritura en Blue o detén brevemente los servicios de aplicación de Blue.

2. Realiza una copia de seguridad final de las bases de datos de usuario (aplicación) de Blue y restáurala en Green para lograr paridad de datos completa. Jitterbit recomienda una copia de seguridad y restauración completas. Una copia de seguridad diferencial se recomienda solo cuando el volumen de datos hace que una copia de seguridad completa sea impráctica.

3. Sincroniza las claves de cifrado entre Blue y Green:

   • Si las claves se almacenan en una ubicación externa, como un bucket de S3, Blue y Green ya las comparten, y no se requiere ninguna acción.

   • Si las claves se almacenan en el sistema de archivos (la opción predeterminada), copia las claves de cifrado de claves (KEK) de Blue a Green ahora.

   • Para cada fuente de datos, abre la pestaña Fuentes de datos, selecciona la fila de la fuente de datos y luego selecciona Claves de cifrado en Capa de lógica empresarial para verificar los registros de claves de cifrado de datos (DEK) creados desde que se aprovisionó Green:

     

     Para cualquier registro nuevo, pídele a un administrador que se conecte directamente a la base de datos Vinyl de Blue, exporte la clave de la tabla Se_DataEncryptionKey e impórtala en la base de datos Vinyl de Green.

   Advertencia

   Un entorno de producción en ejecución debe conservar todas las claves de cifrado generadas durante su vida útil, o los datos que cifra se vuelven permanentemente ilegibles.

4. Vuelve a habilitar o restaura cualquier configuración de SMTP o trabajo en segundo plano que hayas ajustado en Green durante el ensayo.

5. Calienta los grupos de aplicaciones o contenedores en Green.

6. Reapunta los registros DNS, equilibradores de carga o proxies inversos de Blue a Green.

7. Completa las verificaciones en Paso 3: Verifica la actualización, monitorea el tráfico en Green y desactiva o detén Blue una vez que se verifique la estabilidad.

8. Una vez que Blue se desactiva, elimina o actualiza la entrada de sitio que Green heredó de Blue (la que tiene Predeterminado y Redirigir habilitados).

   Nota

   Si se deja en su lugar, esta entrada redirige cualquier solicitud que no coincida con la entrada de sitio propia de Green al Blue ahora desactivado.

Revierte un cambio de Blue/Green

Si las pruebas en Green revelan problemas, o aparece un problema crítico inmediatamente después del cambio, es posible que necesites volver a Blue. Dado que Blue permanece intacto durante las pruebas y el ensayo, volver es sencillo, independientemente de cuándo aparezca el problema:

• Antes del cambio: Si las pruebas en Green revelan problemas, termina Green. Blue no experimenta ningún impacto ni tiempo de inactividad.

• Después del cambio: Si aparecen problemas críticos inmediatamente después de cambiar DNS o enrutamiento, reapunta DNS o equilibradores de carga de vuelta a Blue. Reconcilia manualmente cualquier transacción de escritura registrada en Green después del cambio de vuelta a Blue antes de revertir.

Implementaciones de un solo entorno (solo producción)

Si tienes una implementación de un solo entorno (solo producción), la estrategia de actualización es un poco diferente. Para comenzar, completa los elementos 1, 3 y 4 de los requisitos previos: la congelación de código, la verificación de requisitos del sistema y las copias de seguridad, ya que todos se aplican a una implementación de un solo entorno. El elemento 2 (la sincronización del esquema de base de datos) no se aplica, ya que no hay otro entorno con el que sincronizar. Dado que una implementación de un solo entorno no tiene un entorno de desarrollo o QA, también debes omitir Paso 1: Actualiza y valida desarrollo y QA. En su lugar, elige uno de los siguientes enfoques:

Actualización in situ en un único entorno

Este enfoque sigue los mismos pasos de actualización del runtime que la actualización in situ: detener servicios, hacer una copia de seguridad, actualizar el runtime de la aplicación e iniciar servicios nuevamente. Se omite el paso que implementa un paquete de versión compilado en desarrollo y control de calidad, ya que ninguno existe en una implementación de entorno único. En su lugar, como las pruebas de humo ocurren directamente en producción después de la actualización, los desarrolladores que encuentren problemas en la aplicación deben corregirlos en el entorno activo mientras los usuarios están conectados. Si la actualización en sí falla, se utilizan los mismos pasos de reversión que la actualización in situ.

Para evitar que los usuarios encuentren errores o flujos de trabajo dañados mientras los desarrolladores aplican correcciones, utiliza el flujo de trabajo guiado Maintenance para bloquear aplicaciones afectadas y redirigir el tráfico que no es de administrador a una página de mantenimiento hasta que se completen las pruebas y correcciones.

Blue/Green en un único entorno

Si utilizas una estrategia Blue/Green en una configuración de entorno único, el entorno Green actúa como un área de pruebas temporal. Los desarrolladores ejecutan la actualización de la plataforma, completan pruebas de humo completas y aplican las correcciones de aplicación necesarias en Green mientras Blue permanece activo y maneja el tráfico normal de usuarios.

Una vez que Green se prueba completamente y se verifica, sincroniza los cambios finales de la base de datos y cambia el tráfico, siguiendo implementación Blue/Green. Los usuarios no experimentan estados de aplicación rotos ni ven ventanas de mantenimiento durante el ciclo de corrección.

Una vez que completes la actualización utilizando cualquiera de los enfoques, continúa con Paso 3: Verificar la actualización.

Paso 3: Verificar la actualización

Antes de finalizar la ventana de mantenimiento (si utilizaste la actualización in situ) o decomisionar Blue (si utilizaste implementación Blue/Green), confirma lo siguiente:

• La licencia de App Builder sigue siendo válida y activa en la versión actualizada.

• Los trabajos en segundo plano programados, las colas y los trabajadores del grupo de subprocesos están en estado de ejecución o inactividad, y no fallaron al iniciarse.

• La carpeta logs no muestra excepciones no controladas, errores de mapeo relacional de objetos (ORM) o tiempos de espera de conexión a la base de datos.

• La versión de App Builder que se muestra en el pie de página de la aplicación o en la página de diagnóstico coincide con la versión de destino.