Skip to content

AI-Native SDLC Playbook L12: CI/CD Integration and Deployment

Sep 12, 20261 min
TL;DRPlug Claude into the CI/CD pipeline — start with read-only build failure triage, gradually add write operations behind existing gates, expose deployment tooling through MCP, and tier autonomy by environment. The governing principle is one sentence: 'The agent may act up to the production gate and cannot pass it.'
Table of Contents
  1. What the Course Teaches
    1. Start Read-Only, Gradually Add Write Access
    2. Exposing Deployment Through MCP
    3. Tiered Autonomy by Environment
    4. Rehearse Rollback Extensively
    5. The Governing Principle
  2. Lessons from Practice
  3. Getting Started
  4. References

The previous lessons established review mechanisms (L10) and approval gates (L11). This lesson wires them into the CI/CD pipeline — running Claude non-interactively to make judgments, push fixes, and handle deployments, while always stopping at the production gate.

What the Course Teaches

Start Read-Only, Gradually Add Write Access

The implementation path is pragmatic — not all-at-once, but staged escalation of agent permissions within the pipeline:

Step one: read-only judgment. Platform engineers use claude -p in pipeline jobs for build failure triage, flaky test summaries, and changelog drafts. These are read-only operations with near-zero risk.

The course's pipeline step example:

- 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

Step two: gated writes. Fix lint issues, update generated docs, address review comments. Agent writes arrive as PRs through branch protection — no direct path to push to main.

Step three: sandboxed execution. Agent jobs run in containers under network policy with short-lived scoped tokens and no production credentials by default.

Exposing Deployment Through MCP

This is the lesson's most interesting architectural design — instead of letting the agent run deployment scripts, wrap deploy, status, and rollback as MCP tools, each scoped per environment.

The benefit: the agent's deployment capabilities become an allowlist rather than a pile of shell scripts with embedded credentials. The platform team controls what's on the allowlist; the agent can only operate through these tools.

Tiered Autonomy by Environment

EnvironmentAgent Permissions
DevelopmentFree to deploy
StagingMiddle ground (team-defined)
ProductionRequires release manager authorization

This tiering pairs with the hooks from L11 — the production deploy hook blocks the action without a RELEASE_APPROVAL.

Rehearse Rollback Extensively

The course emphasizes that rollback should be the "most practiced path" in the pipeline. The reasoning is direct: L13 (Closing the loop on metrics) covers what happens when monitoring metrics breach control bands, and the agent needs to trigger a rollback. If the rollback path hasn't been validated in advance, no one will trust it in a real emergency.

The Governing Principle

The entire lesson's governance boils down to one sentence:

"The agent may act up to the production gate and cannot pass it."

Enforced through three mechanisms:

  1. Branch protection: agent writes become PRs with no direct main push path
  2. Production deploy hook: blocks until release manager authorizes
  3. Per-environment permission tiers: define what the agent can do in each environment

Lessons from Practice

In a mid-sized project, we haven't yet used Claude for in-pipeline triage, but we do use hooks as pre-commit gates. Our pnpm verify runs lint, reference checks, and skills-sync validation as a pre-commit hook — nothing gets committed unless it passes. This is the same concept as the course's "read-only judgment," just implemented differently: automated checks that reduce the burden on human review.

Our governance tiering also maps to the course's environment tiering:

Our TierCorresponding Concept
Tier 0 (autonomous)Free operations in dev environment
Tier 1 (gated)Run verify before commit, like branch protection
Tier 2 (ask first)Schema changes, deploys, CI modifications — the production gate
Tier 3 (forbidden)Bypassing checks, writing unsourced facts — hard blocks in managed settings

What we haven't done yet is "expose deployment through MCP" — our deploys are still manually triggered. But the course's MCP architecture is clearly the better approach: abstracting deployment capabilities from shell scripts into scoped tools is far safer than giving an agent direct shell access.

Getting Started

  1. Start with build failure triage: Add an if: failure() step that has Claude read the build log and output a three-line summary. Zero risk, immediate value
  2. Don't skip sandboxing: Agent jobs in CI must have container isolation and short-lived credentials. Don't cut corners by using an engineer's personal API key
  3. Practice rollback first: Don't wait for a real incident to run your first rollback. Practice it on staging until it's second nature, then give the agent permission to trigger it
  4. MCP over shell scripts: If you're designing an agent's deployment path, wrapping it in MCP tools is better than granting shell access. Allowlists are safer than denylists

References