CI/CD-Integration und Deployment

Führe Claude Code nicht-interaktiv innerhalb der CI/CD-Pipeline aus, sandboxe die Ausführung, damit lang laufende Agenten sicher arbeiten, stelle Deployment über MCP-Integrationen bereit und probe die Rollback-Pfade, bevor der Agent sie jemals benötigt.

Was sich ändert

Erste Schritte

• Voraussetzungen: KI im PR-Review-Loop und Hooks als Genehmigungsschranken, denn die Schranken müssen existieren, bevor Automatisierung irgendetwas durch sie hindurch beschleunigt.
• Infrastruktur: Eine CI-Plattform mit installierter claude-code-action, oder ein beliebiger Runner, der claude -p aufrufen kann; Modellzugriff über die API, oder Amazon Bedrock, Microsoft Foundry oder Vertex AI, wo der Traffic auf der Cloud-Vereinbarung der Organisation bleiben muss; MCP-Server für die Deployment-Ziele; ein Sandbox-Profil für Agenten-Jobs ohne dauerhafte Produktions-Zugangsdaten.

Wie man es umsetzt

1. Der Plattform-Engineer beginnt mit schreibgeschützten Urteilsschritten. Verwende claude -p in einem Pipeline-Job, um einen fehlgeschlagenen Build zu triagieren, einen instabilen Test zusammenzufassen oder das Changelog zu entwerfen.
2. Füge Schreibschritte hinter den bestehenden Schranken für Aufgaben wie das Beheben von Lint-Fehlern, das Aktualisieren generierter Dokumentation oder das Bearbeiten von Review-Kommentaren über @claude-Erwähnungen hinzu. Alles, was der Agent schreibt, kommt als PR über den Branch-Schutz an, und der Agent hat keinen Weg, direkt auf main zu pushen.
3. Die Ausführung ist sandboxed. Agenten-Jobs laufen in Containern unter einer Netzwerkrichtlinie mit kurzlebigen, eingeschränkten Tokens und besitzen standardmäßig keine Produktions-Zugangsdaten.
4. Stelle Deployment über MCP bereit. Deploy, Status und Rollback werden zu Tools, pro Umgebung eingeschränkt, sodass die Deployment-Fähigkeiten des Agenten eine Allowlist sind und kein Shell-Skript mit Zugangsdaten.
5. Staffle die Autonomie nach Umgebung. In der Entwicklung deployt der Agent frei. In der Produktion bereitet der Agent das Release vor, und der Release-Manager genehmigt es, und ein Hook erzwingt die Produktionsschranke. Staging liegt irgendwo in der Mitte.
6. Rollback sollte der am häufigsten geprobte Pfad in der Pipeline sein, ein einzelner Befehl, den der Agent ausführen kann und der regelmäßig in Staging geübt wird. Das Spiel zum Schließen des Kreises (Stufe 6: Aufrechterhalten) ruft diesen Rollback auf, wenn ein Kontrollband überschritten wird, daher muss er vorab nachgewiesen sein.

Wie es aussieht

Pipeline-Schritt:

- 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

Der Rest dieses Beispiels ist das Kundenportal eines Versicherers, mit Deployment, das als Tools bereitgestellt wird, und einem MCP-Server pro Umgebung. Eine Regel, die ein MCP-Tool erlaubt, benennt den Server und das Tool, nicht die Argumente des Tools. Ein separater Server pro Umgebung ist also das, was eine Allowlist Staging von Produktion unterscheiden lässt. Die Server werden in der .mcp.json des Projekts eingerichtet:

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

Jeder Server bietet dieselben drei Tools:

Der Staging-Job läuft bei einem Push auf main und genehmigt die drei Tools des Staging-Servers vorab und keine anderen. Er besitzt nur das Staging-Token, sodass die anderen beiden Server kein gültiges Token erhalten und den Job verweigern. Dies ist der Pipeline-Schritt für den Staging-Job:

- 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

Im dontAsk-Modus verweigert Claude Code jeden Aufruf, der sonst nachfragen würde, sodass ein Deployment-Tool, das nicht auf der Liste steht, abgelehnt wird und der Job nie auf eine Antwort wartet.

Ein PreToolUse-Hook auf den release-Tools entscheidet pro Umgebung. Er wird im Spiel „Hooks als Genehmigungsschranken“ ausgearbeitet und ergibt drei Stufen:

In der Produktion führt der dontAsk-Modus weiterhin einen Aufruf aus, den ein PreToolUse-Hook genehmigt, sodass bei release außerhalb der Allowlist das allow des Hooks der einzige Weg durch ist. Die Produktion schlägt daher standardmäßig fehl, denn ein Release wird verweigert, wenn der Hook nicht läuft. rollback bleibt auf der Allowlist, weil es ein vorab genehmigtes Runbook ist.

Wenn der Runner verwaltete Einstellungen mit allowManagedHooksOnly trägt, muss der Hook in den verwalteten Einstellungen definiert sein, und mit allowManagedMcpServersOnly müssen die Server auf der verwalteten Allowlist stehen.

Governance-Überlegungen

Das leitende Prinzip ist, dass der Agent bis zur Produktionsschranke handeln darf und sie nicht überschreiten kann. Die folgenden Kontrollen setzen dieses Prinzip durch.

• Branch-Schutz verwandelt alles, was der Agent schreibt, in einen PR, ohne direkten Weg zu main.
• Der Produktions-Deploy-Hook blockiert das Release, bis ein namentlich benannter Release-Manager es genehmigt. Jeder nicht-interaktive Lauf handelt unter der eigenen Identität des Agenten, sodass das Pipeline-Log trennt, was der Agent getan hat, von dem, was der Engineer, der ihn ausgelöst hat, getan hat.
• Berechtigungsstufen pro Umgebung legen fest, wie viel der Agent auf dem Weg zur Schranke tun darf.

Wie man es misst

• Frühindikator: Der Anteil der Pipeline-Fehler, die ohne Alarmierung eines Menschen triagiert wurden, entnommen aus den CI/CD-Pipeline-Logs.
• Spätindikator: DevOps Research and Assessment (DORA)-Kennzahlen, die das CI-System und das Deployment-Tooling bereits ausgeben.