Automatizar el ciclo completo de desarrollo, desde un cambio en el código hasta su publicación en producción, es una de las mayores ventajas que ofrece Azure DevOps. Con la configuración adecuada de repositorios, pipelines y releases, es posible lograr que todo funcione sin salir del navegador y sin herramientas adicionales.
¿Cómo se conectan los servicios de Azure DevOps en un flujo completo?
El punto de partida es el repositorio alojado en la sección de Repos [0:47]. Allí se encuentra todo el código fuente del proyecto. Este repositorio alimenta directamente al pipeline de integración continua, que se encarga de ejecutar una secuencia de comandos automatizada cada vez que detecta un cambio en el branch asociado.
El pipeline realiza tres tareas fundamentales [1:07]:
- Instalar todas las dependencias del proyecto.
- Compilar el proyecto y preparar los archivos para publicación.
- Empaquetar los archivos en un archivo .zip y publicarlo como un artefacto.
Este artefacto queda disponible para ser consumido por otros pipelines o, en particular, por la sección de releases [1:42]. Los releases permiten ver el historial completo de publicaciones: cuáles fueron satisfactorias, la fecha, el branch asociado y el estado de cada despliegue.
¿Qué sucede al hacer un cambio en el código?
Para demostrar la automatización, basta con editar un archivo directamente desde el portal. En el ejemplo, se modifica el header de la aplicación cambiando el texto de "Reapp Hooks" a "Reapp Hooks en Azure DevOps" [2:29].
Al hacer commit sobre el branch master, que es el branch vinculado al pipeline, se desencadena automáticamente todo el proceso [3:03]. Es importante recordar que el trigger o desencadenador solo se activa cuando el cambio ocurre en el branch configurado; si se modifica otro branch, el pipeline no se ejecutará.
¿Cómo se ejecuta el pipeline de integración continua?
Una vez realizado el commit, el pipeline entra en cola y comienza la ejecución del job configurado [3:22]. Paso a paso, ejecuta cada comando: instalación de dependencias, compilación y empaquetado. Al finalizar, genera el paquete con los archivos listos para producción.
¿Cómo funciona el release automático?
El pipeline de releases detecta el nuevo artefacto y crea automáticamente un release [4:05]. Este proceso descomprime el paquete, toma los archivos y los publica en el sitio web de Static Web App en Azure. Al refrescar la página del sitio, el cambio aparece reflejado de inmediato [4:38].
¿Cómo revertir un despliegue con la función de redeploy?
Una de las funcionalidades más valiosas de la sección de releases es la capacidad de hacer rollback [5:00]. Si el release más reciente presenta errores o contiene cambios que no debieron llegar a producción, es posible seleccionar un release anterior y ejecutar la opción de redeploy.
Por ejemplo, si el release cuatro introdujo un problema, se puede regresar al release tres [5:15]. El release cuatro permanece en el historial como referencia, pero deja de ser la versión activa. Al completarse el redeploy, el release tres aparece resaltado en verde, indicando que es la versión actualmente desplegada [5:55].
Este mecanismo de control de versiones dentro de los releases permite:
- Revertir cambios problemáticos de forma rápida.
- Mantener un historial completo de cada publicación.
- Gestionar qué versión está activa en producción sin modificar el código.
Todo el flujo de integración continua y despliegue continuo (CI/CD) se ejecutó completamente desde el navegador [6:32]. No fue necesario utilizar ninguna herramienta externa: desde la edición del código, pasando por la configuración de pipelines, hasta la publicación y el rollback en producción, Azure DevOps centraliza cada paso del ciclo de desarrollo.
¿Has implementado flujos de CI/CD en tus proyectos? Comparte tu experiencia y qué configuraciones te han resultado más útiles.
