Metadata Card

• Prerequisites: Chapter 4 (Testing Strategies)
• Estimated Time: 40 minutes
• Core Difficulty: Foundation-building
• Completion Milestone: Be able to design a basic CI/CD pipeline, understand deployment environments and automation principles

Your Progress

Your code is correct, organized, tested, and refactored. Now you need to ship it. In the City of Artisans, a blueprint that never reaches the forge floor is worthless.

The problem: your current deployment process is "ssh into server, git pull, restart service." It works — until you forget, typo, or deploy at 3 PM and break production. Your Task

CI/CD (Continuous Integration / Continuous Delivery) automates the path from commit to production. CI catches integration errors early; CD makes deployments repeatable and low-risk. This chapter covers pipeline design, deployment environments, and the engineering practices that make DevOps work.

Chapter tiers

• Required reading: CI concepts, pipeline stages, build automation
• Selective: CD strategies (rolling, blue/green), environment management
• Advanced: Infrastructure as Code (deferred to Vol 7 IaC chapter)

This chapter won't require you to master

• Kubernetes deployment (Vol 7)
• GitOps (Vol 7)

---

Breaking Ground · Tracing the Source

Monday morning. A teammate committed a change Friday evening. You pull, run tests — 3 tests fail. Turns out their change broke the build, but nobody was running CI. You spend an hour debugging merge conflicts.

CI exists to prevent exactly this: "it works on my machine" should never be the answer. The CI server runs the tests in a clean environment. If they pass there, they pass anywhere.

First Layer: CI (Continuous Integration)

CI means: every commit is built and tested on a shared server, and failures are immediately visible.

# .github/workflows/ci.yml — GitHub Actions
name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'

      - name: Run tests
        run: mvn clean test

      - name: Run static analysis
        run: mvn checkstyle:check

      - name: Package
        run: mvn package -DskipTests

Pipeline stages (from first to last):

1. Checkout — get the code
2. Build — compile, ensure no syntax errors
3. Static analysis — linting, style checks, security scanning
4. Unit tests — fast tests first
5. Integration tests — slower tests with real dependencies
6. Package — create deployable artifact (JAR, Docker image)

Second Layer: CD (Continuous Delivery)

CD extends CI — if the pipeline passes, the artifact is ready for deployment. Deployment to production may be manual or automated.

CI Pipeline → Store Artifact → Deploy to Staging → Acceptance Tests → Deploy to Prod
                                  (automatic)                         (manual or automatic)

Environment separation:

dev — developers push code directly. May be unstable.

staging — mirrors production. All changes go through staging before production validation.

production — real users. Minimum risk, maximum stability.

Rule: if it hasn't passed staging, it doesn't touch production.

Third Layer: Deployment Strategies

Strategy	Description	Risk	Traffic Loss During Switch
Rolling	Replace instances one by one	Low	Some (old instances during update)
Blue/Green	Two full environments, swap traffic instantly	Very low	Zero
Canary	Send small % of traffic to new version, gradually increase	Very low	Zero

Fourth Layer: Build Automation Principles

• Build once, deploy everywhere: The artifact built in CI is the exact same artifact deployed to dev, staging, and production. No recompilation in production.
• Immutable artifacts: A build produces a snapshot. Tags and version numbers are forever. Never overwrite a published artifact.
• Artifact repository: Use a tool like Nexus, Artifactory, or Docker Registry to store all artifacts.

---

Common Pitfalls

Pitfall 1: CI pipeline too slow (30+ minutes). Developers will push without waiting for results. Break into fast-feedback (compile + unit tests) and full suite.

Pitfall 2: Environment drift. Staging has JDK 17.0.1, production has 17.0.5 subtle behavior differences. Containerization (Docker) solves this — same image everywhere.

Pitfall 3: Skipping CI because "it's just a config change." Config changes can break things too. Every change goes through CI.

Pitfall 4: No rollback plan. "Deploy and pray." Every deployment should have a tested rollback procedure.

---

Passing Challenges

• Warm up: Set up a basic CI pipeline for one of your projects. Use GitHub Actions, GitLab CI, or Jenkins. Include build + test stages.
• Challenge: Add a second environment (staging) to your deployment pipeline. Manual deploy to staging, automated tests on staging, then manual deploy to production.
• Observe: Look at an open source project's CI configuration (GitHub Actions YAML or .travis.yml). How many stages do they have? What's the estimated time?

---

Traveler's Notes

CI/CD transforms deployment from a manual risk to an automated process. CI catches integration errors at commit time. CD makes pushing to production a low-stress operation. The pipeline is the factory assembly line for your software — every part moves through the same stations, every station validates quality, and the output is a known-good product ready for delivery.

---

Preview of Next Chapter

With CI/CD in place, you can ship code quickly and safely. But the longer your codebase lives, the more it needs to resist entropy. The next section covers the principles that keep code flexible and maintainable: SOLID, DRY, YAGNI. Next: Design Principles.