Azure DevOps Pipelines mit Claude Code für Agentur-Releases prüfen

In einer Webagentur liegen Pull Request, Staging-URL, Kundenfreigabe und Azure-Pipelines-Run oft in getrennten Tabs. Eine kleine Textänderung landet in Produktion, weil alle glauben, jemand anderes habe geprüft. Dieser Artikel macht aus Branch Policies, ManualValidation und Approvals eine Release-Tabelle.

Wo Agentur-Releases scheitern

• Trennen Sie PR-Freigabe, Staging-Prüfung, Kundenfreigabe und Produktionsfreigabe.
• Branch Policies schützen main oder release vor dem Merge.
• ManualValidation pausiert den Run für Staging-URL und Rollback-Prüfung.
• Environment approvals sind das Tor vor Produktion.
• Claude Code fasst YAML und Diffs zusammen; Kunde, Preise, Recht, Zeit und Rollback bleiben beim Menschen.

The source base is Microsoft Learn for pipeline deployment approvals, ManualValidation@1, release approvals, branch policies, and the tasks reference. For an internal release-flow pattern, see the agency cloud release article.

Was Claude Code vorbereitet und Menschen freigeben

In einer Webagentur liegen Pull Request, Staging-URL, Kundenfreigabe und Azure-Pipelines-Run oft in getrennten Tabs. Eine kleine Textänderung landet in Produktion, weil alle glauben, jemand anderes habe geprüft. Dieser Artikel macht aus Branch Policies, ManualValidation und Approvals eine Release-Tabelle. Claude Code should read pipeline YAML, PR template, diff summary, staging checklist, branch policy notes, and environment approval notes. It should output a release table that names branch, build, staging deploy, manual validation, production environment, approver, timeout, rollback note, and evidence link.

Humans keep client acceptance, ad claims, pricing, legal copy, publish timing, emergency exceptions, and rollback decision. This distinction keeps the agent from acting like the release owner. The agent prepares evidence; the agency decides.

Drei Use Cases

Use case 1

Eingabe: PR URL, Diff, Build, Reviewer, Branch Policy, Zielseite. Ausgabe: Tabelle für PR, Produktion und Kunde. Menschliche Prüfung: Preis, rechtlicher Text, Anzeigen, Kunde, Zeit, Rollback.

Use case 2

Eingabe: Staging-URL, Reviewer-Mail, Screenshots, Diff, Rollback, Frist. Ausgabe: ManualValidation@1 instructions und Checkliste. Prüfung: Mobile, Formular, Bilder, Links, Analytics, Kunden-OK.

Use case 3

Eingabe: production environment, Approver, branch control, business hours, exclusive lock, Kanal. Ausgabe: Reihenfolge, Owner, Timeout, Fehlerkontakt. Prüfung: keine Selbstfreigabe, Nacht, Kampagne, Rollback-Owner.

Prompt zum Kopieren

You are auditing an Azure DevOps release flow for a web agency.
Inputs: azure-pipelines.yml, PR template, branch policy memo, production environment approvals memo, staging URL checklist, and a recent rollback or rework note.
Output:
1. Three-column table: PR review, staging/client review, production approval.
2. ManualValidation@1 instruction text with staging URL, diff, rollback note, owner, and deadline.
3. Production environment approvals and checks proposal.
4. Branch policy list: reviewer, build validation, comment resolution, status check.
5. One first action that can be done in 30 minutes.
Rules: do not let the agent approve client acceptance, pricing, legal wording, publish timing, or production release.

Prüfcode

const pipelineText = [
  "trigger:",
  "  branches:",
  "    include:",
  "      - main",
  "stages:",
  "  - stage: Build",
  "    jobs:",
  "      - job: build",
  "        steps:",
  "          - script: npm ci && npm run build",
  "  - stage: DeployStaging",
  "    jobs:",
  "      - job: deploy_staging",
  "        steps:",
  "          - script: echo deploy staging",
  "  - stage: ClientCheck",
  "    jobs:",
  "      - job: wait_for_client",
  "        pool: server",
  "        steps:",
  "          - task: ManualValidation@1",
  "            inputs:",
  "              notifyUsers: [email protected]",
  "              instructions: Check staging URL, PR diff, rollback note, and client approval.",
  "  - stage: DeployProduction",
  "    jobs:",
  "      - deployment: production",
  "        environment: production",
  "        strategy:",
  "          runOnce:",
  "            deploy:",
  "              steps:",
  "                - script: echo deploy production"
].join(String.fromCharCode(10));

const required = [
  { name: "main branch trigger", pattern: /- main/ },
  { name: "staging stage", pattern: /DeployStaging/ },
  { name: "manual validation", pattern: /ManualValidation@1/ },
  { name: "server pool for manual validation", pattern: /pool:\s*server/ },
  { name: "production environment", pattern: /environment:\s*production/ },
  { name: "rollback note in approval text", pattern: /rollback/i }
];

const findings = [];
for (const rule of required) {
  if (!rule.pattern.test(pipelineText)) {
    findings.push({ item: rule.name, fix: "add this gate before production release" });
  }
}

const productionIndex = pipelineText.indexOf("DeployProduction");
const validationIndex = pipelineText.indexOf("ManualValidation@1");
if (productionIndex !== -1 && validationIndex !== -1 && validationIndex > productionIndex) {
  findings.push({
    item: "approval order",
    fix: "place client/manual validation before production deployment"
  });
}

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

Pitfall: häufige Fehler

The first cause is treating PR approval as production approval. The fix is to separate code review, staging review, client acceptance, and production approval by name and owner.

The second cause is relying on notification recipients as if they were approvers. The fix is to inspect environment approval and project permissions separately from notifyUsers.

The third cause is approving without a rollback note. The fix is to add rollback commit, previous artifact, owner, and contact path to the approval text.

The fourth cause is bypassing branch policy under pressure. The fix is to define an emergency exception path with time limit, approver, evidence, and follow-up review.

FAQ

Q. Should we use ManualValidation or environment approval? A. Use ManualValidation for an in-stage pause such as staging URL review. Use environment approvals and checks as the production gate.

Q. Should client approval live inside Azure DevOps? A. If the client does not use Azure DevOps, store the approval URL or message link in the release memo and tie it to the pipeline run.

Q. Does a small content change need branch policy? A. Yes. Pricing pages, hiring pages, and ad landing pages can affect leads and revenue even when the code diff is small.

Q. Can Claude Code approve the release? A. No. It can summarize diff, list missing evidence, and draft checklists. Humans approve production.

Pfad zur Beratung

Für Agenturen zählt nicht mehr YAML, sondern weniger Fehlveröffentlichungen und bessere Kundennachweise. Bringen Sie PR, YAML, Staging-Checkliste und Rollback-Memo in die Beratung. Use Claude Code training and consultation if the team needs help turning PRs, pipeline YAML, staging checks, and rollback memos into a repeatable release workflow.

Was ich geprüft habe

Geprüft wurden Microsoft Learn zu approvals, ManualValidation@1, release approvals, branch policies und task reference. Der lokale Code prüft ManualValidation, server pool, production environment und rollback note. Der erste Schritt ist eine Drei-Spalten-Tabelle für PR, Staging und Produktion.