Course
CI/CD & DevOps Automation
134 lessons across 10 modules
Intermediate, assuming Git, basic Docker, and basic Linux. Every pipeline concept taught once, then built in GitHub Actions, GitLab CI/CD, and Jenkins - followed by automated testing, Docker images, deployment strategies, and pipeline security, ending in a full pipeline from pull request to production. The road is laid out in full; lessons are being written one at a time.
CI/CD Fundamentals
What the three terms mean, and why teams bother
What is CI/CD?
1Automating the path from a commit to running software.
A merge that reaches users without anyone logging into a server
Continuous Integration
2Merging small changes often, each one built and tested automatically.
A broken test caught ten minutes after it was written
Continuous Delivery
3Definition - every change is releasable, and a human decides when.
A release that is one button press away at any moment
Continuous Deployment
4Definition - every change that passes goes to production on its own.
Twenty production releases in one day, none of them manual
CI vs CD
5Where integration ends and delivery begins.
A team doing CI well and still releasing quarterly
Benefits of CI/CD
6Smaller changes, faster feedback, and cheaper failures.
A bug traced to one small commit instead of a month of work
CI/CD Pipeline Lifecycle
7Trigger, run, report, and act on the result.
Following one commit from push to deployment
Build, Test, Package, Deploy
8The four stages nearly every pipeline shares.
The same four stages in a Node, a Python, and a Java project
CI/CD in Modern Software Development
9How pipelines shape branching, reviews, and team habits.
Why trunk-based teams depend on a fast pipeline
CI/CD vs Traditional Deployment
10Release weekends and manual checklists, compared honestly.
The same release done by hand and by pipeline
Git and CI/CD
The branching and review habits a pipeline depends on
Git Fundamentals for CI/CD
11The parts of Git a pipeline actually relies on - commits, refs, and hooks.
Which Git events a pipeline can be triggered by
Branching Strategies
12How long branches live, and what that does to integration.
A two-week branch and the merge conflict it produced
Feature Branch Workflow
13One branch per change, merged through review.
feature, pull request, review, merge, pipeline
Git Flow
14Develop, release, and hotfix branches - and why it has fallen away.
A hotfix that had to be merged into three branches
Trunk-Based Development
15Short-lived branches merged to main daily, kept safe by the pipeline.
Unfinished work merged behind a feature flag
Pull Requests
16The unit of change, and the checks a pipeline runs against it.
A pull request that cannot merge until its checks pass
Code Review
17What humans should review once machines check the rest.
A review focused on design because lint already ran
Merge Strategies
18Merge commits, squash, and rebase - and the history each leaves.
The same branch merged three ways, and the log afterwards
Git Tags and Releases
19Marking a commit as a release, and triggering a pipeline from it.
Pushing a tag that builds and publishes a release
Semantic Versioning
20Major, minor, and patch - and automating the bump.
A version derived from commit messages rather than chosen by hand
CI Pipeline Fundamentals
Every pipeline concept, taught once and tool-free
What is a CI Pipeline?
21An automated sequence that turns a commit into a verdict.
Push, install, lint, test, build, and produce an artifact
Pipeline Stages
22Grouping work into ordered phases, failing fast at the cheap ones.
Lint running before a ten-minute test suite
Jobs and Steps
23A job is an isolated unit of work; steps run inside it in order.
Two jobs that cannot share files without an artifact
Runners and Agents
24The machines that actually execute the jobs.
A hosted runner against one you run yourself
Environment Variables
25Configuring a pipeline without hard-coding values.
One pipeline file serving three environments
Secrets
26The concept - credentials stored apart from code and masked in logs.
A token that shows as *** in the job output
Artifacts
27Files one job produces and a later job or a person consumes.
A build output passed from build to deploy
Pipeline Caching
28Reusing downloads between runs, and what makes a cache key right.
A dependency install falling from three minutes to fifteen seconds
Pipeline Dependencies
29Which jobs wait for which, and running the rest in parallel.
Lint and tests running side by side, build waiting for both
Pipeline Failure Handling
30Failing clearly, retrying only what is genuinely flaky.
A flaky test retried into hiding a real bug
GitHub Actions
The Module 3 concepts, expressed as workflow files
Introduction to GitHub Actions
31CI/CD built into GitHub, driven by YAML in the repository.
A first workflow running on every push
Workflow Files
32The structure of a workflow under .github/workflows.
Reading a real workflow top to bottom
Events and Triggers
33push, pull_request, and the rest - with branch and path filters.
A workflow that skips runs when only docs change
Jobs
34Jobs run in parallel on separate runners by default.
Lint and test as two jobs finishing at the same time
Steps
35Shell commands and actions, run in order within a job.
Checkout, set up Node, install, test
Actions
36Reusable steps from the marketplace - and pinning them to a SHA.
A third-party action pinned so it cannot change underneath you
Runners
37GitHub-hosted runners, their images, and what they cost.
ubuntu-latest against a larger runner for a heavy build
Environment Variables
38env at workflow, job, and step level, and the contexts that fill them.
A variable overridden for one job only
Secrets
39Repository, environment, and organisation secrets.
A production secret available only to the production environment
Artifacts
40Uploading and downloading files between jobs.
A test report attached to the run for later inspection
Caching Dependencies
41The cache action, and setup actions that cache for you.
setup-node caching npm with one extra line
Matrix Builds
42One job definition run across several versions or platforms.
Tests on Node 20, 22, and 24 in parallel
Job Dependencies
43needs, and passing outputs from one job to the next.
A deploy job that waits for tests and reads the build version
Manual Workflows
44workflow_dispatch, with inputs chosen at run time.
A deploy button that asks which environment
Scheduled Workflows
45Cron triggers, and their limits.
A nightly dependency audit that opens an issue on failure
GitLab CI/CD
The same concepts, the GitLab way
Introduction to GitLab CI/CD
46CI/CD built into GitLab, driven by one YAML file.
A first pipeline appearing after one commit
.gitlab-ci.yml
47The structure of the pipeline file, and includes for reuse.
A shared template included by twenty projects
Stages
48Ordered stages, with jobs in a stage running in parallel.
test, build, and deploy as three stages
Jobs
49Jobs, their scripts, and the image each runs in.
A test job running inside a Node image
Runners
50Shared, group, and project runners, and runner tags.
A job routed to a runner with a GPU by tag
Variables
51Predefined, file, project, and group variables.
CI_COMMIT_SHA used to tag a build
Secrets
52Masked and protected variables, and external secret stores.
A deploy key usable only on protected branches
Artifacts
53Artifacts, their expiry, and reports GitLab understands.
A test report rendered inside the merge request
Cache
54Cache keys, and how cache differs from artifacts in GitLab.
node_modules cached per lockfile hash
Pipeline Dependencies
55needs, and the directed acyclic graph it creates.
A pipeline that stops waiting for a whole stage
Rules
56Deciding when a job runs - by branch, path, or variable.
A deploy job that exists only on main
Branch Pipelines
57Pipelines that run for pushes to branches.
Different jobs for feature branches and for main
Merge Request Pipelines
58Pipelines that run against a merge request, and avoiding duplicates.
One pipeline per push instead of two
Manual Jobs
59Jobs that wait for someone to press play.
A production deploy gated behind a manual step
GitLab Environments
60Tracking what is deployed where, with protected environments.
A view showing exactly which commit is in production
Jenkins
The self-hosted classic that many companies still run
What is Jenkins?
61A self-hosted automation server with a huge plugin ecosystem.
Why a company with its own data centre often still runs it
Jenkins Architecture
62The controller, agents, jobs, and plugins as one picture.
Where a build actually runs, and where its state lives
Jenkins Controller and Agents
63Their roles in the architecture - and never building on the controller.
A build on the controller that took the whole server down
Installing Jenkins
64Running Jenkins in a container, with its home directory on a volume.
A Jenkins that survives being recreated
Jenkins Jobs
65The kinds of job, and why pipelines replaced the rest.
The job types compared side by side
Freestyle Projects
66Jobs configured through the UI - and why that does not scale.
A configuration nobody can review or roll back
Jenkins Pipeline
67A pipeline defined as code instead of clicks.
The freestyle job rewritten as a pipeline
Jenkinsfile
68The pipeline kept in the repository, versioned with the code.
A pipeline change reviewed in a pull request
Declarative Pipeline
69The structured syntax most pipelines should use.
Install, test, and build as three declarative stages
Scripted Pipeline
70Groovy with full control, and when that is worth it.
A dynamic set of stages generated in a loop
Credentials
71The credentials store, and binding credentials into a step.
A registry password available only inside one block
Plugins
72The ecosystem - and the upgrade and security burden it brings.
A plugin update that broke three pipelines
Webhooks
73Letting the Git host notify Jenkins instead of polling.
A build starting within seconds of a push
Build Triggers
74Webhooks, schedules, upstream jobs, and manual runs.
A nightly build and an on-push build from one pipeline
Jenkins Agents
75Configuring agents - labels, Docker agents, and ephemeral cloud agents.
A clean container agent created for every build
Automated Testing in CI/CD
The checks that make an automatic release safe
Testing Node.js in depth →Testing Strategy in CI/CD
76Which tests run where, balanced for speed and confidence.
Fast checks on every push, the full suite before a merge
Unit Tests
77The fast, numerous tests that run first.
Thousands of unit tests finishing in under a minute
Integration Tests
78Tests against real dependencies started inside the pipeline.
A PostgreSQL service container spun up for one job
API Tests
79Exercising endpoints the way a client would.
Supertest running against the built API
End-to-End Tests
80A real browser against a deployed build - few and valuable.
A login-to-checkout test run against staging
Code Coverage
81Reporting coverage, and why a coverage target can mislead.
Coverage shown on the pull request, not enforced blindly
Linting
82Style and correctness checks that cost seconds.
A lint failure blocking a merge before any test runs
Static Code Analysis
83Type checks and analysers that find bugs without running code.
A type error caught in CI that the tests missed
Security Scanning
84Scanning source code and its dependencies for known problems.
A vulnerable dependency flagged on the pull request
Quality Gates
85Rules that decide whether a change may proceed.
A merge blocked by one new critical finding
Test Failure Handling
86Reporting failures clearly, and quarantining flaky tests.
A flaky test isolated instead of retried forever
Parallel Testing
87Splitting a slow suite across machines.
A twenty-minute suite split four ways into five minutes
Docker and CI/CD
Building, scanning, and publishing images from a pipeline
The Docker course →Why Use Docker in CI/CD?
88One image built once, tested, and promoted unchanged.
The exact image that passed staging reaching production
Building Docker Images
89Building inside a pipeline, and Docker-in-Docker against BuildKit.
An image built on a runner with no Docker daemon of its own
Dockerfile in CI
90Writing Dockerfiles that build well in a pipeline.
Instruction order changed to keep the cache warm in CI
Docker Build Cache
91Keeping layer cache between runs on ephemeral runners.
A registry-backed cache cutting a build from eight minutes to one
Docker Compose in CI
92Starting a whole stack for integration tests.
An API and its database brought up for one test job
Image Tagging
93Tagging images to match the Git commit and release version.
An image tagged with both its commit SHA and v2.3.1
Container Registry
94Where pipelines push images and deployments pull them.
Choosing a registry that sits close to where you deploy
Docker Hub
95Pushing to Docker Hub from a pipeline, and its pull limits.
A pipeline failing on the anonymous pull rate limit
Amazon ECR
96Pushing to ECR, authenticating with a short-lived token.
A pipeline pushing to ECR with no long-lived keys
GitHub Container Registry
97Images stored beside the code, pushed with the built-in token.
A workflow publishing to ghcr.io with no extra secrets
Image Security Scanning
98Scanning the built image before it can be pushed.
A critical vulnerability in the base image blocking the push
Push Image to Registry
99Pushing only from protected branches, and recording the digest.
Deploying by digest so the image cannot change afterwards
CD and Deployment Strategies
Environments, rollout patterns, and changing a live system safely
Continuous Delivery Pipeline
100Building a delivery pipeline that ends at a release decision.
A pipeline that stops at an approval before production
Continuous Deployment
101Removing the approval, and what must be true before you can.
The test and monitoring maturity automatic releases require
Deployment Environments
102A chain of environments, each a closer copy of production.
One build promoted through four environments
Development Environment
103Fast feedback, deployed on every merge.
A dev environment always running the latest main
QA Environment
104A stable target for testers, updated deliberately.
A QA environment that does not change during a test cycle
Staging Environment
105The last rehearsal - configured as close to production as you can afford.
A bug that only a production-like staging could catch
Production Environment
106Protected, audited, and changed only by the pipeline.
Production credentials that no person holds
Environment Variables
107Per-environment configuration for one immutable build.
The same image with different settings in each environment
Blue-Green Deployment
108Two environments, and switching all traffic at once.
An instant switch back when the new version misbehaved
Rolling Deployment
109Replacing instances a few at a time.
A rollout that paused itself on failing health checks
Canary Deployment
110A small share of traffic first, widened as metrics stay healthy.
Five per cent of users on the new version, then everyone
Feature Flags
111Separating deploying code from releasing a feature.
A feature turned off in seconds without a deployment
Rollbacks
112Returning to the last good version, fast and rehearsed.
A rollback that had never been tried, and did not work
Database Migration in Deployment
113Changing a schema without breaking the version still running.
Expand, migrate, then contract - across three releases
Zero-Downtime Deployment
114Health checks, draining, and compatible changes together.
A release during peak traffic that nobody noticed
Production CI/CD and DevOps Project
Securing and operating pipelines, then building one end to end
Deploying on AWS: the AWS course →CI/CD Security
115A pipeline holds production credentials, so it is an attack target.
A malicious pull request that tried to read deploy secrets
Secrets Management
116Production practice - OIDC, short-lived credentials, and rotation.
A pipeline that deploys without a single stored cloud key
Least Privilege
117Each job allowed only what that job needs.
A test job with no permission to deploy anything
Dependency Security
118Keeping dependencies patched automatically, and reviewing the updates.
Automated update pull requests merged after CI passes
Supply Chain Security
119Pinned actions, SBOMs, signed artifacts, and build provenance.
A compromised third-party action that pinning would have stopped
Pipeline Monitoring
120Tracking duration, failure rate, and flakiness over time.
A pipeline that crept from five minutes to twenty unnoticed
Build Notifications
121Telling the right person, promptly, and only when it matters.
A failure message sent to the commit author, not the whole team
Deployment Notifications
122Announcing what shipped, where, and with which changes.
A channel message listing every change in the release
Pipeline Optimization
123Caching, parallelism, and skipping work that has not changed.
A pipeline cut from twenty-five minutes to six
Self-Hosted Runners
124Running your own runners - cost, control, and the security risks.
An ephemeral runner destroyed after every job
Infrastructure Deployment
125Deploying infrastructure as code through the same pipeline.
A plan shown for review before any change is applied
Production Troubleshooting
126Debugging failed pipelines and failed deployments methodically.
A deploy that passed every check and still broke production
CI/CD Best Practices
127The checklist worth applying to any pipeline.
A real pipeline reviewed against the list
Complete CI/CD Architecture
128Every stage from pull request to production, on one page.
The full pipeline drawn before the project is built
Project - PR Validation and Automated Tests
129Lint, unit, and integration tests gating every pull request.
A pull request that cannot merge until every check is green
Project - Docker Image and Scanning
130Building the Next.js and Express images, and scanning each one.
An image blocked from the registry by a critical finding
Project - Registry and Environment Secrets
131Pushing to the registry, with secrets scoped per environment.
Staging and production each receiving only their own secrets
Project - Staging Deployment
132Every merge to main deployed to staging automatically.
Every merge running in staging within minutes
Project - Production Deployment
133Promotion to production behind an approval, deployed on AWS.
The exact staging image promoted, not rebuilt
Project - Rollback and Notifications
134A rehearsed rollback, and announcements for every deployment.
A bad release rolled back, with the channel told both times