Automating Deployments with CI/CD

Continuous integration (CI) builds and tests every change as soon as a developer pushes it. Continuous delivery or deployment (CD) takes a passing build and releases it to staging or production through an automated process. Teams that automate this ship smaller changes more often, and small changes fail less often and are easier to fix.

What a pipeline should do

1. Install and cache dependencies. Use a lockfile and npm ci for repeatable installs.
2. Lint and type-check. Catch style problems and type errors in seconds.
3. Run tests. Unit tests first, then integration tests, then a few end-to-end tests for critical flows.
4. Build the artifact. A production bundle or a container image tagged with the commit SHA.
5. Scan. Check dependencies for known vulnerabilities and scan images and secrets.
6. Deploy. Push to staging automatically, then to production after approval or further checks.

A GitHub Actions example

name: CI
on:
  pull_request:
  push:
    branches: [develop, main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm test
      - run: npm run build

Add a second job with needs: test that deploys when the branch is main. GitHub, GitLab CI, CircleCI and Jenkins all follow the same ideas with different syntax.

Keep the pipeline fast

Developers stop trusting a pipeline that takes 40 minutes. Aim for CI feedback in under ten. Cache dependencies and build output, run test files in parallel, run only affected packages in a monorepo, and put quick checks first so failures surface early.

Branch strategy

Pair the pipeline with a branching model. A common setup uses short-lived feature branches opened as pull requests into develop, with required status checks and a review before merge. Releases go from develop to main. Protect both branches so nobody pushes to them .

Manage environments and secrets

• Keep development, staging and production separate with their own databases and credentials.
• Store secrets in the CI platform's encrypted secrets or a vault, never in the repository.
• Give each environment the minimum permissions it needs. Prefer short-lived credentials through OpenID Connect over long-lived cloud keys.
• Use preview deployments for pull requests, as Vercel and Netlify provide, so reviewers click a live link.

Deployment strategies

• Rolling: replace instances in small groups. Simple and supported.
• Blue-green: run the new version beside the old one, then switch traffic. Rollback means switching back.
• Canary: send a small share of traffic, such as five percent, to the new version and watch error rates before expanding.
• Feature flags: deploy code turned off and enable it for chosen users. This separates deployment from release.

Handle database changes

Migrations are the riskiest part of a release. Make them backward compatible: add a column first, deploy code that uses it, and remove the old column in a later release. Run migrations from the pipeline with a lock so two deployments cannot collide, and test them against a copy of production-size data.

Plan for rollback

Keep the previous artifact available and make rollback a single command or button. Practice it. After each deployment, run smoke tests against the live URL and watch error rate, latency and business metrics for a few minutes. Alert the team in Slack or Teams on failure, with a link to the logs.

Measure delivery health

The DORA metrics give a useful scorecard: deployment frequency, lead time for changes, change failure rate and time to restore service. Track them monthly, and improve the one that lags.

Start small

Common questions

How much testing is enough before auto-deploy?

Enough that a green build gives you confidence to release on a Friday. A common mix includes many fast unit tests, a moderate set of integration tests around your database and APIs, and a few end-to-end tests for sign-up, login and checkout. Add a test every time a bug reaches production, so the same failure cannot return unnoticed.

Should every merge go straight to production?

Continuous deployment suits teams with strong test coverage, feature flags and quick rollback. Other teams prefer continuous delivery, where every merge produces a releasable build and a person approves the production step. Start with approval and remove it once your safety nets have earned trust.

What does CI/CD cost?

GitHub Actions includes free minutes for private repositories on every plan, and public repositories run free. Paid minutes are inexpensive compared with developer time. Self-hosted runners cut the cost further for heavy workloads. Caching dependencies usually cuts bills and wait times at once.

How do we deploy mobile apps this way?

Tools such as Fastlane and Expo EAS build, sign and upload iOS and Android apps from CI to TestFlight and Google Play internal tracks. Store review still gates public release, so use staged rollouts and remote configuration to limit the impact of a bad build.

Begin with CI that runs lint, types and tests on every pull request. Add automatic deployment to staging next, then production with an approval step. Each stage removes manual work and reduces release stress. Our DevOps team sets up pipelines for web, mobile and backend projects. Get in touch or review our services.