CI - CD — pipeline stages, GitHub Actions - GitLab CI concepts

1. The core definitions

2. WHAT are the pipeline stages? (the standard order)

Figure — CI - CD — pipeline stages, GitHub Actions - GitLab CI concepts

Stage	WHAT it does	WHY it's placed here
Source / Trigger	Event fires (push, PR, tag)	Nothing runs without a cause
Build / Compile	Turn code into runnable form, install deps	Can't test what won't build
Lint / Static analysis	Style + obvious bugs, no execution	Super cheap, fail fast
Test	Unit → integration → e2e	Prove behaviour; ordered cheap→expensive
Package	Make the artifact (image, binary)	Only worth doing if tests pass
Deploy (staging)	Ship to a test environment	Verify in prod-like conditions
Deploy (prod)	Ship to users (gated/auto)	Final delivery

3. HOW the platforms model this

# GitHub Actions — .github/workflows/ci.yml
name: CI
on: [push, pull_request]           # trigger
jobs:
  test:                            # a job
    runs-on: ubuntu-latest         # the runner
    steps:
      - uses: actions/checkout@v4  # reusable action
      - run: npm ci                # build/install
      - run: npm test              # test step

# GitLab CI — .gitlab-ci.yml
stages: [build, test, deploy]      # ordered stages
unit-test:
  stage: test
  script:
    - npm ci
    - npm test
  needs: [build-job]               # DAG dependency

4. A tiny "derivation": why parallelism + caching matters

5. Worked example: read a failing pipeline

6. Common mistakes (Steel-manned)

Recall Feynman: explain it to a 12-year-old

You and friends build a giant LEGO castle together. Every time anyone adds a brick, a robot instantly checks: does the castle still stand? does it look right? If yes, the robot photocopies the castle and puts the copy on the display shelf. CI is the robot checking each new brick fast; CD is the robot putting safe copies on the shelf. Doing tiny checks all the time means you never discover at the end that the whole tower was crooked.

7. Connections

Version Control & Git Branching — pipelines trigger off branches/PRs/tags.
Automated Testing — Unit vs Integration vs E2E — the heart of the test stage.
Docker & Containerization — runners and artifacts are usually containers/images.
Infrastructure as Code — deploy stages provision environments declaratively.
DevOps Principles & Shift-Left — the philosophy CI/CD operationalizes.
Amdahl's Law — why parallel speedup is capped.

Flashcards

What does CI stand for and what is its core idea?

Continuous Integration — merge changes frequently to a shared branch, each merge auto-builds and auto-tests.

Difference between Continuous Delivery and Continuous Deployment?

Delivery has a manual approval gate before production; Deployment auto-releases to production with no human gate.

Why are pipeline stages ordered cheap/fast first?

"Fail fast / shift left" — catch broken code with the cheapest check (lint) before paying for slow stages (deploy).

GitHub Actions hierarchy?

Workflow ➜ Job ➜ Step (a step may use an action).

GitLab CI hierarchy?

Pipeline ➜ Stage ➜ Job.

Jobs in the same stage: serial or parallel?

Parallel; stages themselves run sequentially.

Formula for parallel wall-clock time of n independent jobs on m runners?

T = t\cdot\lceil n/m\rceil

Maximum useful number of runners for n independent jobs?

m = n; beyond that no extra speedup.

What is a runner/agent?

The VM/container that actually executes pipeline jobs.

What is an artifact?

A file/output produced by a stage and stored for later stages (binary, image, report).

Why never put secrets in the pipeline YAML?

YAML is committed to git history; use the platform's masked secret store instead.

What does needs: enable in GitLab CI?

A DAG so a job starts as soon as its dependencies finish, instead of waiting for the whole previous stage.

Why cache dependencies in CI?

Install is repeated/deterministic/large; restoring a cache (time c ≪ d) saves d−c per run.

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Socho 20 log ek hi codebase pe kaam kar rahe hain. Agar har koi apna change bina check kiye merge karega, to bugs aur conflicts pile up ho jayenge aur end pe sab kuch toot jayega. CI (Continuous Integration) ka idea simple hai: chhote-chhote changes baar-baar merge karo, aur har merge pe ek robot automatically build + test chala de. Issse bug "type karte hi" pakda jata hai — jo fix karna sabse sasta hota hai. Yeh "shift left" principle hai: failure ko time mein jitna left (early) le jao, utna better.

CD do flavour mein aata hai. Continuous Delivery matlab har passing build ka ek deployable artifact ban jata hai, par production pe bhejne ke liye ek banda manually button dabata hai. Continuous Deployment matlab woh button bhi automatic — seedha users tak. Yaad rakho: Delivery mein ek aadmi abhi bhi "live" rehta hai button pe.

Pipeline stages ek order mein chalte hain: Source → Build → Lint → Test → Package → Deploy. Cheap aur fast cheezein (lint) pehle, taaki agar woh fail ho to mehnga deploy chalाने ki zaroorat hi na pade. GitHub Actions mein hierarchy hai Workflow → Job → Step, aur GitLab CI mein Pipeline → Stage → Job. Ek stage ke andar ke jobs parallel chalte hain, aur stages aapas mein sequential.

Important baatein: secrets kabhi YAML mein mat likho (git history mein hamesha ke liye leak ho jata hai) — platform ka secret store use karo. Aur "zyada runners = hamesha fast" galat hai: speedup tab tak hi badhta hai jab tak runners ki sankhya independent jobs ke barabar (m = n) na ho jaye. Formula: parallel time $T = t\lceil n/m\rceil$ . Yeh sab samajh lo to CI/CD ka pura mental model clear ho jata hai.