$ cat choices/robust-ci.md
the call
I aim for robust CI, not a particular CI tool. GitLab CI, GitHub Actions, and the rest are just instances; the goal is a pipeline the whole team trusts to catch what's broken before it ships. I pick the one that's actually robust for the team and the moment, not the one on the conference stage.
CI is the guardrail that makes speed safe, the tireless reviewer that runs on every change. Robust means trusted: green actually means good, red actually means stop, and it’s fast enough that nobody’s tempted to route around it. The moment a team stops believing the pipeline, it’s worse than not having one. That’s false confidence at scale, shipping bugs with a clean conscience. The deploy path is a product. Treat it like one.
The mistake is never skipping CI. It’s picking the tool first. The brand on the pipeline is downstream of the requirement: does it give you something this team will trust and maintain? Choosing for résumé or conference hype, or over-building a five-stage matrix for a weekend project, is the same error pointed in opposite directions. Name the robustness you need, then go buy it in whatever form fits.
At GigSmart we’d failed our way through CircleCI and Jenkins before we got CI right. When we landed on GitLab CI, GitHub Actions didn’t exist yet. GitLab was simply the tool that delivered the robust, merge-train-gated pipeline we needed at the time. The lesson was never “GitLab won.” It was that robustness is the requirement and the specific tool is whatever delivers it in your moment. Make the same call today and the answer might be Actions, and that’d be exactly right.— see: works / GigSmart
The tool is downstream of the goal, every time. Name the property you actually need (here: a pipeline the team trusts to catch what’s broken before users do), then choose the instance that delivers it now. Teams that get this wrong argue about CI vendors. Teams that get it right argue about what “robust” means for them, agree on it, then go buy it in whatever shape fits and switch without drama when the shape changes.
the gaps — what it costs even when it’s right
CI you don’t trust is worse than none. A flaky suite trains the team to ignore red, and false green ships bugs with confidence. Flake is the fastest way to erode the trust the whole thing depends on. Guard it like production.
Robust CI is a standing commitment, not a setup task. Someone owns pipeline speed, flake rate, and the config, or it quietly rots into the thing everyone routes around with “just merge it.”
Pipeline config is its own codebase, in a vendor’s DSL. Once it’s load-bearing it sprawls into includes, templates, and rules nobody fully holds in their head, and migrating CI vendors later is real, painful work. The choice has gravity even though “the tool is downstream.”