How to release a backend before the frontend (and roll both back)

Many products ship as two repositories: an API and a web or mobile client. When a change touches both, the order matters. If the frontend goes live first, it calls an endpoint that does not exist yet. If the backend goes live first and removes something the old frontend still uses, users see errors in between.

Make each side safe on its own

Add before you remove: the backend adds the new field or endpoint and keeps the old one for a while, then removes it in a later release.
Make the frontend tolerate a missing field or a failed call, so a short gap does not break the page.
Put risky changes behind a feature flag, so deploying and releasing are separate steps.

Pick an order

The usual rule: backend first, then frontend, when the frontend needs something new. Frontend first, then backend, when the backend is removing something the frontend no longer uses.

Three ways to time the second release

After the first deploy succeeds. The safest: the frontend merges only once the backend deploy has finished green.
A fixed delay after the first merge, if you know your deploy takes about ten minutes.
Both finishing at about the same moment, by starting the faster deploy later. This needs a decent estimate of each deploy time, and it is still not atomic.

Decide what happens when something fails

If the backend deploy fails, the frontend should not merge at all.
If the frontend fails after the backend is live, decide in advance: leave the backend (fine if it is backward compatible) or roll both back.
Roll back in the opposite order: the frontend first, then the backend.

Doing it by hand

It works, and it is exactly the kind of babysitting that gets skipped at 11 p.m.

Merge the backend pull request.
Watch the deploy run until it is green.
Merge the frontend pull request and watch its deploy.
If something fails, open revert pull requests in reverse order.

How Merge Scheduler handles it

On paid plans, Merge Scheduler can chain several pull requests into one release. Each later step starts after the previous deploy succeeds, a set number of minutes after it merges, or timed from past deploy times so both finish at about the same moment. If a deploy fails, steps that have not merged are cancelled and steps already live are rolled back, newest first. An optional switch also rolls the earlier steps back when a later one fails. Until it has deploy history for a repository, the timed option waits for the first deploy to finish.