Standing service upgrade-next-version-canary-kept-green · revised 11 October 2026
Standing service
Keep a test run on the next framework or runtime version green, month after month
A second test run on the next runtime or framework version stays in your pipeline. Up to three failure causes a month end in a compatible fix pull request or a tracked reason.
This starts a conversation by email. Nothing is charged, and nothing is changed, until we have agreed scope and terms with you in writing.
The responsibility you hand over
Upgrades become big because nobody looks at the next version until the old one is about to lose support. By then, deprecation warnings that were cheap to fix individually have piled up and every dependency has moved. The Rails upgrade guide recommends moving one minor version at a time and using deprecation warnings as the guide; teams with no recurring job that runs on the next version never get that guidance in time.
Who it’s for: An engineering lead who wants the next upgrade to be a small step instead of a project, and who has no one whose job is to look at the next version before it becomes urgent.
Usually starts when: A big upgrade has just been finished, or abandoned halfway, and the team wants to avoid falling that far behind again.
The result: One extra test run on the next runtime or framework version you name stays in your pipeline and runs on a schedule you choose, no less often than once a week. Up to three distinct failure causes a month are traced and end in a compatible fix pull request, a tracked issue or a plain note that the cause is outside your repository, any further cause is listed with the evidence from the logs, and each month you see how the failure and deprecation counts changed.
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 actually 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
- A test run on the next version you name exists in your pipeline and runs on the agreed schedule
- Up to three distinct failure causes a month on that run are investigated and end in a compatible fix pull request, a tracked issue with the cause, or an explanation; any further cause is listed with the evidence from the logs
- The number of deprecation warnings that the next version prints is reported each month
What we watch
- Run results for the extra job, read through a read-only token you create
- The warnings and failures in that job's logs
- The vendor's release notes and upgrade guide for the version being tracked
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| The next-version job fails. | We read the log and, for each of up to three distinct causes a month, reproduce the failure on a branch and open a pull request that works on both versions, or open an issue with the cause. A cause is counted once however many runs or tests it fails. |
| The vendor releases a newer version than the one being tracked. | We propose retargeting the job and change it only after you agree. |
| A month ends. | We send a short written summary: failures seen, deprecation counts, pull requests opened and what is still open. |
We do on our own
- Read run results and logs
- Reproduce and investigate failures on a branch
- Open pull requests that change the extra job or the code to work on both versions
We ask you first
- Merging, or any change to your default branch
- Making the extra job a required check on merges
- Changing the version being tracked
- Anything that changes secrets, runners, permissions or billing
We escalate to you when
- The cause is a dependency with no release for the next version
- A fix would change what the product does, not only how it runs on the next version
- More than three distinct causes arise in a month, or a fix would be larger than a compatible fix
How you know it held. Each month you get the failures seen and how each ended, and the deprecation count, so you can compare it with the previous month. A passing run on both versions is the evidence for each fix.
How we keep it true
This service is never finished. Each month's summary shows what the next version would break today, and it continues until you end it.
Move one Rails 7.0–7.2 app to Rails 8.1 with its key flows tested Job Each time it fires
Take one Rails 7.0, 7.1 or 7.2 app to Rails 8.1 one minor version at a time, on the Ruby each step supports. Tests and five named business flows pass on a staging copy before your release.
May make the real upgrade smaller; its price is quoted separately. It applies only if the tracked version is Rails 8.1 and the app is on Rails 7.0 to 7.2.
Move one Node.js 18, 20 or 22 app to Node 24 LTS with builds and tests passing Job Each time it fires
Run one Node.js app on Node 24 LTS: clean install from the lockfile, native modules rebuilt or replaced, the test suite and the container or CI configuration all on 24, checked on a copy.
May make the real upgrade smaller; its price is quoted separately. It applies only if the tracked version is Node.js 24 LTS and the app is on Node.js 18, 20 or 22. For any other tracked version the real upgrade is quoted on its own.
What is included, and what is not
- The pipeline job configuration, as a pull request
- Compatible fix pull requests for causes we can fix within the stated size, each passing on both versions, up to three causes a month
- A written monthly summary with the failure and deprecation counts
Included
- One repository, one runtime or framework and one next version agreed with you, for example the next minor release of your framework
- Adding or maintaining a separate pipeline job that installs the next version and runs your existing test suite on a schedule you choose, no less often than once a week and no more often than once a day, which does not block your merges unless you choose that
- Investigation of up to three distinct failure causes a month on that job: a pull request with a change that works on both the current and the next version, a tracked issue with the cause, or an explanation when the cause is a dependency or outside the repository. A failure here is one distinct cause of one or more failing runs or tests; the same cause failing again, or in several tests, in the same month counts once. Up to three causes a month are investigated and taken to a compatible fix pull request, a tracked issue or an explanation. A fourth or later cause is listed in the summary with the failing test names and the first error line, and is not investigated or fixed. A compatible fix changes no more than three files and about 60 lines; a larger change is written up as part of the real upgrade.
- A monthly summary: failures seen, deprecation warnings counted, pull requests opened and what remains
Not included
- Moving production to the next version, which is a separate one-off job
- Merging to your default branch, which stays with your team
- Investigating or fixing a fourth or later cause in a month, or a change larger than a compatible fix: each is listed with the evidence and can be quoted
- Fixing application bugs that the tests correctly report; those are separate jobs
- Changing secrets, runners, permissions or billing
- Any guarantee that the real upgrade will have no further surprises
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
A job that installs the tracked next version and runs the existing test suite is present in your pipeline and ran on the agreed schedule, at least once a week, in the month.
Evidence: Links to each scheduled run of the job.
Every distinct failure cause of that job in the month, up to three, ended in a fix pull request that passes on both versions, a tracked issue stating the cause, or a written explanation that the cause is outside the repository; each further cause is listed in the summary with the failing test names and the first error line.
Evidence: The monthly summary, with one line per cause and a link to each outcome.
The monthly summary reports the number of deprecation warnings the next version prints for the test run, with the figure for the previous month for comparison.
Evidence: The deprecation counts from the job logs in the written monthly summary.
Sign-off. You review and merge each pull request, and you read each monthly summary. A fix counts as delivered when you accept it.
If it fails. If we cannot fix a failure, we say so, explain what we found and what it would take, and it does not count against the three causes 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
- Your tests run in a pipeline you control, and a job can be added to it from a branch or fork
- The tests can run against the next version without production data or secrets
- You can give us a read-only token for run results and a fork or branch for pull requests
- A person on your side reviews and merges pull requests
We stop and tell you if
- There are no automated tests, so the job would have nothing to run
- The next version cannot be installed because a required package has no release for it, and you cannot or will not replace it
- The pipeline can only run with production secrets that we would have to hold
- Most failures are caused by things outside the repository that you cannot or will not change
- More than three distinct causes a month arise regularly, so we agree a different scope with you
What could go wrong
Every change is a pull request that your team merges, so you can revert it as you would any other change. Removing the extra job restores your pipeline as it was. Ending the service leaves your repository as it is, with our open pull requests finished or handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A fix that works on the next version breaks the current one. | Each fix must pass on both versions before the pull request is opened, and the pull request shows both runs. |
| The extra job slows or blocks your merges. | It does not block merges unless you choose that, and it runs on the schedule you agree. |
| A passing run gives false confidence about the real upgrade. | The monthly summary says what the tests cover and what they do not, and the real upgrade is still a separate job with its own checks. |
Each pull request is checked by a reviewer separate from the work that produced it before it is opened. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review and merge every pull request
- You approve any change to what is tracked or to required checks
Access we would need
- A read-only token for pipeline run results
- Access to a fork or branch for pull requests
Questions
How is this different from keeping my CI green?
Keeping CI green fixes failures in your current pipeline. This adds a second run on the next version, so the failures it reports are early warnings, not broken builds.
Will this make my real upgrade free?
No. It makes the upgrade smaller by finding and fixing problems early, but the upgrade itself is a separate job with its own acceptance checks.
Does the extra job block my merges?
Not unless you decide it should. It runs alongside your existing checks.
What counts as a failure, and what happens after three?
A failure is one distinct cause of one or more failing runs or tests, so the same cause failing again in the same month counts once. Up to three causes a month are investigated and taken to a fix pull request, a tracked issue or an explanation. A fourth or later cause is listed in the summary with the failing tests and the first error line, and can be quoted.
Send an enquiry
Send us
- The repository link or the pipeline system you use, and the runtime or framework to track
- How long the test suite takes and how often it runs
- The current version and the next version you would want to be ready for
- Who reviews and merges pull requests
Later, once you agree
- A read-only token or app installation limited to run results and workflow files
- A fork or branch we can open pull requests from
- How to run the tests, and a schedule for the extra job of at least once a week
- Who to tell when a cause is outside the repository, and who may approve a quote for a larger change
Your repository, secrets and runners stay yours. We read pipeline run results with a read-only token you create and change files only on a branch or fork, through pull requests your team reviews and merges. We never ask for passwords in the first enquiry.
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 “upgrade-next-version-canary-kept-green” as the subject.