El despliegue canario es una técnica de desarrollo y despliegue de software que ejecuta un lanzamiento gradual de nuevas características o actualizaciones a un pequeño subconjunto de usuarios antes de desplegarlo a toda la base de usuarios.
Este enfoque consiste en crear una nueva versión del software y desplegarla a un pequeño grupo de usuarios mientras se mantiene la versión antigua en funcionamiento para el resto de los usuarios. El equipo de desarrollo supervisa de cerca la nueva versión para asegurarse de que es estable y funciona como se espera.
Si todo va bien, la nueva versión se despliega a más usuarios hasta que finalmente llega a toda la base de usuarios. De este modo, el equipo del proyecto minimiza el riesgo de introducir errores u otros problemas que podrían afectar a todos los usuarios a la vez.
El objetivo del despliegue canario es reducir el riesgo de introducir nuevas funciones a una gran base de usuarios. Al desplegar gradualmente los cambios a los usuarios, los desarrolladores pueden supervisar el rendimiento y la estabilidad de la nueva versión. Realizan los ajustes necesarios antes de desplegarla a toda la base de usuarios. La transición a la nueva versión se realiza, por tanto, de forma mucho más fluida.
Principios clave y ventajas
Los principios clave del despliegue canario son los siguientes:
- Despliegue primero la nueva versión a un pequeño subconjunto de usuarios y, a continuación, extiéndala gradualmente a más usuarios a lo largo del tiempo.
- Supervise de cerca la nueva versión para asegurarse de que es estable y funciona como se espera.
- Si surge algún problema, retroceda el despliegue a la versión anterior de forma rápida y sencilla.
- Automatice el proceso de despliegue en la medida de lo posible para reducir el riesgo de error humano.
Los beneficios del despliegue canario en DevOps incluyen:
- Al desplegar gradualmente los cambios, minimiza el riesgo de introducir errores u otros problemas que podrían afectar a todos los usuarios a la vez.
- Los desarrolladores pueden recibir comentarios sobre la nueva versión con mayor rapidez, lo que les permite realizar los ajustes necesarios antes de desplegarla a toda la base de usuarios.
- Al supervisar el rendimiento y la estabilidad de la nueva versión, los desarrolladores pueden asegurarse de que cumple las normas de calidad necesarias antes de desplegarla a toda la base de usuarios.
- El despliegue Canary ayuda a aumentar la confianza de los desarrolladores y las partes interesadas en el proceso de despliegue, ya que reduce el riesgo de introducir problemas que puedan afectar a la experiencia del usuario.
Despliegue Canary basado en el concepto y la terminología
Repasemos el ciclo de vida típico del proceso.
Todo comienza con Canary, es decir, los «primeros usuarios» de la nueva versión del sistema. Paralelamente, existe el grupo Baseline. Aquí pertenecen el resto de usuarios que no están dentro de Canary.
A medida que los usuarios de Canary siguen utilizando la nueva versión, el despliegue de Canary se extiende a más y más usuarios. Esto es Traffic Shifting. El grupo Canary crece mientras que el grupo Baseline se reduce, por lo que el sistema realiza un Despliegue Gradual.
Por el camino, el proceso de monitorización registra todas las actividades y resultados de uso y genera métricas que los desarrolladores necesitan como retroalimentación. A continuación, los desarrolladores reaccionan y corrigen lo que sea necesario. O retroceden a la Línea de Base si no pueden solucionar los problemas en este momento.
Automatice todas las actividades de supervisión y despliegue. De este modo, los desarrolladores se centran exclusivamente en solucionar los problemas.
Puede que el grupo canario descubra que algunas características de la nueva versión son malas mientras que otras son estupendas. Así que los desarrolladores marcarán las características que tienen problemas para desactivarlas de los procesos de despliegue.
Los desarrolladores vigilan simultáneamente a los dos grupos: el Canario y el de Referencia. Los usuarios están generando resultados de Pruebas A/B. Es decir, el comportamiento del sistema antiguo y del nuevo en las mismas condiciones. Pero además, hay pruebas automáticas que se ejecutan constantemente en la nueva versión del sistema para garantizar que el grupo Canary Health Check es estable.
En qué se diferencia de las estrategias de implantación tradicionales
Después de comprender el proceso del ciclo de vida de alto nivel, las diferencias entre éste y los procesos de despliegue tradicionales son bastante obvias.
- Usted despliega gradualmente y con mejor control en lugar de desplegar todo a la vez a todo el mundo y esperar a que los problemas afecten a toda la producción.
- Usted limita el riesgo de errores de la nueva versión sólo al grupo canario frente a exponer a todo el mundo a los problemas simultáneamente.
- Usted supervisa la nueva versión antes de que la tengan los usuarios, en lugar de supervisarla después e invertir una cantidad considerable de tiempo y recursos en la fase de hipercuidado del proceso de lanzamiento.
- Puede decidir sobre el rollback mucho antes de desplegar la nueva versión completamente en producción. Por otro lado, puede programar otra ventana de lanzamiento para deshacer la producción justo después de que se haya completado el lanzamiento a producción.
- Contar con el despliegue Canary le obliga naturalmente a invertir en herramientas y procesos automatizados siempre que sea posible. En el otro lado, apegarse a las estrategias de despliegue tradicionales naturalmente desprioriza todas las iniciativas de automatización al final de la lista de pendientes.
Canalizaciones CI/CD en el despliegue canario
En una tubería típica de CI/CD, los cambios se construyen automáticamente, se prueban y se despliegan en un entorno de preparación para realizar más pruebas antes de desplegarse en producción. Y además, es un caso de uso perfecto dentro de un despliegue Canary.
Una vez que los cambios se han desplegado en el entorno de staging y han pasado todas las pruebas necesarias, la canalización CI/CD desplegará automáticamente la versión canaria a un pequeño subconjunto de usuarios en el entorno de producción.
Si algo sale mal, basta con ejecutar otra canalización para una reversión. O marque las características problemáticas, y nunca volverá a aparecer en el proceso de despliegue de la tubería de despliegue. Todo automático, y ya no tendrá que preocuparse por ello.
Dado que la versión canary está repleta de pruebas automatizadas de comprobación de la salud, todas ellas se incorporan de forma natural a las características básicas de los conductos CI/CD. De todos modos, son una parte imprescindible de todo buen CI/CD Pipeline.
Flujo de Trabajo y las Fases del Despliegue Canario
Resumiendo la información en conjunto, este es el flujo de trabajo habitual de un despliegue Canary típico que puede utilizar en su proyecto.
#1. Planificación y preparación
En esta fase, el equipo de desarrollo planifica y se prepara para el despliegue canario. Esto incluye la identificación de los cambios o actualizaciones que deben realizarse, la creación de una nueva versión del software y la definición de las métricas y comprobaciones de estado que se utilizarán para supervisar el rendimiento de la nueva versión. El equipo también identifica el subconjunto de usuarios que recibirán primero la nueva versión y define el plan de despliegue.
#2. Implantación del enrutamiento y la supervisión del tráfico
La nueva versión del software se despliega al subconjunto de usuarios identificado en la fase de planificación. Se implementa el enrutamiento del tráfico para dirigir una parte del tráfico de usuarios a la nueva versión mientras se mantiene la versión antigua en funcionamiento para el resto de usuarios. El rendimiento y la estabilidad de la nueva versión se supervisan de cerca utilizando métricas y comprobaciones de salud para garantizar que funciona como se espera.
#3. Análisis y evaluación del rendimiento de la implantación
El rendimiento de la nueva versión se analiza y evalúa basándose en las métricas y comprobaciones de salud definidas en la fase de planificación. Si el rendimiento de la nueva versión es bueno, el despliegue se incrementa gradualmente a más usuarios a lo largo del tiempo. Si surge algún problema con la nueva versión, el despliegue puede revertirse rápidamente a la versión anterior.
#4. Promoción o retroceso de la implantación
El equipo de desarrollo decide si promover la nueva versión a toda la base de usuarios o retroceder a la versión anterior. Si la nueva versión funciona bien y cumple las normas de calidad necesarias, promuévala a toda la base de usuarios. Si surge algún problema con la nueva versión, retroceda el despliegue a la versión anterior de forma rápida y sencilla.
Mejores prácticas y estrategias
Cuando implemente el Despliegue Canario en su plataforma, empiece por definir objetivos claros y cómo es el éxito al final. Aquí puede ayudarse con aspectos como las métricas de rendimiento, los criterios de respuesta de los usuarios y el impacto empresarial.
Cree un pequeño subconjunto de usuarios para probar la nueva versión (Canary) del software. Un grupo más grande al principio no es realmente una ventaja. Conviene ser lo más flexible posible, sobre todo al principio.
Como ya se ha mencionado varias veces, supervise el rendimiento y la estabilidad de la nueva versión utilizando métricas y comprobaciones de salud. Reaccione siempre que vea algo sospechoso. Es mejor reaccionar de forma exagerada que insuficiente cuando se trata de un despliegue gradual.
Aumente gradualmente el despliegue de la nueva versión a más usuarios a lo largo del tiempo. Esto garantiza una transición más suave a la nueva versión.
Utilice herramientas y procesos de automatización siempre que sea posible para agilizar el proceso de despliegue y supervisión. Inclúyalos en los conductos CI/CD y haga que los procesos de despliegue programados se activen automáticamente. Esto reduce el riesgo de error humano y garantiza que el proceso de despliegue sea coherente y repetible.
Implemente banderas de características para activar o desactivar características específicas en el software. Ganará control sobre los futuros procesos de despliegue sin necesidad de modificarlos o actualizarlos siempre manualmente. Dará más enfoque a los desarrolladores en las áreas que importan: corregir los errores.
Utilice las pruebas A/B para comparar el rendimiento de dos versiones diferentes del software. Asigne usuarios al azar a una versión o a la otra. Identifique qué versión funciona mejor y reaccione ante ello con futuras decisiones de desarrollo.
Asegúrese de que puede revertir la implantación rápidamente y en cualquier momento si surge algún problema con la nueva versión. Reducirá el impacto de cualquier problema y permitirá una rápida recuperación.
Retos y casos prácticos
Aún existen algunos retos que se asocian al despliegue Canary, a pesar de sus claras ventajas.
Uno de los retos de la implantación de Canary es la latencia de la red, que puede afectar al rendimiento de la nueva versión del software. Para hacer frente a este reto, los desarrolladores pueden utilizar herramientas como equilibradores de carga y redes de distribución de contenidos para mejorar el rendimiento de la red. No se trata sólo de la latencia para el sistema por el uso externo. Sino también la latencia para procesos internos como despliegues o ejecuciones de CI/CD Pipelines. Éstos deben completarse lo más rápido posible. De lo contrario, tendrá una fila de desarrolladores en estado inactivo esperando a que los pipelines terminen su ejecución.
Otro reto es garantizar la coherencia de los datos entre la versión antigua y la nueva del software. Para hacer frente a este reto, los desarrolladores pueden utilizar técnicas como la replicación y la sincronización de bases de datos para garantizar que los datos sean coherentes en todas las versiones. Tener usuarios de producción operando en versiones antiguas y nuevas al mismo tiempo aumenta las expectativas de que se asegurará de que ambas versiones están totalmente sincronizadas todo el tiempo y que los usuarios no pierden ningún dato de producción sólo porque están en el grupo Canary/Baseline. Ésta puede ser una expectativa realmente difícil de cumplir, así que respáldese con procesos de fondo sólidos.
Netflix es un ejemplo bien conocido de una empresa que utiliza Canary Deployment para desplegar cambios en su servicio de streaming. La empresa utiliza una combinación de pruebas automatizadas, indicadores de características y pruebas A/B para desplegar lentamente los cambios.
Google es otro ejemplo de empresa que utiliza Canary Deployment para desplegar cambios en sus servicios en la nube. Del mismo modo, la empresa utiliza las ventajas de las pruebas automatizadas, la división del tráfico y la inclusión de la supervisión para desplegar gradualmente los cambios a un pequeño subconjunto de usuarios antes de desplegarlos a todos los usuarios. Este enfoque ha ayudado a Google a mejorar la calidad y la estabilidad de sus servicios.
Palabras finales
Como ocurre con todos los procesos, enfoques o estrategias, el despliegue canario no es una solución para todos los problemas del mundo. Hay casos en los que es casi imposible de implantar debido a restricciones del entorno, a los conocimientos de la gente o a una falta general de comprensión conceptual. I
s mucho más adecuada para los proyectos de la nueva era. Donde una mentalidad ágil es la propiedad básica sólida como una roca, la automatización de cada proceso es una prioridad indudable, y un nivel máximo de fiabilidad es una fuerte expectativa de las partes interesadas.
En ese caso, el despliegue canario es, en cierto modo, el siguiente nivel de las prácticas de desarrollo ágil. Puede elevar a los equipos a un territorio en el que el proyecto nunca estuvo antes.
A continuación, eche un vistazo a la ampliación y optimización de CI/CD.