Automatizar el ciclo de desarrollo con CI/CD en Azure DevOps te permite llevar cambios de código a producción sin salir del navegador. Aquí verás cómo se conectan repos, pipelines y releases para desplegar una React app en Azure, y cómo revertir versiones cuando algo falla. Es útil si trabajas en equipos que buscan rapidez y trazabilidad en cada publicación.

Qué pasa cuando haces commit en el repo de Azure DevOps

El flujo arranca en la sección de repos, donde vive el código fuente del proyecto, en este caso Platzi React App [01:30]. Cualquier cambio que hagas ahí, siempre que sea sobre el branch asociado al pipeline, dispara la cadena completa de integración y despliegue.

Para probarlo en vivo, basta con editar un componente directamente desde el navegador. En el ejemplo, se modifica el header que decía React Hooks y se cambia por React Hooks en Azure DevOps [02:50]. Al hacer commit sobre el branch master, el pipeline entra en cola automáticamente.

¿Qué dispara un pipeline en Azure DevOps? Un commit o push sobre el branch que configuraste como trigger. Si el cambio va a otro branch distinto al asociado, el pipeline no se ejecuta.

Esto es importante: el pipeline está atado a un branch específico. Puedes asociar el que quieras, pero si haces commit en otro, no pasa nada. Por eso conviene definir desde el inicio cuál branch va a producción.

Cómo funciona el pipeline de build y el artefacto generado

El pipeline de build ejecuta una secuencia de comandos clara: instala dependencias, compila el proyecto, prepara los archivos de salida y los empaqueta en un .zip [01:50]. Ese paquete se publica como artefacto, listo para que cualquier otro pipeline lo consuma.

En el caso de la React app, el artefacto contiene los archivos estáticos que luego van a un Static Web App en Azure. La gracia está en que este paquete se vuelve la unidad de despliegue: lo que se construyó una vez puede reutilizarse en distintos releases.

• Instalación de dependencias del proyecto.
• Compilación y preparación de archivos.
• Empaquetado en .zip y publicación como artefacto.

Después de la lista, el pipeline queda esperando a que el siguiente eslabón, el release, tome ese paquete y lo lleve al ambiente final.

Cómo conecta el release con el artefacto del build

La sección de releases toma el artefacto generado, lo descomprime y publica los archivos en el Static Web App de Azure [05:00]. En el ejemplo, el cambio del header genera el release número 4, que se despliega automáticamente sin intervención manual.

Cuando refrescas el sitio web, el cambio aparece. Eso es despliegue continuo funcionando: del editor del navegador a producción en minutos.

¿Qué es un release en Azure DevOps? Es el proceso que toma un artefacto y lo publica en un ambiente, como producción o staging. Cada ejecución queda registrada con su fecha, branch y estado.

Por qué la sección de releases es clave para el control de versiones

Más allá de desplegar, releases te da algo crítico: historial completo y reversión rápida. Puedes ver qué publicaciones fueron satisfactorias, cuáles fallaron, en qué fecha ocurrieron y a qué branch pertenecen [02:20].

Si el release actual rompe algo en producción, no necesitas volver a buildear desde cero. Te paras sobre un release anterior y das redeploy. En el ejemplo, estando en el release 4, se navega al release 3 y se hace redeploy [06:30]. Azure DevOps lo pone en cola y lo vuelve a desplegar tal cual estaba.

Después del redeploy, el release 4 queda en el historial pero deja de ser el actual. Al refrescar la app, el título React Hooks en Azure DevOps desaparece, porque vuelve la versión previa al cambio.

¿Cómo revierto un despliegue en Azure DevOps? Vas a la sección de releases, seleccionas la versión anterior que sí funcionaba y haces clic en redeploy. Esa versión vuelve a producción sin tener que recompilar.

Este mecanismo es lo que convierte a releases en una herramienta de gestión de riesgo, no solo de despliegue.

Qué herramientas necesitas para correr CI/CD en Azure DevOps

Uno de los detalles más llamativos del flujo completo es que todo se hace desde el navegador. No hubo terminal, no hubo IDE local, no hubo herramientas adicionales [08:00]. Edición de código, commit, pipeline, release y reversión, todo dentro del portal.

Eso no significa que en proyectos reales trabajes así, pero demuestra hasta dónde llega la integración del ecosistema de Azure DevOps. Las piezas que entraron en juego fueron:

• Repos para alojar el código y disparar triggers por commit.
• Pipelines para compilar, empaquetar y publicar el artefacto.
• Releases para desplegar a Azure y mantener historial versionado.
• Static Web App en Azure como destino final del despliegue.

Con estas cuatro piezas conectadas, un cambio en el código llega a producción de forma automatizada. Y si algo sale mal, el rollback está a un par de clics.

¿Has automatizado tus despliegues con Azure DevOps o prefieres otra herramienta de CI/CD? Cuéntame en los comentarios cómo manejas los rollbacks en tu flujo.