The first time I watched a parts catalog go out through a pipeline instead of a USB stick, the release engineer apologised for the wait. It took eleven minutes, most of it queued behind somebody else’s build. Twelve months later the same catalog ships in under four, nobody apologises, and the two-person software team that serves this business spends its Fridays on inventory rather than firefighting. Nobody reorganised the company to make it happen; they simply stopped accepting folklore as an explanation. That year, looked at closely, is a fair portrait of where GitLabOps — the Ops Atlas’s practical shorthand for running software delivery on GitLab — stands for small aviation businesses right now.
What Changed in the GitLabOps Year
Three shifts stand out when the months are stacked side by side. The platform itself kept a brisk cadence; the current line sits at 19.x, and disciplined operators plan an upgrade roughly every month or two rather than once a geological era. Expectations moved too: boards that once accepted “the deploy failed, we are looking into it” now expect an answer with a number attached. And the tooling story consolidated around one architectural idea — the agent for Kubernetes as the sanctioned bridge between pipelines and clusters — which quietly retired a decade of improvised kubeconfig files sitting in variables fields. None of it arrived through a keynote; it arrived in release notes, and teams that read them noticed first.
A Parts Desk Meets Its Runner Fleet
Our distributor’s story begins, as most do, with a queue. Builds idled twenty minutes at a stretch while a single overworked machine churned through everything: website deploys, pricing imports, the scanning jobs that check dependencies for known vulnerabilities. The instinct was to buy a bigger server. The fix, it turned out, was not more iron; it was zoning. The team wrote down which work involved code from outside the company, gave that work dedicated ephemeral machines that die after one assignment, and tagged the rest by capability. Within a fortnight the queue cleared without a single new server. Freed from competition, the scanning jobs — which nobody had trusted enough to schedule often — began running on every merge request instead of once a month, and the monthly vulnerability spreadsheet quietly retired itself.
GitLabOps Decisions Score Better on Paper First
The most instructive afternoon of the year was a scoring exercise. Faced with rising compute costs, the team listed every fleet option and graded each against its real requirements: burst capacity, isolation, maintenance burden, price per successful pipeline. The Docker Autoscaler arrangement led at 3.85. Then, in drafting the requirements, somebody asked whether the private-network linkage those builders depended on was actually needed any longer — the vendor integrations had long since moved behind public APIs. With that requirement withdrawn, hosted runners rescored at 4.30 and the decision flipped. Nothing about the infrastructure changed that afternoon; the requirements did. That is the quiet lesson of the Atlas’s worked example: a fleet choice is only as good as the honesty of the list it is scored against.
GitLabOps Maturity, Climbed One Rung at a Time
Nobody in this story announced a transformation programme. What actually happened fits the five-level ladder the Atlas draws, which climbs from improvisation to evidence:
- Ad-hoc — pipelines exist, standards do not, and heroics carry every release.
- Repeatable — the same jobs run everywhere, but each project keeps private habits.
- Defined — shared components are pinned, workflow rules are written, duplicates are gone.
- Managed — two numbers on a whiteboard, queue time and review turnaround, checked quarterly.
- Optimising — fleet, capacity and cost decisions trace back to measurements.
For most of the year the team sat on rung two: pipelines everywhere, standards nowhere. Pinning the shared components and writing one workflow rule that finally killed duplicate builds moved them to a defensible three. The quarterly review — queue time and review turnaround against targets of two and fifteen minutes — is rung four in practice. Rung five remains aspirational, and the team says so out loud, which is itself a mark of maturity.
When a Small Team Should Not Invest
An honest year-in-review includes the counter-case. The Atlas’s adoption guidance is blunt, and worth taping to a monitor. Heavier investment earns its keep under three conditions:
- the platform serves several teams with competing needs;
- the installation is self-managed and somebody must own its upkeep;
- continuous integration has grown into a material cost line worth optimising.
Outside those conditions, a single small team on GitLab.com should keep the whole thing light — one tidy pipeline, honest tags, no platform bureaucracy. Our distributor crossed the “several products, one part-time team” threshold around March, which is precisely when the zoning and scoring exercises began paying for themselves.
Keeping the Hangar Honest Next Year
The habits that made the difference were humble: a checklist reviewed before each quarter, the way an owner works through a fuel-system checklist before a cross-country; an upgrades calendar treated as an inspection, never deferred twice; and a refusal to make platform decisions without a scored list beside them. Readers weighing the infrastructure side of the same equation will find useful ground in this guide to scalable cloud infrastructure, and anyone mapping the skills such a team needs next should like this piece on growing an engineering career. For the reference standard behind most of the practices above — hosting thresholds, the upgrade stops, the worked fleet scoring — the Atlas’s GitLabOps entry remains the single page worth bookmarking. The catalog ships faster now, the audit trail reads like a logbook instead of a mystery, and the two-person team takes its Fridays back. The real product, though, is the calm.
