Estrategias de implementación y de prueba de aplicaciones

En este documento, se proporciona una descripción general de los patrones de implementación y prueba de aplicaciones que más se usan. Se analiza cómo funcionan los patrones, los beneficios que ofrecen y los aspectos que se deben considerar cuando se implementan.

Supongamos que deseas actualizar una aplicación en ejecución a una versión nueva. Para garantizar un lanzamiento sin interrupciones, por lo general, debes tener en cuenta lo siguiente:

  • Cómo minimizar el tiempo de inactividad de la aplicación (si corresponde)
  • Cómo administrar y resolver incidentes con un impacto mínimo en los usuarios
  • Cómo abordar las implementaciones fallidas de manera confiable y eficaz
  • Cómo minimizar los errores de las personas y los procesos para lograr implementaciones predecibles y repetibles

El patrón de implementación que elijas depende en gran medida de tus objetivos empresariales. Por ejemplo, es posible que debas lanzar cambios sin tiempo de inactividad o en un entorno o un subconjunto de usuarios antes de que una función esté disponible para el público general. En cada metodología que se analiza en este documento, se tienen en cuenta los objetivos particulares que debes cumplir antes de que una implementación se considere exitosa.

Este documento está dirigido a los administradores de sistemas y a los ingenieros DevOps que trabajan en la definición y la implementación de estrategias de implementación y lanzamiento para varias aplicaciones, sistemas y frameworks.

Estrategias de implementación

Cuando implementas un servicio, no siempre se expone a los usuarios de inmediato. A veces, solo después de que se lanza el servicio, los usuarios ven cambios en la aplicación. Sin embargo, cuando un servicio se lanza de forma local, la implementación y el lanzamiento se realizan de forma simultánea. En este caso, cuando implementas la versión nueva, esta comienza a aceptar tráfico de producción. Como alternativa, hay estrategias de implementación para aprovisionar varias versiones del servicio en paralelo. Estos patrones de implementación te permiten controlar y administrar qué versión recibe una solicitud entrante. Lee Kubernetes y los desafíos de la entrega continua de software para obtener más información sobre implementaciones, lanzamientos y conceptos relacionados.

Los patrones de implementación que se analizan en esta sección te ofrecen flexibilidad para automatizar el lanzamiento de software nuevo. El enfoque más adecuado para ti depende de tus objetivos.

Patrón de implementación de recreación

Con una implementación de recreación, puedes reducir por completo la escala de la versión de la aplicación existente antes de escalar verticalmente la versión nueva.

En el siguiente diagrama, se muestra cómo funciona una implementación de recreación para una aplicación.

El flujo de una implementación de recreación.

La versión 1 representa la versión actual de la aplicación, y la versión 2 representa la versión nueva de la aplicación. Cuando actualizas la versión actual de la aplicación, primero reduces la escala de las réplicas existentes de la versión 1 a cero y, luego, implementas las réplicas de forma simultánea con la versión nueva.

Ventajas clave

La ventaja del enfoque de recreación es su simplicidad. No tienes que administrar más de una versión de la aplicación en paralelo y, por lo tanto, evitas los problemas de retrocompatibilidad con los datos y las aplicaciones.

Consideraciones

El método de recreación implica tiempo de inactividad durante el proceso de actualización. El tiempo de inactividad no es un problema para las aplicaciones que pueden manejar períodos de mantenimiento o interrupciones. Sin embargo, si tienes aplicaciones esenciales con Acuerdos de Nivel de Servicio (ANS) y requisitos de disponibilidad elevados, puedes elegir una estrategia de implementación diferente.

Patrón de implementación de actualización progresiva

En una implementación de actualización progresiva, se actualiza un subconjunto de instancias de aplicación en ejecución en lugar de actualizar cada instancia de aplicación de forma simultánea, como se muestra en el siguiente diagrama.

El flujo de una implementación de actualización progresiva.

En este enfoque de implementación, la cantidad de instancias que actualizas de forma simultánea se denomina tamaño de período. En el diagrama anterior, la actualización progresiva tiene un tamaño de período de 1. Se actualiza una instancia de aplicación a la vez. Si tienes un clúster grande, puedes aumentar el tamaño de período.

Con las actualizaciones progresivas, tienes flexibilidad para actualizar la aplicación:

  • Puedes escalar verticalmente las instancias de la aplicación con la versión nueva antes de reducir la escala de la versión anterior (un proceso conocido como actualización de aumento).
  • Puedes especificar la cantidad máxima de instancias de la aplicación que no están disponibles mientras escalas verticalmente las instancias nuevas en paralelo.

Ventajas clave

  • No hay tiempo de inactividad. Según el tamaño del período, debes actualizar de forma incremental los destinos de implementación, por ejemplo, uno por uno o dos por dos. Dirige el tráfico a los destinos de implementación actualizados solo después de que la versión nueva de la aplicación esté lista para aceptar el tráfico.
  • Reduce el riesgo de implementación. Cuando lanzas una actualización de forma incremental, cualquier inestabilidad en la versión nueva afecta solo a una parte de los usuarios.

Consideraciones

  • Reversión lenta. Si el lanzamiento nuevo es inestable, puedes finalizar las réplicas nuevas y volver a implementar la versión anterior. Sin embargo, al igual que un lanzamiento, una reversión es un proceso incremental y gradual.
  • Retrocompatibilidad. Debido a que el código nuevo y el código antiguo residen uno al lado del otro, es posible que los usuarios se enruten a cualquiera de las versiones de manera arbitraria. Por lo tanto, asegúrate de que la implementación nueva sea retrocompatible, es decir, que la nueva versión de la aplicación pueda leer y manejar los datos que almacena la versión anterior. Estos datos pueden incluir datos almacenados en el disco, en una base de datos o como parte de la sesión del navegador de un usuario.
  • Sesiones fijas. Si la aplicación requiere persistencia de sesiones, recomendamos que el balanceador de cargas admita la persistencia y el vaciado de conexiones. Además, recomendamos que invoques el uso compartido de sesiones cuando sea posible (a través de la replicación de sesiones o la administración de sesiones mediante un almacén de datos) para que las sesiones puedan separarse de los recursos subyacentes.

Patrón de implementación azul-verde

En una implementación azul-verde (también conocida como implementación roja-negra), realizas dos implementaciones idénticas de la aplicación, como se muestra en el siguiente diagrama.

El flujo de una implementación azul-verde.

En el diagrama, el color azul representa la versión actual de la aplicación, y el color verde representa la versión nueva de la aplicación. Solo una versión está activa a la vez. El tráfico se enruta a la implementación azul mientras se crea y se prueba la implementación verde. Una vez que termines las pruebas, debes enrutar el tráfico a la versión nueva.

Después de que la implementación se realice de forma correcta, puedes conservar la implementación azul para una posible reversión o retirarla. Como alternativa, puedes implementar una versión más reciente de la aplicación en estas instancias. En ese caso, el entorno actual (azul) sirve como el área de etapa de pruebas para la próxima versión.

Ventajas clave

  • Sin tiempo de inactividad. La implementación azul-verde permite una migración de sistemas rápida sin tiempo de inactividad.
  • Reversión instantánea. Puedes revertir en cualquier momento durante el proceso de implementación si ajustas el balanceador de cargas para dirigir el tráfico de vuelta al entorno azul. El impacto del tiempo de inactividad se limita al tiempo que lleva cambiar el tráfico al entorno azul después de detectar un problema.
  • Separación de entornos. La implementación azul-verde garantiza que la activación de un entorno verde paralelo no afecte a los recursos que admiten el entorno azul. Esta separación reduce el riesgo de implementación.

Consideraciones

  • Costo y sobrecarga operativa. La adopción del patrón de implementación azul-verde puede aumentar la sobrecarga operativa y el costo, ya que debes mantener entornos duplicados con una infraestructura idéntica.
  • Retrocompatibilidad. Las implementaciones azul y verde pueden compartir datos y almacenes de datos. Recomendamos que verifiques que ambas versiones de la aplicación puedan usar el esquema del almacén de datos y el formato de los registros. Esta retrocompatibilidad es necesaria si deseas alternar sin problemas entre las dos versiones si necesitas revertir.
  • Migración de sistemas. Si planeas retirar la versión actual, te recomendamos que permitas el vaciado de conexiones adecuado en las sesiones y las transacciones existentes. Este paso permite que las solicitudes procesadas por la implementación actual se completen o finalicen de forma correcta.

Estrategias de prueba

Los patrones de prueba que se analizan en esta sección se suelen usar para validar la confiabilidad y la estabilidad de un servicio durante un período razonable bajo un nivel realista de simultaneidad y carga.

Patrón de prueba de versiones canary

En las pruebas de versiones canary, debes lanzar de forma parcial un cambio y, luego, evaluar su rendimiento en comparación con una implementación de referencia, como se muestra en el siguiente diagrama.

La configuración para una prueba de versiones canary.

En este patrón de prueba, debes implementar una versión nueva de la aplicación junto con la versión de producción. Luego, debes dividir y enrutar un porcentaje de tráfico de la versión de producción a la versión canary y evaluar el rendimiento de la versión canary.

Selecciona las métricas clave para la evaluación cuando configures la versión canary. Recomendamos que compares la versión canary con una versión de referencia equivalente y no con el entorno de producción en vivo.

A fin de reducir los factores que podrían afectar el análisis (como el almacenamiento en caché, las conexiones de larga duración y los objetos hash), te recomendamos que completes los siguientes pasos para la versión de referencia de la aplicación:

  • Asegúrate de que las versiones de referencia y de producción de la aplicación sean idénticas.
  • Implementa la versión de referencia al mismo tiempo que implementas la versión canary.
  • Asegúrate de que la implementación de referencia (como la cantidad de instancias de aplicación y políticas de ajuste de escala automático) coincida con la implementación de versiones canary.
  • Usa la versión de referencia para entregar el mismo tráfico que la versión canary.

En las pruebas de la versión canary, el lanzamiento parcial puede seguir varias estrategias de partición. Por ejemplo, si la aplicación tiene usuarios distribuidos geográficamente, primero puedes lanzar la versión nueva en una región o una ubicación específica. Para obtener más información, consulta Automatiza el análisis de versiones canary en GKE con Spinnaker.

Ventajas clave

  • Posibilidad de probar el tráfico de producción en vivo. En lugar de probar una aplicación mediante el uso de tráfico simulado en un entorno de etapa de pruebas, puedes ejecutar pruebas de versiones canary en el tráfico de producción en vivo. Con los lanzamientos de versiones canary, debes decidir en qué incrementos lanzas la aplicación nueva y cuándo activas el siguiente paso en una versión. La versión canary necesita suficiente tráfico para que la supervisión pueda detectar con claridad cualquier problema.
  • Reversión rápida. Puedes revertir rápido si redireccionas el tráfico del usuario a la versión anterior de la aplicación.
  • Sin tiempo de inactividad. Los lanzamientos Canary te permiten enrutar el tráfico de producción en vivo a diferentes versiones de la aplicación sin tiempo de inactividad.

Consideraciones

  • Lanzamiento lento. Cada versión incremental requiere supervisión durante un período razonable y, como resultado, puede demorar la versión general. Las pruebas de versiones canary suelen llevar varias horas.
  • Observabilidad. Un requisito para implementar pruebas de versiones canary es la capacidad de observar y supervisar la infraestructura y la pila de la aplicación de manera eficaz. Implementar una supervisión sólida puede requerir un esfuerzo considerable.
  • Retrocompatibilidad y sesiones fijas. Al igual que con las actualizaciones progresivas, las pruebas de versiones canary pueden presentar incompatibilidad con versiones anteriores y persistencia de las sesiones, ya que varias versiones de la aplicación se ejecutan en el entorno mientras se implementan las versiones canary.

Patrón de prueba A/B

Con las pruebas A/B, puedes probar una hipótesis mediante implementaciones de variantes. Las pruebas A/B se usan para tomar decisiones empresariales (no solo para hacer predicciones) en función de los resultados derivados de los datos.

Cuando realizas una prueba A/B, enrutas un subconjunto de usuarios a una funcionalidad nueva según las reglas de enrutamiento, como se muestra en el siguiente diagrama.

La configuración para una prueba A/B.

Las reglas de enrutamiento suelen incluir factores como la versión del navegador, el usuario-agente, la ubicación geográfica y el sistema operativo. Después de medir y comparar las versiones, actualiza el entorno de producción con la versión que produjo mejores resultados.

Ventajas clave

Las pruebas A/B sirven para medir la eficacia de una funcionalidad en una aplicación. Los casos de uso de los patrones de implementación que se describieron antes se centran en lanzar software nuevo de forma segura y revertir de manera predecible. En las pruebas A/B, puedes controlar el público objetivo de las funciones nuevas y supervisar las diferencias con importancia estadística en el comportamiento de los usuarios.

Consideraciones

  • Configuración compleja. Las pruebas A/B necesitan una muestra representativa que se pueda usar para proporcionar evidencia de que una versión es mejor que la otra. Debes calcular con anterioridad el tamaño de la muestra (por ejemplo, con una calculadora de tamaño de muestra de pruebas A/B) y ejecutar las pruebas durante un período razonable para alcanzar una importancia estadística de al menos un 95%.
  • Validez de los resultados. Varios factores pueden sesgar los resultados de las pruebas, incluidos los falsos positivos, el muestreo sesgado o los factores externos (como la temporada o las promociones de marketing).
  • Observabilidad. Cuando ejecutas varias pruebas A/B en el tráfico superpuesto, los procesos de supervisión y solución de problemas pueden ser difíciles. Por ejemplo, si pruebas la página del producto A en comparación con la página del producto B o la página de confirmación de la compra C en comparación con la página de confirmación de la compra D, el seguimiento distribuido se vuelve importante para determinar las métricas, como la división del tráfico entre las versiones.

Patrón de prueba paralela

Las técnicas de experimentos secuenciales, como las pruebas de versiones canary, pueden exponer a los clientes a una versión inferior de la aplicación durante las primeras etapas de la prueba. Puedes administrar este riesgo mediante técnicas que no requieren conexión, como la simulación. Sin embargo, estas técnicas no validan las mejoras de la aplicación porque no hay interacción del usuario con las versiones nuevas.

Con las pruebas paralelas, implementas y ejecutas una versión nueva junto con la versión actual, pero de tal manera que la versión nueva está oculta para los usuarios, como se muestra en el siguiente diagrama.

La configuración para una prueba paralela.

Una solicitud entrante se duplica y se vuelve a reproducir en un entorno de prueba. Este proceso puede ocurrir en tiempo real o de forma asíncrona después de que se vuelve a reproducir una copia del tráfico de producción capturado en el servicio recién implementado.

Debes asegurarte de que las pruebas paralelas no activen efectos secundarios que puedan alterar el entorno de producción existente o el estado del usuario.

Ventajas clave

  • No hay impacto en la producción. Debido a que el tráfico está duplicado, los errores en los servicios que procesan datos paralelos no afectan la producción.
  • Se prueban nuevas funciones de backend mediante la carga de producción. Cuando se usa con herramientas como Diffy, la duplicación del tráfico te permite medir el comportamiento del servicio en comparación con el tráfico de producción en vivo. Esto te permite probar errores, excepciones, rendimiento y paridad de resultados entre las versiones de la aplicación.
  • Reduce el riesgo de implementación. Por lo general, la duplicación del tráfico se combina con otros enfoques, como las pruebas de versiones canary. Después de probar una función nueva mediante la duplicación del tráfico, puedes probar la experiencia del usuario. Para ello, lanza de forma gradual la función a una cantidad cada vez mayor de usuarios. No se producirá un lanzamiento completo hasta que la aplicación cumpla con los requisitos de estabilidad y rendimiento.

Consideraciones

  • Efectos secundarios. Con la duplicación del tráfico, debes tener cuidado con la forma en que manejas los servicios que mutan el estado o interactúan con servicios de terceros. Por ejemplo, si quieres hacer una prueba paralela del servicio de pago de una plataforma con carrito de compras, los clientes podrían pagar dos veces por el pedido. Para evitar las pruebas paralelas que podrían dar lugar a mutaciones no deseadas o a otras interacciones propensas al riesgo, te recomendamos que uses stubs o herramientas de virtualización como Hoverfly en lugar de sistemas o almacenes de datos de terceros.
  • Costo y sobrecarga operativa. La configuración de las pruebas paralelas es bastante compleja. Además, al igual que las implementaciones azul-verde, las implementaciones paralelas tienen implicaciones operativas y de costos, porque la configuración requiere la ejecución y la administración de dos entornos en paralelo.

Elige la estrategia adecuada

Puedes implementar y lanzar la aplicación de varias maneras. Cada enfoque tiene sus ventajas y desventajas. La mejor opción depende de las necesidades y las limitaciones de tu empresa. Ten en cuenta lo siguiente:

  • ¿Cuáles son las consideraciones más importantes? Por ejemplo, ¿es aceptable el tiempo de inactividad? ¿Los costos te limitan? ¿El equipo tiene las habilidades adecuadas para implementar parámetros de configuración complejos de lanzamiento y reversión?
  • ¿Tienes controles de prueba estrictos o quieres probar los lanzamientos nuevos con el tráfico de producción para garantizar la estabilidad de la versión y limitar el impacto negativo?
  • ¿Quieres probar las funciones en un grupo de usuarios para verificar ciertas hipótesis empresariales? ¿Puedes controlar si los usuarios objetivo aceptan la actualización? Por ejemplo, las actualizaciones en dispositivos móviles necesitan una acción explícita del usuario y pueden requerir permisos adicionales.
  • ¿Los microservicios del entorno son completamente autónomos? ¿Tienes un híbrido de aplicaciones estilo microservicio que funcionan junto con aplicaciones tradicionales y difíciles de cambiar? Para obtener más información, consulta los patrones de implementación en entornos híbridos y de múltiples nubes.
  • ¿El lanzamiento nuevo implica algún cambio de esquema? Si es así, ¿los cambios de esquema son demasiado complejos para separarlos de los cambios de código?

En la siguiente tabla, se resumen las características más destacadas de los patrones de implementación y de prueba que se analizaron antes en este documento. Cuando evalúes las ventajas y las desventajas de varios enfoques de implementación y prueba, considera tus recursos tecnológicos y necesidades empresariales y, luego, selecciona la opción que más te convenga.

Patrón de implementación o
de prueba		 Sin tiempo de inactividad Pruebas de tráfico de producción real Lanzamiento a los usuarios según las condiciones Duración de la reversión Impacto en el hardware y los costos de la nube
Recreación
Se cancela la versión 1 y se lanza la versión 2.		 x x x Rápida pero perjudicial debido al tiempo de inactividad No se requiere ninguna configuración adicional
Actualización progresiva
La versión 2 se lanza de forma gradual y reemplaza a la versión 1.		 ✓ x x Lenta Puede requerir una configuración adicional para actualizaciones de aumento
Azul-verde
La versión 2 se lanza junto con la versión 1. El tráfico se pasa a la versión 2 después de la prueba.		 ✓ x x Instantánea Se deben mantener los entornos azul y verde en simultáneo
Versión canary
La versión 2 se lanza a un subconjunto de usuarios, seguida de un lanzamiento completo.		 ✓ ✓ x Rápida No se requiere ninguna configuración adicional
A/B
La versión 2 se lanza, en condiciones específicas, a un subconjunto de usuarios.		 ✓ ✓ ✓ Rápida No se requiere ninguna configuración adicional
Paralela
La versión 2 recibe tráfico real sin afectar las solicitudes de los usuarios.		 ✓ ✓ x No aplica Se deben mantener entornos paralelos para capturar y volver a reproducir las solicitudes de los usuarios

Prácticas recomendadas

Para que los riesgos de implementación y pruebas sean mínimos, los equipos de la aplicación pueden seguir varias prácticas recomendadas:

  • Retrocompatibilidad. Cuando ejecutes varias versiones de la aplicación al mismo tiempo, asegúrate de que la base de datos sea compatible con todas las versiones activas. Por ejemplo, una versión nueva requiere un cambio de esquema en la base de datos (como una columna nueva). En esa situación, debes cambiar el esquema de la base de datos para que sea compatible con la versión anterior. Después de terminar un lanzamiento completo, puedes quitar la compatibilidad con el esquema anterior y dejar la compatibilidad solo con la versión más reciente. Una forma de lograr la retrocompatibilidad es separar los cambios de esquema de los cambios de código. Para obtener más información, consulta los patrones de cambios paralelos y de refactorización de bases de datos.
  • Integración continua/implementación continua (CI/CD). La CI garantiza que el código registrado en la rama de funciones se fusione con la rama principal solo después de realizar con éxito las verificaciones de dependencias, las pruebas de integración y unidad, y el proceso de compilación. Por lo tanto, cada cambio en una aplicación se prueba antes de que se pueda implementar. Con la CD, el artefacto de código que compila la CI está empaquetado y listo para implementarse en uno o más entornos. Para obtener más información, consulta Compila una canalización de CI/CD con Google Cloud.
  • Automatización. Si ofreces actualizaciones de aplicaciones a los usuarios continuamente, te recomendamos que crees un proceso automatizado que compile, pruebe e implemente el software de manera confiable. También recomendamos que los cambios de código fluyan de forma automática a través de una canalización de CI/CD que incluya la creación de artefactos, las pruebas de unidades, las pruebas funcionales y el lanzamiento en producción. Mediante herramientas de automatización como CloudBuild, Cloud Deploy, Spinnaker y Jenkins, puedes automatizar los procesos de implementación para que sean más eficientes, confiables y predecibles.
  • IaC y GitOps. Si necesitas administrar estrategias de implementación y prueba complicadas, considera usar las herramientas de infraestructura como código (IaC) y GitOps. El uso de IaC con Terraform y Config Connector puede ayudarte a usar el lenguaje declarativo para definir la infraestructura y las estrategias. El uso de GitOps con Config Sync y Argo CD puede ayudarte a administrar el código con Git.
  • Estrategia de reversión. A veces ocurren errores. Recomendamos crear una estrategia de reversión para seguir cuando se produzca lo inesperado. Tener una estrategia de reversión confiable puede ayudar a los administradores y a los ingenieros de DevOps a administrar los riesgos. Puedes crear una estrategia de reversión con una plataforma que admita reversiones como función integrada, como App Engine , yCloud Run. Para satisfacer tus necesidades de reversión, también puedes usar herramientas de automatización de versiones como Cloud Deploy, Spinnaker y Argo RollOuts.
  • Supervisión posterior a la implementación. Para supervisar las métricas críticas y alertar al equipo responsable cuando una implementación o prueba falla, compila un sistema de supervisión mediante Google Cloud's operations suite. También puedes habilitar las reversiones automatizadas para las implementaciones que no aprueban las verificaciones de estado. Mediante el uso de Error Reporting, Cloud Trace y Cloud Profiler pueden ayudarte a encontrar la solución causa de problemas simples y complejos posteriores a la implementación.

¿Qué sigue?