{"id":878,"date":"2026-10-27T03:40:00","date_gmt":"2026-10-27T03:40:00","guid":{"rendered":"https:\/\/planespart.com\/blog\/?p=878"},"modified":"2026-10-27T03:40:00","modified_gmt":"2026-10-27T03:40:00","slug":"planespart-gitlabops-hangar-year","status":"publish","type":"post","link":"https:\/\/planespart.com\/blog\/planespart-gitlabops-hangar-year\/","title":{"rendered":"A Year of GitLabOps on the Hangar Floor"},"content":{"rendered":"

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 \u2014 the Ops Atlas’s practical shorthand for running software delivery on GitLab \u2014 stands for small aviation businesses right now.<\/p>\n

What Changed in the GitLabOps Year<\/h2>\n

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 \u2014 the agent for Kubernetes as the sanctioned bridge between pipelines and clusters \u2014 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.<\/p>\n

A Parts Desk Meets Its Runner Fleet<\/h2>\n

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 \u2014 which nobody had trusted enough to schedule often \u2014 began running on every merge request instead of once a month, and the monthly vulnerability spreadsheet quietly retired itself.<\/p>\n

GitLabOps Decisions Score Better on Paper First<\/h2>\n

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 \u2014 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.<\/p>\n

GitLabOps Maturity, Climbed One Rung at a Time<\/h2>\n

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:<\/p>\n

    \n
  1. Ad-hoc \u2014 pipelines exist, standards do not, and heroics carry every release.<\/li>\n
  2. Repeatable \u2014 the same jobs run everywhere, but each project keeps private habits.<\/li>\n
  3. Defined \u2014 shared components are pinned, workflow rules are written, duplicates are gone.<\/li>\n
  4. Managed \u2014 two numbers on a whiteboard, queue time and review turnaround, checked quarterly.<\/li>\n
  5. Optimising \u2014 fleet, capacity and cost decisions trace back to measurements.<\/li>\n<\/ol>\n

    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 \u2014 queue time and review turnaround against targets of two and fifteen minutes \u2014 is rung four in practice. Rung five remains aspirational, and the team says so out loud, which is itself a mark of maturity.<\/p>\n

    When a Small Team Should Not Invest<\/h2>\n

    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: <\/p>\n