CI/CD Explained: Build a Simple Pipeline Today

CI and CD are two of the most overloaded acronyms in software. Ask five engineers what they mean and you will get five slightly different answers, most of them wrapped in dashboards and pipeline YAML. Strip away the tooling and the ideas are simple: CI makes sure your code is healthy every time it changes, and CD gets that healthy code somewhere useful automatically. This post walks through a minimal pipeline you can build today with nothing more than a Git repository and one small server.

What CI Actually Does

Continuous integration means merging code changes into a shared branch frequently and verifying each change automatically. Before CI, teams hit a "merge hell" where integration happened rarely and painfully. CI inverts that: you push often, and a machine checks your work every time.

• A commit triggers the pipeline.
• The pipeline runs checks: lint, tests, build.
• A failing check blocks the merge until fixed.
• The result becomes the shared truth for everyone.

The value is not the tools. It is the cadence. Small, frequent, verifiable changes mean the shared branch is always in a working state, and debugging a bad merge is a non-event because you know exactly which commit broke it.

What CD Means (and Does Not)

Continuous delivery means every change that passes CI is ready to deploy to production at the push of a button. Deployment itself may still be manual, but the release is always *releasable*. Continuous deployment goes one step further and deploys every passing change automatically, no human approval.

For a solo project or a small team, you rarely need full continuous deployment at first. Getting CI solid, then adding a manual deploy step, is the honest path. Automation that rolls out broken code because nobody looked is worse than no automation.

A Minimal Pipeline You Can Build Today

You do not need a heavy CI platform to start. A single small VPS can host a runner that watches a repo and runs your checks. On Netbay you can spin up an Ubuntu instance in under a minute and turn it into a build box with nothing but Git, a shell script, and a cron entry or a webhook.

# install the build tools you actually need
sudo apt-get update
sudo apt-get install -y git build-essential

# clone the repo once onto the runner
git clone https://example.com/team/app.git /opt/app

The simplest correct pipeline is a script that the runner executes on every push. It does not need to be fancy, it needs to be repeatable.

#!/bin/bash
set -euo pipefail
cd /opt/app
git pull --ff-only origin main
npm ci
npm run lint
npm test
npm run build
echo "checks passed for $GIT_BRANCH"

That script is your entire pipeline: pull, install, lint, test, build. The set -euo pipefail line makes any failing command stop the run, so a broken check fails loudly. Put it in ci.sh, make it executable, and have your webhook or cron run it on every push. Later you can graduate to a hosted CI service and translate the same steps into YAML.

How This Maps to a Real Flow

The diagram shows the shape almost every pipeline settles on. The left side runs on every push and must be fast. The right side moves an artifact to environments, and how automatic it is depends on your risk tolerance.

• **Left side (CI):** run every push, keep under a few minutes, block merges.
• **Middle:** store the artifact once, never rebuild per environment.
• **Right side (CD):** deploy to staging on every push; production can be gated.

Where the Checks Run Matters

Whether your checks run on hosted runners or a box you control changes your infrastructure. A hosted CI service is convenient and often free, but you hand your source code and secrets to a third party. A self-hosted runner on your own VPS keeps everything inside your perimeter, which matters for private codebases and compliance. You can start with one runner on a modest Netbay instance and scale up as your test suite grows.

Takeaway

CI/CD is a discipline more than a product. Start with a single shell script that pulls, checks, and builds your code on every push, then layer on environments and approval gates as you gain confidence. You do not need a complex platform on day one.

You can build runners and test environments on a Netbay VPS in under a minute and follow this whole flow hands-on — spin one up at netbayhosts.in.