Intégration CI/CD et déploiement

Exécutez Claude Code de manière non interactive au sein du pipeline CI/CD, mettez l'exécution en bac à sable pour que les agents de longue durée s'exécutent en toute sécurité, exposez le déploiement via des intégrations MCP, et répétez les chemins de retour en arrière avant que l'agent n'en ait jamais besoin.

Ce qui change

Pour commencer

• Prérequis : l'IA dans la boucle de revue de PR et les hooks comme portes d'approbation, car les portes doivent exister avant que l'automatisation n'accélère quoi que ce soit à travers elles.
• Infrastructure : une plateforme CI avec le claude-code-action installé, ou tout exécuteur capable d'appeler claude -p ; un accès au modèle via l'API, ou Amazon Bedrock, Microsoft Foundry, ou Vertex AI lorsque le trafic doit rester sur l'accord cloud de l'organisation ; des serveurs MCP pour les cibles de déploiement ; un profil de bac à sable pour les tâches d'agent sans identifiants de production permanents.

Comment l'exécuter

1. L'ingénieur de plateforme commence par des étapes de jugement en lecture seule. Utilisez claude -p dans une tâche de pipeline pour trier une build échouée, résumer un test instable, ou rédiger le journal des modifications.
2. Ajoutez des étapes d'écriture derrière les portes existantes pour des tâches comme corriger le lint, mettre à jour la documentation générée, ou traiter les commentaires de revue via les mentions @claude. Tout ce que l'agent écrit arrive sous forme de PR via la protection de branche, et l'agent n'a aucun moyen de pousser vers main.
3. L'exécution est mise en bac à sable. Les tâches d'agent s'exécutent dans des conteneurs sous une politique réseau avec des jetons à portée limitée et de courte durée, et ne détiennent aucun identifiant de production par défaut.
4. Exposez le déploiement via MCP. Le déploiement, le statut et le retour en arrière deviennent des outils, à portée limitée par environnement, de sorte que les pouvoirs de déploiement de l'agent constituent une liste d'autorisation plutôt qu'un script shell avec des identifiants.
5. Échelonnez l'autonomie par environnement. En développement, l'agent déploie librement. En production, l'agent prépare la version et le responsable des versions l'autorise, et un hook applique la porte de production. La préproduction se situe quelque part entre les deux.
6. Le retour en arrière devrait être le chemin le plus répété du pipeline, une commande unique que l'agent peut exécuter et qui est exercée régulièrement en préproduction. Le scénario de fermeture de la boucle (Étape 6 : Maintenir) déclenche ce retour en arrière lorsqu'une bande de contrôle est dépassée, il doit donc être éprouvé à l'avance.

À quoi cela ressemble

Étape de 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

Le reste de cet exemple concerne le portail client d'un assureur, avec le déploiement exposé comme des outils et un serveur MCP par environnement. Une règle qui autorise un outil MCP nomme le serveur et l'outil, pas les arguments de l'outil. Ainsi, un serveur distinct par environnement est ce qui permet à une liste d'autorisation de distinguer la préproduction de la production. Les serveurs sont configurés dans le fichier .mcp.json du projet :

{
  "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}" }
    }
  }
}

Chaque serveur propose les trois mêmes outils :

La tâche de préproduction s'exécute lors d'un push vers main et pré-approuve les trois outils du serveur de préproduction et aucun autre. Elle ne détient que le jeton de préproduction, de sorte que les deux autres serveurs ne reçoivent aucun jeton valide et refusent la tâche. Voici l'étape de pipeline pour la tâche de préproduction :

- 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 mode dontAsk, Claude Code refuse tout appel qui aurait sinon déclenché une invite, de sorte qu'un outil de déploiement absent de la liste est refusé et la tâche n'attend jamais de réponse.

Un hook PreToolUse unique sur les outils release décide par environnement. Il est décrit dans le scénario des hooks comme portes d'approbation, et il établit trois niveaux :

En production, le mode dontAsk exécute toujours un appel qu'un hook PreToolUse approuve, de sorte qu'avec release absent de la liste d'autorisation, l'allow du hook est le seul moyen de passer. La production échoue donc de manière fermée, car une version est refusée si le hook ne s'exécute pas. rollback reste sur la liste d'autorisation car c'est une procédure approuvée à l'avance.

Si l'exécuteur porte des paramètres gérés avec allowManagedHooksOnly, le hook doit être défini dans les paramètres gérés, et avec allowManagedMcpServersOnly, les serveurs doivent figurer sur la liste d'autorisation gérée.

Considérations de gouvernance

Le principe directeur est que l'agent peut agir jusqu'à la porte de production et ne peut pas la franchir. Les contrôles ci-dessous appliquent ce principe.

• La protection de branche transforme tout ce que l'agent écrit en PR, sans chemin direct vers main.
• Le hook de déploiement en production bloque la version jusqu'à ce qu'un responsable des versions nommé l'autorise. Chaque exécution non interactive agit sous l'identité propre de l'agent, de sorte que le journal du pipeline distingue ce que l'agent a fait de ce que l'ingénieur qui l'a déclenché a fait.
• Les niveaux de permission par environnement déterminent ce que l'agent peut faire sur le chemin vers la porte.

Comment le mesurer

• Indicateur avancé : la part des échecs de pipeline triés sans alerter un humain, tirée des journaux du pipeline CI/CD.
• Indicateur retardé : les mesures DevOps Research and Assessment (DORA), que le système CI et l'outillage de déploiement émettent déjà.