CI/CD Deployment Pipelines
Term 29 of 68 in the ERPStack technical glossary
What is CI/CD Deployment Pipelines?
CI/CD (Continuous Integration and Continuous Delivery) is a set of practices and tools that automates the building, testing, and deployment of software changes to staging and production environments.
CI/CD Deployment Pipelines at a glance
- Pipeline stages
- 5 gates on every pull request: typecheck, lint, unit tests, end-to-end tests, build
- Tooling
- GitHub Actions running Vitest 4 and Playwright 1.59 against a preview database branch
- Release control
- Deploy continuously, release behind feature flags — 2 separate decisions
- Rollback
- 1 previous immutable build kept ready, so recovery is a switch rather than a rebuild
- Built with
- GitHub Actions running TypeScript 5.9 typecheck, lint, Vitest 4 and Playwright 1.59, building Docker images, deploying to Vercel, AWS or Kubernetes, with Sentry releases tagged per deploy
- Numbers that matter
- 5 gates per pull request; minutes not hours; 1 previous build retained for rollback; 2 migration phases, expand then contract
- Toolchain
- GitHub Actions, Docker images, Vitest, Playwright, Semgrep SAST and OWASP ZAP
- Deploy targets
- GitHub Actions, Docker images, Vitest 4, Playwright 1.59, Semgrep SAST, OWASP ZAP, Vercel or AWS deploys, Kubernetes rollouts and Sentry releases
- Migration safety
- Two-phase schema change: expand, deploy, backfill, contract — 4 steps, so 1 rollback never meets a column that has already been dropped.
- Where the log is evidence
- healthcare, finance and government delivery, where the pipeline record is the change-control artefact an assessor reads instead of a ticket.
- Why duration matters
- 5 gates finishing in 8 minutes get run on every push; the same 5 taking 45 minutes get worked around. 1 previous immutable build stays ready for a 1-step rollback.
How CI/CD Deployment Pipelines works in production
The ERPStack approach to CI/CD Deployment Pipelines
We set up automated CI/CD pipelines using GitHub Actions, running comprehensive lints, type checks, and Playwright tests before code is shipped.
Frequently asked questions about CI/CD Deployment Pipelines
What belongs in CI/CD Deployment Pipelines?
Everything that must be true before code reaches production. Deployment Pipelines should typecheck, lint, run unit tests, run end-to-end tests against a realistic environment and produce the deployable artefact — 5 gates that run on every pull request rather than before a release. A check that only runs occasionally is a check the team learns to work around.
How fast should a pipeline be?
Fast enough that nobody waits for it to finish before starting something else, which in practice means minutes rather than an hour. Slow Deployment Pipelines change behaviour: people batch changes into larger pull requests, which are riskier and harder to review, and they start ignoring results. Parallelising suites and caching dependencies is not polish — it directly determines whether the pipeline is used as intended.
What does continuous deployment require to be safe?
Three things working together. Deployment Pipelines that deploy automatically need a test suite trustworthy enough to gate on, feature flags so shipping code is not the same as releasing behaviour, and observability good enough to detect a regression quickly. Missing any 1 of the 3 turns continuous deployment into continuous exposure, which is why teams that adopt it without them retreat within weeks.
How should database migrations fit into deployment?
Expand first, contract later. Deployment Pipelines should apply additive migrations before the code that uses them, keeping the schema compatible with both the old and new versions during rollout, and remove the old columns in a later release. That ordering means a rollback does not require a reverse migration, which is the step most likely to fail at exactly the wrong moment.