Deployment pipeline

The same release setup runs three of my products. It is worth describing on its own because reusing it is the point.

What happens automatically

Open a pull request and it is checked, packaged, and deployed to its own live URL — a complete working copy of the site with that change in it, at its own address. Review happens on something real rather than on a screenshot. Close the pull request and the environment is torn down.

Merging deploys to a staging site automatically.

Production is promoted, never rebuilt

Releasing to production does not rebuild anything. It takes the exact package already tested on staging and re-labels it. The bits that go live are guaranteed identical to the bits that were tested — a rebuild, even from the same code, is not.

Production releases are triggered by hand. Nothing automatic touches them.

The things that had to be learned the hard way

• Merging a pull request fires two jobs at once, and if they are grouped only by branch, the cleanup job cancels the deploy mid-flight. The symptom is maddening: merged changes silently stop deploying. The fix is to include the event type in the grouping.
• No build settings may vary by branch, or promoting by re-labeling ships the wrong build.
• Values baked in at build time cannot be changed later. Anything that differs between staging and production has to be read when a page is requested, not when it is packaged.
• Cleanup must run even when the checks fail, or closed pull requests leave environments running forever.