What Is a CI/CD Pipeline? (Explained for Infrastructure People)
BLUF — Bottom Line Up Front
A CI/CD pipeline is a series of automated steps that move code from a developer's commit to a running server — replacing manual file transfers with a repeatable, observable process. To a developer it's a workflow. To an infrastructure person, it's plumbing: runners that consume compute, SSH keys that need managing, and deployment targets that need to be healthy. Understanding it doesn't require learning to write application code. It requires understanding the logistics of how software moves through your infrastructure.
The Problem CI/CD Solves
Before CI/CD, web application deployment was manual and fragile.
The old way. A developer finishes a feature, packages the source code, and transfers it to a production server via FTP or SCP. Maybe the database migration script runs. Maybe it doesn't. When five developers do this independently, they eventually overwrite each other's work, break the production environment, and spend hours diagnosing what amounts to a sequencing problem.
The CI/CD way. Automation owns the deployment process. Code is tested before it reaches a server. Every deployment is logged — who pushed what, when it ran, and exactly why it failed if it did.
For the infrastructure operator, CI/CD means fewer emergency calls about "broken servers" that turn out to be nothing more than a missing dependency or a misconfigured environment variable.
What "Continuous Integration" Actually Means
CI stands for Continuous Integration. When a developer commits code to a repository (GitHub, GitLab, Bitbucket), the CI system automatically triggers a sequence of actions against the new code.
Build. The system compiles the code or pulls in dependencies — Node modules, Python libraries, Go binaries, whatever the project requires.
Test. Automated test scripts run against the code: unit tests for logic correctness, linting for formatting standards, integration tests for cross-component behavior.
Result. If any test fails, the build breaks. The developer is notified immediately. The code stays in the repository and never proceeds.
Infrastructure implication. CI runners are temporary compute resources — VMs or containers that spin up to execute the build, then terminate. As an infrastructure operator, you care about runner resource consumption, runner security (what they can access), and where they run (cloud-hosted vs. self-hosted).
What "Continuous Deployment" and "Continuous Delivery" Actually Mean
CD covers two related but distinct practices.
Continuous Delivery
Code that passes CI testing is packaged into a deployable artifact — a Docker image, a compiled binary, a zip archive — and staged for deployment. A human approves the final push to production. This is standard in regulated industries and enterprise environments with formal change windows.
Continuous Deployment
No human approval step. If the CI phase passes, the code automatically deploys to production. This is appropriate for organizations with high test coverage, mature rollback capabilities, and fast release cycles.
Infrastructure implication. The CD phase is where the pipeline reaches out to your servers. It needs SSH access or an API key to update the deployment target. Managing these credentials as secrets — not hardcoding them in pipeline configuration files — and ensuring deployment targets are in a healthy state before deployment proceeds are infrastructure responsibilities.
What a Pipeline Actually Looks Like
A typical GitHub Actions workflow deploying to a VPS:
- Push. Developer runs
git push. GitHub receives the commit. - Trigger. GitHub detects a
.github/workflows/deploy.ymlfile and queues a workflow run. - Runner. GitHub spins up a runner VM in their infrastructure.
- Build and test. The runner pulls the repository, installs dependencies, and runs the test suite.
- Deploy. If tests pass, the runner uses a stored SSH key to connect to the VPS, pulls the latest code, and restarts the application service.
Developer pushes → GitHub Actions triggers → Tests run → SSH to VPS → App updated
If tests fail at step 4, step 5 never executes. Production is unchanged.
How to Lab a CI/CD Pipeline Without a Team
A functional pipeline requires three components and costs under $10/month.
Source control and pipeline: GitHub with GitHub Actions. Free for public repositories, free tier covers most personal projects on private repos.
Deployment target: A VPS — Contabo entry tier at approximately $4.50–7/month provides a stable deployment target with full SSH access.
The project: The application code is secondary. A boilerplate web project or a basic Python script is sufficient. The goal is learning to manage SSH keys as pipeline secrets, write the YAML configuration file that instructs the runner, and diagnose why a deployment step hangs or fails.
For a full lab architecture mapping all components: How to Lab the Full Dev Stack Without Buying Hardware For the decision on which components to self-host vs. manage: How to Lab the Full Stack Without Buying Hardware (What Goes Where)
CI/CD Tools Landscape
GitHub Actions is the right starting point for most operators. It's built into the platform where code already lives, requires no infrastructure to manage, and has extensive documentation for common deployment patterns.
GitLab CI is prevalent in enterprise environments that self-host their entire development stack. More configurable than GitHub Actions, more operational overhead to manage.
Jenkins is the grandfather of CI/CD — extraordinarily flexible, notoriously complex. Running Jenkins means managing the Jenkins server itself, its plugins, and its update cycle. Justified at enterprise scale or for specific compliance requirements; overkill for most lab environments.
CircleCI / Travis CI are dedicated pipeline platforms. They add cost without adding capability that GitHub Actions or GitLab CI don't cover for most use cases.
FAQ
Do I need to know how to code to set up a CI/CD pipeline? You need to be comfortable with YAML (the pipeline configuration format) and basic terminal commands. You don't need to be a software engineer. The skills required — file paths, environment variables, SSH key management, service restarts — are standard infrastructure operations work.
What's the infrastructure cost to run a personal CI/CD setup? The pipeline itself is near-zero using GitHub Actions' free tier. The only real cost is the deployment target — a VPS starting around $4.50–7/month. Total for a functional personal pipeline: under $10/month.
How is a CI/CD runner different from just running a deployment script? A manual script is a pull process you trigger yourself. A runner is an automated push process triggered by an event — a code commit, a pull request merge, a scheduled time. Runners also execute in a clean, reproducible environment each time and produce detailed structured logs. A manual script runs in whatever environment state exists at the moment you run it, with whatever logging you remembered to add.
Related: