Presentación

Nombre:
Jonathan Montero Olivo

Matrícula:
2021-0079

Grupo:
4

Profesor:
Francis Ramirez

Materia:
Electiva ll
 Capítulo 4 “Continuos Deployment”

Entrega continua e implementación continua

La entrega continua es una práctica en la que los equipos se aseguran de que los

artefactos que construyen se validen continuamente y estén listos para

implementarse en el entorno de producción. A menudo, esto se hace

implementando los artefactos en un entorno de producción, como un entorno de

aceptación o incluso de ensayo, y aplicando una serie de pruebas, como pruebas

de verificación, para garantizar que la aplicación funcione correctamente.

La implementación continua es una práctica en la que cada versión que se

implementa en un entorno similar al de producción y pasa todas las pruebas y

verificaciones, también se implementa en producción automáticamente.

Cuando se trabaja con Azure DevOps, Azure Pipelines es la herramienta preferida

para implementar la entrega y la implementación continuas. Esto se puede hacer

con el editor visual clásico o con canalizaciones YAML de varias etapas, las cuales

se analizarán en la siguiente sección.

 ¿Qué etapas necesito?

Una de las preguntas que surgen con frecuencia cuando se trabaja con

lanzamientos es, ¿qué etapas necesito en mi tubería de lanzamiento? De acuerdo

con la documentación, las etapas deben indicar las principales divisiones de una

canalización de lanzamiento. Al comenzar con los lanzamientos, esto a menudo

se reduce a tener una etapa por entorno en una canalización de lanzamiento. Las

etapas apropiadas incluyen prueba, aceptación y producción.

Cuando trabajamos con lanzamientos durante mucho tiempo, es posible que

incorporemos más automatización en las canalizaciones y deseemos agregarles

etapas de verificación adicionales. Un ejemplo podría ser una etapa llamada

prueba de carga que se ejecuta en paralelo a la etapa de prueba. Otro ejemplo

podría ser la introducción de una etapa para pruebas de IU automatizadas.

Independientemente de las etapas que se agreguen, el enfoque para propagar

una versión a producción siempre debe ser el mismo. Cuando una versión se

propaga de una etapa a otra y se acerca a la producción, esto debería mostrar

que existe confianza en esta versión, que funciona correctamente y que se puede

promocionar a producción.
 Trabajar con grupos de implementación

Otro tema con el que puede encontrarse en algún momento es la implementación

de una aplicación en servidores locales o servidores que están detrás de un firewall.

También puede encontrarse con situaciones en las que es necesario ejecutar scripts

en todas las máquinas que alojan la aplicación o situaciones en las que el entorno

de destino no proporciona un mecanismo para implementar aplicaciones.

Cuando se implementa en máquinas de destino a las que no se puede conectar, se

debe adoptar otro enfoque. Este enfoque se denomina implementación basada en

agentes. En una implementación basada en agentes, se instala un agente de Azure

DevOps en cada máquina en la que se instalará la aplicación. A continuación, estos

agentes deben agruparse en grupos de implementación. Una vez hecho esto, se

puede agregar un trabajo de grupo de implementación a la versión.

 Implementación de estrategias de implementación continua

Antes de implementar una aplicación de forma continua, es importante pensar en la

estrategia que debemos usar. Hacer una implementación tras otra puede tener más

riesgos asociados de los que la empresa está dispuesta a aceptar. Es importante

pensar en cómo lidiar con los problemas que pueden ocurrir durante o después de

implementar una nueva versión de su aplicación.

Hay algunas estrategias de implementación que se pueden aplicar para reducir los

riesgos que pueden surgir con las implementaciones, tenga en cuenta que es

posible combinar uno o más de los siguientes patrones. Por ejemplo, es

perfectamente posible utilizar una estrategia azul-verde para cada anillo en una

implementación basada en anillos. Además, todas las estrategias de

implementación se pueden combinar con el uso de indicadores de funciones.

 Despliegues azul-verde

Las implementaciones blue-green son una técnica en la que una nueva versión de

una aplicación nunca se implementa directamente en los servidores de producción.

En su lugar, primero se implementa en otro conjunto de servidores. Una vez que

esto se ha hecho con éxito, los usuarios son dirigidos a la nueva implementación.

Servidores inmutables

Una variación del patrón de implementación azul-verde son los servidores

inmutables. Con servidores inmutables, no hay ida y vuelta entre dos grupos de

servidores. En cambio, el grupo de servidores que sirven la versión anterior de la

aplicación se ignora o elimina por completo. A menudo, esto se hace después de

un período de gracia.
 Exposición progresiva

La exposición progresiva es una estrategia de implementación en la que la cantidad

de usuarios que tienen acceso a una nueva implementación o una nueva

característica aumenta lentamente con el tiempo. El objetivo de esta estrategia es

limitar la cantidad de usuarios que experimentan problemas cuando se pone a

disposición una versión defectuosa de una función.

Despliegues canarios

La primera estrategia para la exposición progresiva es usar despliegues

controlados. En una implementación canary, no todos los usuarios se enrutan a la

nueva versión de inmediato; solo un porcentaje limitado de los usuarios obtiene

acceso a esa versión. Estos usuarios son los canarios y son monitoreados muy de

cerca. Si experimentan algún problema o si se mide la degradación del rendimiento

o de un servicio, la nueva implementación se revierte rápidamente.

 Despliegues basados en anillo

En un entorno basado en anillo, no hay un solo entorno de producción, hay varios.

Cada entorno de producción sirve solo a una parte de los usuarios. Su diferencia

con una implementación canary es que, en lugar de solo dos entornos, puede

haber tantos entornos como sea necesario. Además, cada nueva versión va a

todos los anillos, uno tras otro.

Indicadores de funciones

La tercera forma de implementación progresiva se puede lograr mediante

indicadores de funciones, también llamados conmutadores de funciones.

Mientras que las implementaciones canarias y las implementaciones basadas en

anillos se basan en la exposición lenta de nuevos archivos binarios a un número

cada vez mayor de usuarios, las marcas de funciones se utilizan para exponer

lentamente las nuevas funciones a un número cada vez mayor de usuarios. Esto

se puede lograr incluso si todos envían solicitudes al mismo servidor. Los

indicadores de funciones se utilizan para desvincular la implementación de una

nueva versión de los archivos binarios de la aplicación de la publicación de

nuevas funciones al habilitar o deshabilitar funciones específicas en tiempo de

ejecución.
El mejor ejemplo de un indicador de función es mostrar u ocultar un botón que

brinda a los usuarios acceso a una nueva función. La configuración de la

aplicación, una base de datos o un servicio externo se utilizan para realizar un

seguimiento de qué función se ha habilitado para qué usuario. Dependiendo de

esa configuración, la función se muestra u oculta. Ejemplos de dichos servicios

externos incluyen LaunchDarkly, Split.IO y Prefab.cloud.

Otros indicadores de funciones pueden activar o desactivar las correcciones de

errores o las mejoras de rendimiento. Esto puede ayudar a exponerlos

gradualmente para garantizar que no haya problemas. Cuando se usan

alternancias de funciones para este tipo de cambios más profundos en una base

de código, la introducción de alternancias de funciones también tiene un costo, y

debe existir un proceso para esto. Este proceso no solo debe describir la adición

de alternancias de funciones, sino también cómo eliminarlas lo antes posible. Un

ejemplo de tal proceso puede ser el siguiente.

Un desarrollador introduce un nuevo indicador de función tan pronto como la

empresa necesita lanzar la función independientemente de las implementaciones

realizadas por el equipo de desarrollo, o para un cambio que el equipo de

desarrollo califica como de alto riesgo y quiere poder realizar. en cualquier

momento sin volver a implementarlo.

Después de introducir el cambio de función, se desarrolla y prueba la nueva

función o el cambio. Esto significa que hay una o más declaraciones si en el

código base que ejecutan diferentes rutas de código, según el estado del

indicador de función. En este punto, la aplicación debe mantener dos rutas de

ejecución de código hasta que eliminen nuevamente el indicador de función. Es

una buena práctica separar estas dos rutas de código tanto como sea posible

utilizando las prácticas de ingeniería existentes, como la inyección de

dependencia.

Si bien el código se envía continuamente a los usuarios, la función no está

habilitada para nadie. Solo cuando el equipo de desarrollo está completamente

satisfecho con el cambio o el propietario del producto siente que es el momento

adecuado para lanzar una nueva función, se activa el indicador de función.

Es importante no detenerse aquí. Después de activar el indicador de función, se

debe determinar activamente si la función o el cambio funcionan correctamente.

Y si es así, el indicador de función debe eliminarse lo antes posible. De esta

manera, el tiempo durante el cual se deben mantener las dos rutas de código es

lo más corto posible.

 Retroceder o fallar adelante

Independientemente de la estrategia que se utilice, es necesario pensar en la

capacidad de revertir una o más versiones y cuánto tiempo llevará. Por ejemplo, las

implementaciones azul-verde nos brindan la capacidad de volver a una versión casi

instantáneamente, siempre que aún no se implemente una nueva versión en los

servidores no activos. Por otro lado, realizar una reversión en una implementación

basada en anillo requerirá una nueva implementación completa de la versión

anterior, lo que probablemente llevará más tiempo y conlleva todos los riesgos de

la implementación en sí misma. Es posible que esto incluso deba hacerse en varios

anillos, lo que lo hace más desafiante.

Otro enfoque que se puede adoptar es el de fallar hacia adelante. Al adoptar este

enfoque, se afirma que nunca habrá una reversión a una versión anterior. En

cambio, cuando se encuentre algún problema, se solucionará volviendo a

implementar una nueva versión con la solución de ese problema. Esta estrategia

está ganando terreno últimamente, ya que ahorra tiempo, ya que no tenemos que

preparar, probar y practicar retrocesos. Sin embargo, puede haber riesgos

relacionados con este proceso:

• No hay garantía de que la corrección sea correcta. Es posible que la nueva

versión implementada no resuelva el problema o, peor aún, que la nueva versión

provoque la transición de un problema a otro.

• Resolver una causa raíz detallada de cualquier problema lleva tiempo, al igual

que escribir una solución. La consecuencia de esto podría ser que la corrección

podría tardar más de lo que hubiera tardado una reversión.

No importa qué enfoque se adopte, considere las consecuencias y prepárese para

ellas.
 Despliegue de Octopus

Octopus Deploy es una herramienta de automatización de implementación que

se basa en el concepto de ejecutar una serie de tareas en una o más máquinas

de destino.

Octopus llega a estas máquinas a través de un tentáculo (un agente) que se

instala en estas máquinas. En Octopus Deploy, es posible definir aplicaciones y

entornos y asignar una o más máquinas a cada uno de ellos. Para realizar

implementaciones, los pasos de ejecución se pueden definir en un editor gráfico,

comparable al editor de versión visual de Azure DevOps.

Una de las principales diferencias es que estos pasos no se definen por entorno,

solo una vez por tubería. A continuación, es posible especificar en qué entornos

debe ejecutarse cada tarea. De esta forma, es más fácil ver dónde varía la

implementación en diferentes entornos.

Hay una integración disponible entre Azure DevOps y Octopus Deploy, en forma

de una tarea de compilación y lanzamiento. Con esta integración, puede iniciar

una implementación con Octopus Deploy desde una canalización de versión o

compilación de Azure DevOps.