LFCA 82 🐧 CI/CD — Concepts and Pipelines
Continuous Integration and Continuous Delivery are the two practices that turn DevOps from a philosophy into a workflow. They are the engine of the software delivery pipeline: the automated system that takes code from a developer’s commit and moves it, step by step, toward production.
The LFCA exam places CI/CD under DevOps Fundamentals, which carries 12–16% of the total weight. The study plan lists “DevOps Basics” and “Deployment Environments” as core topics. The exam expects you to understand the difference between CI, Continuous Delivery, and Continuous Deployment, and to know the stages of a pipeline and what each stage verifies.
Key point: CI and CD are not the same thing. CI is the practice of merging code frequently and verifying it with automated builds and tests. CD is the practice of keeping that verified code always ready for deployment, and automating the path to production. Some teams stop at Continuous Delivery, where a human approves the final deployment. Others practice Continuous Deployment, where every change that passes the pipeline goes to production automatically. The distinction matters for understanding risk and governance .
Why CI/CD exists
A manual release process does not scale. It is slow, error-prone, and impossible to reproduce. CI/CD replaces the manual process with an automated pipeline that runs the same steps every time.
The integration problem. Without CI, developers work on long-lived branches and merge them at the end of a release cycle. The merges are painful because the branches have diverged. CI requires developers to merge into a shared trunk frequently, at least daily. The automated build and test run on every merge, so integration problems are discovered in hours, not weeks .
The quality problem. A manual release process cannot run the full test suite on every change. CI runs the tests automatically. A failing test blocks the pipeline. The developer who wrote the code gets feedback within minutes, while the change is still fresh in their mind .
The release problem. Continuous Delivery ensures that the code is always in a deployable state. The artifact that passes the pipeline is the same artifact that goes to production. There is no “rebuild for production” step that introduces differences. The deployment is a release of a versioned, tested artifact .
The risk problem. Small, frequent releases are safer than large, infrequent ones. If something breaks, the change set is small and the cause is easier to identify. Rollback is faster because the previous version is a known artifact. The DORA metrics measure this: deployment frequency, lead time for changes, mean time to recovery, and change failure rate .
The trade-off. CI/CD requires investment. The pipeline must be built, maintained, and secured. The tests must be reliable. A flaky test that fails intermittently erodes trust in the pipeline. The team must treat test reliability as real engineering work. The investment pays back in speed, quality, and lower deployment risk .
a. Continuous Integration (CI)
Continuous Integration is the practice of merging all developers’ working copies to a shared mainline several times a day. Each merge triggers an automated build and test sequence. The goal is to detect integration errors as quickly as possible .
The CI pipeline typically runs these stages:
Source. The developer pushes code to the repository. The push triggers the pipeline. The source stage checks out the code at the specific commit .
Build. The code is compiled and packaged into an artifact. The artifact might be a JAR file, a Docker image, a ZIP archive, or a binary. The build is deterministic: the same source produces the same artifact every time .
Test. The automated tests run. The test suite includes unit tests, integration tests, and sometimes end-to-end tests. The tests verify that the code behaves as expected. A failing test fails the pipeline .
Static Analysis. The code is scanned for style violations, security vulnerabilities, and dependency issues. Tools like linters, SAST scanners, and dependency checkers run in this stage. The results are reported to the developer .
Package. The verified artifact is versioned and stored in a registry or artifact repository. The version is tied to the commit SHA or a semantic version number. The artifact is immutable: it is never rebuilt for a different environment .
The CI stage is the gate. If any step fails, the pipeline stops, and the developer is notified. The failure is the feedback. The goal is to never merge code that does not pass the gate.
b. Continuous Delivery (CD)
Continuous Delivery extends CI. Every change that passes the CI pipeline is automatically deployed to a production-like environment. The code is always in a deployable state. The actual deployment to production may require a manual approval, but the path to production is automated .
The CD pipeline adds these stages:
Deploy to Staging. The artifact is deployed to a staging environment that mirrors production. The deployment is automated. The environment is used for final validation before production .
Acceptance Tests. The tests that run in staging verify the application in an environment that is as close to production as possible. The tests may include smoke tests, API contract tests, and performance tests .
Approval. In Continuous Delivery, a human approves the promotion to production. The approval is a governance gate. The approver reviews the staging deployment and the test results. If the approval is granted, the pipeline proceeds to production .
Deploy to Production. The artifact is deployed to production. The deployment strategy determines how the new version replaces the old one. Blue-green deployments and canary releases are common strategies for reducing risk .
Verify. After deployment, the pipeline verifies that the application is healthy. The verification might include health checks, smoke tests, and monitoring alerts. If the verification fails, the pipeline can trigger a rollback .
Continuous Delivery is the practice of keeping the code ready. The deployment is a business decision, not a technical one. The technical risk is already managed by the pipeline. The remaining decision is when to release.
c. Continuous Deployment
Continuous Deployment is the next step. In Continuous Deployment, every change that passes the pipeline is deployed to production automatically. There is no manual approval. The pipeline is the only gate .
Continuous Deployment requires robust automated testing and advanced process planning. It is not appropriate for every team. The teams that practice it have invested heavily in test reliability, monitoring, and rollback automation. They deploy multiple times per day, and the deployment process is so reliable that manual approval would be a bottleneck .
The difference between Continuous Delivery and Continuous Deployment is the approval gate. Continuous Delivery has one. Continuous Deployment does not. Both require the same automated pipeline. The difference is where the human decision sits .
Complete Example Session
This session demonstrates a CI/CD pipeline using GitHub Actions and Docker.
# ============================================
# PART 1: THE CI PIPELINE
# ============================================
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 22
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Run linter
run: npm run lint
- name: Run unit tests
run: npm test -- --coverage
- name: Build application
run: npm run build
- name: Build Docker image
run: docker build -t my-app:${{ github.sha }} .
- name: Run integration tests
run: |
docker run -d -p 3000:3000 my-app:${{ github.sha }}
sleep 5
npm run test:integration
# ============================================
# PART 2: THE CD PIPELINE
# ============================================
# .github/workflows/cd.yml
name: CD
on:
workflow_run:
workflows: [CI]
types: [completed]
branches: [main]
jobs:
deploy-staging:
if: ${{ github.event.workflow_run.conclusion == 'success' }}
runs-on: ubuntu-latest
environment: staging
steps:
- name: Deploy to staging
run: |
kubectl apply -f k8s/staging/
- name: Run smoke tests
run: npm run test:smoke
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment: production
steps:
- name: Deploy to production
run: |
kubectl apply -f k8s/production/
- name: Verify deployment
run: |
kubectl rollout status deployment/my-app
- name: Run health checks
run: npm run test:healthThe CI pipeline runs on every push and pull request. It checks out the code, installs dependencies, runs the linter, runs the unit tests, builds the application, builds the Docker image, and runs the integration tests. If any step fails, the pipeline stops .
The CD pipeline runs after the CI pipeline completes successfully on the main branch. It deploys to staging, runs smoke tests, and then deploys to production. The production deployment uses the same artifact that was built in CI .
# ============================================
# PART 3: THE DEPLOYMENT MANIFEST
# ============================================
# k8s/production/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
labels:
app: my-app
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-registry/my-app:${{ github.sha }}
ports:
- containerPort: 3000
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 15
periodSeconds: 20The deployment manifest uses a RollingUpdate strategy. The maxSurge: 1 and maxUnavailable: 0 settings ensure that the new version is deployed one pod at a time, and no pods are taken down until the new ones are healthy. The readiness and liveness probes verify that the application is running correctly .
# ============================================
# PART 4: THE PIPELINE STAGES IN PRACTICE
# ============================================
# Developer pushes code
git push origin main
# CI pipeline triggers
# 1. Source: checkout the code
# 2. Build: npm ci, npm run build
# 3. Test: npm test
# 4. Static analysis: npm run lint
# 5. Package: docker build, docker push
# CI pipeline succeeds
# CD pipeline triggers
# 1. Deploy to staging
# 2. Run smoke tests
# 3. Wait for approval (Continuous Delivery)
# 4. Deploy to production
# 5. Verify healthThe pipeline runs the same steps every time. The artifact that was tested is the artifact that is deployed. The developer gets feedback within minutes of the push .
# ============================================
# PART 5: THE DORA METRICS
# ============================================
# The pipeline collects metrics:
# - Deployment frequency: how often code is deployed
# - Lead time for changes: time from commit to production
# - Mean time to recovery: time to recover from a failure
# - Change failure rate: percentage of deployments that fail
# These metrics measure the performance of the CI/CD pipeline.
# The goal is to improve them over time.The DORA metrics are the standard measure of DevOps performance. The pipeline should collect and report them .
Quick Reference
The CI/CD Concepts
| Concept | Definition |
|---|---|
| Continuous Integration | Merge code frequently, verify with automated build and test |
| Continuous Delivery | Keep code always deployable, automate the path to production, human approves final deployment |
| Continuous Deployment | Every change that passes the pipeline goes to production automatically |
The Pipeline Stages
| Stage | Purpose |
|---|---|
| Source | Checkout code at the commit |
| Build | Compile and package the artifact |
| Test | Run automated tests |
| Static Analysis | Scan for style, security, and dependency issues |
| Package | Version and store the artifact |
| Deploy Staging | Deploy to a production-like environment |
| Acceptance Tests | Verify in the staging environment |
| Approval | Human gate (Continuous Delivery only) |
| Deploy Production | Deploy to production |
| Verify | Health checks and smoke tests |
The Deployment Strategies
| Strategy | Behavior |
|---|---|
| RollingUpdate | Replace pods gradually |
| Blue-Green | Run two identical environments, switch traffic |
| Canary | Route a subset of traffic to the new version |
The DORA Metrics
| Metric | Definition |
|---|---|
| Deployment frequency | How often code is deployed |
| Lead time for changes | Time from commit to production |
| Mean time to recovery | Time to recover from a failure |
| Change failure rate | Percentage of deployments that cause a failure |
The Tools
| Category | Tools |
|---|---|
| CI/CD | GitHub Actions, GitLab CI, Jenkins, Azure Pipelines |
| Artifact Registry | Docker Hub, Amazon ECR, Azure Container Registry |
| Deployment | Kubernetes, AWS CodeDeploy, Argo CD |
Best Practices
✅ Do This:
# Run CI on every push and pull request
on:
push:
branches: [main]
pull_request:
branches: [main] # ✅# Build the artifact once, deploy the same artifact everywhere
docker build -t my-app:${{ github.sha }} . # ✅# Use environment protection rules for production
environment: production # ✅# Run health checks after deployment
kubectl rollout status deployment/my-app # ✅# Use declarative manifests for Kubernetes
kubectl apply -f k8s/production/ # ✅❌ Don’t Do This:
# Don't rebuild the artifact for each environment
docker build -t my-app:prod . # after building for staging # ❌# Don't skip tests for speed
# run: npm test -- --passWithNoTests # ❌# Don't deploy on Friday afternoon without monitoring
# The pipeline should be reliable, but incidents are worse on weekends # ❌# Don't store secrets in the pipeline file
env:
DB_PASSWORD: "hardcoded" # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Flaky tests | Non-deterministic tests | Treat test reliability as engineering work |
| Environment drift | Staging diverges from production | Use Infrastructure as Code |
| No rollback path | Never tested | Automate rollback, keep previous artifacts |
| Secrets in pipeline | Convenience | Use a vault, OIDC authentication |
| Slow pipeline | Too many stages | Parallelize, cache dependencies |
Real-World Examples
1. CI Trigger
on: [push, pull_request]2. Build Artifact
docker build -t my-app:${{ github.sha }} .3. Run Tests
npm test4. Static Analysis
npm run lint5. Deploy to Staging
kubectl apply -f k8s/staging/6. Manual Approval
environment: production7. Deploy to Production
kubectl apply -f k8s/production/8. Rollback
kubectl rollout undo deployment/my-app9. DORA Metrics
# Deployment frequency, lead time, MTTR, change failure rate10. Artifact Registry
docker push my-registry/my-app:${{ github.sha }}Visual
The CI/CD Pipeline
┌──────────────────────────────────────────────┐
│ CI/CD PIPELINE │
│ │
│ Source ──> Build ──> Test ──> Package │
│ │ │
│ └──> Static Analysis │
│ │
│ CONTINUOUS DELIVERY │
│ ──────────────────── │
│ Deploy Staging ──> Acceptance Tests │
│ │ │
│ ▼ │
│ Approval (human gate) │
│ │ │
│ ▼ │
│ Deploy Production ──> Verify │
│ │
│ CONTINUOUS DEPLOYMENT │
│ ──────────────────── │
│ Deploy Production (no gate) │
│ │
└──────────────────────────────────────────────┘The CI/CD Difference
┌──────────────────────────────────────────────┐
│ CI │
│ Merge code frequently │
│ Automated build and test │
│ Feedback in minutes │
│ │
│ CD (Delivery) │
│ Always deployable │
│ Automated path to production │
│ Human approves final deployment │
│ │
│ CD (Deployment) │
│ Every change goes to production │
│ No manual approval │
│ Requires robust testing and monitoring │
│ │
└──────────────────────────────────────────────┘The Deployment Strategies
┌──────────────────────────────────────────────┐
│ ROLLING UPDATE │
│ Replace pods one at a time │
│ maxSurge: 1, maxUnavailable: 0 │
│ │
│ BLUE-GREEN │
│ Two identical environments │
│ Switch traffic from blue to green │
│ │
│ CANARY │
│ Route 5% of traffic to new version │
│ Gradually increase │
│ │
└──────────────────────────────────────────────┘The DORA Metrics
┌──────────────────────────────────────────────┐
│ DORA METRICS │
│ │
│ Deployment frequency: │
│ How often code is deployed │
│ │
│ Lead time for changes: │
│ Time from commit to production │
│ │
│ Mean time to recovery: │
│ Time to recover from a failure │
│ │
│ Change failure rate: │
│ Percentage of deployments that fail │
│ │
└──────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Continuous Integration | Merge frequently, automated build and test |
| Continuous Delivery | Always deployable, human approves final deployment |
| Continuous Deployment | Every change goes to production automatically |
| Pipeline stages | Source, Build, Test, Static Analysis, Package, Deploy |
| Deployment strategies | RollingUpdate, Blue-Green, Canary |
| DORA metrics | Deployment frequency, lead time, MTTR, change failure rate |
| Key tools | GitHub Actions, GitLab CI, Jenkins, Azure Pipelines |
| LFCA weight | DevOps Fundamentals, 12–16% |
Key takeaways:
- CI is the practice of merging code frequently and verifying it with automated builds and tests. The goal is to detect integration errors quickly. The feedback loop is measured in minutes, not weeks .
- Continuous Delivery extends CI by keeping the code always ready for deployment. The path to production is automated, but a human approves the final deployment. The code is always in a deployable state .
- Continuous Deployment removes the human approval. Every change that passes the pipeline goes to production. It requires robust testing, monitoring, and rollback automation .
- The pipeline stages are Source, Build, Test, Static Analysis, Package, and Deploy. Each stage is a gate. If a stage fails, the pipeline stops, and the developer is notified .
- The artifact is built once and deployed everywhere. The same Docker image or JAR file that passes the CI pipeline is the one that goes to staging and production. It is never rebuilt for a different environment .
- The DORA metrics measure CI/CD performance. Deployment frequency, lead time for changes, mean time to recovery, and change failure rate. The goal is to improve them over time .
- The LFCA exam tests the difference between CI, Continuous Delivery, and Continuous Deployment. The distinction is the approval gate and the scope of automation .
Remember: CI/CD is the automated pipeline that takes code from a commit to production. CI merges and verifies. CD keeps the code ready and automates the path. Continuous Deployment removes the human gate. The pipeline runs the same steps every time. The artifact is built once and deployed everywhere. The DORA metrics measure the performance. The goal is to deliver value faster, with less risk, and with more confidence.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!