CI/CD for Web Apps: Pipelines That Make Shipping Routine

A deployment pipeline is worth what it prevents and costs what it delays, and most pipelines get that balance wrong in the direction of slow. This guide covers building one teams use willingly, drawing on FISTA Solutions' web and mobile work.

What should a pipeline contain?

Ordered by speed, so the common failures are caught first.

Stage	Purpose
Lint and type checks	Seconds; catch obvious errors
Unit tests	Fast feedback on logic
Build	Verify it compiles and bundles
Integration tests	Verify services work together
Preview deployment	Review the change in use
Deploy	Rolling, with health checks

Why does speed dominate everything else?

Because a slow pipeline changes how people work.

When a run takes half an hour, developers batch changes to avoid waiting. Larger changes are riskier, harder to review, and harder to roll back, which is the opposite of what the pipeline exists to achieve.

Target feedback within a few minutes for the fast stages. Parallelise, cache dependencies, and split test suites. The engineering time spent on pipeline speed returns more than most feature work.

Which tests belong where?

Fast unit tests on every commit, integration tests before deployment, and end-to-end tests limited to the critical journeys.

End-to-end suites grow until they are slow and flaky, at which point people ignore failures, which is worse than not having them. Keep them small and deliberately chosen.

Flaky tests deserve the same attention as failing ones. A suite people re-run rather than investigate has stopped being a control.

What deployment strategy works?

Rolling deployments with health checks for most applications, blue-green where an instant switch matters, and canary for changes with elevated risk.

The property that matters is the ability to stop and reverse partway through. A deployment that must complete before anything can be undone converts a small problem into a full outage.

Health checks should verify the application works rather than that the process started. A container that starts and cannot reach its database will pass a naive check and fail every request.

Why do preview environments change review quality?

Because reviewers can use the change rather than read it.

Interface changes in particular are difficult to evaluate from a diff. A preview link in the pull request lets a reviewer click through, and the problems they find are the ones users would have.

They also let non-engineers review, which moves design and content feedback earlier. That is frequently worth more than the infrastructure costs.

How do you make rollback real?

By exercising it during ordinary operations, not by documenting it.

A rollback procedure nobody has run is a hypothesis. Configurations drift, migrations complicate reversal, and the moment you need it is the worst time to discover a gap.

Database migrations are the usual complication. Expand-and-contract migrations keep the schema compatible with both versions, which is what makes a code rollback possible at all. See database schema design guide.

Why separate deployment from release?

Because it converts two coupled risks into one routine event and one controlled decision.

Code deployed behind a flag is inert. Enabling it is a separate action that can be limited to a percentage, a segment, or an internal group, and reversed instantly without a deployment.

That decoupling is what allows frequent deployment without frequent risk, and it is the practice that most changes how a team ships. See feature flags guide.

What are the common mistakes?

Slow pipelines. Large end-to-end suites. Tolerating flaky tests. Health checks that only verify the process started. Untested rollback. And deployments that cannot be reversed because of a migration.

How do you test it?

Test the pipeline itself: verify a failing test blocks deployment, verify rollback works, and verify health checks catch a broken dependency.

Run a deliberate bad deployment in a staging environment periodically. It is the only way to know the safety mechanisms function.

What does it cost to operate?

Compute for runners and environments, which is modest, plus the engineering time to keep it fast.

Preview environments per pull request are the largest variable cost and usually worth it. Set them to expire automatically, because orphaned environments accumulate.

What should you measure?

Pipeline duration at the median and tail, deployment frequency, change failure rate, time to restore after a bad deployment, and flaky test rate.

What changes for AI systems?

Evaluation becomes a pipeline stage. A prompt, model, or corpus change should trigger the evaluation suite the same way a code change triggers tests, and a regression should block the change.

That is the single most valuable addition to a pipeline for a team shipping AI features, and it requires the evaluation infrastructure to exist first. See how to set up AI change control.

When is this the wrong approach?

An elaborate pipeline is disproportionate for a static site with one contributor. The stages should match the risk, and for low-risk projects a build-and-deploy step with a smoke check is adequate.

What should you do first?

Measure how long your pipeline takes from commit to feedback. If it is more than a few minutes for the fast checks, that is the change that improves everything else.

How FISTA Solutions helps

FISTA Solutions builds and operates production systems through web and mobile, AI enablement, and staff augmentation: pipelines ordered by speed so failures surface in minutes, rollback exercised during ordinary operations rather than documented, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To scope this work, message FISTA on WhatsApp, or read feature flags guide.