La fase de despliegue de la entrega de software desempeña un papel sustancial en el desarrollo de software actual, más aún en un entorno de nube.
A pesar de ello, también es una de las fases de entrega más subestimadas. Las empresas no suelen invertir el tiempo y la energía suficientes para que el despliegue sea rápido, fiable, automatizado, ni nada de eso.
La mayoría de las veces, sigo viendo diversas formas de procedimientos de despliegue manual. En el mejor de los casos, al menos con una lista de comprobación de pasos debidamente documentada. En el peor de los casos, sólo planes aleatorios creados por improvisación en los últimos minutos.
El procedimiento de despliegue automatizado es siempre un objetivo lejano y un marcador de ruta a corto y medio plazo, pero el camino real hacia él es accidentado e impredecible. Sin embargo, disponer de un procedimiento de despliegue totalmente automatizado y fiable es la clave de un ahorro significativo a lo largo del tiempo. Así podrá eliminar el esfuerzo que la mayor parte del equipo de desarrollo suele dedicar a cada versión de producción para su despliegue.
Las estrategias de despliegue Canary y Blue-Green toman todas esas ventajas y les añaden otras, alta disponibilidad y procesos rápidos de instalación y reversión. Permitiendo al equipo lanzar aún más a menudo y sin más noches de insomnio. Echemos un vistazo a lo que aportan y en qué se diferencian.
Despliegue Azul-Verde: Una visión general
La implantación Blue-Green reduce el tiempo de inactividad y el riesgo de las nuevas versiones de software mediante la creación de dos entornos idénticos: activo (azul) e inactivo (verde).
El entorno activo es donde se ejecuta la versión actual del software y los usuarios generan tráfico de producción. El entorno inactivo es donde se despliega y prueba la nueva versión del software.
Una vez que la nueva versión está probada y lista, el tráfico se cambia del entorno activo al inactivo, convirtiéndolo en el nuevo entorno activo. Puede repetir este proceso cuando sea necesario.
Lea también: Explicación del despliegue azul-verde y su papel en DevOps
Características y ventajas clave
Estas son las características específicas del proceso de despliegue Blue-Green:
- Dos entornos idénticos desde el punto de vista de los datos y los procesos. El entorno azul (activo) es donde los usuarios de producción ejecutan sus procesos cotidianos. El entorno verde (inactivo) es donde se instala el nuevo despliegue y siempre está sincronizado con el azul.
- El cambio de tráfico que puede hacer del entorno activo al inactivo, convirtiéndolo en el nuevo entorno activo. El cambio es instantáneo. Todo el despliegue es ya cosa del pasado. No hay ventana de tiempo de inactividad. Los usuarios no necesitan hacer nada para acceder al nuevo entorno.
- La consecuencia es una rápida reversión en caso de problemas. Esto garantiza un tiempo de inactividad mínimo si algo va mal con la nueva versión del software, y la aplicación sigue estando altamente disponible.
- Las pruebas automatizadas son un aspecto clave del despliegue Blue-Green. Garantiza que la nueva versión del software se pruebe a fondo antes de desplegarla en el entorno activo.
- Este despliegue forma parte de una canalización de entrega continua, lo que en última instancia significa lanzamientos más rápidos y frecuentes de software a la producción. Puesto que el despliegue ya está hecho y sólo tiene que hacer el cambio de tráfico en sí, es tan rápido que puede hacerlo todos los días. Suponiendo que sea rápido en las actividades de prueba.
Despliegue canario: Una visión general
El despliegue Canary 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 mientras se mantiene la versión antigua 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 propósito es reducir el riesgo de introducir nuevas características a una gran base de usuarios. De este modo, la transición a la nueva versión se realiza de forma mucho más fluida.
Lea también: Canary Deployment y su papel en DevOps Explicado
Características y ventajas clave
Estas son las características específicas del proceso de despliegue de Canary:
- 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. Así minimiza el riesgo de introducir errores u otros problemas que podrían afectar a todos los usuarios a la vez.
- Supervise de cerca la nueva versión para asegurarse de que es estable y funciona como se espera. Los desarrolladores pueden recibir comentarios sobre la nueva versión más rápidamente, lo que les permite hacer los ajustes necesarios antes de desplegarla a toda la base de usuarios.
- Si surge algún problema, puede revertir el despliegue a la versión anterior de forma rápida y sencilla. Esto ayuda a aumentar la confianza de los desarrolladores y las partes interesadas en el proceso de implantación, ya que reduce el riesgo de introducir problemas que puedan afectar a la experiencia del usuario.
- Automatice el proceso de implantación en la medida de lo posible para reducir el riesgo de error humano.
Resumen: Despliegue azul-verde frente a despliegue canario
| Característica | Implantación Blue-Green | Implantación canaria |
|---|---|---|
| Sincronización de datos | Sincronización constante de datos entre los entornos azul y verde. | Un subconjunto de usuarios o servidores recibe la nueva versión; el resto continúa con la versión actual. |
| Proceso de activación | Pase del entorno activo al inactivo cuando la nueva versión esté lista. | Despliegue gradual a un subconjunto definido de usuarios que prueban activamente las nuevas versiones. |
| Experiencia de los usuarios de producción | Sin tiempo de inactividad en producción; cambio sin interrupciones entre entornos activos. | Un subconjunto de usuarios de producción prueba activamente la nueva versión; posibles problemas para este grupo. |
| Alta disponibilidad frente a velocidad de respuesta | Prioridad a la alta disponibilidad. | Prioridad a una retroalimentación más rápida y un despliegue controlado. |
| Mitigación de riesgos | Reducción de la posibilidad de problemas mediante la liberación gradual a un subconjunto de usuarios. | Pruebas principalmente en entornos inactivos; es posible que los probadores no detecten todos los problemas del mundo real. |
| Enfoque de las pruebas | Pruebas principalmente en entornos inactivos; es posible que los probadores no detecten todos los problemas del mundo real. | Los usuarios de producción actúan como probadores, descubriendo pronto los problemas del mundo real. |
| Casos de uso notables | Netflix, Amazon, Etsy, LinkedIn e IBM utilizan Blue-Green. | Netflix y Google utilizan Canary, junto con pruebas automatizadas y despliegues graduales. |
Despliegue Blue-Green vs. Despliegue Canary: Características
Implantación
El despliegue Blue-Green implica dos entornos (azul y verde). Pero al mismo tiempo, los dos entornos están constantemente sincronizados en términos de datos. Esto aumenta la demanda de procesos permanentes de sincronización de datos entre los dos entornos.
Una vez que se prueba la nueva versión y se considera que está lista, se cambia el tráfico del entorno activo al inactivo, convirtiéndolo en el nuevo entorno activo.
No se pierde tiempo en desplegar el nuevo código y no hay tiempo de inactividad de la producción. Todos los usuarios de producción trabajan todo el tiempo en el entorno actualmente activo, y ni siquiera notan el cambio.
El despliegue canario consiste en desplegar una nueva versión del software a un pequeño subconjunto de usuarios mientras la mayoría de usuarios o servidores siguen utilizando la versión actual. Se trata de un despliegue gradual en lugar de un cambio completo. Los probadores son, en este caso, usuarios directos de producción, aunque sólo un subconjunto definido de ellos. Este grupo está probando activamente la nueva versión con los procesos de producción, y cuando finalmente sea estable, la nueva versión se extenderá al resto de los usuarios.
El despliegue Azul-Verde será su elección si su prioridad es la alta disponibilidad. Puede decantarse por el despliegue Canario si prefiere una retroalimentación más rápida y un despliegue más controlado (aunque más lento).
Mitigación de la diferencia de riesgos
El despliegue Blue-Green mitiga el riesgo de fallo de lanzamiento cambiando rápidamente a la versión anterior estable. Para todos los usuarios y de forma instantánea. Obviamente, sigue existiendo el riesgo de que las nuevas funciones se retrasen para los usuarios en caso de retroceso, pero al menos ninguno de los usuarios se verá bloqueado debido a algún problema crítico de la nueva versión.
La estrategia de mitigación del riesgo de despliegue de Canary radica en la reducción gradual de la posibilidad de problemas. Dado que las nuevas características se liberan a un subgrupo de usuarios de producción, éstos ya utilizan esa versión del software en algún momento antes de que la liberación se extienda a todos los usuarios. La probabilidad de que esos usuarios iniciales detecten pronto algún problema es muy alta.
Diferencia en el enfoque de las pruebas
El despliegue azul-verde deja los procesos de prueba exclusivamente para el entorno inactivo. Aquí los desarrolladores, probadores y diversas partes interesadas pueden probar lo que quieran. Siempre puede esperar un comportamiento similar al que tendrían si las pruebas se ejecutaran directamente en el entorno de producción activo (ya que los datos y la configuración están siempre sincronizados entre los dos entornos).
Así que sus probadores están ejecutando el programa de pruebas, y aún existe la posibilidad de que no detecten todos los problemas que sí detectarían los usuarios reales de producción. Sin embargo, eso no es realmente un problema, ya que el cambio entre los entornos inactivo y activo es siempre rápido. A continuación, puede dejar que los desarrolladores solucionen el problema y volver a realizar el cambio.
El despliegue Canary le permite utilizar usuarios de producción como probadores. Estos usuarios suelen encontrar más problemas en menos tiempo. Sencillamente, ejecutan los procesos empresariales cotidianos de principio a fin.
No sólo porque hayan construido esos escenarios y casos de prueba, sino porque deben hacerlo de todos modos. Se arriesgan a que los del grupo tengan problemas graves durante algún tiempo. Pero no afecta a la mayoría de los usuarios, y el equipo de desarrollo puede concentrarse en los problemas más graves del mundo real de inmediato.
Experiencia y casos de uso
Estos son algunos de los casos de uso conocidos en los que este tipo de despliegues ya funcionan con éxito:
- Netflix utiliza el despliegue Blue-Green para desplegar nuevas versiones de su servicio de streaming.
- Amazon y Etsy utilizan el despliegue Blue-Green para desplegar nuevas versiones de su plataforma de comercio electrónico.
- LinkedIn utiliza el despliegue Blue-Green para desplegar nuevas versiones de su plataforma de redes sociales.
- IBM utiliza el despliegue Blue-Green para desplegar nuevas versiones de su plataforma en la nube.
- Netflix también utiliza Canary Deployment para desplegar cambios en su servicio de streaming. La empresa utiliza una combinación de pruebas automatizadas, banderas de características y pruebas A/B para desplegar lentamente los cambios.
- Google utiliza Canary Deployment para desplegar cambios en sus servicios en la nube. De forma similar, 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 los cambios gradualmente a un pequeño subconjunto de usuarios antes de desplegarlos a todos los usuarios.
Mejores prácticas y tendencias futuras
La automatización es la clave, y los pipelines DevOps son definitivamente el futuro de los procesos de despliegue. Se trata de procesos totalmente automáticos que contienen pasos como
- Creación o actualización de entornos de destino en términos de servicios, datos, usuarios o privilegios.
- Despliegue automatizado de versiones completas/delta de los códigos fuente directamente desde el repositorio de código.
- Actualización del esquema de la base de datos y refresco de datos.
- Ejecución automatizada de pruebas directamente durante las actividades de despliegue.
- Procesos de reversión automatizados en caso de que algún caso de prueba importante no se complete con éxito.
- Eliminación a cero de cualquier paso de intervención manual.
Una vez que disponga de estos pipelines de despliegue, podrá conectar los procesos Canary o Blue-Green o cualquier otro que desee. Ésos son sólo dos de los ejemplos que ya han demostrado funcionar bien. Pero sólo son marcos filosóficos para resolver la mayoría de los problemas de las actividades de despliegue. Ni siquiera es difícil cambiar de uno a otro con el tiempo o utilizar una combinación de ambos.
Palabras finales
Ceñirse a procedimientos de despliegue manuales es la muestra de procesos de desarrollo o incluso de equipos que no han madurado. Alternativamente, puede exponer lo inflexible y monolítica que es la empresa en cuestión en términos de entrega de software. En ambos casos, supone mucho trabajo arreglar el statu quo. Por lo tanto, intente aplicar a su proyecto las estrategias de despliegue mencionadas anteriormente.
A continuación, consulte cómo desplegar aplicaciones en Kubernetes.