Project pipeline-preview-release-rollback-project · revised 11 October 2026
Project
Give one service a delivery pipeline with previews, releases and a rehearsed rollback
We deliver previews for every pull request, automated versions and changelog, and a rollback rehearsed on staging for one service, with an end-to-end run-through, one handover and your sign-off.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the scope, the price and the terms in writing.
The result you are buying
Shipping safely needs three things that depend on each other: a way to see each change running before merge, a release that is numbered and described by the pipeline, and a way back that has been tried. Bought separately they are configured separately, and the rollback ends up pointing at releases that were never named.
Who it’s for: A small team that ships by hand: nobody sees a change running before merge, releases are numbered by feel, and going back after a bad deploy is a guess.
Usually starts when: A bad release took too long to undo, a client asked to see changes before they ship, or the one person who knows how releases work is leaving.
The result: You buy the finished pipeline for one service. Every pull request gets a preview, a release is created once from the release branch with a version and changelog, and a named earlier release has been redeployed on staging and passed the health check. Each part comes with evidence, and the limits are written down.
How the work fits together
The project is complete when previews, versioned releases and the rehearsed rollback have each been accepted by you, and the optional image build too if it was agreed. You accept the finished pipeline, not each internal step.
Give every pull request its own preview that updates on push and cleans up on close Job Included
Each pull request gets a preview with a link on it. A push updates it, closing removes it, and previews use test settings only, with no secrets for fork pull requests.
One service, one repository
Automate version numbers, changelog entries and tagged releases for one repository Job Included
A dry run on a test branch shows the next version, a grouped changelog and a tag computed from your commit history. A real release is created once, from the release branch, only after your approval.
One release branch
Add one rollback step to your deploy pipeline and rehearse it on staging Job Included
One pipeline action redeploys a named earlier release to staging, the health check passes on it and the time is recorded, with a written list of what a rollback does not undo.
One staging environment
The rollback goes back to releases the pipeline has named.
After: Automated versions and changelog
Make one Docker image build from a clean checkout in CI and start healthy Job Optional
One Docker image builds from a fresh checkout on your CI runner for the platform you agreed, and a container from it passes your health check. We inspect its build arguments and history for secrets.
One image, if the service ships as a container
How an engagement works
The price covers the agreed list only. Additions are quoted separately, and a part that turns out to be a bigger job is re-scoped with you.
How it starts
You send a link to the repository and a short description of how you deploy.
We read how the service deploys and propose the list and a fixed price.
You agree the list, price and terms in writing. Nothing starts before then.
We deliver previews, then versioned releases, then the rehearsed rollback, each as a pull request with evidence.
We send the final summary and hand over anything left open.
Who decides what
You decide the list and accept each part. Your person approves staging runs and performs production releases on your own gates.
Handover
Each accepted part arrives as a pull request with its evidence. Anything left unfinished is handed back with notes.
Sharing your product safely. Send a link and a short description, never credentials or code in the first message. After you agree the project, share a repository or fork you control, with no production access.
What is included, and what is not
- A pull request for each part, with its evidence
- Test pull request, release and rehearsal run links
- The written limits list for the rollback
- The end-to-end run-through links, and a final summary: accepted, removed, and anything that turned out to need a bigger job
Included
- One service, one repository, one hosting route and one staging environment, agreed in writing after we have read how you deploy
- Previews for every pull request, versioned releases with a changelog, and a rehearsed rollback, delivered in that order
- A container image build for the service, if it ships as one, built from a clean checkout
- A fixed price for the agreed list, set after we have read it
- One end-to-end run-through on staging in which the rollback goes back to a release that the new versioned pipeline created, and a single combined handover with a written final summary showing each part and how it ended
Not included
- Creating hosting accounts, buying plans or domains
- Running a release or a rollback on production, which stays with your team
- Database rollback, data restore or blue-green and canary redesign
- Publishing to a package registry unless agreed in writing
- On-call cover or any recovery-time promise
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A test pull request gets a preview and a link, a second push updates it, closing removes it, and a fork-style pull request receives no secret.
Evidence: The test pull request and the preview run links.
A dry run produces the agreed versions from the agreed synthetic commits, and one approved run creates exactly one tag and one release record.
Evidence: The dry run table, the approved run and a repeat run that created nothing.
The rollback action redeploys a named earlier release to staging, the health check passes on it, and the written limits list is confirmed by you.
Evidence: The rollback and forward-deploy run links with times, and the limits list.
In one end-to-end run-through on staging, a test pull request gets a preview, the approved release run from the release branch creates a tag and release record, staging is then moved forward to a later test build, and the rollback action redeploys the tag the pipeline created (not one tagged by hand) and the health check passes.
Evidence: The run links for the preview, the approved release, the later test build and the rollback in that order, with the tag name shown in the release and rollback runs.
Every part on the agreed list is accepted by you or removed from the list in writing.
Evidence: The final summary, with your acceptance or removal recorded for each part.
Sign-off. You accept each part, or send it back with comments, and then you accept the finished pipeline.
If it fails. A part we cannot deliver is named with the reason and what it would take, and is taken off the list with a matching change to the price. Nothing is billed as delivered that you have not accepted.
When it fits, and when we stop
It fits when
- The service already deploys through a pipeline to a staging environment separate from production
- A host or CI route that supports previews exists and previews can use non-production values
- The team can adopt a commit or pull request title convention
- A person on your side holds deploy credentials, approves staging runs and merges
We stop and tell you if
- Staging does not exist or shares data with production
- Previews can only work by using production data or secrets
- Tagging cannot be separated from publishing or deploying production
- Earlier releases are not retained and cannot be
What could go wrong
Every part is a separate pull request that your team merges, so any one can be reverted on its own. If the project stops, accepted parts stay accepted and the rest is handed back with notes.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A rehearsal or a test release touches production. | Everything runs on test branches and staging, tagging is separated from publishing before any rehearsal, and your person approves every deploying run. |
| The parts are built in an order that leaves the rollback pointing at unnamed releases. | Releases are named before the rollback is built, and the rollback is tested against a release the pipeline created. |
| A passing staging rehearsal is read as a promise about production. | The limits list and the final summary say plainly what staging showed and what it did not. |
Each part is reviewed separately from the work that produced it, and you accept every part. Your person approves each deploying run. No human supervisor is included unless your proposal names one. At launch the work is largely automated, and we say so.
Stays with a person
- You accept each part
- Your person approves every deploying run and performs any production change
Access we would need
- Access to a repository or fork you control
- A staging approval route held by your person
Questions
Do I have to buy all three parts?
No. Each is a separate job you can buy alone. This project is for when you want them built in order and shown to work together as one pipeline. It adds one end-to-end run-through on staging, with the rollback going back to a release the new pipeline created, and one combined handover.
Will you run a release or rollback on production?
No. We rehearse on staging with your person approving each run. You run any production change.
What if we deploy on a platform that already has rollbacks?
Then the rollback part may reduce to configuring and rehearsing what the platform provides. We say so after reading how you deploy and adjust the price.
Is it cheaper to buy the three jobs separately?
The project starts at the three parts' own starting prices plus the end-to-end run-through and the combined handover, so the saving is in coordination rather than price. If you only need one part, buy that job alone. All prices are untested hypotheses.
Send an enquiry
Send us
- A link to the repository (a link only) and a short description of how you deploy today
- Whether staging exists and holds only test data
- How you merge changes and how you decide a release is healthy
Later, once you agree
- The pipeline and deploy files through a repository or fork you control, with no production access
- Non-production setting values entered by you, and a staging approval route held by your person
- A named person to accept each part
Your repository, hosting, credentials and production stay yours. We work on branches or a fork you control and return pull requests. Your person approves every run that deploys to staging, using credentials we never see, and performs any production release or rollback.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “pipeline-preview-release-rollback-project” as the subject.