CI/CD turns a commit into a traceable production artifact through explicit checks, promotions and recovery steps. The pipeline should answer four questions: what was built, which controls passed, where it is running and how to return to a known-good version.
This guide focuses on pipeline implementation: job boundaries, artifact integrity, policy controls, environment promotion, progressive rollout and rollback.
Manual releases are fragile because they depend on memory, local setup and one-off commands. A missing environment variable, skipped test or different dependency version can break production even when the feature works locally.
CI/CD reduces that risk by making every change follow the same path: build, test, package, deploy, verify and monitor.
CI is the practice of integrating code changes frequently and validating them with automated checks. Here is what happens in a typical CI workflow:
For example, imagine a team working on an e-commerce platform. One developer adds a payment gateway while another updates the shopping cart. With CI, each pull request runs tests that can catch integration issues before the changes are merged.
Continuous delivery means the application is always in a deployable state, but production release may still require manual approval. Continuous deployment goes one step further: validated changes deploy to production automatically.
Start with continuous delivery and manual production approval before moving to full continuous deployment. This gives the team time to trust the pipeline.
# Example Git workflow
git checkout -b feature/payment-gateway
git commit -m "Add PayPal integration"
git push origin feature/payment-gateway
# Create Pull Request
Set up a robust build pipeline:
Example Jenkins Pipeline:
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'npm install'
sh 'npm run build'
}
}
stage('Test') {
steps {
sh 'npm run test'
}
}
}
}
Implement a testing pyramid:
The exact percentages matter less than the principle: keep most tests fast and focused and use slower end-to-end tests for critical paths.
Build an immutable artifact once, identify it by commit and promote that exact artifact through environments. Rebuilding for production can change dependencies or tooling after staging passed.
# Example GitHub Actions workflow
name: Build artifact
on:
pull_request:
push:
branches: [main]
jobs:
verify-and-package:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint
- run: npm test
- name: Build image
run: docker build -t registry.example.com/myapp:${{ github.sha }} .
- name: Push image
if: github.ref == 'refs/heads/main'
run: docker push registry.example.com/myapp:${{ github.sha }}
npm ci uses the lockfile, the job has minimal token permissions and the image tag connects the artifact to its source commit. In a production workflow, pin third-party actions to reviewed commit SHAs and attach a software bill of materials and provenance attestation.
Modern web apps benefit from CI/CD through:
For example, an e-commerce platform can reduce deployment time when manual packaging, server access and smoke testing are replaced by one repeatable pipeline.
CI/CD in mobile development enables:
CI/CD excels in microservices by providing:
Infrastructure as Code (IaC) automation:
A healthy pipeline should be easy to explain from left to right:
This trace matters because many delivery problems come from rebuilding, retesting or reconfiguring the same code differently in each environment.
For a small Next.js or Node.js application, a reliable first CI/CD pipeline can stay simple:
Pull Request
-> install dependencies
-> run linting
-> run unit tests
-> build the app
-> preview deploy for review
Main Branch
-> reuse the tested build steps
-> deploy to staging
-> run smoke tests
-> require approval
-> deploy to production
-> monitor errors and latency
The important detail is not the tool name. The important detail is that the same checks run for every change. A pipeline that only works when one senior developer remembers the steps is still a manual process with a nicer interface.
For a public website, a smoke test that loads the home page, one content page and the contact route can catch broken builds, missing assets and routing errors before visitors encounter them.
Not every check belongs at every stage. Fast, deterministic checks should protect pull requests; environment-dependent checks belong after deployment.
| Stage | Required controls | Failure action |
|---|---|---|
| Pull request | Lockfile install, lint, unit tests, secret scan | Block merge |
| Package | Reproducible build, image scan, SBOM, artifact signature | Do not publish |
| Staging | Migration dry run, integration tests, smoke tests | Do not promote |
| Production canary | Health, error rate, latency, critical business event | Halt or roll back |
| Full rollout | Post-deploy verification and release record | Roll back or mitigate |
Define thresholds in code or configuration. “Watch the dashboard for a while” is not a control because two operators can make different decisions from the same signal.
For a checkout API, the release contract could be:
artifact:
identity: "registry.example.com/checkout:${GIT_SHA}"
required_evidence:
- unit-tests.xml
- integration-tests.xml
- sbom.spdx.json
- image-signature
production:
strategy: canary
steps: [5, 25, 50, 100]
observation_minutes: [10, 15, 20, 30]
continue_when:
error_rate: "< 1%"
p95_latency: "< 450ms"
checkout_success_rate: ">= 99%"
rollback_when:
error_rate: ">= 2% for 5 minutes"
checkout_success_rate: "< 98.5% for 5 minutes"
The numbers must come from the service's normal baseline and reliability objective. This artifact gives the pipeline deterministic promotion and rollback rules rather than leaving them in a release manager's memory.
Deploying code isn't just about copying files. Smart strategies minimize downtime and risk.
GitOps uses Git as the source of truth for infrastructure and application configuration.
kubectl apply manually, you commit configuration changes to Git. A tool like Argo CD or Flux syncs the environment to match the repository.Control feature rollout:
if (featureFlag.isEnabled("new-payment-gateway")) {
// New implementation
} else {
// Old implementation
}
A feature flag can disable behavior without replacing the deployed artifact, but it is not a substitute for deployment rollback. Assign an owner and removal date; stale flags multiply code paths and test combinations.
Test new features with real users:
def get_payment_flow(user_id):
if experiment.is_in_test_group(user_id):
return new_payment_flow()
return current_payment_flow()
Implement comprehensive monitoring:
Monitor technical signals such as error rate and latency, but also monitor user-facing signals such as failed checkouts, signup errors or broken page views.
Use tools like Terraform:
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Environment = "production"
}
}
Choose the right tools:
Rollback must be a routine pipeline operation, not an emergency command discovered during an outage:
if ! ./verify-release.sh --version "$GIT_SHA"; then
kubectl rollout undo deployment/myapp
kubectl rollout status deployment/myapp --timeout=5m
fi
Test rollback in staging with the same deployment mechanism used in production. Database changes need special care: prefer backward-compatible expand-and-contract migrations so the previous application version can still run. If a migration destroys or rewrites data, application rollback alone cannot restore it.
Automating deployments means automating security checks. Integrate these tools into your pipeline:
# Example GitHub Actions for Trivy
- name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@master
with:
image-ref: "docker.io/my-organization/my-app:${{ github.sha }}"
format: "table"
exit-code: "1"
ignore-unfixed: true
vuln-type: "os,library"
severity: "CRITICAL,HIGH"
Measure pipeline queue time, duration, flaky-test rate, deployment success and rollback time. Delivery metrics can reveal broader trends, but these pipeline measurements identify implementation bottlenecks directly.
Continuous delivery keeps code ready to deploy with a manual approval step for production. Continuous deployment automatically releases validated changes to production.
A first pipeline should install dependencies deterministically, run fast checks, build one versioned artifact, deploy it to staging, run a smoke test and promote the same artifact deliberately to production.
Use it when checks are trusted, changes are small, rollout signals are timely and rollback is proven. A manual promotion is reasonable when an external release window, irreversible migration or legal control requires a human decision.
Yes. Dependency scanning, secret detection and basic static analysis can catch issues earlier and reduce the chance of shipping vulnerable code.
A trustworthy release links source, checks, artifact digest, environment and outcome in one trace. It advances only while explicit controls pass, limits initial exposure and has a rollback path that the team has already exercised.
Learning to code can feel confusing at first because there are many languages, tools, tutorials and opinions. One person says to start with Python, another recommends JavaScript and someone else says
Read MoreClean code pays long-term dividends on real software teams: fewer regressions, faster onboarding, easier reviews and simpler releases. It is not about making code look clever. It is about making futu
Read MoreStrong API design decisions reduce bugs, support faster frontend integration and make future scaling much easier. A good REST API is predictable: clients know where resources live, which HTTP methods
Read More
