Estrategias de implementación

Las prácticas de DevOps incluyen ciclos de lanzamiento frecuentes que benefician a las organizaciones y a los usuarios finales de muchas maneras. Dado que las implementaciones individuales son más pequeñas, resultan más rápidas y menos estresantes, pero aun así se pueden producir errores. Para reducir la posibilidad de que se produzcan problemas, debe adoptar la estrategia de implementación que se adapte mejor a las necesidades de su organización.

Ya conoce el enfoque de "despliegue épico", también conocido como la estrategia del "big bang". Como ya sabe, este método no funciona bien con las aplicaciones modernas. Existen otras estrategias de implementación que se han popularizado en el contexto de las operaciones modernas, cada una de ellas con sus propias ventajas y debilidades, en función de la situación.

Estrategia de implementación gradual

La estrategia de implementación gradual adopta un enfoque gradual para introducir nuevas versiones de código. La nueva versión se realiza por fases durante un período de tiempo, lo que aumenta gradualmente las instancias del nuevo código mientras se reducen las instancias del antiguo. Como resultado, las instancias antiguas y nuevas coexisten en el destino de implementación durante el lanzamiento. Por ejemplo, puede actualizar el software en un servidor, una máquina virtual o un contenedor a la vez.

Una ventaja de esta estrategia es que puede supervisar el nuevo código en el entorno de producción para asegurarse de que cumple los requisitos de rendimiento, seguridad, confiabilidad y otros estándares antes de implementarlo de forma generalizada.

Estrategia de implementación azul-verde

La estrategia de implementación azul-verde usa dos entornos independientes que se mantienen lo más similares posible y son capaces de atender el tráfico de producción. Un entorno controla la carga de producción actual, mientras que la otra hospeda la nueva versión del software para que pueda validarla antes de cambiar el tráfico. Cuando esté satisfecho con que la nueva versión es saludable, puede cambiar todo el tráfico de una vez o aumentar gradualmente el porcentaje de tráfico que va al nuevo entorno mientras monitorea los resultados.

El entorno azul es el que actualmente atiende el tráfico de producción. El entorno verde es su homólogo paralelo. Primero se implementa la nueva versión del software en verde, se valida y, a continuación, se enruta el tráfico de producción de azul a verde. Después de la transición, los roles pueden cambiar: el entorno inactivo (verde) pasa a ser el entorno de producción y el entorno activo (azul) se puede preparar para el siguiente ciclo o versión.

Una ventaja de esta estrategia es que puede cambiar rápidamente, a menudo con poco o sin tiempo de inactividad. También es relativamente fácil dirigir el tráfico al entorno anterior si se produce un problema después de que el nuevo entorno vuelva a estar activo.

Estrategia de implementación canaria

La estrategia de implementación de valores controlados combina algunos elementos de la implementación gradual y de la implementación azul-verde. El cambio no se realiza a la vez, sino que se implementa la nueva versión en una parte limitada del entorno de producción y, luego, se traslada gradualmente todo el tráfico a la nueva versión. El software se implementa en pasos incrementales en un número limitado de instancias o usuarios hasta que se haya comprobado que funciona correctamente y, luego, se implementa en el resto de la infraestructura.

El nombre proviene de la práctica de usar canarios en las minas de carbón como un sistema de advertencia temprana. En una implementación de valores controlados, puede realizar pruebas automatizadas y usar la supervisión y el análisis para obtener una advertencia anticipada de cualquier problema relacionado con la nueva versión en un subconjunto de instancias o usuarios. De este modo, todo el entorno de producción no se ve afectado.

Banderas de características

El concepto de "marca de característica" es otra estrategia que requiere un poco más de sofisticación por parte de los desarrolladores. En lugar de tener dos versiones independientes del mismo software (una antigua y otra nueva con nuevas características), se envía una sola versión que contiene el comportamiento anterior más los cambios nuevos. Los nuevos cambios están inactivos de forma predeterminada y no son visibles hasta que se active la "marca de características" correspondiente. Una marca puede tomar muchas formas, incluida una línea en un archivo de configuración, un argumento de línea de comandos o un valor recuperado de un servicio de configuración remota y evaluado en tiempo de ejecución.

Una ventaja fuerte de este enfoque es la facilidad de revertir si se produce un problema y la facilidad de implementación lenta de los cambios. En muchos casos, no es necesario enviar una nueva versión para exponer u ocultar la característica. Simplemente puede desactivar o activar la marca adecuada y permitir que la aplicación en ejecución reaccione a la nueva configuración.

En Azure, la funcionalidad feature management de Azure App Configuration proporciona un almacén de marcas de características administrado desde el que las aplicaciones pueden leer en tiempo de ejecución, con compatibilidad con SDK para .NET, Java, Python, JavaScript y Go.

Implementaciones basadas en topología de anillo

Una implementación basada en anillos es una forma estructurada de lanzamiento progresivo que se usa ampliamente dentro de Microsoft y Azure. El nuevo código se publica en una secuencia de "anillos". Por ejemplo, una fase interna o de prueba piloto, una fase de implementación temprana, una fase de implementación general y, por último, una fase de disponibilidad general. Cada anillo es más grande que el anterior y la implementación solo avanza al siguiente anillo después de que las señales de estado del anillo actual cumplan con los criterios definidos. Las implementaciones basadas en etapas combinan la exposición gradual de las implementaciones con segmentación (tipo canario) con audiencias directas, designadas y con controles de validación entre fases.

Entrega progresiva

Las estrategias anteriores (con valores controlados, basadas en etapas y activadores de funciones) a menudo se agrupan bajo el término entrega progresiva. La premisa fundamental consiste en que una versión se expone a un grupos de usuarios controlado que va aumentando, se evalúa mediante métricas de estado y de negocio y pasa de fase o se revierte automáticamente según los indicadores recibidos. La entrega progresiva es cada vez más el modelo predeterminado para los servicios en la nube de alta confiabilidad porque limita el radio de explosión de cualquier cambio individual.

Procedimientos recomendados de implementación

Independientemente de la estrategia de implementación que use, algunos procedimientos recomendados le ayudarán a minimizar el riesgo al implementar software nuevo o una nueva versión de software existente:

• Use herramientas adecuadas, como Azure Pipelines o GitHub Actions, para crear una canalización de implementación e integración continuas.

• Integre las pruebas automatizadas.

• Use canales de comunicación para notificar a las partes adecuadas de los resultados de las pruebas. Alertar a los equipos cuando las implementaciones fallen o encuentren problemas.

• Supervise los problemas inmediatamente después de la implementación.

• Tenga un plan para revertir si una nueva versión no supera las comprobaciones de estado ni funciona correctamente.