• Nombre: Misael Samboy Sanchez

• Matrícula: 2021-1066
• Período académico: Septiembre, diciembre 2023
• Fecha de entrega: 17 de Noviembre de 2023
• Nombre del Profesor: Francis Ramirez
• Nombre del tema de estudio: Asignación individual
Despliegue continuo
En el capítulo anterior, aprendió a utilizar canalizaciones de Azure DevOps para una integración continua.
Debido a esto, ahora sabe cómo elegir una versión de sus fuentes y crear artefactos que puedan
implementarse. En este capítulo, aprenderá cómo ampliar esta práctica con entrega e implementación
continuas para que pueda implementar automáticamente estos artefactos en los servidores o
plataformas en los que se ejecuta su código.

Para hacer esto, comenzaremos presentando las definiciones de versiones de Azure DevOps para que
pueda definir y ejecutar las versiones de su aplicación. A continuación, se presentarán una serie de
estrategias que puede utilizar para realizar implementaciones de manera de bajo riesgo. Hacer esto le
permite automatizar el proceso de implementación de nuevas versiones sin supervisión, con un riesgo
limitado de que se produzcan incidentes. A partir de aquí, centraremos nuestra atención en automatizar
la creación de notas de la versión. Después de esto, presentaremos App Center, que se utiliza para
implementar aplicaciones móviles. Finalmente, se introducirán otras herramientas para el despliegue
continuo.

Los siguientes temas se cubrirán en este capítulo:

• Entrega continua e implementación continua

• Trabajar con versiones de Azure DevOps
• Escribir canalizaciones YAML de varias etapas
• Implementar estrategias de implementación continua
• Implementación de aplicaciones móviles
• Automatización de notas de la versión
• Otras herramientas
Requerimientos técnicos
Para experimentar con las técnicas descritas en este capítulo, es posible que necesite uno o más de los
siguientes:

• Una cuenta de Azure DevOps para crear definiciones de versiones y canalizaciones YAML de
varias etapas.
• Una cuenta de App Center para implementar aplicaciones móviles

Hay opciones de prueba gratuitas disponibles para ambos.

Entrega e implementación continuas

La diferencia entre entrega e implementación continuas es una fuente común de confusión. Algunas
personas piensan que estos términos son intercambiables y los ven como dos sinónimos del mismo
concepto, pero en realidad tienen dos significados diferentes.

La entrega continua es una práctica en la que los equipos se aseguran de que los artefactos que crean 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 similar a la producción, como un entorno de
aceptación o incluso de prueba, y aplicando una serie de pruebas, como pruebas de verificación, para
garantizar que la aplicación esté funcionando correctamente.

La implementación continua es una práctica en la que cada versión que se implementa en un entorno
similar a la 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 elegida para implementar la
entrega y la implementación continuas. Esto se puede hacer utilizando el editor visual clásico o con
canalizaciones YAML de varias etapas, las cuales se analizarán en la siguiente sección.
Trabajar con versiones de Azure DevOps
La entrega y la implementación continuas se pueden implementar en Azure DevOps mediante versiones.
Al crear una nueva definición de lanzamiento, se crea un esquema del proceso de lanzamiento. Este
proceso suele comenzar con un artefacto que desencadena la creación de una nueva versión. A
continuación, es posible definir una o más etapas en las que se puede implementar la versión. A
menudo, estas etapas corresponden a los diferentes entornos de la aplicación, por ejemplo, prueba y
producción, pero esto no es obligatorio.

¿Qué etapas necesito?

Una de las preguntas que surge con frecuencia cuando se trabaja con lanzamientos es: ¿qué etapas
necesito en mi canal de lanzamientos? Según la documentación, las etapas deben indicar las divisiones
principales de un proceso de lanzamiento. Al comenzar con los lanzamientos, esto a menudo se reduce a
tener una etapa por entorno en un proceso de lanzamiento. Las etapas apropiadas incluyen prueba,
aceptación y producción.

Cuando trabajamos con versiones durante mucho tiempo, es posible que incorporemos más
automatización en las canalizaciones y queramos agregarles etiquetas 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.

No importa qué etapas se agreguen, el enfoque para propagar un lanzamiento a producción siempre
debe ser el mismo. Cuando un lanzamiento se propaga de etapa en etapa y se acerca a la producción,
esto debería mostrar que hay confianza en este lanzamiento, que está funcionando correctamente y que
se puede promover a producción.
Trabajar con grupos de implementación
Otro tema con el que podría toparse 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 sea necesario ejecutar scripts en todas las máquinas que alojan la aplicación o
situaciones en las que el entorno de destino no proporcione un mecanismo para implementar
aplicaciones.

El enfoque para realizar versiones, que se mostró en la sección Trabajar con versiones de Azure DevOps
de este capítulo, se basa en poder conectarse a las máquinas o servicios de destino que hospedarán la
aplicación. A estas las llamamos implementaciones basadas en push y esto no siempre es posible.

Al implementar 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
agente, 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.

Esto es muy similar al trabajo de un agente, excepto por una cosa. En un trabajo de agente, las tareas del
trabajo se ejecutarán en uno de los agentes en la máquina de destino. En un trabajo de grupo de
implementación, todas las tareas se ejecutarán en todos los agentes del grupo de versión en las
máquinas de destino. Esta diferencia entre ambos enfoques se puede ver en el siguiente diagrama:

Cuando se utiliza este enfoque, es necesario tener agentes en las máquinas en las que se debe
implementar la aplicación. Estos agentes escuchan Azure DevOps y cada vez que se solicita una nueva
versión, recuperan el trabajo y lo ejecutan en la máquina local.
Escribir canalizaciones YAML de varias etapas
Además del diseñador visual para las definiciones de versiones, también es posible implementar una
implementación continua utilizando canalizaciones YAML. Al hacerlo, aún se recomienda diferenciar
entre las fases de compilación (CI) y lanzamiento (CD) de una canalización. Para hacer esto posible se
utiliza el concepto de etapas. Una canalización YAML se puede dividir en una o más etapas. Una etapa
puede representar un entorno como prueba, aceptación o producción, pero esto no siempre es cierto.
Si, en un escenario de aplicación, tiene sentido agregar etapas adicionales, como la preproducción o la
puesta en escena, esto es posible. Es una buena práctica publicar artefactos de canalización en etapas
anteriores y consumir o descargar artefactos en etapas posteriores.

Las canalizaciones YAML de varias etapas son el nuevo valor predeterminado para crear canalizaciones
en Azure DevOps. Dado que trabajar con canalizaciones YAML puede tener una curva de aprendizaje más
pronunciada que trabajar con versiones clásicas, a algunos les resulta más fácil trabajar primero con
versiones clásicas y cambiar a canalizaciones YAML más tarde. Al igual que con las compilaciones,
muchos de los conceptos de las versiones clásicas también se traducen en canalizaciones YAML de varias
etapas.

Aprobaciones

En una canalización de varias etapas, no es posible definir aprobadores como ocurre en una canalización
de lanzamiento clásica. La razón de esto es que el proceso (el proceso de construcción e
implementación) se considera código. Sólo los desarrolladores y operadores trabajan en el código. Las
aprobaciones las elaboran, por ejemplo, los propietarios de productos. Sin embargo, esto no significa
que no sea posible implementar flujos de aprobación para el avance de un oleoducto a la siguiente
etapa.

Para controlar si se permite que una tubería avance hasta una determinada etapa, es necesario
introducir el concepto de entornos. Un entorno se define cuando le damos un nombre y una descripción.
Se pueden adjuntar uno o más aprobadores a estos entornos. Una vez hecho esto, los trabajos se
pueden configurar para apuntar a dicho entorno. Si hay al menos un trabajo en una etapa que apunta a
un entorno, entonces se dice que ese entorno es utilizado por la etapa. Si se ha configurado una
aprobación en ese entorno, la implementación en esa etapa no continuará hasta que el aprobador haya
dado permiso.
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 utilizar. Simplemente realizar 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 abordar los problemas
que puedan surgir 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, todas las cuales se tratarán en esta sección. 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.

Implementaciones azul-verde
Las implementaciones azul-verde 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 cambio, primero se implementa en
otro conjunto de servidores. Una vez que esto se haya hecho correctamente, los usuarios serán dirigidos
a la nueva implementación.

Supongamos que una aplicación se ejecuta en un total de tres hosts de forma predeterminada. Una
configuración típica para la implementación azul-verde sería dos conjuntos de tres hosts: el grupo azul y
el grupo verde. Delante de estos dos conjuntos, hay un proxy inverso que funciona como equilibrador de
carga y redirige las solicitudes entrantes al grupo azul. El siguiente diagrama muestra cómo funciona
esto:

Para implementar una nueva versión de la aplicación en esta situación, es necesario implementarla en
los servidores. Dado que estos servidores no reciben ningún tráfico de los usuarios finales, este es el
caso.

grupo verde de no tiene ningún impacto en Después de la implementación, se puede verificar la nueva
implementación para garantizar que haya sido exitosa y que la aplicación se esté ejecutando
correctamente. Después de esta verificación, el balanceador de carga se reconfigura para redirigir el
tráfico al grupo verde. Ahora, la nueva versión de la aplicación. que el está servido.
Si de repente surge algún problema inesperado, es muy fácil volver a la implementación anterior
reconfigurando el balanceador de carga al grupo azul. Si la implementación es exitosa y no hay
problemas, es posible iniciar la implementación de la siguiente versión siguiendo el mismo
procedimiento, pero ahora con las funciones de los grupos verde y azul intercambiadas.

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 se elimina por completo. A menudo esto se hace
después de un período de gracia.

El resultado de esto es que todavía habrá medios para volver a una versión anterior, casi
instantáneamente si los servidores antiguos se mantienen por un tiempo. El otro beneficio es que ahora
existe la garantía de que ningún resto de un despliegue anterior se trasladará a los despliegues más
nuevos. Al utilizar servidores inmutables, el cambio de servidores activos a lo largo del tiempo podría
verse de la siguiente manera:

Por supuesto, un enfoque como este sólo es factible cuando se utilizan tecnologías como contenedores.
o máquinas virtuales. Nadie esperaría que alguien ignorara los servidores físicos después de cada
redistribución.

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 característica aumenta lentamente con el tiempo. El
objetivo de esta estrategia es limitar la cantidad de usuarios que experimentan problemas cuando está
disponible una versión defectuosa de una función.

También podemos ver esto de manera más positiva y en línea con la forma de pensar de la
implementación continua: exponer una nueva característica solo a unos pocos usuarios al principio y
aumentar ese número con el tiempo nos permite aumentar la confianza en una nueva versión o
característica. de una aplicación antes de exponerla a todos los usuarios.
Implementaciones canarias
La primera estrategia para una exposición progresiva es utilizar implementaciones canary. En una
implementación canary, no todos los usuarios son dirigidos a la nueva versión inmediatamente; 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.

Un enfoque típico para realizar implementaciones canary es utilizarlas en combinación con

implementaciones azul-verde. La diferencia es que en lugar de cambiar a todos los usuarios al mismo
tiempo, solo un pequeño porcentaje se mueve a la nueva versión al principio, y luego la cantidad de
usuarios que se mueven aumenta gradualmente con el tiempo. Esto podría ser algo similar a lo
siguiente:

Si una implementación se revierte porque se han observado errores, esta no es una experiencia divertida
para los usuarios. Para evitar que el mismo pequeño grupo de usuarios tenga problemas repetidamente,
podría resultar beneficioso seleccionar un grupo diferente de usuarios canary posteriormente.

Implementaciones basadas en anillos

En un entorno basado en anillo, no existe un único entorno de producción, sino varios. Cada entorno de
producción sirve sólo 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 llega a todos los anillos, uno tras otro.
Banderas de características
Se puede lograr una tercera forma de implementación progresiva utilizando indicadores de
características, también llamados cambios de características. Mientras que las implementaciones canary
y basadas en anillos dependen de la entrega lenta de nuevos archivos binarios a cada vez más usuarios,
los indicadores de funciones se utilizan para entregar lentamente nuevas funciones a cada vez más
usuarios. Los indicadores de funciones se utilizan para desacoplar la implementación de una nueva
versión de los archivos binarios de una aplicación del lanzamiento de nuevas funciones al habilitar o
deshabilitar ciertas funciones en tiempo de ejecución.

Se utiliza una configuración de aplicación, una base de datos o un servicio externo para rastrear qué
función está habilitada para qué usuario.

Otros proveedores de funciones pueden habilitar o deshabilitar correcciones de errores o mejoras de

rendimiento. Cuando se utilizan funciones de conmutación para realizar cambios como este más
profundamente en la base del código, realizar cambios en las funciones también tiene un costo y es
necesario que exista un proceso para hacerlo. Este proceso debe cubrir no sólo la adición de cambios de
funciones, sino también cómo eliminarlos lo antes posible.

Un desarrollador introduce una nueva característica tan pronto como la empresa necesita lanzar esa
característica, independientemente de las implementaciones realizadas por el equipo de desarrollo, o
para un cambio que el equipo de desarrollo evalúa como de alto riesgo y desea poder implementar.
Introducir un indicador de función significa que se aplica una nueva entrada de base de datos o una
declaración de una nueva configuración a la configuración de la aplicación.

código dependiendo del 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.

La bandera de función se activa solo cuando el equipo de desarrollo está completamente satisfecho con
el cambio o el propietario del producto considera que es el momento adecuado para lanzar una nueva
función.

Después de habilitar el indicador de función, debe determinar activamente si la función o el cambio

funcionan correctamente. De esta forma, el tiempo que deben mantenerse las dos rutas de código es lo
más corto posible.

También tenga en cuenta que además de gestionar una mayor cantidad de rutas de ejecución, ahora
también hay una mayor cantidad de rutas para pruebas. Los indicadores de funciones que solo se
pueden activar o desactivar según el estado de otro indicador de funciones pueden ser costosos y es
mejor evitarlos.

Cuando se implementa correctamente y se elimina lo más rápido posible, el costo adicional de los
indicadores de funciones a menudo vale la pena.

Si bien el código se distribuye continuamente a los usuarios, la función no está habilitada para nadie.
Retroceder o avanzar
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
posibilidad de retroceder una versión casi instantáneamente, siempre y cuando aún no se haya
implementado 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 reimplementació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 incluso sea necesario hacer esto en varios anillos, lo que lo hace más desafiante.

Centro de aplicaciones a través de Azure Pipelines

App Center también se puede integrar con Azure Pipelines. Si los equipos están familiarizados con el
proceso de lanzamiento en Azure Pipelines, podría tener sentido crear la aplicación en Azure Pipelines y
usar solo App Center para la implementación en tiendas y grupos de distribución.

Para que esto sea posible, hay tareas disponibles en Azure Pipelines para descargar una versión y
desencadenar su implementación en un repositorio o grupo de distribución. De esta manera, las
versiones se pueden administrar en Azure Pipelines y, al mismo tiempo, aprovechar las capacidades de
App Center cuando sea necesario.

Centro de aplicaciones a través de Azure Pipelines

App Center también se puede integrar con Azure Pipelines. Si los equipos están familiarizados con el
proceso de lanzamiento en Azure Pipelines, puede ser sensato crear la aplicación en Azure Pipelines y
usar App Center solo para la implementación en tiendas y grupos de distribución.

Para que esto sea posible, hay tareas disponibles en Azure Pipelines que le permiten cargar una versión y
desencadenar la implementación de una versión en una tienda o grupo de distribución. De esa manera,
la administración de versiones se puede realizar en Azure Pipelines mientras se siguen aprovechando las
capacidades específicas de App Center cuando corresponda.

Esta sección se centró específicamente en las aplicaciones móviles, mientras que la siguiente sección se
aplicará a todo tipo de lanzamientos. Cuando la creación de versiones está automatizada y las nuevas
versiones se suceden rápidamente, también es útil comenzar a automatizar la creación y publicación de
notas de la versión. Esto se discutirá en la siguiente sección.
Implementación de pulpo
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 está instalado 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 lanzamiento visual de Azure DevOps.

Una de las principales diferencias es que estos pasos no se definen por entorno, solo una vez por
canalización. A continuación, es posible especificar en qué entornos debe ejecutarse cada tarea. De esta
manera, 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 tarea de compilación
y lanzamiento. Con esta integración, puede iniciar una implementación usando Octopus Deploy desde
una canalización de compilación o versión de Azure DevOps.

Resumen
En este capítulo, aprendió sobre la entrega e implementación continuas y cómo implementarlas
mediante Azure DevOps. Además del editor de lanzamiento visual, también aprendió sobre las
canalizaciones YAML de múltiples etapas, que puede usar para lanzar su software en múltiples etapas,
hasta llegar a producción. A continuación, analizamos una serie de estrategias que puede utilizar para
realizar la publicación. Ahora ya conoce las implementaciones azul-verde, el uso de servidores
inmutables y las diferentes estrategias para una exposición progresiva. También aprendió a elegir entre
asegurarse de tener capacidades de reversión o aceptar una estrategia de avance fallido.

Luego, aprendió a automatizar las notas de la versión y la documentación y cómo puede generarlas
automáticamente como parte de su proceso. Después de eso, aprendió sobre la implementación
continua de aplicaciones móviles y en qué se diferencia de la entrega de aplicaciones web. Finalmente,
conoció la existencia de Octopus Deploy, cómo opera y que se integra con Azure DevOps.