CodeOath
← All posts
CI/CD & DevOps60 min total · 17 parts

CI/CD Pipelines Explained: From git push to Production

Contents — Part 2 of 17: Three Different Things, One Slash
  1. 1.Overview
  2. 2.Three Different Things, One Slash
  3. 3.Why Automate This At All
  4. 4.Anatomy of a Pipeline
  5. 5.A Real Pipeline, Stage by Stage
  6. 6.Triggers: What Actually Starts a Run
  7. 7.Jobs, Steps, and Runners
  8. 8.Caching Dependencies
  9. 9.Testing in CI: What Runs, and When
  10. 10.Build Artifacts and Why You Promote, Not Rebuild
  11. 11.Why Staging Exists
  12. 12.Secrets Management
  13. 13.Deployment Strategies
  14. 14.Feature Flags: Decoupling Deploy from Release
  15. 15.Rollbacks
  16. 16.Monitoring and Post-Deploy Verification
  17. 17.Common Mistakes Worth Remembering
Part 2 of 17 · ~1 min

Three Different Things, One Slash

Diagram of a CI/CD pipeline from git push through build, test, package, and deploy stages

  • Continuous Integration (CI) — every push is automatically built and tested. This alone catches "works on my machine" problems the moment they happen, not days later, and catches two developers' changes conflicting with each other before either of them finds out manually.
  • Continuous Delivery — every change that passes CI is automatically packaged into a release that's ready to deploy — but an actual deploy to production still needs a human to click a button.
  • Continuous Deployment — every change that passes CI deploys to production automatically, with no manual gate at all.

Most teams that say "CI/CD" mean CI plus Continuous Delivery — automated up to the door of production, with a person deciding when to walk through it. True Continuous Deployment (no human gate, ever) is real at some organizations, but it demands a level of test coverage, monitoring, and fast-rollback tooling that most teams haven't actually built yet — turning it on without that foundation just means bugs reach production automatically instead of manually.

← Previous
Overview
Next →
Why Automate This At All