You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
What is CI/CD
What is CI/CD
CI/CD stands for Continuous Integration, Continuous Delivery, and Continuous Deployment. Together, these practices form the backbone of modern software development, enabling teams to deliver code changes frequently, reliably, and with minimal manual intervention.
A Brief History
- 2000 — Kent Beck popularises Continuous Integration as part of Extreme Programming (XP)
- 2006 — Martin Fowler publishes his seminal article on Continuous Integration
- 2010 — Jez Humble and David Farley publish Continuous Delivery, defining the practice
- 2011 — Jenkins (forked from Hudson) becomes the most popular open-source CI server
- 2014 — Docker revolutionises CI/CD with containerised build environments
- 2018 — GitHub Actions launches, bringing CI/CD directly into source control platforms
- 2020s — GitOps, platform engineering, and AI-assisted pipelines reshape the CI/CD landscape
- Today — CI/CD is considered a fundamental practice in every software organisation
The Three Pillars
1. Continuous Integration (CI)
Continuous Integration is the practice of merging code changes into a shared branch frequently — ideally several times per day — and running automated checks on every change.
Key principles:
- Developers commit to the main branch (or short-lived feature branches) regularly
- Every commit triggers an automated build and test suite
- Broken builds are fixed immediately — the build must always be in a working state
- Integration problems are detected early, when they are cheap to fix
2. Continuous Delivery (CD)
Continuous Delivery extends CI by ensuring the software is always in a releasable state. Every change that passes automated testing can be deployed to production with a single manual approval.
Key principles:
- The deployment pipeline automates building, testing, and staging
- Production releases require a deliberate human decision (e.g., clicking a button)
- Rollbacks are fast and reliable
- Any commit that passes all stages is a release candidate
3. Continuous Deployment
Continuous Deployment goes one step further: every change that passes all automated stages is automatically deployed to production without human intervention.
Key principles:
- Full trust in the automated pipeline
- Feature flags control visibility, not deployment
- Monitoring and alerting are critical safety nets
- Common at companies like Netflix, Etsy, and GitHub
CI vs CD vs Continuous Deployment
| Aspect | Continuous Integration | Continuous Delivery | Continuous Deployment |
|---|---|---|---|
| Goal | Detect integration issues early | Keep software releasable | Deploy every passing change |
| Automation | Build + test | Build + test + staging | Build + test + staging + production |
| Human gate | Fix broken builds | Approve production release | None — fully automated |
| Risk level | Low | Medium | Higher (requires strong tests) |
| Adoption | Very common | Common | Less common |
Why CI/CD Matters
Faster Feedback Loops
Without CI/CD:
Developer writes code → waits days → manual testing → finds bugs → rework
With CI/CD:
Developer pushes code → automated build (minutes) → tests run → instant feedback
Reduced Risk
Small, frequent releases are far less risky than large, infrequent releases:
| Release Strategy | Batch Size | Risk per Release | Rollback Difficulty |
|---|---|---|---|
| Monthly release | Large | High | Very difficult |
| Weekly release | Medium | Medium | Moderate |
| CI/CD (daily+) | Small | Low | Easy |
Business Benefits
- Faster time to market — features reach users sooner
- Higher quality — automated testing catches regressions
- Lower costs — less manual testing, fewer production incidents
- Developer satisfaction — less toil, more shipping
The CI/CD Pipeline
A typical CI/CD pipeline consists of several stages:
┌──────────┐ ┌───────┐ ┌──────┐ ┌─────────┐ ┌────────────┐
│ Source │───▶│ Build │───▶│ Test │───▶│ Staging │───▶│ Production │
│ (commit) │ │ │ │ │ │ │ │ │
└──────────┘ └───────┘ └──────┘ └─────────┘ └────────────┘
| Stage | What Happens | Typical Tools |
|---|---|---|
| Source | Code is committed / PR is opened | Git, GitHub, GitLab |
| Build | Code is compiled, dependencies resolved, artefacts created | npm, Maven, Docker |
| Test | Unit tests, integration tests, linting, security scans | Jest, pytest, ESLint |
| Staging | Deploy to a pre-production environment for validation | Kubernetes, AWS, Terraform |
| Production | Deploy to live users | Kubernetes, Argo CD, Spinnaker |
Core Concepts
Pipeline
A pipeline is the complete end-to-end workflow from code commit to production deployment. It defines the stages, jobs, and steps that every change must pass through.
Artefacts
Artefacts are the outputs of a build — compiled binaries, Docker images, bundled JavaScript files, or any deployable package.
Triggers
Pipelines are triggered by events:
- Push to a branch — most common trigger
- Pull request opened or updated — for pre-merge validation
- Scheduled (cron) — nightly builds or periodic scans
- Manual — on-demand runs for specific tasks
Environments
CI/CD pipelines typically deploy to multiple environments:
| Environment | Purpose |
|---|---|
| Development | Individual developer testing |
| CI | Automated build and test |
| Staging | Pre-production mirror |
| Production | Live users |
Popular CI/CD Tools
| Tool | Type | Best For |
|---|---|---|
| GitHub Actions | Cloud-hosted | GitHub-centric workflows |
| GitLab CI/CD | Cloud / self-hosted | All-in-one DevOps platform |
| Jenkins | Self-hosted | Maximum flexibility / legacy |
| CircleCI | Cloud-hosted | Speed and Docker workflows |
| Azure DevOps | Cloud / self-hosted | Microsoft ecosystem |
| AWS CodePipeline | Cloud-hosted | AWS-native deployments |
| Argo CD | Self-hosted | GitOps / Kubernetes |
Tip: You do not need to adopt Continuous Deployment immediately. Start with Continuous Integration, then progress to Continuous Delivery, and only move to Continuous Deployment when your test coverage and monitoring are mature.
Summary
CI/CD is the practice of automating the integration, testing, and deployment of software. Continuous Integration catches bugs early by running automated tests on every commit. Continuous Delivery ensures software is always releasable. Continuous Deployment takes this further by automatically deploying every passing change. Together, these practices reduce risk, accelerate delivery, and improve software quality. In the following lessons, we will explore each component of a CI/CD pipeline in detail.