CI/CD Pipeline Explained: A Practical Guide for Developers

Imagine this:

You finish coding a feature.

Then you:

git push
   ↓
Build manually
   ↓
Run tests manually
   ↓
Create deployment package
   ↓
Upload to server
   ↓
Restart application
   ↓
Check whether it works

This process can become slow and error-prone when repeated every day.

CI/CD changes this workflow by automating many of these steps.

A typical pipeline can look like:

Developer
    ↓
Git Push
    ↓
Build
    ↓
Test
    ↓
Package
    ↓
Deploy
    ↓
Production

This guide explains CI/CD from a developer's perspective and shows how a simple pipeline can be built.

1. CI/CD in One Minute

CI/CD is a collection of software development practices and automation workflows that help teams build, test, and deliver software more reliably.

The terms usually refer to:

CI — Continuous Integration

Developers frequently integrate code changes into a shared repository, with automated checks validating those changes.

CD — Continuous Delivery

Software is kept in a releasable state so it can be deployed when the team chooses.

CD — Continuous Deployment

Changes that pass the required automated checks can be deployed automatically.

The exact pipeline differs between organizations.

2. Why Do Developers Need CI/CD?

Without automation, developers may repeatedly perform tasks like:

Pull Code
 ↓
Install Dependencies
 ↓
Build
 ↓
Run Tests
 ↓
Create Artifact
 ↓
Deploy

A CI/CD pipeline can automate these steps.

That means developers can focus more on writing and improving software instead of repeating deployment tasks manually.

3. The Basic Pipeline

Here is a simple CI/CD workflow:

Each stage has a specific purpose.

4. What Happens When You Push Code?

Suppose you make a change:

git add .
git commit -m "Add login validation"
git push origin main

The Git repository can trigger the CI/CD workflow.

The pipeline may then:

Push
 ↓
Checkout Code
 ↓
Install Dependencies
 ↓
Build
 ↓
Run Tests
 ↓
Deploy

You do not need to manually execute every step.

5. CI: Continuous Integration

Continuous Integration focuses on integrating code changes frequently and validating them automatically.

For example:

Developer A ─┐
Developer B ─┼──> Shared Repository
Developer C ─┘
                  ↓
             CI Pipeline
                  ↓
              Build + Test

The goal is to identify problems early.

6. What Does CI Usually Do?

A CI pipeline commonly performs:

• Code checkout
• Dependency installation
• Compilation or build
• Unit tests
• Linting
• Static analysis
• Security checks

For a JavaScript application, it might look like:

npm install
npm run lint
npm test
npm run build

For a Python application:

pip install -r requirements.txt
pytest

The exact commands depend on the project.

7. Why Automated Testing Matters

Imagine a developer changes an authentication function.

The application still builds successfully.

But a previously working login test now fails.

A CI pipeline can detect this before the change reaches production.

Code Change
    ↓
Automated Tests
    ↓
Test Failed
    ↓
Pipeline Stops
    ↓
Developer Fixes Problem

This is one of the biggest benefits of CI/CD.

8. Unit Tests vs Integration Tests

A pipeline can contain different types of tests.

Unit Tests

Test small pieces of code independently.

Function
   ↓
Test
   ↓
Pass / Fail

Integration Tests

Test how multiple components work together.

API
 ↓
Service
 ↓
Database
 ↓
Result

A mature pipeline may use several layers of testing.

9. CD: Continuous Delivery

Continuous Delivery means the software is automatically built and validated so that it is ready to release.

A simplified process:

Code
 ↓
Build
 ↓
Test
 ↓
Package
 ↓
Release Candidate

A human may still decide when production deployment happens.

10. CD: Continuous Deployment

Continuous Deployment goes one step further.

If the required checks succeed, deployment can happen automatically.

Code
 ↓
Build
 ↓
Test
 ↓
Security Checks
 ↓
Deploy
 ↓
Production

This can enable teams to release small changes frequently.

11. Delivery vs Deployment

The difference is mainly about the final release step.

Continuous Delivery

Code
 ↓
Build
 ↓
Test
 ↓
Ready for Production
 ↓
Manual Release

Continuous Deployment

Code
 ↓
Build
 ↓
Test
 ↓
Automatic Production Deployment

Organizations choose the approach that fits their risk, compliance, and operational requirements.

12. What Is a Pipeline Stage?

A pipeline is usually divided into stages.

For example:

Build
  ↓
Test
  ↓
Security
  ↓
Package
  ↓
Deploy

Each stage can contain multiple commands or jobs.

This makes the workflow easier to understand and maintain.

13. Jobs and Steps

A pipeline can be organized into jobs.

For example:

Pipeline
│
├── Build Job
│
├── Test Job
│
├── Security Job
│
└── Deploy Job

Each job can contain several steps.

Test Job
│
├── Install dependencies
├── Start services
├── Run tests
└── Generate report

14. Artifacts

A build often produces an artifact.

An artifact can be:

• Compiled application
• Docker image
• ZIP package
• Binary
• Static website files
• Deployment package

For example:

Source Code
    ↓
Build
    ↓
Application Artifact
    ↓
Deployment

Artifacts make the output of a build reproducible and easier to move between environments.

15. Build Once, Deploy Consistently

A useful principle is to avoid rebuilding different versions for different environments when possible.

For example:

Source
  ↓
Build
  ↓
Artifact
  ↓
Development
  ↓
Staging
  ↓
Production

The same tested artifact can move through environments.

This reduces differences between what was tested and what gets deployed.

16. Development, Staging, and Production

Many teams use multiple environments.

Development

Used for active development.

Staging

Used for testing a production-like environment.

Production

The live environment used by customers.

A common flow is:

Not every organization needs all three environments.

17. What Is a Deployment?

Deployment means making a software version available in a target environment.

For example:

Application v1
     ↓
Production

Application v2
     ↓
Deployment
     ↓
Production

Deployment can involve:

• Uploading artifacts
• Starting containers
• Updating services
• Changing configuration
• Running migrations
• Performing health checks

18. Manual Deployment vs Automated Deployment

Manual

Developer
   ↓
SSH Server
   ↓
Pull Code
   ↓
Build
   ↓
Restart

Automated

Git Push
   ↓
Pipeline
   ↓
Build
   ↓
Test
   ↓
Deploy

Automation reduces repetitive work and makes the process more consistent.

19. GitHub Actions

GitHub Actions is one option for implementing CI/CD workflows.

A workflow can run when:

• Code is pushed
• A pull request is opened
• A release is created
• A schedule occurs
• A manual workflow is triggered

A basic workflow might look like:

name: CI

on:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

The exact versions and commands should match your project.

20. Understanding the Workflow File

A workflow generally defines:

Trigger
   ↓
Jobs
   ↓
Steps

For example:

on:
  push:
    branches:
      - main

means the workflow is triggered by pushes to the main branch.

The job defines where and how the commands run.

21. Pull Requests and CI

CI is especially useful with pull requests.

A typical workflow is:

This prevents obvious build or test failures from being merged.

22. Branch Protection

Repositories can require checks to pass before a pull request can be merged.

For example:

Pull Request
     ↓
Tests
     ↓
Lint
     ↓
Build
     ↓
All Checks Pass
     ↓
Merge Allowed

This creates a quality gate around the main branch.

23. Secrets in CI/CD

CI/CD systems often need credentials.

Examples include:

• Cloud credentials
• Deployment tokens
• API keys
• Registry credentials

These should not be placed directly inside source code.

Bad:

password: my-secret-password

Better:

CI/CD Secret Store
        ↓
Workflow
        ↓
Environment Variable

Never commit production credentials to a public repository.

24. Environment Variables

Applications commonly use environment variables for configuration.

For example:

DATABASE_URL
API_URL
PORT
APP_ENV

A deployment environment can provide different values.

Development
DATABASE_URL → Development DB

Production
DATABASE_URL → Production DB

Keep secrets separate from ordinary configuration whenever the platform supports it.

25. Docker in CI/CD

Docker is commonly used to create reproducible application environments.

A pipeline may look like:

For example:

docker build -t my-app:latest .

Then the image can be pushed to a container registry.

26. Container Registry

A container registry stores container images.

The workflow becomes:

Source Code
    ↓
Docker Build
    ↓
Docker Image
    ↓
Container Registry
    ↓
Server / Cloud

Examples of container registries include:

• Docker Hub
• GitHub Container Registry
• Cloud provider registries

27. Why Version Docker Images?

Avoid relying only on:

latest

Versioned tags can make deployments easier to track.

For example:

my-app:1.0.0
my-app:1.1.0
my-app:1.2.0

A deployment can then reference a specific version.

28. Deployment Strategies

There are several ways to deploy a new version.

Recreate

Stop the old version and start the new version.

Old Version
     ↓
Stop
     ↓
New Version

Simple, but it may cause downtime.

Rolling Deployment

Gradually replace old instances.

Old Old Old
   ↓
New Old Old
   ↓
New New Old
   ↓
New New New

Blue-Green Deployment

Maintain two environments.

Blue → Current
Green → New

Traffic can be switched to the new environment after validation.

29. Canary Deployment

Canary deployment sends a small percentage of traffic to the new version first.

Users
  ↓
Traffic Router
  ├── 95% → Old Version
  └── 5%  → New Version

If the new version behaves correctly, traffic can gradually increase.

This can reduce the blast radius of a bad release.

30. Health Checks After Deployment

A deployment should not be considered successful simply because the deployment command completed.

You should also verify application health.

For example:

Deploy
  ↓
Health Check
  ↓
API Response
  ↓
Metrics
  ↓
Logs

A simple health endpoint might be:

GET /health

31. Rollbacks

Sometimes a deployment causes problems.

A rollback returns the system to a known working version.

Fast and reliable rollback procedures are an important part of production operations.

32. Database Migrations

Database changes require special attention.

Suppose version 2 adds a column:

users
----------------
id
name
email

becomes:

users
----------------
id
name
email
phone

The application and database migration need to be coordinated safely.

Database migrations should be tested before production deployment.

33. The Expand-and-Contract Pattern

For important database changes, a safer approach can be:

1. Add New Structure
       ↓
2. Deploy Compatible Application
       ↓
3. Migrate Data
       ↓
4. Switch Application
       ↓
5. Remove Old Structure

This can reduce the risk of deploying application code that expects database changes that are not yet available.

34. What Happens When a Pipeline Fails?

A failed pipeline is not necessarily a disaster.

For example:

Push
 ↓
Build
 ↓
Test
 X
 ↓
Pipeline Failed

The developer can inspect:

• Error message
• Failed step
• Logs
• Test results
• Build output

Then fix the problem and push again.

35. Common CI Failures

Dependency Failure

Package installation failed

Test Failure

Expected 200
Received 500

Build Failure

Compilation failed

Lint Failure

Linting errors found

Environment Failure

Required environment variable missing

Deployment Failure

Server rejected deployment

Read the earliest meaningful error rather than only the final failure message.

36. CI/CD Logs

Logs are one of the most useful debugging tools.

A pipeline log might contain:

Installing dependencies...
Dependencies installed.

Running tests...
42 passed
2 failed

Pipeline stopped.

The important information is often close to the first actual error.

37. Notifications

Teams can receive notifications when pipelines fail or succeed.

For example:

Developer Push
      ↓
Pipeline
      ↓
Failed
      ↓
Notification
      ↓
Developer Investigates

Notifications can be integrated with the team's existing communication tools.

38. Security Checks in CI/CD

Security can be integrated into the pipeline.

Possible checks include:

• Dependency scanning
• Secret scanning
• Static analysis
• Container image scanning
• Infrastructure checks

A simplified pipeline:

Security should be integrated throughout development rather than treated as a final manual step.

39. Dependency Scanning

Applications depend on external packages.

For example:

Application
   ↓
Package A
   ↓
Package B
   ↓
Package C

If a dependency contains a known vulnerability, the team may need to update it.

Automated dependency checks can help identify such issues.

40. Secret Scanning

Secrets accidentally committed to repositories can create serious security risks.

Examples include:

API_KEY
DATABASE_PASSWORD
PRIVATE_KEY
ACCESS_TOKEN

Use secret-management systems and scanning tools where appropriate.

If a real credential is accidentally exposed, simply deleting it from the latest commit may not be sufficient. The credential should generally be revoked or rotated.

41. Infrastructure as Code

Infrastructure can also be managed using code.

Instead of manually creating infrastructure:

Click Dashboard
   ↓
Create Server
   ↓
Configure Network
   ↓
Configure Storage

Infrastructure as Code allows configuration to be represented as files.

Common technologies include:

• Terraform
• OpenTofu
• CloudFormation
• Pulumi

This allows infrastructure changes to be reviewed and automated.

42. CI/CD and Infrastructure as Code

A more advanced pipeline can look like:

This creates a consistent process for both application and infrastructure changes.

43. CI/CD for a Frontend

A frontend pipeline might be:

Git Push
   ↓
Install Dependencies
   ↓
Lint
   ↓
Test
   ↓
Build
   ↓
Upload Static Files
   ↓
CDN

For example:

npm ci
npm run lint
npm test
npm run build

The generated build directory can then be deployed to the chosen hosting platform.

44. CI/CD for a Backend

A backend pipeline might be:

Git Push
   ↓
Install Dependencies
   ↓
Test
   ↓
Build
   ↓
Docker Image
   ↓
Registry
   ↓
Deployment

The backend can then be deployed to a VM, container platform, Kubernetes cluster, or another supported environment.

45. CI/CD for a Python Application

A simplified workflow might run:

python -m venv .venv
pip install -r requirements.txt
pytest

Then the application could be packaged into a Docker image.

46. CI/CD for a Node.js Application

A simple Node.js pipeline might run:

npm ci
npm run lint
npm test
npm run build

After the build succeeds, the application can be packaged and deployed.

47. A Practical Example

Suppose you have a web application.

Your current deployment process is:

1. Developer writes code
2. Pushes to GitHub
3. SSH into server
4. Pulls repository
5. Installs dependencies
6. Builds application
7. Restarts service
8. Checks website

You want to automate it.

The new workflow becomes:

Developer
   ↓
Git Push
   ↓
CI
   ├── Build
   ├── Test
   └── Security Checks
          ↓
       Docker Build
          ↓
      Container Registry
          ↓
        Deployment
          ↓
      Health Check

Now the deployment process is repeatable.

48. A Simple Pipeline Design

For a beginner project, you do not need a massive DevOps platform.

Start with:

GitHub
   ↓
CI Workflow
   ↓
Tests
   ↓
Build
   ↓
Docker
   ↓
Deployment

Once this works reliably, add more capabilities.

49. What Should You Automate First?

Start with repetitive tasks.

A good progression is:

1. Automated Tests
       ↓
2. Automated Build
       ↓
3. Automated Docker Build
       ↓
4. Automated Deployment
       ↓
5. Health Checks
       ↓
6. Monitoring
       ↓
7. Rollback

Do not try to automate everything on day one.

50. A Beginner CI/CD Project

Build a small application such as:

Frontend
   +
Backend API
   +
Database

Then create this workflow:

This single project can teach many practical DevOps concepts.

51. Recommended Project Structure

A project could contain:

my-app/
│
├── src/
├── tests/
├── Dockerfile
├── package.json
├── README.md
└── .github/
    └── workflows/
        └── ci.yml

The exact structure depends on the programming language and framework.

52. Example Dockerfile

For a simple Node.js application:

FROM node:22

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

RUN npm run build

EXPOSE 3000

CMD ["npm", "start"]

Production Dockerfiles should be designed according to the application's requirements and security needs.

53. Pipeline Quality Gates

A pipeline can prevent deployment when important checks fail.

For example:

Build
  ↓
Pass
  ↓
Tests
  ↓
Pass
  ↓
Security
  ↓
Pass
  ↓
Deploy

If testing fails:

Build
  ↓
Pass
  ↓
Tests
  X
  ↓
STOP

This prevents known failures from automatically moving forward.

54. Deployment Approval

Some organizations require human approval before production deployment.

For example:

Code
 ↓
CI
 ↓
Staging
 ↓
Testing
 ↓
Approval
 ↓
Production

This can be useful for systems with strict operational or compliance requirements.

55. Observability After Deployment

Deployment is not the end of the pipeline.

You should also monitor the application.

Track things such as:

• Error rate
• Response time
• CPU usage
• Memory usage
• Request volume
• Availability

A useful production workflow is:

Deploy
 ↓
Observe
 ↓
Detect
 ↓
Respond
 ↓
Improve

56. CI/CD and DevOps

CI/CD is one part of DevOps.

DevOps involves broader practices around:

• Development
• Operations
• Automation
• Collaboration
• Infrastructure
• Monitoring
• Security
• Delivery

A simplified relationship is:

CI/CD helps connect development work with reliable software delivery.

57. Common CI/CD Mistakes

Deploying Without Tests

Automation should not simply automate bad practices.

Storing Secrets in Git

Never commit sensitive credentials.

Using Only latest

Version artifacts when practical.

No Rollback Plan

Every important deployment should have a recovery strategy.

Ignoring Logs

Pipeline and application logs are essential for troubleshooting.

Deploying Directly to Production

Use appropriate validation and environments.

Overcomplicating the Pipeline

Start simple and add complexity when requirements justify it.

58. How to Improve a CI/CD Pipeline

Once your basic pipeline works, improve it gradually.

Level 1

Build
 ↓
Test

Level 2

Build
 ↓
Test
 ↓
Docker

Level 3

Build
 ↓
Test
 ↓
Security
 ↓
Docker
 ↓
Deploy

Level 4

Build
 ↓
Test
 ↓
Security
 ↓
Staging
 ↓
Health Check
 ↓
Approval
 ↓
Production
 ↓
Monitoring

The right level depends on the application.

59. CI/CD Tools

Different organizations use different tools.

Common categories include:

Source Control

• GitHub
• GitLab
• Bitbucket

CI/CD Platforms

• GitHub Actions
• GitLab CI/CD
• Jenkins
• CircleCI
• Azure Pipelines

Containers

• Docker
• Podman

Infrastructure

• Terraform
• OpenTofu
• CloudFormation
• Pulumi

Monitoring

• Prometheus
• Grafana
• Cloud monitoring platforms

You do not need to learn every tool.

60. What Should Beginners Learn?

A practical learning order is:

Git
 ↓
GitHub
 ↓
Linux
 ↓
Docker
 ↓
CI/CD
 ↓
Cloud Basics
 ↓
Infrastructure as Code
 ↓
Monitoring
 ↓
Kubernetes

Kubernetes is useful, but you should understand containers and deployment fundamentals first.

61. CI/CD Learning Roadmap

This gives beginners a logical progression instead of trying to learn every DevOps tool simultaneously.

62. Final Practical Advice

If you are a developer learning DevOps, do not start by memorizing dozens of CI/CD tools.

Build one complete pipeline.

For example:

GitHub Repository
       ↓
Git Push
       ↓
GitHub Actions
       ↓
Run Tests
       ↓
Build Docker Image
       ↓
Push Image
       ↓
Deploy
       ↓
Health Check

Once you understand this workflow, the same concepts become easier to apply with other CI/CD platforms.

63. Final Takeaway

CI/CD is about making software delivery more consistent, repeatable, and automated.

The core idea is simple:

Code
 ↓
Build
 ↓
Test
 ↓
Package
 ↓
Deploy
 ↓
Monitor

You do not need a complicated infrastructure setup to start.

Take a small project and automate it.

Start with:

Git
+
Tests
+
Build

Then add:

Docker
+
Deployment
+
Monitoring

As your applications and teams grow, you can introduce more advanced practices such as:

• Deployment strategies
• Infrastructure as Code
• Security scanning
• Automated rollbacks
• Kubernetes
• Advanced observability
• Multi-environment deployments

The most valuable CI/CD skill is not memorizing a particular tool.

It is understanding the software delivery process and knowing how to automate it safely.

Quick CI/CD Reference

A good beginner goal is simple:

Push code once and let the pipeline do the repetitive work safely.