DevOps CI/CD Fundamentals

CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). It is the practice of automating the steps that take code from a developer's laptop to a live production server — reliably and repeatedly.

CI/CD is the backbone of modern DevOps. Without it, every release is a manual, error-prone event. With it, teams ship new features multiple times a day with confidence.

What Is Continuous Integration (CI)?

Continuous Integration means developers merge their code changes into a shared repository frequently — several times a day. Each merge triggers an automated process that:

1. Pulls the latest code from the repository.
2. Builds the application.
3. Runs automated tests.
4. Reports the result back to the developer.

If a test fails, the developer is notified immediately — while the change is still fresh in mind. Fixing a bug minutes after writing it is far easier than fixing it weeks later.

What Is Continuous Delivery (CD)?

Continuous Delivery extends CI. After code passes all tests, it is automatically packaged and made ready for release to production. The actual deployment to production may still require a manual approval step.

What Is Continuous Deployment?

Continuous Deployment goes one step further. Every change that passes all automated tests is deployed to production automatically — no human approval needed. Companies like Netflix and Amazon use this approach.

CI vs CD vs Continuous Deployment

What Is a CI/CD Pipeline?

A pipeline is the automated sequence of steps that code moves through from commit to deployment. Think of it as an assembly line in a factory — each station performs a specific job, and the product moves forward only when each step succeeds.

A Typical CI/CD Pipeline

1. Source: Developer pushes code to Git repository.
2. Build: The pipeline compiles the code or creates a Docker image.
3. Test: Unit tests, integration tests, and security scans run automatically.
4. Artifact: A deployable package (JAR, Docker image, ZIP) is created and stored.
5. Deploy to Staging: The artifact is deployed to a test environment.
6. Acceptance Test: Automated end-to-end tests confirm the app works correctly.
7. Deploy to Production: The artifact goes live — automatically or after manual approval.

Popular CI/CD Tools

GitHub Actions – A Simple Pipeline Example

GitHub Actions pipelines are defined in YAML files stored inside the repository at .github/workflows/. Here is a simple pipeline that builds and tests a Node.js app on every push:

name: CI Pipeline

on:
  push:
    branches:
      - main

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      - name: Build the app
        run: npm run build

Every time code is pushed to main, GitHub automatically runs this pipeline. If tests fail, the team gets a notification and the bad code never reaches production.

Key Concepts in CI/CD

Build Artifact

An artifact is the compiled, packaged version of the application ready for deployment. Examples: a .jar file for Java apps, a Docker image for containerized apps, a .zip for serverless functions.

Pipeline Stages

Pipelines are divided into stages. Each stage contains one or more steps. If a stage fails, the pipeline stops and reports the failure.

Environment Variables and Secrets

Pipelines need sensitive values like API keys and passwords. These are stored as secrets in the CI/CD tool and injected into the pipeline at runtime — never hardcoded in files.

Pipeline Triggers

Pipelines start automatically based on events:

• Push to a branch
• Opening a pull request
• Merging to main
• A scheduled time (nightly builds)
• Manual trigger by a team member

The Importance of Fast Feedback

The primary value of CI/CD is fast feedback. Consider these two scenarios:

Without CI/CD: A developer writes code for two weeks. The code gets deployed manually. Ten bugs are found. The developer has to remember what each change was and why — a painful debugging session.

With CI/CD: The developer pushes code every hour. Each push triggers a pipeline. A bug appears within minutes of being introduced. The developer knows exactly which change caused it and fixes it immediately.

Real-World Example

A team builds a travel booking website. Here is their CI/CD setup:

• Developers push code to GitHub feature branches.
• GitHub Actions triggers a pipeline: linting → unit tests → build Docker image.
• After merge to develop, the image deploys automatically to a staging server.
• QA team tests on staging. Once approved, a manual click deploys to production.
• The entire process from code push to staging takes under 8 minutes.

CI/CD Best Practices

• Keep pipelines fast: Pipelines over 10 minutes slow the team down. Optimize tests and builds.
• Never skip tests: Tests are the safety net. A failed test that stops a deployment is a feature, not a bug.
• Store pipeline definitions in Git: Pipeline YAML files belong in the same repository as the application code.
• Use separate environments: Never deploy directly from a CI job to production without a staging step.
• Monitor pipeline health: Track failure rates and duration over time. Slow or flaky pipelines need fixing.

Summary

• CI automates build and test on every code commit — catching bugs early.
• CD ensures code is always in a deployable state.
• Continuous Deployment pushes every passing change to production automatically.
• A pipeline moves code through source → build → test → deploy stages.
• Fast feedback loops are the core value CI/CD brings to a DevOps team.