Home/Learn/CI/CD & GitHub Actions/What is CI/CD and Why It Matters

What is CI/CD and Why It Matters

Beginner
Fundamentals

CI/CD automates the path from code commit to production deployment. Continuous Integration catches bugs early; Continuous Delivery/Deployment eliminates manual, error-prone release processes.

Overview

Before CI/CD, releasing software meant a painful "integration hell" — developers worked in isolation for weeks, then merged everything and spent days resolving conflicts and debugging environment differences. CI (Continuous Integration) fixes this by integrating code frequently and running automated tests immediately on every commit. CD (Continuous Delivery) takes passing code and automatically packages it into a deployable artifact. Continuous Deployment goes one step further — it automatically deploys to production without human approval. Together they compress the feedback loop from "weeks" to "minutes," allowing teams to ship code safely many times per day.

CI/CD Pipeline Stages

A typical pipeline has discrete stages. Each stage acts as a quality gate — if any stage fails, the pipeline stops and the change does not proceed to the next environment.

CI/CD pipeline stages overview
Developer pushes code

         │

         â–¼

┌──────────────────┐

│  1. SOURCE       │  GitHub/GitLab detects push → triggers pipeline

â””────────┬─────────┘

         │

         â–¼

┌──────────────────┐

│  2. BUILD        │  Compile code, install dependencies, build Docker image

â””────────┬─────────┘  ← fails here if: compile errors, missing deps

         │

         â–¼

┌──────────────────┐

│  3. TEST         │  Unit tests, integration tests, linting, security scan

â””────────┬─────────┘  ← fails here if: tests fail, coverage drops, CVEs found

         │

         â–¼

┌──────────────────┐

│  4. STAGING      │  Deploy to staging environment, run E2E tests

â””────────┬─────────┘  ← fails here if: deployment fails, E2E tests fail

         │

         â–¼

┌──────────────────┐

│  5. PRODUCTION   │  Manual approval (CD) or automatic (Continuous Deployment)

â””──────────────────┘



Key principle: FAIL FAST — catch errors in the cheapest stage (unit tests)

before they reach expensive stages (E2E tests, staging deploy)

CI vs CD vs Continuous Deployment

These three terms are often confused. The key distinction is where human approval sits in the flow.

CI vs CD vs Continuous Deployment comparison
Continuous Integration (CI):

  • Every commit triggers: build + automated tests

  • Goal: always keep main branch in a working, tested state

  • Eliminates: integration hell, "it worked on my machine"



Continuous Delivery (CD):

  • CI + automatically build a deployable artifact (Docker image, JAR, zip)

  • Artifact is deployable to production at any time

  • HUMAN approves the production deployment

  • Goal: production deployment is always ready, low-ceremony

  • "The code is always releasable, but we choose when"



Continuous Deployment:

  • CI + CD + automatic deployment to production on green build

  • NO human approval gate before production

  • Requires: excellent test coverage, feature flags, monitoring

  • Companies doing this: Etsy, Amazon (deploys every ~11.6 seconds)

  • "Every green build is automatically in production"



Which should I use?

  Startups/fast teams:     Continuous Deployment

  Regulated industries:    Continuous Delivery (manual approval for compliance)

  Large enterprises:       Continuous Delivery with change management gates

GitHub Actions — Your First Pipeline

GitHub Actions is event-driven CI/CD built directly into GitHub. Workflows are YAML files in .github/workflows/. They trigger on push, pull_request, schedule, or manual dispatch.

.github/workflows/ci.yml — first pipeline
# .github/workflows/ci.yml

name: CI Pipeline



on:

  push:

    branches: [main, develop]

  pull_request:

    branches: [main]



jobs:

  test:

    runs-on: ubuntu-latest         # GitHub-hosted runner



    steps:

      - name: Checkout code

        uses: actions/checkout@v4



      - name: Set up Node.js

        uses: actions/setup-node@v4

        with:

          node-version: '20'

          cache: 'npm'             # cache node_modules between runs



      - name: Install dependencies

        run: npm ci                # clean install (uses package-lock.json)



      - name: Run linter

        run: npm run lint



      - name: Run tests

        run: npm test



      - name: Upload coverage report

        uses: actions/upload-artifact@v4

        with:

          name: coverage

          path: coverage/

          retention-days: 7



# Every push to main or PR targeting main now runs this pipeline

# Green check on PR = tests pass → safe to merge

Key Points to Remember

  • 1CI: every commit triggers build + tests to keep main always working.
  • 2CD (Delivery): artifact is always deployable; human decides when to release.
  • 3Continuous Deployment: every green build automatically ships to production.
  • 4Fail fast: run cheapest checks first (lint → unit tests → integration tests → E2E).
  • 5GitHub Actions triggers on events: push, pull_request, schedule, workflow_dispatch.
  • 6actions/checkout, actions/setup-node are official actions from GitHub — always use versioned tags (@v4).

Interview Questions

Sign in to ask Aria
1

What is the difference between Continuous Delivery and Continuous Deployment?

2

What triggers a GitHub Actions workflow?

Ask Aria about What is CI/CD and Why It Matters

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Sign in to save personal notes for this topic.

Discussion

Sign in to join the discussion.

Loading discussion…
All CI/CD Concepts
Next
GitHub Actions — Workflows, Jobs & Steps