Data teams have spent years learning that folklore dies hard: the dashboard everyone trusts was built on a broken join, the “automated” report has a manual step hidden inside a cron job, the “single source of truth” has three owners. The same scepticism is overdue on the delivery side of the house. GitLabOps — the Atlas’s shorthand for operating software delivery on GitLab, nothing more official than that — has collected its own folklore in a remarkably short time, and data engineers who inherit a CI estate alongside their warehouses are the likeliest victims. Below are the five myths that come up most often in the wild, each one tested against what the platform actually does rather than what a conference talk claimed.
Where GitLabOps Folklore Comes From
Most of these beliefs started life as true-ish observations that outlived their context. Somebody solved a problem once, the fix got copy-pasted into every repository in the organisation, and within a year nobody can remember whether the fix was ever sound — only that “we always do it this way”. Sound familiar? It is the data-quality story all over again, which is why teams who enjoyed reading about stopping bad data before it reaches production will recognise the disease immediately. Bad assumptions, unmonitored, compound quietly until the day they surface as an incident.
Five GitLabOps Myths, Tested One by One
Myth 1: Our kubectl apply job makes us GitOps
A pipeline step that pushes changes into a cluster is a push. GitOps asks for more: state declared somewhere reviewable, a controller pulling it, and reconciliation running continuously so drift gets corrected without a human babysitting the diff. GitLab’s own guidance for production clusters pairs Flux with the agent for Kubernetes. If the only thing watching your cluster is a job that fires once per merge, you have automation, not reconciliation — roughly the difference between a scheduled dbt run and an enforced data contract. Both move rows; only one notices when reality disagrees.
Myth 2: The Kubernetes executor always wins on price
It is an option, not a law of economics. The Atlas works through a runner-strategy example in which Docker Autoscaler scored 3.85 against hosted runners at 4.30 — and the ranking flipped the moment private-network requirements disappeared from the picture. Cost per runner decision depends on saturation, idle behaviour and networking needs, so score your own constraints instead of inheriting someone else’s spreadsheet. Teams who have compared data platforms feature by feature already know how these evaluations end: the winner is contextual, and a written-down scorecard beats folklore every time.
Myth 3: Setting retry to two fixes flaky pipelines
A blanket retry of two does not fix flakiness; it launders it. The second attempt passes, the job goes green, and the signal that something is wrong with a test, a dependency or an environment never reaches a human. Data teams understand this instinctively — nobody seriously proposes fixing a failing validation by re-running the table until the check turns blue. Retry deliberately, only on named and understood failures, and keep a visible budget for the flakes you have consciously chosen to tolerate. Hidden retries are how silent data breakage and silent pipeline breakage look identical from the outside.
Myth 4: Pipelines are just YAML, how hard can it be
The configuration layer is a merge engine: includes and reusable components combine into one pipeline graph, and the classic failures are duplicates and invalid YAML surfacing at the least convenient moment. Treating that as casual text is like treating a DAG definition as a friendly suggestion. Structure earns its keep — workflow rules that decide what even runs, explicit needs for ordering, auto-cancel for superseded runs — and it is the same order that Dagster brings to tangled data graphs. The tooling differs; the discipline rhymes loudly.
Myth 5: The dashboard proves we are fast
Dashboards deserve interrogation, not applause. Pipeline duration, as reported, leaves out queue time, so a “fast” job that waited forty minutes for a runner is lying by omission. Percentile figures from different stages do not add together, however tidy the sum looks on a slide. And deployment dashboards in the DORA style count only successful production-tier releases — dry runs and rollbacks are invisible to them. Anyone who has defended a data-quality metric against a sceptical executive will recognise every one of these traps, because metric-gaming is metric-gaming whatever the domain.
Myth 6: Self-managed means we upgrade whenever it suits us
Deferral has a price curve, and it steepens. A healthy self-managed instance gets attention every six to eight weeks, stopping at the mid-stream versions the vendor flags as compulsory — the 2, 5, 8 and 11 minors — and letting background migrations run to completion before moving on. Stretch the gap well past a couple of minor versions and you have not saved time; you have booked a migration project with an incident attached as a bundle deal.
What to Do With This List
- Pick the single myth your team quietly believes.
- Pull one piece of evidence against it this sprint.
- Write down, in one line, what the platform actually did.
Small evidence beats loud opinion. The paper trail you build — a queue-time figure, a retry log, one component definition — is how expectation-based validation tamed data pipelines in the first place. The fuller definitions behind every point above are collected in the Atlas’s GitLabOps entry, the source this piece starts from. Myths survive on plausibility and die on contact with instrumented reality; five minutes against your own platform, with the logs open, usually retires one on the spot. Retire two and your next quarter becomes noticeably quieter; retire the whole set and the delivery side of your team finally earns the same trust as the data side.
