Skip to main content

Introduction to CI/CD

Table of contents​

  1. CI/CD definitions
  2. Continuous Integration (CI)
  3. Continuous Delivery (CD)
  4. Continuous Deployment
  5. Anatomy of a pipeline
  6. Best practices

1 - CI/CD definitions​

Overview​

The three concepts​

ConceptDefinitionAutomation
CIFrequent integration of codeBuild + Tests
Continuous DeliveryReady to deploy at any time+ Release
Continuous DeploymentAutomatic deployment+ Production
info

The difference between Continuous Delivery and Continuous Deployment is a manual validation: Delivery waits for an approval, Deployment is fully automatic.

🔝 Back to table of contents​


2 - Continuous Integration (CI)​

The problem without CI​

The CI solution​

The rules of CI​

RuleDescription
Frequent commitsAt least once a day
Automatic buildTriggered on every commit
Automatic testsUnit + Integration
Fast feedback< 10 minutes ideally
Immediate fixBroken build = priority #1
warning

A broken build blocks the whole team. Fixing it is the absolute priority. No "I'll get to it later".

Typical CI pipeline​

Benefits of CI​

  • Early bug detection
  • Fewer merge conflicts
  • Code always in a deployable state
  • Fast feedback to developers
  • Confidence in the code

🔝 Back to table of contents​


3 - Continuous Delivery (CD)​

Extension of CI​

Continuous delivery extends CI by ensuring the code can be deployed at any time.

Environments​

EnvironmentUsage
DevelopmentLocal tests, experimentation
Testing/QAAutomated tests, validation
StagingMirror of production, final tests
ProductionReal users

Key practices​

  • Identical deployments: same process for all environments
  • Externalized configuration: environment variables
  • Database migrations: versioned and automated
  • Feature flags: enable/disable features

🔝 Back to table of contents​


4 - Continuous Deployment​

Beyond delivery​

Continuous deployment removes the manual validation: every validated change goes automatically to production.

Prerequisites​

PrerequisiteReason
Exhaustive testsSafety net
Robust monitoringFast detection
Automatic rollbackFast recovery
Feature flagsExposure control
Quality cultureShared responsibility
danger

Continuous deployment without exhaustive tests is a recipe for disaster. Make sure you have sufficient test coverage before implementing it.

Comparison of approaches​

🔝 Back to table of contents​


5 - Anatomy of a pipeline​

Structure of a pipeline​

Example pipeline file​

GitHub Actions:

name: CI/CD Pipeline

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Deploy to production
        run: echo "Deploying..."

Parallel vs sequential jobs​

tip

Parallelize independent jobs to reduce the total pipeline time.

Artifacts and cache​

ConceptUsage
ArtifactResult of a job (JAR, Docker image)
CacheReusable dependencies (node_modules)
WorkspaceFiles shared between jobs

🔝 Back to table of contents​


6 - Best practices​

The 10 CI/CD commandments​

#Practice
1Maintain a single source repository
2Automate the build
3Make the build self-testing
4Commit frequently to mainline
5Build on every commit
6Keep the build fast
7Test in a clone of production
8Make artifacts accessible
9Visibility into the process
10Automate deployment

Fast pipeline​

note

Goal: feedback in under 10 minutes. Beyond that, developers lose the context of their change.

Trunk-based development​

Recommended practice:

  • Short-lived branches (< 1 day)
  • Frequent merges to main
  • Feature flags for incomplete code

Secrets management​

MethodExample
Environment variablesGitHub Secrets
VaultHashiCorp Vault
Cloud KMSAWS Secrets Manager
danger

Never commit secrets into the code. Always use environment variables or a secrets manager.

🔝 Back to table of contents​


Key takeaways​

  • CI: frequent integration with automatic build and tests
  • Continuous Delivery: ready to deploy, manual validation
  • Continuous Deployment: automatic deployment to production
  • A fast pipeline (< 10 min) is essential
  • Automated tests are the safety net
  • Feature flags let you decouple deployment from release

🔝 Back to table of contents​

← Previous chapter | Next chapter: Overview of Tools →