How code gets built, tested, and shipped-from single pipelines to enterprise release trains.
How code gets built, tested, and shipped-from single pipelines to enterprise release trains.
Lesson outline
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.
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 buildThis workflow runs automatically on every push and pull request, ensuring code is always tested and buildable.
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.
Code is always deployable, but a human approves the release.
Passing pipeline automatically ships to production.
A typical CI/CD pipeline has four main stages that run automatically on every code change.
Compile code, install dependencies, create artifacts (containers, packages)
Run unit, integration, E2E tests, plus linters and security scanners
Push artifacts to registries (Docker Hub, ECR, ACR, Artifact Registry)
Roll out to staging, then production (blue/green, canary, rolling)
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.
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
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.
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
| Category | AWS | Azure | GCP |
|---|---|---|---|
| Pipeline Orchestration | CodePipeline | Azure Pipelines | Cloud Build |
| Build Service | CodeBuild | Azure Pipelines (hosted agents) | Cloud Build |
| Deployment Service | CodeDeploy | Azure Pipelines (deployment tasks) | Cloud Deploy |
| Container Registry | ECR (Elastic Container Registry) | ACR (Azure Container Registry) | Artifact Registry |
| Source Control Integration | CodeCommit, GitHub, Bitbucket | Azure Repos, GitHub, GitLab | Cloud Source Repositories, GitHub, GitLab |
| Serverless CI/CD | CodePipeline + Lambda | GitHub Actions (Azure-hosted) | Cloud Build (serverless) |
Many teams choose third-party CI/CD platforms that work across all cloud providers. These tools offer unique advantages and vendor independence.
Deep GitHub integration
.github/workflows/)Complete DevOps platform
.gitlab-ci.ymlOpen-source veteran
Speed & developer experience
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.
Related concepts
Explore topics that connect to this one.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.