Skip to content

CI/CD

From 220 Lines of Debt to a Single CI Template

A pull request to update a service's CI pipeline landed. It deleted 220 lines of YAML and shell script, adding only 50. The test suite passed, the deployment succeeded, and the service hummed along as if nothing had happened. A 75% reduction in pipeline code with zero functional changes looks like a magic trick, but it was the quiet, deliberate outcome of a strategy we'd been executing for over a year: standardizing our CI/CD practices by moving from scattered, bespoke scripts to a shared, centrally managed template.

The CI Job That Replaced Our Release Committee

The Tuesday 10 AM release-review meeting was gone. In its place was a single, green checkmark in a pull request: release-process-compliance: success. No more checklists in a wiki, no more cross-referencing tickets, no more asking, "Did someone remember to update the changelog?" That single, automated check confirmed it all.

The Boolean That Lied

I set IS_RELEASE_CANDIDATE=false in the pipeline config. Ten minutes later, production shipped a release nobody signed off on.

The flag was right. The intent was right. But somewhere between the YAML file and the deployment script, false stopped meaning false. The parser read the string "false" as a non-empty value, and non-empty meant truthy. My kill switch had flipped itself the moment I set it.

I've since learned this wasn't a fluke. It's a pattern with a name, and it bites teams that treat configuration as an afterthought.