Continuous Integration and Continuous Deployment automate the process of testing, building, and deploying code changes. Instead of manually running tests, building production bundles, and uploading files to servers, a CI/CD pipeline handles all of this automatically every time code is pushed. At Born Digital, we set up CI/CD pipelines for every project — it is foundational infrastructure, not a luxury. Here is how to build one.
Continuous Integration
CI is the practice of automatically testing and validating every code change before it is merged. When a developer pushes code or opens a pull request, the CI pipeline runs linting, type checking, unit tests, and integration tests. If any step fails, the merge is blocked. This catches bugs before they reach production and ensures that the main branch always has passing tests.
A typical CI pipeline includes these stages:
- Install dependencies: Use cached node_modules to speed up subsequent runs. Lock files ensure reproducible installs.
- Lint and type check: ESLint and TypeScript catch code quality issues and type errors before tests even run.
- Run tests: Unit tests, integration tests, and optionally end-to-end tests verify that the application behaves correctly.
- Build: Compile the production bundle to verify the build succeeds. This catches issues like missing imports that tests might not cover.
Continuous Deployment
CD extends CI by automatically deploying code that passes all checks. The most common approach for web applications is: merge to main triggers a production build, and the build output is deployed to your hosting platform automatically. Platforms like Cloudflare Pages, Vercel, and Netlify handle this natively — connect your Git repository, and every push to main deploys automatically.
For more complex deployments — Docker containers, Kubernetes clusters, or multi-service architectures — GitHub Actions or GitLab CI can build Docker images, push them to a registry, and trigger rolling updates on your infrastructure. The key principle is the same: code that passes tests deploys automatically, removing manual steps and the human errors they introduce.
GitHub Actions: A Practical Setup
GitHub Actions is the most accessible CI/CD platform for teams already using GitHub. Workflows are defined in YAML files within your repository. A basic workflow triggers on pull requests and pushes to main, installs Node.js, runs your test suite, and deploys on success. GitHub provides generous free-tier minutes for open-source and private repositories, and the marketplace offers pre-built actions for common tasks like caching, deploying to cloud platforms, and sending notifications.
Deployment Strategies
For most web applications, a simple rolling deployment is sufficient — the new version replaces the old version, and the CDN cache is invalidated. For higher-stakes applications, blue-green deployments maintain two production environments and switch traffic between them, enabling instant rollback if issues are detected. Canary deployments route a small percentage of traffic to the new version first, catching problems before they affect all users.
Preview deployments are particularly valuable for teams. Every pull request gets its own deployment URL where stakeholders can review changes before merging. This turns code review from a purely technical exercise into a collaborative process where designers, product managers, and clients can verify changes in a real environment.