Daniel Holz published Part 1 on 10 June 2022. FreeAgent is UK online accounting software. The main app is a Rails monolith with more than 58,000 unit, integration, and feature specs.
They run the whole suite on every push, and again on merge. One machine would take about nine hours. Parallel runners bring that to about three to four minutes.
Part 1 promised a second post on the cutover. Daniel’s author page still lists only Part 1. The 16 June 2022 URL 404s. I am not reconstructing a how from a missing page.
If you are looking at the same route, start with the Jenkins → GitHub Actions playbook. GitHub’s manual Jenkins guide is the generic path. FreeAgent’s published half is the why, the pain, and the outcome numbers.
Why Jenkins was the wrong leftover
Jenkins had followed them from the data centre to AWS in 2020. It still did useful work. Build on change. Test reports. Slack status. Many agents. Cached gems on those agents.
Recovery was the tax. One dead agent marked the whole parallel build FAILURE. You reran everything. A poisoned dependency on one box failed every job that landed there. They found those agents by reading logs and pulled them by hand.
One Jenkins master ran every repo. When it hit resource limits, all builds stopped. Upgrades were a Java and Groovy problem on a Ruby team. Smoke tests on staging still were not a full build next to production. They talked about multi-hour freezes every few months just to stay current.
Spot c5.4xlarge agents, driven by the Amazon EC2 Jenkins plugin, made it worse. Instances escaped Jenkins and needed a cleanup job. Retail peaks pulled that instance type back to On Demand. Agents vanished. They flipped to On Demand for the season and tried to remember to flip back in January. AMI IDs and other settings lived in the UI, with a wiki list for rollback.
What they wanted was a worker pool someone else patched, and a scheduler the Developer Platform team did not own.
Why Actions, and what they say they got
They already ran static checks on GitHub Actions. They already paid GitHub and hosted gems there. YAML looked easier to teach than Groovy. Marketplace actions were easier to read than Jenkins plugins.
The outcomes in Part 1 are theirs:
- p95 deploys from 25 minutes to 16
- about 90% less monthly spend on test infrastructure
- fewer instance interruptions, and no failures from leftover agent state
- less firefighting
The shape they name is GitHub Action workflows plus AWS EC2 Fleets of ephemeral instances. That is the architecture sentence. There is no workflow file, no runner AMI, and no dual-run plan in Part 1.
A later Dev Platform interview says the Jenkins-to-Actions move is done. Maintenance time dropped. The suite there is “more than 60,000 tests” in about six minutes, with a deploy about twelve minutes after merge. Those are Peter’s later numbers, not Daniel’s 2022 ones. I am keeping them separate.
What I would copy
Do not upgrade Jenkins in place if the pain is poisoned agents and a single master. FreeAgent looked at maintenance windows and refused to block deploys every quarter.
Measure p95 and the test-infra bill before you start. Those two figures are why Part 1 is worth reading without Part 2.
If you use Spot for agents, write down the instance family and the retail calendar. Their c5.4xlarge hole is a capacity problem, not a YAML problem.
Keep Jenkins until a known branch has run on Actions without a leftover workspace. Part 1 never describes that flip. GitHub’s importer will draft workflows. It will not invent ephemeral EC2 Fleets.
The Jenkins → GitHub Actions playbook is the checklist. Use Part 1 for the 58,000-test reasons, and do not pretend the missing Part 2 is in the archive.