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:
mainis always deployable to production- Feature work happens in short-lived branches (
feature/my-thing) - PRs merge into
mainonly 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. Still deploying by hand from Heroku or a VM? From Heroku (or a VM) to Cloud Run covers the migration itself, before you wire up this pipeline around it.
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.