Continuous integration and continuous delivery (CI/CD or CICD)

Continuous integration and continuous delivery (CI/CD or CICD)

TODO

1. detailed steps from jenkins pipeline.
2. When is the docker image built?
3. What happens to that Docker image.
4. How are containers spawned from the docker image? In both ECS and EKS?

Deployment frequency

https://medium.com/@manjunath.rs/from-%EF%B8%8F-sprints-to-streams-rethinking-deployment-frequency-in-the-ai-era-898a8ee1ac68

Are you still shipping only once every two weeks?

How Deployment Frequency Was Born

Back in the 1990s, releases were epic events. Code piled up for months, bundled into “big bang” releases. They were risky, stressful, and often underwhelming.

Then came the Agile Manifesto (2001), which flipped the script: deliver working software frequently. That principle introduced deployment frequency as a measure of agility.

Agile begot Continuous Integration (CI) and Continuous Delivery (CD) — automating builds, tests, and deploys so teams could ship every sprint. Suddenly, releases weren’t rare events. They were routine.

From Radical Idea to Industry Standard

Some tech giants turned deployment frequency into their superpower:

1. Amazon → embraced microservices & ownership; by 2011 they deployed every 11.6 seconds.
2. Netflix → pioneered canaries and feature flags, making continuous rollouts safe.
3. Facebook → shifted to daily pushes, shrinking the loop between idea and user feedback.

The result? Deployment frequency became not just about risk reduction, but about competitive advantage.

The Principles That Made It Work

Behind deployment frequency are timeless truths:

1. Small Batches → ship less, reduce risk
2. Automation Everywhere → pipelines build confidence
3. Fast Feedback Loops → more releases, more learning
4. Deploy ≠ Release → feature flags separate code from customer exposure
5. Culture of Trust → developers own what they ship, with rollback safety nets

These principles became the backbone of DevOps️ and the DORA metrics

Where We Are Now

Today, deployment frequency is a core KPI:

1. Elite teams️ → deploy multiple times/day
2. Mid-tier → weekly
3. Low performers → monthly or less

But most orgs are still tied to sprint cadence (every 2 weeks) — not because code can’t move faster, but because approvals, reviews, and governance slow things down.

With the advent of LLMs

Even with LLMs, Code is abundant. Confidence is scarce. Without guardrails, faster coding only leads to faster mistakes. This is the AI speed trap: velocity without evolved processes = risk.

Signs of What’s Coming

1. Amazon, Netflix, Shopify → already deploy on demand
2. Feature flag platforms → booming (LaunchDarkly, Unleash)
3. AI in pipelines → LLMs making rollout, test, and risk decisions

The writing’s on the wall.

The Future: From Sprints to Streams

Tomorrow’s deployment frequency won’t look like “faster sprints.” It will look like:

1. On-Demand Releases → ship anytime, safely.
2. AI Guardrails → compliance, risk scoring, rollback automation.
3. Progressive Delivery by Default → canaries, A/B, blue-green.
4. From Cadence to Flow → continuous streams of changes, not biweekly trains.

Not every company needs to deploy every 11.6s️ — but every company will need to move faster, safer, and smarter.

Final Reflection

Deployment frequency was born when code was scarce. In the AI era, code is abundant. The scarce resource now is confidence — confidence in testing, governance, and culture.

The winners of tomorrow won’t just code faster. They’ll deliver value faster, smarter, and safer.

From sprints to streams: that’s the real future of deployment frequency.