CI/CD for a Small Web App: From Pull Request to Production

Define what 'releasable' means

Before writing pipeline configuration, agree on the checks a change must pass to be released: formatting, linting, type checking, unit tests, integration tests for critical paths and a successful production build. Write them down. The pipeline is simply an automated, repeatable way of applying this agreement to every change.

Run fast checks on every pull request

Trigger the pipeline on each pull request. Run the fastest checks first and in parallel, cache dependencies keyed on the lock file and make failure output point to the exact problem. Require these checks to pass before merging into main. A pull request should get its first result within a few minutes; slow feedback is the main reason teams start ignoring CI.

Build one artefact and promote it

When a change merges into main, build the deployable artefact once: a container image, a static bundle or a packaged function. Tag it with the commit SHA. Deploy that same artefact to each environment, changing only configuration. Rebuilding separately for staging and production means production may run code that was never tested.

Deploy to staging automatically

Deploy each main-branch build to a staging environment that resembles production. Run smoke tests against it: the home page loads, a user can sign in, a key workflow completes. Use test credentials and synthetic data rather than copies of production data.

Promote to production deliberately

Promote the same artefact to production, either automatically after staging passes or with a one-click approval, depending on your team's risk tolerance. Use a rollout strategy suited to your platform: rolling updates, blue-green deployment or a small canary percentage first. Run the same smoke tests after deployment and watch error rates and latency closely for the first minutes.

Handle databases and secrets carefully

• Make schema migrations backward compatible, so old and new versions of the app can run during a rollout; remove old columns in a later release.
• Run migrations as a separate, logged pipeline step before deploying the new code.
• Store deployment credentials and secrets in the CI platform's secret store with the narrowest permissions possible.
• Never print secrets in logs, and restrict who can modify pipeline configuration.

Make rollback boring

Rolling back should mean redeploying the previous artefact with one command or click. Practise it before you need it. Combined with backward-compatible migrations and feature flags for risky features, a quick rollback turns most bad releases into minor incidents.

Checklist

• Release criteria are written and automated
• Pull requests get fast, parallel, cached checks
• One artefact per commit is promoted through environments
• Staging deployments run smoke tests automatically
• Production rollouts are gradual and monitored
• Migrations are backward compatible and secrets are protected
• Rollback is a practised, one-step action