CI/CD Pipeline Setup Checklist (2026)

0 of 24 completed

0%

Build Stage

The build stage compiles code, installs dependencies, and produces deployable artifacts. It should be fast and deterministic.

Pin all dependency versions with a lockfilecritical

Use package-lock.json, yarn.lock, Pipfile.lock, or go.sum. Without pinned versions, builds can break randomly when a dependency releases a new version. Commit your lockfile to version control.

Cache dependencies between buildscritical

Configure your CI to cache node_modules, pip packages, or Go modules between runs. This typically reduces build time by 40-70%. GitHub Actions, GitLab CI, and Bitbucket Pipelines all support caching.

Keep build time under 5 minutesimportant

If your build takes longer than 5 minutes, investigate: unnecessary dependencies, unoptimized compilation, or missing caching. Developers lose focus during long builds, which degrades developer experience.

Build in a clean, reproducible environmentimportant

Use Docker containers or ephemeral CI runners to ensure builds don't depend on local state. A build that passes on one machine and fails on another wastes hours of debugging time.

Produce versioned build artifactsimportant

Tag each build artifact with the git commit SHA or a semantic version. This makes it possible to trace any deployed version back to the exact code that produced it, which is essential for debugging production issues.

Testing Stage

Automated tests are your safety net. They should run fast enough that developers don't skip them.

Run unit tests on every PRcritical

Unit tests should run on every push and PR. They should complete in under 2 minutes. If they take longer, parallelize them or identify slow tests that can be moved to a separate suite.

Run integration tests before merge to maincritical

Integration tests verify that components work together. Run them on PRs targeting main. They can be slower than unit tests (up to 10 minutes) but should still complete before the developer loses context.

Fail the build on test failures — no exceptionscritical

Never allow merging with failing tests. If a test is flaky, fix the flaky test — don't skip it. Allowing test failures to pass erodes trust in the entire test suite.

Track and fix flaky tests aggressivelyimportant

Flaky tests (tests that pass and fail randomly) destroy CI credibility. Track flaky test rate and dedicate time each sprint to fixing the worst offenders. A 5% flaky rate means 1 in 20 builds fails for no real reason.

Parallelize test executionimportant

Split tests across multiple CI runners to reduce total test time. Most CI systems support parallelism. A test suite that takes 20 minutes sequentially can often run in 5 minutes across 4 parallel runners.

Run end-to-end tests on staging before production deployimportant

E2E tests (Playwright, Cypress, Selenium) verify critical user flows. Run them against the staging environment after deployment but before promoting to production. Keep the E2E suite focused on critical paths — 10-20 tests, not 200.

Security Scanning

Catch security issues before they reach production. Automate what you can.

Enable dependency vulnerability scanningcritical

Use Dependabot (GitHub), GitLab Dependency Scanning, or Snyk to automatically detect known vulnerabilities in dependencies. Configure automatic PRs for security patches.

Scan for secrets in codecritical

Use tools like git-secrets, truffleHog, or GitHub's built-in secret scanning to detect accidentally committed API keys, passwords, or tokens. Block PRs that contain secrets.

Run SAST (static analysis) on PRsimportant

Static Application Security Testing tools (CodeQL, Semgrep, SonarQube) analyze code for security vulnerabilities without running it. Configure as a CI check on every PR.

Scan container images for vulnerabilitiesimportant

If you deploy containers, scan images with Trivy, Snyk Container, or Docker Scout. Block deployment of images with critical or high vulnerabilities.

Deployment Stage

Deployment should be automated, repeatable, and reversible.

Automate deployment — no manual stepscritical

Every deployment should be triggered by code merge or a single command. Manual deployment steps (SSH into server, run scripts) are error-prone and limit deployment frequency. Use GitHub Actions, GitLab CI, or a deployment platform.

Deploy to staging before productioncritical

Every change should hit a staging environment first. Run smoke tests and E2E tests against staging before promoting to production. Staging should mirror production as closely as possible.

Implement zero-downtime deploymentsimportant

Use rolling deployments, blue-green deployments, or canary releases to deploy without taking the service offline. This is essential for any user-facing application.

Configure automatic rollback on health check failureimportant

After deployment, run health checks (HTTP endpoint, database connectivity, critical flow test). If health checks fail, automatically roll back to the previous version.

Keep deployment under 5 minutesimportant

From merge to running in production should take under 5 minutes for most applications. Long deployment times limit your deployment frequency and increase MTTR during incidents.

Monitoring & Observability

You can't improve what you can't measure. Monitor both the pipeline and the deployed application.

Alert on deployment failurescritical

If a deployment fails, the team should be notified immediately via Slack, PagerDuty, or email. Don't let failed deployments go unnoticed.

Track deployment frequency automaticallyimportant

Record every successful deployment with timestamp, version, and deployer. Use this data to calculate DORA deployment frequency. Tools like Gitmore can track this from git data.

Monitor error rates post-deploymentimportant

After each deployment, watch error rates for 15-30 minutes. Set up alerts that fire if error rate exceeds baseline by more than 2x. This catches issues that health checks miss.

Track CI pipeline duration over timenice-to-have

CI pipelines tend to get slower over time as more tests and steps are added. Track total pipeline duration weekly and investigate when it crosses your threshold (e.g., 10 minutes).

Pro Tips

Expert advice

1

The fastest way to improve deployment confidence: make rollback a one-click operation that takes under 2 minutes

2

If your CI pipeline takes more than 10 minutes, developers will push to skip it. Invest in speed.

3

Run your full CI pipeline on main branch merges, not just PRs — this catches integration issues from concurrent merges

4

Use Gitmore to track deployment frequency and lead time automatically from your git activity

5

Treat CI configuration as code — review pipeline changes in PRs just like application code

FAQ

Common questions

Should we deploy on Fridays?

If your CI/CD pipeline is reliable, your rollback is fast, and your monitoring is solid — yes. Avoiding Friday deploys is a sign of low deployment confidence. Work on the confidence (testing, monitoring, rollback) rather than restricting when you can deploy.

How do you handle database migrations in CI/CD?

Run migrations as a separate step before application deployment. Make migrations backwards-compatible (add columns as nullable, never rename in one step). Test migrations against a database with production-like data in CI. Always have a rollback migration ready.

How many environments do we need?

At minimum: development (local), staging (shared, production-like), and production. Some teams add a QA environment between staging and production. More environments mean more maintenance — start with three and add only if you have a specific need.

Should CI run on every commit or just PRs?

Run a fast suite (lint, unit tests) on every push. Run the full suite (integration tests, security scans, E2E) on PRs and merges to main. This balances fast feedback with comprehensive checking.

More Checklists