Progressive delivery without a second deployment pipeline

The problem with parallel release systems

Teams often create one pipeline for normal releases and another for risky launches. That doubles configuration, obscures which artifact is actually running, and makes rollback less predictable. Apex treats preview, canary, and production as stages over the same immutable deployment.

Preview first, promote later

A pull request can receive its own environment with branch-specific variables and an isolated URL. Reviewers validate behavior against a real edge runtime without changing production traffic.

Canary on the same artifact

When a release is ready, Apex can route a small percentage of production requests to the new version. Health signals are visible beside the traffic split, so the operator can increase exposure, pause the release, or return traffic to the previous version.

• Keep the artifact immutable between stages.
• Define the rollback version before increasing traffic.
• Measure error rate and latency by version, not just globally.
• Document which database changes are backward compatible before the canary begins.

Rollback should be boring

A rollback changes the traffic target, not the source code or build. That property makes release recovery both fast and explainable during high-pressure incidents.