Azure Pipelines: por qué lo elegimos sobre GitHub Actions y GitLab CI

Elegir plataforma de CI/CD no es decisión neutra. Cambia cómo se escribe el YAML, qué secrets se comparten, cómo se aprueban deploys y cuánto pagas al mes. En ServerStack usamos Azure Pipelines y la pregunta "¿por qué no GitHub Actions si ya tienen el código ahí?" es frecuente.

Este post explica por qué — con la comparación honesta.

Lo que Azure Pipelines hace bien

Environments con gates reales

Un "environment" en Azure Pipelines es más que una etiqueta — es un objeto con reglas propias: approvals manuales, checks automáticos, historial de deploys. Cuando un deploy a producción necesita aprobación de dos personas del equipo, lo defines en el environment y el pipeline se pausa hasta que ambos aprueban. En GitHub Actions esto existe (environments con protection rules) pero es más limitado y su UI está por detrás.

Variable groups y secrets centralizados

Defines los secrets una vez en un "variable group" y los importas en los pipelines que los necesiten. No los copias-pegas por pipeline. Evita el drift donde un secret cambia y te olvidaste de actualizarlo en tres lugares.

Agents hospedados vs self-hosted

Azure te da 1800 minutos gratis mensuales de agents hospedados (Linux/Windows/Mac) para proyectos públicos y privados. Si ya tienes servidor propio, corres un agent self-hosted en Docker en 10 minutos y no gastas minutos.

YAML explícito

Los pipelines de Azure son más verbosos que los de GitHub Actions. Suena a desventaja pero es explícito: las stages, jobs, steps están escritos con jerarquía clara. Menos "magia oculta" en acciones de terceros.

Lo que duele

Curva inicial más empinada

Si vienes de GitHub Actions, los primeros pipelines en Azure se sienten burocráticos. Aparecen conceptos como templates, extends, resources — poderosos cuando los dominas, ruido cuando empiezas.

Marketplace menos vivo

GitHub Actions tiene un marketplace enorme; Azure Pipelines tiene tareas oficiales buenas pero menos comunidad. Para casos estándar no es problema; para integraciones exóticas sí.

Precio para equipos grandes

Azure DevOps cobra por "basic user" desde el sexto usuario. Para un equipo de 3-5 devs, es gratis. Para 15+, calcula $6 USD/usuario/mes. GitHub Actions no tiene ese costo per-user pero cobra por minutos cuando pasas el free tier.

Nuestro flujo típico en ServerStack

Cada proyecto tiene un azure-pipelines.yml con esta estructura:

trigger:
  branches: { include: [main, develop] }

stages:
  - stage: Build
    jobs:
      - job: test_and_build
        steps:
          - script: npm ci && npm test
          - task: Docker@2
            inputs: { command: 'build', repository: 'myapp' }

  - stage: Deploy_Staging
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/develop'))
    jobs:
      - deployment: deploy
        environment: 'staging'
        strategy:
          runOnce: { deploy: { steps: [ - script: ./deploy.sh staging ] } }

  - stage: Deploy_Prod
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: deploy
        environment: 'production'   # con approvals configurados en la UI
        strategy:
          runOnce: { deploy: { steps: [ - script: ./deploy.sh prod ] } }

El truco: los environments tienen sus propios approvals en la UI, no en el YAML. Eso permite cambiar políticas sin tocar código.

Cuándo te conviene

• Ya trabajas con Microsoft/Azure.
• Necesitas approvals manuales con auditoría real.
• Tienes múltiples ambientes y quieres separar quién puede desplegar a cuál.
• Valoras que los secrets estén en un lugar central, no scattered por pipelines.

Cuándo no

• Equipo de 1-2 devs sin workflow crítico. GitHub Actions te ahorra configurar otra plataforma.
• Proyecto 100% open source y público. GitHub Actions gratis para siempre.
• No te gusta el YAML verboso. (Sí, es un punto legítimo.)

En ServerStack Solutions

Toda la infraestructura de deploys de nuestros clientes corre sobre Azure Pipelines. Configuramos los environments, approvals y variable groups desde el día 1. Si quieres migrar tu CI/CD a algo así o empezar un proyecto con pipelines bien armados, agenda una consulta.

---

Relacionado: Pipelines multi-stage desde cero, Docker + ECR, la arquitectura completa.