Back

What is CI/CD?

How code gets built, tested, and shipped-from single pipelines to enterprise release trains.

Continuous Integration (CI)

Continuous Integration (CI) means merging code changes often and automatically running builds and tests. Every commit triggers a pipeline that compiles the code, runs unit tests, and may run linting or security checks.

Key principle: Catch problems early. When CI is healthy, a broken test is treated as an emergency-the team fixes main before adding new work.

⚑

The CI Mindset

When CI is healthy, a broken test is treated as an emergency. The team fixes main before adding new work. This discipline turns the pipeline into a safety net: if it's green, everyone trusts that shipping is safe.

Example: Simple GitHub Actions Workflow

name: CI Pipeline

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Build
        run: npm run build

This workflow runs automatically on every push and pull request, ensuring code is always tested and buildable.

CI/CD Pipeline FlowGit CommitCode PushContinuous Integration (CI)BuildCompile CodeTestRun TestsLintCode QualityArtifactReady for DeploymentContinuous Deployment (CD)StagingProductionTests FailFix & RetryRe-run Pipeline

Continuous Delivery vs. Continuous Deployment

Continuous Delivery (CD): Code is always in a deployable state. Automated checks give confidence, but a human presses the deploy button.

Continuous Deployment: One step further-passing the pipeline automatically ships to production. No human approval needed.

Most teams start with continuous delivery for safety, then move to continuous deployment once they trust their pipeline.

Continuous Delivery

Code is always deployable, but a human approves the release.

πŸ‘€Human in the loop

Continuous Deployment

Passing pipeline automatically ships to production.

πŸ€–Fully automated

Pipeline stages: build, test, package, deploy

A typical CI/CD pipeline has four main stages that run automatically on every code change.

1

Build

Compile code, install dependencies, create artifacts (containers, packages)

2

Test

Run unit, integration, E2E tests, plus linters and security scanners

3

Package

Push artifacts to registries (Docker Hub, ECR, ACR, Artifact Registry)

4

Deploy

Roll out to staging, then production (blue/green, canary, rolling)

Real-world scenario: failing tests block a release

Expert scenario

Scenario: A feature branch passes local tests, but when merged to main the CI pipeline fails during integration tests.

Decision: Instead of bypassing the pipeline, the team treats the red build as the highest priority. They revert or fix the change before merging new work, keeping main always green and deployable.

This discipline turns the pipeline into a safety net: if it is green, everyone trusts that shipping is safe.

CI/CD and team workflows

Healthy CI/CD pipelines shape how teams work: small pull requests, trunk‑based development, and frequent deploys reduce risk compared to big‑bang releases.

In cloud environments, pipelines also manage infrastructure changes (IaC). Tools like Terraform, Pulumi, or CloudFormation run inside the same CI/CD system, so app and infra changes ship together in a repeatable way.

πŸ“¦

Small PRs

Easier to review

🌳

Trunk-based

Main branch always deployable

πŸš€

Frequent deploys

Less risk than big releases

πŸ—οΈ

Infrastructure as Code (IaC)

Pipelines also manage infrastructure changes. Tools like Terraform, Pulumi, or CloudFormation run in the same CI/CD system, so app and infra changes ship together in a repeatable way.

CI/CD tools across cloud providers

Each major cloud provider offers managed CI/CD services. Understanding the options helps you choose the right tools for your team and integrate with cloud-native services.

Managed CI/CD Services Comparison

CategoryAWSAzureGCP
Pipeline OrchestrationCodePipelineAzure PipelinesCloud Build
Build ServiceCodeBuildAzure Pipelines (hosted agents)Cloud Build
Deployment ServiceCodeDeployAzure Pipelines (deployment tasks)Cloud Deploy
Container RegistryECR (Elastic Container Registry)ACR (Azure Container Registry)Artifact Registry
Source Control IntegrationCodeCommit, GitHub, BitbucketAzure Repos, GitHub, GitLabCloud Source Repositories, GitHub, GitLab
Serverless CI/CDCodePipeline + LambdaGitHub Actions (Azure-hosted)Cloud Build (serverless)

Third-party CI/CD platforms: GitHub Actions, GitLab CI, and more

Many teams choose third-party CI/CD platforms that work across all cloud providers. These tools offer unique advantages and vendor independence.

πŸ™

GitHub Actions

Deep GitHub integration

  • βœ“Workflows as code (YAML in .github/workflows/)
  • βœ“Massive marketplace of pre-built actions
  • βœ“Free minutes for public repos
  • βœ“CI/CD lives right next to your code
🦊

GitLab CI

Complete DevOps platform

  • βœ“Everything in one place (Git, CI/CD, registry, PM)
  • βœ“Advanced features: parallel jobs, matrix builds
  • βœ“Powerful caching and artifact management
  • βœ“Config file: .gitlab-ci.yml
πŸ‘¨β€πŸ”§

Jenkins

Open-source veteran

  • βœ“Highly customizable with 1000+ plugins
  • βœ“Run on your own infrastructure (full control)
  • βœ“Free to run at any scale
  • βœ“Requires more setup and maintenance
β­•

CircleCI

Speed & developer experience

  • βœ“Fast builds with intelligent caching
  • βœ“Excellent Docker support
  • βœ“Reliable and performant
  • βœ“Great for containerized applications
πŸ”“

Vendor Independence

Your CI/CD logic isn't locked to one cloud provider. Deploy to AWS, Azure, GCP, or on-premises from the same pipelineβ€”making multi-cloud strategies much easier.

Sign in to track progress on your dashboard.

Ready to see how this works in the cloud?

Switch to Career Paths on the Academy page for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths