CI/CD Pipelines Explained: From Push to Production

Part 3 of 17 · ~1 min

Why Automate This At All

Before there's a pipeline at all, "integration" for snapledger means: you, Marcus, and Priya each work on your own branch for a few days, then merge into main and find out together whether it still works. It mostly does, until the week Marcus refactors how worker batches jobs off the queue at the same time Priya changes the shape of the data those jobs carry, and neither branch touches a line the other one touches — so nothing conflicts, GitHub lets both merges through cleanly, and the app is broken for ninety minutes before anyone runs it end to end and notices worker is silently dropping every third receipt.

That's the actual case for automating this, and it has nothing to do with buzzwords: the smaller the gap between "someone changed something" and "someone finds out whether it still works," the cheaper the fix is, because the person who broke it still remembers exactly what they touched. Wait three days and the fix costs an afternoon of git bisect; catch it in ninety seconds on the push that caused it and the fix is usually one line, made by the person already looking at the file.

It generalizes past "does it run," too. Priya's lint config and Marcus's lint config have quietly drifted — his editor auto-fixes semicolons on save, hers doesn't — and every third pull request turns into a five-minute argument about formatting that has nothing to do with the actual change being reviewed. A pipeline doesn't care whose editor does what; it runs the same check, the same way, on every single push, and a formatting disagreement stops being something two humans negotiate and becomes something a machine either passes or fails.