{"id":4317,"date":"2026-10-27T17:25:00","date_gmt":"2026-10-27T17:25:00","guid":{"rendered":"https:\/\/www.devopstrainer.in\/blog\/?p=4317"},"modified":"2026-10-27T17:25:00","modified_gmt":"2026-10-27T17:25:00","slug":"gitlabops-team-quarter-training-story","status":"publish","type":"post","link":"https:\/\/www.devopstrainer.in\/blog\/gitlabops-team-quarter-training-story\/","title":{"rendered":"One Team’s GitLabOps Quarter: A Training Story"},"content":{"rendered":"

Kestrel Freight is not a real company, which is precisely why it can tell the truth. Composite it from the dozen platform teams I have trained and you get the same picture every time: eleven engineers, one self-managed GitLab estate, four product lines sharing a runner pool, and a deploy story told with wide eyes. I worked with them for one quarter as their trainer, and because the Atlas now gives this scope a name \u2014 GitLabOps, a coinage of the Atlas rather than anything official \u2014 the syllabus finally had a spine. What follows is the quarter as I would teach it, with the names changed and the numbers kept honest. Trainers get one advantage operators lack: we see a dozen estates a year, so the patterns repeat early for us. Kestrel is every one of those estates, compressed into one calendar for the sake of the lesson.<\/p>\n

The Team and the Mess They Started With<\/h2>\n

The baseline audit found everything a trainer hopes to find, because every finding is a lesson with the wrapping still on. One privileged Docker-in-Docker pool served every product line. Cloud credentials from a 2023 migration sat in CI variables. Two product lines’ pipelines inherited overlapping includes, so a template edit in one repo broke three repos the same morning. Deploys to production needed “a nod from someone senior”, which was not a control but a rumour. And the platform version had drifted five minors behind because upgrades were scheduled “when things are quiet” \u2014 a season that, in freight logistics as in software, never actually arrives. The audit took two days. Writing it plainly took longer than fixing half of it.<\/p>\n

The Quarter, Month by Month<\/h2>\n

Month one: inventory and trust<\/h3>\n

We began by drawing the four loops on the whiteboard \u2014 configuration, scheduling, delivery, platform \u2014 and mapping every pipeline, runner, token and environment onto them. Then came the fleet split: runners for protected branches moved to their own tier, build environments became ephemeral, and the runners doing protected-branch work were set to retire after a single job. The shell executor option was removed entirely for anything built from outside code. Nothing about this was clever; all of it was drawn on the whiteboard before it was done in the console, which is exactly why it survived contact with real deadlines.<\/p>\n

Month two: identity and guardrails<\/h3>\n

The 2023 credentials were revoked on a Tuesday and replaced by short-lived OIDC tokens issued fresh for each job, with the signing-grade credential reserved for the deploy job and nothing else. Production was marked protected, deployment runs to the same target were serialised, superseded deploy jobs learned to reject themselves, and the production container tag was locked to maintainers. Images began shipping with signatures that the pull-side controller verifies before anything rolls out, which quietly ended the ancient argument about whose job verification was \u2014 the machine now has the job. The team’s own phrase for the feeling was “the corridor got narrower” \u2014 approvals became structure instead of seniority. Two engineers who had bristled at the change in week five were defending it to a visitor by week nine, which is the timeline most cultural change actually follows.<\/p>\n

Month three: rhythm and proof<\/h3>\n

Three artefacts went up on the wall that week:<\/p>\n