Your First CI/CD Pipeline Checklist (For Startups)

Most startups write good code. Most startups also ship it by SSHing into a server, running git pull, and hoping nothing breaks. It works — until it doesn’t, and by then you’ve already lost a Friday afternoon to a botched deploy.

A CI/CD pipeline fixes this. Not because it’s a tech-cool requirement, but because it removes the single biggest source of human error in software delivery: the manual step. This checklist walks you through building your first one, in the right order, without over-engineering it.

What a CI/CD pipeline actually does

CI (Continuous Integration) means every code change is automatically tested before it merges. CD (Continuous Delivery/Deployment) means once code passes those tests, it’s automatically built and shipped — to staging or production, depending on your setup.

The pipeline runs every time a developer pushes code. It either goes green and ships, or it fails and tells someone exactly why. No more “it worked on my machine.”

The checklist

Work through these in order. Each step builds on the previous one.

Step 1 — Source control with a clear branching strategy

Before you can automate anything, you need a predictable branching model. The simplest one that works for early-stage teams:

main is always deployable to production
Feature work happens in short-lived branches (feature/my-thing)
PRs merge into main only after automated checks pass
No one pushes directly to main

That’s it. Don’t add develop and staging branches until you actually need them — they add merge overhead with no benefit at your stage.

Tooling: GitHub, GitLab, or Bitbucket. GitHub Actions is the easiest CI trigger to start with.

Step 2 — Automated tests on every pull request

This is the core of CI. Every PR should trigger a test run. You need at least:

Unit tests — fast, no external dependencies, run in seconds
Integration tests — test your actual database queries, API responses, service interactions

A rule of thumb: if tests take more than 5 minutes, developers will start skipping them. Keep the CI test suite fast.

If you have no tests yet — don’t try to retrofit coverage overnight. Start by writing tests for every new feature and every bug fix from this point forward. The coverage compounds.

Step 3 — Linting and static analysis

Automated style enforcement stops the kind of small issues that clog code reviews. Add these to the CI run alongside tests:

A linter for your language (ESLint, golangci-lint, Ruff for Python)
A formatter check (Prettier, gofmt, Black) — fail the build if formatting is wrong
A secret scanner (Gitleaks, TruffleHog) — reject any commit that contains a hard-coded secret

The secret scanner is non-negotiable. A credential leaked in a commit lives in git history forever, even after you delete the file.

Step 4 — Build and containerize

Once tests pass, build your deployable artifact. For most startups today, this means a Docker image:

Build the image (docker build)
Tag it with the git commit SHA — never latest
Push it to a container registry (AWS ECR, GCP Artifact Registry, or Docker Hub for smaller teams)

Tagging with the commit SHA is important. It gives you a clear line from every running container back to the exact code that’s in it.

Step 5 — Secrets management (not in the repo)

Never pass secrets as environment variables baked into the image. The right pattern:

Secrets live in a secret manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, or even GitHub Actions secrets for small teams)
Your deploy step reads them at runtime, not at build time
The image itself contains no credentials

This is the step most early teams skip, and it’s the step that causes the most painful incidents later. Set it up correctly from day one.

Step 6 — Deploy to a staging environment

Before production, every change should hit a staging environment that mirrors production as closely as possible. Staging should have:

The same infrastructure type as production (same managed service, same container platform)
Realistic-but-anonymized data, or a clean dataset
Smoke tests that run automatically after deploy (at minimum: does the app respond? do core endpoints return 200?)

Staging catches the issues your unit tests can’t: environment-specific config errors, migration failures, third-party API behavior differences.

Step 7 — Deploy to production with rollback

Production deploy should be automatic after staging passes — or gated by a single manual approval, depending on your risk tolerance.

Either way, make rollback trivially easy:

Blue/green deploy: spin up the new version alongside the old one, cut traffic over, keep the old one running for 10 minutes before terminating it
Canary: route 5–10% of traffic to the new version first, watch error rates, then roll it out fully
Immediate rollback: if errors spike, deploy the previous image tag — which you still have in the registry

Most managed platforms (Cloud Run, App Runner, ECS) give you traffic-splitting and rollback buttons out of the box. Use them.

Step 8 — Observability and notifications

A pipeline is only useful if the team knows what’s happening. Set up:

Notifications: Slack or email on pipeline failure, deploy success, and rollback events
Deployment tracking: log which commit SHA reached production and when — you’ll need this for incident post-mortems
Error monitoring: Sentry, Datadog, or CloudWatch Alarms with a simple alert if error rate spikes within 10 minutes of a deploy

The goal: when something goes wrong after a deploy, you can answer “what changed, when, and who deployed it” in under 2 minutes.

The full checklist at a glance

Step	What	Why
1. Branching	`main` always deployable, short-lived feature branches	Predictable merge target for automation
2. Tests	Unit + integration on every PR	Catch regressions before they reach `main`
3. Lint + secrets scan	Linter + formatter + Gitleaks	Enforce style; block leaked credentials
4. Build	Docker image tagged with commit SHA	Reproducible, traceable artifact
5. Secrets	Pulled at runtime from secret manager	No credentials in images or repo
6. Staging	Auto-deploy + smoke tests	Catch environment issues before production
7. Production	Auto or gated deploy + traffic-split rollback	Safe, reversible production changes
8. Observability	Slack alerts + deploy log + error monitoring	Fast incident response

Common mistakes to avoid

Skipping staging. “We’ll add it later” usually means after a bad production incident. Staging is cheap; downtime isn’t.

Testing only the happy path. CI suites that only test the golden path miss the edge cases that actually break in production. Add at least one error-case test per feature.

Building from environment variables. If your image build needs a database URL or API key, the image isn’t portable. Build clean; inject at runtime.

Long-running pipelines. If your CI takes 20 minutes, developers will push multiple commits before seeing results, stacking failures. Optimize relentlessly — cache dependencies, parallelize test suites, run only affected tests on small changes.

What to build this on

For most early-stage startups: GitHub Actions for CI/CD pipeline orchestration, Docker + ECR or Artifact Registry for images, and Cloud Run or App Runner for deployment. This stack costs almost nothing at low volume, scales automatically, and can be set up in a day.

If you’re wondering whether you should be on Kubernetes instead — read Do You Actually Need Kubernetes? first. Most teams that reach for K8s too early would have shipped faster with this simpler stack.

Next steps

If you’re building this from scratch or trying to clean up a fragile manual deploy process, the DevOps for Startups guide covers the full picture: infrastructure as code, secrets management, observability, and the maturity stages from “deploy script” to “production-grade platform.”

Ready to stop firefighting deploys and build a foundation that scales? Book a free intro call — we’ll audit your current setup and tell you exactly what to fix first.