CI/CD Pipelines Explained: From Push to Production

Part 2 of 17 · ~1 min

Three Different Things, One Slash

"We have CI/CD" is doing three different jobs depending on who says it, and snapledger genuinely moves through all three, in order, over about six weeks:

• Continuous Integration (CI) — build and test run against whatever just got pushed, automatically, no human deciding when it's worth checking. This is the first thing the team gets, and it alone kills the Friday-tag problem's cousin: a bug that only shows up when Marcus's and Priya's branches both touch the same file, caught the moment either one pushes instead of the moment they both try to merge into the same release.
• Continuous Delivery — anything that clears CI is built into a release candidate and left sitting there, fully ready to go live, until a person decides it's the one and says so.
• Continuous Deployment — the same packaging, minus the person. It ships the instant it's green.

Snapledger settles on the middle one, deliberately, and it's worth being honest about why: full Continuous Deployment is not a maturity badge you unlock by wanting it badly enough. It works only once you trust your test suite enough to let it be the only thing standing between a bug and a customer, and once a bad deploy is cheap and fast to detect and undo automatically — which is exactly the rollback and monitoring machinery covered near the end of this piece, and which snapledger, three weeks into having any pipeline at all, does not have yet. Skip straight to zero-human deploys before that's true, and the pipeline hasn't removed the risk of a bad Friday deploy — it's just made the bad deploy faster and harder to stop.