Integración y despliegue de CI/CD

Ejecuta Claude Code de forma no interactiva dentro del pipeline de CI/CD, aísla la ejecución en un sandbox para que los agentes de larga duración se ejecuten de forma segura, expón el despliegue a través de integraciones MCP, y ensaya las rutas de rollback antes de que el agente las necesite.

Qué cambia

Primeros pasos

• Requisitos previos: IA en el ciclo de revisión de PR y hooks como puertas de aprobación, porque las puertas deben existir antes de que la automatización acelere algo a través de ellas.
• Infraestructura: Una plataforma de CI con claude-code-action instalado, o cualquier runner que pueda llamar a claude -p; acceso al modelo a través de la API, o Amazon Bedrock, Microsoft Foundry o Vertex AI cuando el tráfico deba permanecer dentro del acuerdo de nube de la organización; servidores MCP para los objetivos de despliegue; un perfil de sandbox para los trabajos del agente sin credenciales de producción permanentes.

Cómo ejecutarlo

1. El ingeniero de plataforma comienza con pasos de criterio de solo lectura. Usa claude -p en un trabajo del pipeline para triar una compilación fallida, resumir una prueba inestable o redactar el changelog.
2. Agrega pasos de escritura detrás de las puertas existentes para trabajos como corregir el lint, actualizar documentación generada o abordar comentarios de revisión mediante las menciones @claude. Todo lo que el agente escribe llega como un PR a través de la protección de rama, y el agente no tiene ninguna ruta para hacer push a main.
3. La ejecución está en sandbox. Los trabajos del agente se ejecutan en contenedores bajo una política de red con tokens delimitados de corta duración, y no tienen credenciales de producción por defecto.
4. Expón el despliegue a través de MCP. Deploy, status y rollback se convierten en herramientas, delimitadas por entorno, de modo que los poderes de despliegue del agente son una lista de permitidos (allowlist) en lugar de un script de shell con credenciales.
5. Escalona la autonomía por entorno. En desarrollo, el agente despliega libremente. En producción, el agente prepara el release y el gestor de releases lo autoriza, y un hook aplica la puerta de producción. Staging se encuentra en un punto intermedio.
6. El rollback debería ser la ruta más ensayada del pipeline, un único comando que el agente pueda ejecutar y que se practique regularmente en staging. La jugada de cerrar el ciclo (Etapa 6: Mantener) invoca este rollback cuando se incumple una banda de control, por lo que debe estar probado de antemano.

Cómo se ve

Paso del pipeline:

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log at out/build.log. Identify the most
    likely cause, say whether the failure looks flaky or real, and write a
    three-line summary for the PR thread." >> triage.md

El resto de este ejemplo es el portal de clientes de una aseguradora, con el despliegue expuesto como herramientas y un servidor MCP por entorno. Una regla que permite una herramienta MCP nombra al servidor y a la herramienta, no a los argumentos de la herramienta. Por eso, un servidor separado por entorno es lo que permite que una lista de permitidos distinga staging de producción. Los servidores se configuran en el .mcp.json del proyecto:

{
  "mcpServers": {
    "deploy-dev": {
      "type": "http",
      "url": "https://deploy.example.com/mcp/dev",
      "headers": { "Authorization": "Bearer ${DEPLOY_DEV_TOKEN}" }
    },
    "deploy-staging": {
      "type": "http",
      "url": "https://deploy.example.com/mcp/staging",
      "headers": { "Authorization": "Bearer ${DEPLOY_STAGING_TOKEN}" }
    },
    "deploy-prod": {
      "type": "http",
      "url": "https://deploy.example.com/mcp/prod",
      "headers": { "Authorization": "Bearer ${DEPLOY_PROD_TOKEN}" }
    }
  }
}

Cada servidor ofrece las mismas tres herramientas:

El trabajo de staging se ejecuta con un push a main y preaprueba las tres herramientas del servidor de staging y ninguna otra. Solo tiene el token de staging, por lo que los otros dos servidores no obtienen un token válido y rechazan el trabajo. Este es el paso del pipeline para el trabajo de staging:

- name: Release to staging and roll back if it is unhealthy
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
    DEPLOY_STAGING_TOKEN: ${{ secrets.DEPLOY_STAGING_TOKEN }}   # no other environment's token
  run: >
    claude -p "Release version ${{ github.sha }} of the claims portal to staging,
    then call status. If the 5xx rate on any endpoint is over 1%, roll back.
    Finish with three lines for the release notes: what you released, what status
    reported, and whether you rolled back."
    --allowedTools "mcp__deploy-staging__release,mcp__deploy-staging__status,mcp__deploy-staging__rollback"
    --permission-mode dontAsk >> release-notes.md

En el modo dontAsk, Claude Code deniega cualquier llamada que de otro modo generaría una solicitud, por lo que una herramienta de despliegue que no esté en la lista es rechazada y el trabajo nunca espera una respuesta.

Un hook PreToolUse en las herramientas release decide por entorno. Está detallado en la jugada de hooks como puertas de aprobación, y ofrece tres niveles:

En producción, el modo dontAsk sigue ejecutando una llamada que un hook PreToolUse aprueba, por lo que, con release fuera de la lista de permitidos, el allow del hook es la única forma de pasar. Por lo tanto, producción falla de forma cerrada (fail closed), porque un release se deniega si el hook no llega a ejecutarse. rollback permanece en la lista de permitidos porque es un runbook aprobado de antemano.

Si el runner tiene configuraciones administradas con allowManagedHooksOnly, el hook debe estar definido en la configuración administrada, y con allowManagedMcpServersOnly los servidores deben estar en la lista de permitidos administrada.

Consideraciones de gobernanza

El principio rector es que el agente puede actuar hasta la puerta de producción y no puede atravesarla. Los siguientes controles aplican este principio.

• La protección de rama convierte todo lo que el agente escribe en un PR, sin ninguna ruta directa a main.
• El hook de despliegue de producción bloquea el release hasta que un gestor de releases designado lo autoriza. Cada ejecución no interactiva actúa bajo la identidad propia del agente, de modo que el registro del pipeline separa lo que hizo el agente de lo que hizo el ingeniero que lo activó.
• Los niveles de permisos por entorno establecen cuánto puede hacer el agente en el camino hacia la puerta.

Cómo medirlo

• Indicador adelantado: La proporción de fallos del pipeline triados sin avisar a un humano, obtenida de los registros del pipeline de CI/CD.
• Indicador rezagado: Las métricas de DevOps Research and Assessment (DORA), que el sistema de CI y las herramientas de despliegue ya emiten.