I used to deploy code by SSHing into a server, pulling the latest changes, and running pm2 restart app. Every time. Manually. And every time I held my breath until the app came back online.
Then one Friday evening, I pushed a change that broke the build. The app went down. I was alone, in a panic, trying to remember what the rollback steps were. I didn't have any. That night cost me three hours and aged me considerably. It's also the night I decided to learn CI/CD properly — not just what the acronym stood for, but how to actually set it up and trust it.
What Is CI/CD?
CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). These are two related but distinct practices that together form the backbone of modern software delivery.
Continuous Integration (CI) is the practice of frequently merging code changes into a shared repository — multiple times a day — with each merge triggering an automated build and test process. The goal is to catch integration problems early, when they're cheap to fix, rather than at release time, when they're expensive and you're already exhausted.
Continuous Delivery (CD) extends CI by automating the preparation and staging of code for release. After CI validates the code, CD automatically deploys it to a staging environment where further testing can happen. The release to production still requires a manual approval step — a human checkpoint before real users are affected.
Continuous Deployment removes that last manual step: every change that passes all automated tests goes straight to production automatically. Companies like Netflix and Amazon deploy to production thousands of times per day using this approach. That's not recklessness — it's confidence built through automation.
The Pipeline: Stages of Automation
A CI/CD pipeline is a series of automated stages that code passes through on its way to production. Think of it like an assembly line in a factory — raw materials (code) enter at one end, and a finished, tested, packaged product exits at the other.
A typical pipeline has these stages:
Source triggers the pipeline when code is pushed to the repository — a commit, a pull request, a merge to main.
Build compiles the code and packages it into a deployable artifact: a JAR file, a Docker image, a compiled binary. If it doesn't compile, the pipeline stops here.
Test runs the automated test suite. Unit tests first (fastest, most isolated), then integration tests, then end-to-end tests. A failing test means the pipeline stops — nothing broken ships forward.
Security scan checks for known vulnerabilities in your dependencies. Tools like Snyk, Trivy, or OWASP dependency check slot in here. I added this to one of my pipelines after I discovered a critical vulnerability in a package I had been running for six months.
Staging deployment pushes the validated build to a pre-production environment that mirrors production as closely as possible.
Acceptance testing runs automated tests against staging — smoke tests, API contract tests, critical user journey tests.
Production deployment pushes to production, either automatically or after manual approval.
If any stage fails, the pipeline stops and alerts the team immediately. This discipline of "if it breaks, nothing proceeds" is what keeps the main branch always in a deployable state.
Key CI/CD Tools
GitHub Actions is now the most widely used CI/CD tool for open-source and GitHub-hosted projects. Workflows are defined in YAML files stored directly in your repository under .github/workflows/. Triggers can be pushes, pull requests, schedules, or manual dispatches. The marketplace of pre-built actions makes it easy to integrate with any tool — deploy to AWS, send a Slack notification, run Lighthouse. Because it lives in the same repository as your code, pipeline changes are versioned alongside the code they test. This is where I started, and for most solo developers and small teams it's all you need.
Jenkins is the veteran of the CI/CD world — open-source and deeply configurable. It integrates with virtually any tool through its massive plugin ecosystem. Jenkins requires self-hosting, which gives you full control but also means you own the maintenance burden. It's the right choice when you need deep customization, complex pipeline logic, or operate in environments where cloud-hosted tools aren't permitted.
GitLab CI/CD is built directly into GitLab and provides a seamless end-to-end experience for teams on that platform. Pipelines are defined in .gitlab-ci.yml. GitLab's integrated container registry, package registry, and built-in security scanning make it a complete DevOps platform in one place.
CircleCI and Bitbucket Pipelines are strong alternatives with tight integrations for their respective ecosystems.
The Benefits That Change Everything
The most obvious benefit of CI/CD is speed — features reach users faster. But the deeper benefit is confidence. I noticed this personally: after I set up a proper pipeline for my project, I stopped dreading deployments. Small changes went out as soon as they were ready. If one failed, only that change was affected — not three weeks of accumulated features all shipping together.
CI/CD enforces quality by making your test suite non-negotiable. When the pipeline runs your full tests on every commit, broken tests can't be ignored or skipped. Coverage requirements, linting rules, and security checks become part of the definition of "done."
The discipline also changes how you write code. When you know that every commit will be tested automatically, you write smaller, more focused commits. When you know bad code can't reach production, you invest more in tests. The pipeline changes the culture, not just the process.
Getting Started with CI/CD
If you're starting fresh, GitHub Actions is the easiest entry point. Add a .github/workflows/ci.yml file to your repository with three steps: install dependencies, run tests, build the project. Here's what a minimal Node.js pipeline looks like:
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
- run: npm ci
- run: npm test
- run: npm run build
That's it. Once that's working and you trust it, add deployment steps to push to your hosting provider when the main branch is updated. From this simple beginning, gradually add more stages: security scanning, performance testing, staging environments.
The night I set up my first working pipeline and watched a green checkmark appear automatically after pushing code — I understood why developers who use CI/CD never want to go back to manual deployments. It's not about automation for automation's sake. It's about being able to sleep soundly after shipping.