Module 6: Project — Complete CI/CD Pipeline with Claude Code
Module 6: Integrative Project — Complete CI/CD Pipeline
Module 6: Integrative Project — Complete CI/CD Pipeline
Overview
This is the guide's culminating module. Modules 1-5 gave you each piece separately: GitHub Actions as a platform, automatic code review on PRs, the headless SDK for cross-platform portability, deployment automation, and resilience with security scanning + rollback. Now you connect all the pieces into an end-to-end pipeline that demonstrates the full potential of Claude Code as a CI/CD agent.
The complete pipeline operates like this: PR opened → automatic code review → tests and linting → security scan → merge to main → generated changelog → deployment readiness check → staging deploy → staging validation → production deploy with an approval gate → monitoring → automatic rollback with diagnosis if something fails. Each step uses what you learned in previous modules.
This isn't an academic exercise — it's a real system adaptable to your project. The deliverable is portfolio-worthy: a working pipeline, documented, with failure paths covered, and with a cost analysis. It's what demonstrates that you master Claude Code in CI/CD at a professional level.
By completing the 6 capsules, you'll have a complete pipeline working, documented for your team, optimized for costs, and with a response plan for when things go wrong. That pipeline is transferable to any professional project you touch.
Where We Are in the Guide
Phase 1: Pre-Merge Automation (Modules 1-2)
├── Module 1: Claude Code in GitHub Actions ✅
└── Module 2: Automated Code Review on PRs ✅
Phase 2: Cross-Platform and Deployment (Modules 3-4)
├── Module 3: GitLab CI/CD and Headless SDK ✅
└── Module 4: Deployment Automation ✅
Phase 3: Resilience and Project (Modules 5-6)
├── Module 5: Security Scanning and Rollback ✅
└── Module 6: Integrative Project ← YOU ARE HERE
→ End-to-end pipeline, documentation, retrospective
This is the guide's last module. There's no next module — the next reference is Guide 11 (Security for AI-Generated Code), which closes the Agentic Development path with a focus on the security of AI-generated code.
The Shift in Focus: From Steps to System
Until now each module dealt with a step of the pipeline. This module shifts the focus to the system:
MODULES 1-5 (individual steps):
→ How to configure code review
→ How to configure deployment
→ How to configure rollback
→ Each one isolated, with controlled conditions
MODULE 6 (complete system):
→ How all the steps fit together
→ What happens when one fails and how it propagates
→ How the whole system is documented and operated
→ How to balance costs in a 5+ step pipeline
→ Without controlled conditions: reality
It's the difference between practicing free throws and playing a full game. The previous modules are free throws. This is the game. The integration reveals problems that don't show up in isolated steps: dependencies between steps, accumulated execution times, summed costs, and the points where a failure in one step should or shouldn't propagate.
What makes this project portfolio-worthy
What you produce is NOT:
❌ A YAML workflow that works on the happy path
❌ A series of scripts without documentation
What you produce IS:
✅ A complete pipeline with a happy path AND failure paths
✅ Documentation that a teammate can use to
operate the pipeline without your help
✅ A retrospective with metrics: time per run, cost per run,
comparison vs the manual process
✅ An optimization plan: what to cache, what to run selectively,
where the bottlenecks are
An employer, a client, or a new team can read this deliverable and verify that you design and operate CI/CD pipelines at a senior level — not that you "know how to use GitHub Actions".
The Complete Pipeline: Overview
┌─────────────────────────┐
│ Developer opens a PR │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Workflow triggers │ ← Module 1
│ (pull_request.opened) │
└────────────┬────────────┘
│
┌────────────────┴────────────────┐
▼ ▼
┌───────────────────┐ ┌──────────────────┐
│ Code Review │ │ Security Scan │
│ inline on the PR │ ← Module 2 │ pre-merge │ ← Module 5
└─────────┬─────────┘ └────────┬─────────┘
│ │
└──────────────┬─────────────────┘
│
Did the gates pass?
│
┌────────┴────────┐
│ │
▼ ▼
NO YES
│ │
▼ ▼
Block the merge ┌──────────────────┐
│ Merge to main │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Auto changelog │ ← Module 4
│ Readiness check │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Deploy to staging│ ← Module 4
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Staging validate │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Approval gate │ ← Module 4
│ (human required) │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Deploy to prod │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Monitoring + │ ← Module 5
│ rollback trigger │
└──────────────────┘
Each node of this diagram is a step you already configured in previous modules. What this project integrates is the flow between nodes: what happens when a step fails, how it propagates, where the human gates are.
Prerequisites
Required knowledge:
- ✅ Modules 1-5 completed (all the pieces working individually)
- ✅ Access to a project where you can configure the complete pipeline
- ✅ Admin permissions on the repository (to configure environments, secrets, branch protection)
Recommended:
- ✅ A realistically sized project (not a "hello world")
- ✅ Accessible monitoring metrics
- ✅ Team agreement to use the pipeline (not just a personal project)
NOT required:
- ❌ You don't need to have Kubernetes/Terraform/etc — the pipeline is hosting-agnostic
Module Roadmap
Capsule 01 — Project introduction (this capsule)
Overview of the complete pipeline. Why integration matters. Project structure.
Capsule 02 — End-to-end pipeline design
Design the architecture: which steps, in what order, what dependencies, what gates. Decide trade-offs (speed vs coverage, parallelism vs cost).
Capsule 03 — Implementation: stages 1-3 (PR review)
Implement the pre-merge stages: automatic code review, security scanning, validation. Make the gates fail correctly.
Capsule 04 — Implementation: stages 4-6 (deployment)
Implement the post-merge stages: changelog, readiness, deploy to staging, validation, approval gate, deploy to production.
Capsule 05 — Failure paths and observability
Cover the paths where something fails: code review found problems, security scan blocked, deployment to staging failed, production detected an issue. For each: what happens, what's notified, how it recovers.
Capsule 06 — Documentation, optimization, and retrospective
Document the pipeline so a teammate can operate it. Optimize costs and speed. Produce a retrospective with real metrics: how much it costs, how much time it saves, what you'd improve.
Progression map
Capsule 01 (this) → Overview
Capsule 02 → Design
Capsule 03 → Implement pre-merge
Capsule 04 → Implement deployment
Capsule 05 → Failure paths
Capsule 06 → Docs + optimization + retrospective
Difficulty: ⭐⭐⭐ ──────────▶ ⭐⭐⭐⭐⭐
What You'll Achieve in This Project
By completing the 6 capsules, you'll have:
- A working end-to-end pipeline from PR to production with all the gates
- Failure paths covered: what happens when each step fails, how it's notified, how it recovers
- Operational documentation: a README a teammate can use without your help
- A cost analysis: how much each run costs, how much it costs per month, where to optimize
- A professional retrospective: time saved vs the manual process, calculated ROI, proposed improvements
- A transferable pipeline: the methodology applies to any future project
Project Deliverables
1. A working pipeline
YAML workflow(s) in GitHub Actions (or the GitLab CI/CD equivalent if you use the Module 3 SDK) that runs:
- ✅ Automatic code review on PRs (Module 2)
- ✅ Security scanning with Claude Code + tools (Module 5)
- ✅ Tests and linting
- ✅ Changelog generation (Module 4)
- ✅ Readiness validation (Module 4)
- ✅ Deploy to staging
- ✅ Staging validation
- ✅ Approval gate before production (Module 4)
- ✅ Deploy to production
- ✅ Monitoring + automatic rollback (Module 5)
- ✅ Post-rollback diagnosis (Module 5)
2. Documentation
- The pipeline's README.md — what it does, how it runs, how it's operated
- OPERATIONS.md — what to do if X fails (a basic runbook)
- CONFIG.md — variables, secrets, configured environments
3. Retrospective
- METRICS.md — time per run, cost per run, comparison with the manual process
- OPTIMIZATIONS.md — what you'd improve, in what order, at what cost
- LESSONS.md — what you learned building it
Pitfalls to Avoid While Taking This Module
Five predictable misunderstandings. Anticipate them before you start.
1. "Only the happy path is enough"
No. A pipeline that only works when everything goes right isn't finished. Capsule 05 covers the failure paths — what happens when code review rejects, what happens when staging fails, what happens when production detects an error. Without failure paths, the pipeline can't be used in real production.
2. "Documentation at the end if there's time left"
No. Documentation is the second most valuable deliverable of the project, after the pipeline itself. A pipeline only the creator understands isn't adoptable by the team. Capsule 06 develops docs as part of the process, not optional.
3. "Ignoring costs because 'it's just a project'"
No. The integrative pipeline with Claude Code in 5+ steps can cost several dollars per run. With 50 PRs per week, that's hundreds of dollars a month. Without cost analysis and optimization, the team will disable the pipeline when the bill arrives. Capsule 06 teaches you to calculate and optimize (cache, conditional execution, parallelism).
4. "A longer pipeline is a better pipeline"
The opposite. If the pipeline takes 30 minutes per PR, developers perceive it as an obstacle and look for ways to skip it. Optimizing for fast execution on the happy path (with fast gates) is part of the design. Capsule 06 develops the optimization techniques.
5. "Skipping the retrospective"
The retrospective is what turns the project into systematized learning. How much does each run cost? How much time does it save vs manual review? What are the bottlenecks? These questions are what differentiate an academic project ("I made a pipeline") from a professional project ("I delivered a pipeline with ROI analysis"). Capsule 06 structures the retrospective.
Diagnosis: Ready for the Integrative Project?
Five questions to confirm you have what you need before starting.
Question 1: Do you have a working YAML workflow with correct secrets management? (Module 1)
If yes: you're ready for capsule 02.
If no: review Module 1. It's the technical foundation of the whole pipeline.
Question 2: Does your code review bot generate inline comments and operate in suggest-only mode? (Module 2)
If yes: capsule 03 can run.
If no: review Module 2 capsule 03 (inline comments) and capsule 04 (suggest-only).
Question 3: Do you know how to generate an automatic changelog and validate pre-deploy readiness? (Module 4)
If yes: capsule 04 will flow.
If no: review Module 4. Without this, the post-merge half of the pipeline is weak.
Question 4: Does your pipeline have automatic rollback with diagnosis configured? (Module 5)
If yes: capsule 05 (failure paths) builds on this.
If no: review Module 5. It's the pipeline's safety net.
Question 5: Do you know the difference between security scanning with Claude Code and tools like Snyk?
If yes: capsule 03 integrates them correctly.
If no: review Module 5 capsule 03. Confusing them leads to duplicating work or skipping layers.
If you hesitated on 2 or more: go back to the corresponding module before starting the project. Module 6 can't run well without the previous ones solid. If you answered all of them confidently, you're ready — start with the pipeline design in capsule 02.
How to Work Through This Module
- Capsule 02 is the most strategic. Designing well before implementing saves you hours.
- Capsules 03-04 are the most mechanical. Piece-by-piece implementation, you already have all the techniques.
- Capsule 05 is where the pipeline becomes real. Covering failure paths is what separates a demo from a production system.
- Capsule 06 is where the pipeline becomes transferable. Documentation + optimization + retrospective.
Estimated time:
Capsule 01 (this) → 10 min reading
Capsule 02 → 20-30 min of design
Capsule 03 → 30-45 min of implementation
Capsule 04 → 30-45 min of implementation
Capsule 05 → 30 min of covering failure paths
Capsule 06 → 30-45 min of docs + retrospective
Total: ~2.5-3.5 hours (a large project)
Final Project Evidence of Success
At the close of the whole Guide #10, validate that your deliverable meets the following 8 points:
- ✅ A working end-to-end pipeline that covers from PR to production with all the gates
- ✅ Failure paths covered for the 5 main failure modes (code review rejects, security blocks, staging fails, approval rejected, production detects an error)
- ✅ The pipeline's README that a teammate uses to operate it without your help
- ✅ A basic runbook (OPERATIONS.md) with what to do if X fails
- ✅ Real metrics (time, cost) per run and comparison with the manual process
- ✅ A cost analysis with a prioritized optimization plan
- ✅ Documented lessons — what you learned, what you'd change
- ✅ The pipeline running on at least 3 real PRs with positive results
If the 8 points are in place, you completed Guide #10 — and you have an artifact that demonstrates senior skill in CI/CD with Claude Code.
Summary
- This module integrates the 5 previous modules into an end-to-end pipeline
- The shift in focus is from individual steps to a coordinated system
- Failure paths are features, not optional
- Documentation is a deliverable, not an afterthought
- Costs are calculated and optimized — the pipeline has to be sustainable
- A retrospective turns the project into systematized learning
- The deliverable is portfolio-worthy — it demonstrates senior skill in CI/CD with Claude Code
Next capsule: 02 — End-to-end pipeline design. We start with the design before the implementation. Without a clear design, capsules 03-04 become blind implementation with costly rework.
What Comes After the Module
This is the last module of Guide #10 (Claude Code in CI/CD Pipelines). The next step in the Agentic Development path is Guide 11 (Security for AI-Generated Code) — the path's final guide. The transition is natural:
- This guide: how to automate Claude Code in pipelines
- Guide 11: how to ensure that AI-generated code (interactive or in pipelines) is secure
Guide 11 is 100% tool-agnostic — it applies to any AI tool, not just Claude Code. It's the close of the path with the perspective that differentiates a professional developer: not just automating, but automating securely.
Resources for the Project
- GitHub Actions Documentation — Your main platform
- Claude Code SDK — For cross-platform portability
- Site Reliability Engineering Book — Google's book on operating systems
- The Twelve-Factor App — Principles for deployable apps
- Continuous Delivery — Jez Humble — The classic reference
- GitHub Actions Pricing — For calculating pipeline costs
- DORA Metrics — The 4 metrics that matter for CI/CD (deployment frequency, lead time, MTTR, change failure rate)