La única versión que debería llegar a producción es la que pasó por el pipeline. Un equipo de cuatro personas que despliega a mano un viernes a las cinco ya conoce el motivo: alguien olvida un paso, la versión sube con una variable mal puesta y el fin de semana se va corrigiendo. El pipeline hace que el proceso se repita igual cada vez.
Empieza con lo mínimo que protege
El primer pipeline debería hacer solo tres cosas. Compilar el proyecto desde cero en una máquina limpia, correr las pruebas automatizadas y empaquetar el resultado en un artefacto, que puede ser una imagen de Docker o un paquete listo para desplegar. Con eso, "en mi máquina funciona" deja de ser una defensa.
En Azure DevOps esto se define en un archivo azure-pipelines.yml dentro del repositorio, de modo que el pipeline se versiona, se revisa en un pull request y viaja con el código. Un esqueleto para un proyecto Node con Docker se ve así:
trigger:
branches:
include: [main]
pool:
vmImage: ubuntu-latest
steps:
- script: npm ci
displayName: Instalar dependencias
- script: npm test
displayName: Pruebas
- script: docker build -t miapp:$(Build.BuildId) .
displayName: Construir imagen
Instala, prueba y construye la imagen. Publicarla en un registro y desplegar son los pasos siguientes.
Políticas de rama que hacen el trabajo aburrido
Las políticas de la rama principal exigen que cada cambio pase por un pull request, que el pipeline termine en verde y que al menos una persona lo revise. Configurarlo lleva minutos y evita el error más repetido en equipos chicos, los cambios subidos directo a la rama principal.
Un detalle del esqueleto anterior: ese trigger corre después de fusionar. Para que el pipeline también valide cada pull request, se configura como política de validación de compilación en la rama principal (Repos > Branches > Branch policies > Build validation). Sin esa política, el pipeline en verde es una costumbre y no una barrera.
Despliegue por entornos
Con la misma imagen avanzando de desarrollo a pruebas y de ahí a producción, se verifica lo que realmente va a correr.
La configuración que cambia entre entornos, como cadenas de conexión y claves, vive en variables secretas del pipeline, en grupos de variables o en un gestor como Azure Key Vault, y nunca en el repositorio. Para producción tiene sentido una aprobación manual antes de desplegar, al menos mientras el equipo gana confianza. En Azure DevOps se configura como una aprobación en el entorno de producción. La etapa de despliegue declara ese entorno y la aprobación se configura en él (Pipelines > Environments > Approvals and checks):
stages:
- stage: Build
jobs: [...] # los pasos de arriba
- stage: Prod
dependsOn: Build
jobs:
- deployment: Desplegar
environment: production # aprobación configurada en el entorno
strategy:
runOnce:
deploy:
steps:
- script: ./desplegar.sh miapp:$(Build.BuildId)
Aquí desplegar.sh representa el script que use tu equipo para publicar la imagen.
Qué agregar después
Cuando lo básico funciona vienen los extras de mejor retorno: análisis estático de código, un escaneo de dependencias vulnerables con npm audit, dotnet list package --vulnerable o el equivalente de tu lenguaje, y pruebas de humo automáticas contra el entorno recién desplegado. También entra la validación del contrato de la API, como se explica en documentar una API con OpenAPI. Cada extra se suma como un paso nuevo.
También hace falta un plan de reversión. Si un despliegue falla, volver a la imagen anterior tiene que tomar minutos, y se ensaya antes de necesitarlo.
Lo que un equipo pequeño debe evitar
Hay dos trampas habituales: copiar pipelines de cien líneas de otro proyecto sin que nadie los entienda, y automatizar un despliegue que ni siquiera se hace igual dos veces. Primero se estandariza a mano.
¿Todavía despliegas a mano? Cuéntanos cómo despliegas hoy y armamos el primer pipeline contigo. Los pipelines con Docker y Azure DevOps o GitHub Actions son parte del servicio de despliegue en la nube y CI/CD.