CI/CD en Azure DevOps: de 45 a 4 minutos

Un ingeniero de Blue Yonder contó en dev.to cómo pasó de un despliegue manual de 45 minutos a uno automatizado de 4 minutos con CI/CD en Azure DevOps. Mismo resultado siempre, log de auditoría completo y rollback en un solo comando.

CI/CD en Azure DevOps es la práctica de integrar y desplegar código de forma automática mediante pipelines definidos en archivos YAML. Continuous Integration construye y testea cada push; Continuous Delivery lleva el build a staging con aprobación humana; Continuous Deployment publica a producción sin intervención. Azure DevOps es la plataforma de Microsoft que orquesta todo eso con repos Git, pipelines y entornos.

¿Cómo se pasa de despliegues manuales a automatizados?

Ponele que es viernes a las 18 y tenés que subir una versión a producción. Copiás archivos al servidor, editás el config a mano, reiniciás el servicio y llamás al equipo para confirmar que quedó vivo. Eso es exactamente lo que describe el ingeniero de Blue Yonder: 45 minutos, un resultado ligeramente distinto cada vez según quién lo ejecutara, y solo dos personas en todo el equipo conocían los pasos completos.

El cambio fue brutal. Push al repo, esperás 4 minutos, listo.

Lo interesante es lo que viene con eso: el mismo resultado en cada corrida, cualquiera del equipo puede dispararlo, queda un log de auditoría de cada despliegue y el rollback es un solo comando. Ese es el verdadero valor de CI/CD en Azure DevOps, no la velocidad sola sino la repetibilidad. Un proceso que depende de la memoria de dos personas es una bomba de tiempo (y cualquiera que haya heredado un servidor sin documentar sabe de qué hablo).

¿Cuál es la diferencia real entre CI y CD?

Acá viene la confusión más común. La mayoría usa “CI/CD” como una sola palabra sin saber dónde termina uno y empieza el otro. Tema relacionado: comparativa entre Microsoft y GitHub.

Continuous Integration es mergear código seguido y verificarlo de forma automática. Cada vez que un dev hace push, el sistema compila y corre los tests. El objetivo es cazar problemas en minutos, no días después cuando alguien prueba la feature a mano.

Continuous Delivery agarra ese build verificado y lo lleva a staging de forma automática, pero pide aprobación humana antes de tocar producción. Continuous Deployment elimina ese paso: si pasa los tests, va directo a producción sin que nadie apriete un botón. La sigla “CD” tapa dos cosas distintas, y confundirlas te puede costar caro el día que un commit roto llegue a producción solo porque pensabas que había un visto bueno manual de por medio.

Sintaxis YAML para pipelines de CI/CD en Azure DevOps

El pipeline vive en un archivo azure-pipelines.yml en la raíz del repo. La jerarquía es simple: stages (etapas grandes), jobs (trabajos dentro de cada etapa) y steps (los comandos concretos). Según la documentación de Microsoft, este YAML versionado es la base recomendada para desplegar a App Service.

trigger:
 - main

pool:
 vmImage: 'ubuntu-latest'

stages:
 - stage: Build
 jobs:
 - job: Compilar
 steps:
 - script: npm ci && npm run build
 displayName: 'Instalar y compilar'

 - stage: Deploy
 dependsOn: Build
 jobs:
 - deployment: DeployProd
 environment: 'produccion'
 strategy:
 runOnce:
 deploy:
 steps:
 - script: ./deploy.sh

Fijate dos cosas. El trigger dispara el pipeline en cada push a main, y el dependsOn obliga a que Deploy espere a que Build termine bien. Las variables sensibles no van acá: se cargan como resources y secretos, tema que tocamos abajo. La sangría importa, sí, en serio. Un espacio de más y YAML te tira el pipeline entero.

¿Qué estrategias de despliegue conviene usar?

No todos los despliegues se hacen igual. Azure DevOps soporta varias estrategias dentro de los deployment jobs, y elegir bien depende de cuánto riesgo podés tolerar. Ya lo cubrimos antes en incidentes de seguridad en repositorios.

Estrategia	Cómo funciona	Cuándo usarla
Blue/Green	Dos entornos idénticos; switch de tráfico instantáneo entre el viejo y el nuevo	Cuando el rollback tiene que ser inmediato y cero downtime
Canary	Liberás a un % chico de usuarios, medís, después al resto	Features riesgosas donde querés datos reales antes del 100%
Rolling	Actualizás instancias de a tandas, no todas juntas	Flotas de varios servidores donde no querés tirar todo a la vez

Si el destino del deploy es infraestructura propia o en la nube, el pipeline es solo la mitad: necesitás dónde alojar el resultado. Para hosting y dominios en Argentina, donweb.com te resuelve esa pata sin vueltas.

¿Cómo se resuelven los conflictos de merge en CI/CD?

Los conflictos pasan cuando dos ramas editan las mismas líneas del mismo archivo. Git no adivina cuál versión querés, así que te frena y te pide que decidas. En un flujo de CI/CD esto aparece seguido, porque hay varias ramas integrándose contra main todo el tiempo.

Tenés tres caminos para resolverlos, según la guía de merging de Azure DevOps:

• CLI de Git: control total, ideal para conflictos grandes o cuando sabés exactamente qué querés conservar.
• Visual Studio o tu IDE: vista lado a lado de ambas versiones, cómodo para conflictos del día a día.
• Editor web de Azure DevOps: resolución desde el navegador en el propio pull request, sin bajar la rama.

¿La mejor forma de resolver conflictos? No tenerlos. Ramas chicas, vida corta y merges frecuentes bajan la probabilidad muchísimo. Cuanto más vieja la rama, peor el conflicto.

¿Cómo se asegura un pipeline de despliegue?

Un pipeline automatizado tiene acceso a producción. Eso lo vuelve un objetivo jugoso si lo dejás abierto.

Las prácticas base que menciona el artículo original: los secretos nunca van hardcodeados en el código ni en el YAML, se cargan como variables protegidas o desde un vault. El log de auditoría completo te deja saber quién desplegó qué y cuándo. Y conviene meter escáneres en el propio pipeline, SAST para analizar el código fuente, SCA para las dependencias, más herramientas tipo git-secrets que detectan credenciales filtradas antes de que lleguen al repo. En Azure DevOps eso se combina con permisos y roles por entorno, así una aprobación para producción no la puede dar cualquiera. Te puede servir nuestra cobertura de alternativas modernas de CI/CD.

Errores comunes que rompen pipelines en producción

Pasan los tests en local y explota en producción. ¿Por qué? Casi siempre por las mismas razones.

• Environment drift: staging no es igual a producción. Versiones distintas de runtime, variables que faltan o configs que nadie sincronizó. El “en mi máquina anda” del entorno.
• Tests flaky: fallan a veces sin razón aparente y el equipo termina ignorándolos. El día que uno avisa de un bug real, ya nadie le cree.
• Dependencias desincronizadas: el lockfile dice una cosa y el entorno instaló otra. Tip: en CI usá npm ci, no npm install.
• Secretos expuestos: una API key que se coló en un commit viejo sigue ahí aunque la borres después. Rotala y escaneá el historial.

Preguntas Frecuentes

¿Cuál es la diferencia entre CI y CD?

CI (Continuous Integration) mergea código seguido y corre build y tests automáticos en cada push para cazar errores en minutos. CD se refiere a dos cosas: Continuous Delivery despliega a staging de forma automática pero exige aprobación humana para producción, mientras Continuous Deployment publica a producción sin intervención.

¿Cómo se automatizan despliegues con Azure DevOps?

Se define un archivo azure-pipelines.yml en el repo con stages, jobs y steps que compilan, testean y despliegan. Un trigger dispara el pipeline en cada push, y los deployment jobs publican al entorno configurado con la estrategia que elijas (blue/green, canary o rolling).

¿Cuánto tiempo se ahorra con despliegues automatizados?

En el caso de Blue Yonder, el despliegue pasó de 45 minutos manuales a 4 minutos automatizados. Más que el ahorro de tiempo, lo clave es la consistencia: el mismo resultado en cada corrida y rollback en un solo comando, contra un proceso manual que daba un resultado distinto según quién lo ejecutaba. Complementá con GitHub Actions versus Jenkins.

¿Cómo se resuelven los conflictos de merge en CI/CD?

Los conflictos surgen cuando dos ramas editan las mismas líneas y se resuelven por la CLI de Git, desde un IDE como Visual Studio o con el editor web del pull request en Azure DevOps. La mejor prevención son ramas de vida corta con merges frecuentes contra la rama principal.

¿Cómo se escribe un pipeline YAML para Azure DevOps?

Un pipeline YAML se estructura en stages (etapas), jobs (trabajos) y steps (comandos), más un bloque trigger que define qué ramas lo activan y un pool con la imagen de la máquina. La sangría es significativa, así que un espacio mal puesto invalida todo el archivo.

Conclusión

Lo que cambió no es solo el reloj. Un despliegue de 4 minutos repetible vale más que uno de 45 que sale distinto cada vez y depende de dos personas. CI/CD en Azure DevOps te da eso: integración con tests automáticos, despliegues versionados en YAML y un log de auditoría que cualquiera del equipo puede consultar.

Si recién arrancás, empezá chico. Un pipeline que compile y testee en cada push ya te ahorra dolores de cabeza. Después sumás los deployment jobs, elegís una estrategia según tu tolerancia al riesgo y blindás los secretos. El error de la mayoría es querer automatizar todo de una; andá por etapas, igual que el pipeline.

Fuentes

• CI/CD, YAML, Azure DevOps and Merge Conflicts (dev.to) – artículo original con el caso de Blue Yonder
• Microsoft Learn – Desplegar a App Service con Azure Pipelines
• Microsoft Learn – Recursos en pipelines de Azure DevOps
• Microsoft Learn – Merging y resolución de conflictos en Git
• Whitestack – Qué es CI/CD (introducción en español)