Standing service release-pipeline-rehearsed-monthly · revised 11 October 2026
Standing service
Rehearse your build, release and rollback path every month, and fix what has drifted
Each month we rehearse your release dry run, a clean image build and a staging rollback, then fix what drifted in a small pull request (up to two a month), or tell you what only you can change.
This starts a conversation by email. Nothing is charged, and nothing is monitored, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Release machinery decays quietly. A base image tag changes, a tool releases a new major version, a token expires, a runner image is retired or an earlier release is cleaned out of storage. Nothing fails until the day a release or a rollback is needed, which is the worst moment to learn it.
Who it’s for: A small team that has a release process, a container build or a rollback step, but only finds out that one of them has rotted when it needs it.
Usually starts when: The last release needed an emergency fix to the release process itself, or nobody has run the rollback since it was written.
The result: Each month your release dry run, a clean image build and a staging rollback are run on non-production targets and their results are reported. Anything that has stopped working since the baseline rehearsal ends in a small fix pull request, a written explanation or a quote for the bigger job, so the path is known to work before it is needed.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target is agreed in writing before it starts, set to what a service at this stage can keep.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock, so we do not offer round-the-clock cover.
What must remain true
- The release dry run, the clean image build and the staging rollback each still work when rehearsed
- Every rehearsal failure ends in a monthly fix pull request, an explanation with evidence, or a quote for the bigger job
What we watch
- The rehearsal runs on the rehearsal branch and the staging environment
- Notices of retired runner images, base images or tool versions that your pipeline uses
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| The release dry run no longer produces the version or changelog it should. | We find the change that broke it and, if the restore fits a monthly fix, open a pull request that restores the dry run to how it passed the baseline; otherwise we tell you what only you can change or what the bigger job would be. Priced as: Automated versions and changelog |
| The clean image build fails or produces an image that does not start. | We reproduce the failure from a clean checkout and, if the restore fits a monthly fix, open a pull request that restores the build; otherwise we write up what the bigger job would be. Priced as: Docker image that builds in CI |
| The staging rollback no longer restores the earlier release. | We rehearse again, find what changed and, if the restore fits a monthly fix, open a pull request that restores the rollback to how it passed the baseline; otherwise we write up what the bigger job would be. If the limits list from the rollback job is out of date, the summary says so. Priced as: Rehearsed one-step rollback |
| A month ends. | We send a short written summary: what was rehearsed, what passed, what failed and what is still open. |
We do on our own
- Run the release dry run and the clean image build on the rehearsal branch
- Investigate failures on a branch
- Open pull requests within the monthly fix size that change pipeline, release or image files
We ask you first
- Any run that deploys to staging, which your person approves
- Anything that changes secrets, registries, runners or billing
- Merging, or any change to your default branch
We escalate to you when
- A rehearsal would need to publish or touch production
- A failure is caused by an expired credential or a registry restriction
- More than two failures in a month, or a restore larger than a monthly fix
How you know it held. Each month you get a link to each rehearsal run and its result, and a passing rehearsal run is the evidence for each fix.
How we keep it true
This service is never finished. Each month's summary shows what was rehearsed and what happened, and it continues until you end it.
Automate version numbers, changelog entries and tagged releases for one repository Job Each time it fires
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.
Within the two monthly fixes
A monthly fix restores a release dry run that passed the baseline rehearsal, within the stated size. It is smaller than this job. Setting the release automation up, changing the scheme or rebuilding it is this job at its listed price.
Make one Docker image build from a clean checkout in CI and start healthy Job Each time it fires
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.
Within the two monthly fixes
A monthly fix restores a clean image build that passed the baseline rehearsal, within the stated size. It is smaller than this job. A build that never passed, or one that needs a redesign of the Dockerfile or build, is this job at its listed price.
Add one rollback step to your deploy pipeline and rehearse it on staging Job Each time it fires
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.
Within the two monthly fixes
A monthly fix restores a staging rollback that passed the baseline rehearsal, within the stated size. It is smaller than this job. Building a rollback step, or changing what it restores, is this job at its listed price.
What is included, and what is not
- A rehearsal result for each part of the path every month, with run links
- A baseline rehearsal record for each existing part in the first month
- A monthly fix pull request for each failure we can restore within the stated size, up to two a month
- An explanation of what you need to change when the cause is not in the repository, or of what a larger restore would take
- A written monthly summary
Included
- One service's release path: a release dry run, a clean image build and a staging rollback rehearsal, each only where it exists
- A baseline rehearsal of each existing part in the first month, inside the monthly price; a part that does not pass its baseline is reported each month but is not covered by the monthly fix until it does
- A monthly rehearsal on a rehearsal branch and a staging environment you control
- Up to two monthly fixes a month. A monthly fix is a pull request that returns one part that passed the baseline rehearsal to the way it passed, changing no more than three files and about 60 lines of pipeline, release or image configuration. It never rebuilds a part, adds a tool or changes what a part does. A failure is one distinct cause of one or more failing rehearsals; the same cause failing again, or in more than one part, in the same month counts once.
- A plain written explanation with evidence when the cause is outside the repository, when a third failure arrives in a month, or when a restore would be larger than a monthly fix; none of these is fixed under this price, and the bigger job is quoted at the matching job's listed price
- A written monthly summary of what was rehearsed and what happened
Not included
- Running a release or a rollback on production
- Building the release automation, image build or rollback step from scratch, or rebuilding one that did not pass its baseline rehearsal: those are the separate jobs at their listed prices
- A fix larger than a monthly fix, or a third failure in a month: each is written up and can be quoted as the matching job
- Merging to your default branch or deploying, which stay with your team
- Changing secrets, registries, runners or billing
- Any recovery-time promise or out-of-hours cover
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month's rehearsal ran every existing part of the path on the rehearsal branch or staging, with a run link for each.
Evidence: The monthly summary and its run links.
For each monthly fix, the rehearsal that failed passes after the change on the rehearsal branch.
Evidence: Links to the failing and passing rehearsal runs.
No rehearsal published a package, moved a production tag or deployed production.
Evidence: The list of tags, releases and deployments touched, included in the summary.
Each monthly fix changes no more than three files and about 60 lines, and returns the part to the behaviour recorded in the baseline rehearsal; no more than two causes are fixed in a month.
Evidence: The pull request diff summary and the baseline and current run links, listed in the monthly summary.
Sign-off. You review and merge each pull request and read each monthly summary. A fix counts as delivered when you accept it.
If it fails. If we cannot restore a part within the monthly fix size, we say so, explain what we found and what it would take, and it does not count against the two a month. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- A release dry run, a clean image build or a staging rollback already exists, whether built by us or by you
- A staging environment separate from production exists for the rollback rehearsal
- A rehearsal branch can be used without publishing or deploying production
- A person on your side approves rehearsal runs that deploy to staging and reviews pull requests
We stop and tell you if
- A rehearsal can only run by publishing or touching production
- Staging is not isolated from production data
- More than two failures a month, or restores larger than a monthly fix, happen regularly, so we agree a different scope with you
What could go wrong
Every fix is a pull request that your team merges, so you can revert it as you would any other change. Rehearsals touch only the rehearsal branch and staging. Ending the service leaves your pipelines as they are.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A rehearsal publishes or deploys something it should not. | Rehearsals run only on the rehearsal branch and staging, publishing steps are switched off, and your person approves each deploying run. |
| A passing staging rehearsal is read as proof that production will behave the same. | Each summary states that rehearsals are checks on staging, not guarantees about production. |
| A fix weakens a check so a rehearsal passes. | We change what is broken, not what the check demands, and you review and merge every pull request. |
| A monthly fix grows into a rebuild that the monthly price does not cover. | A monthly fix is limited to three files and about 60 lines and to returning a part to how it passed the baseline; anything larger is written up and quoted as the matching job before work starts. |
Each pull request is checked by a reviewer separate from the work that produced it before it is opened. Your person approves every run that deploys. At launch the work is largely automated, and we say so.
Stays with a person
- Your person approves every run that deploys to staging
- You review and merge every pull request
Access we would need
- Access to a fork or branch for pull requests
- A staging approval route controlled by your person
Questions
Will you roll back production each month?
No. Rehearsals run on a rehearsal branch and your staging environment, and your person approves every run that deploys.
What counts as a monthly fix?
A pull request that returns a part that passed the baseline rehearsal to the way it passed, in no more than three files and about 60 lines. A failure is one distinct cause, so the same cause failing again in the same month counts once. Up to two causes a month are fixed; anything beyond that, or anything bigger, is written up and can be quoted as the matching one-off job at its listed price.
Is the baseline rehearsal included?
Yes, in the first month. It records how each existing part behaves, and it is what later fixes are measured against. A part that does not pass its baseline is reported every month, but putting it right is the matching one-off job.
What if we do not have a rollback step yet?
Then there is nothing to rehearse for that part. Building one is the separate rehearsed-rollback job at its listed price, and this service covers the parts that exist.
Is this a guarantee that releases will work?
No. A passing rehearsal shows that the path worked on staging that month. It is a check, not a promise about production.
Send an enquiry
Send us
- The repository name or link (a link is not access) and which of the three parts exist: release dry run, image build, staging rollback
- Where releases and images are stored and for how long
- Who approves rehearsal runs and who reviews and merges pull requests
Later, once you agree
- Access to a fork or branch we can open pull requests from, for a company-controlled identity
- A staging approval route in which your person approves each deploying run and the credentials stay in your secret store
- Who to tell when something is outside the repository, and who may approve a quote for a bigger fix
Your repository, registries, environments and secrets stay yours. After you agree in writing, we change files only on a branch or fork through pull requests your team reviews and merges, using a company-controlled identity and never a personal login. Any run that deploys to staging is approved by your person using credentials we never see.
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 “release-pipeline-rehearsed-monthly” as the subject.