DIDO = Deploy In, Deploy Out

It is a practical workflow pattern used during application deployments to ensure zero downtime, smooth upgrades, and safe rollback.

Think of DIDO as:

• Deploy In: Bring the new version into the environment.

• Deploy Out: Move the old version out once the new one is verified.

✅ How DIDO Works (Simple Explanation)

1. Deploy In → Introduce the new version

You introduce (deploy) the new version of your application alongside the existing version.

• New container / new pod / new server instance is created

• Health checks run

• Traffic is NOT yet fully shifted

This is a safe testing zone.

2. Verification Phase

Before removing the old version, you ensure:

• Health checks pass

• APIs respond correctly

• No errors in logs

• Smoke testing works

• Performance is stable

If anything fails → simply REMOVE the new version (Deploy Out) and keep the old one.

3. Deploy Out → Remove the old version

Once everything looks good:

• Traffic is shifted to the new version

• Old version is scaled down or terminated

• System continues running smoothly with zero downtime

This makes rollback much easier and ensures safer deployments.

🔄 Where DIDO Is Used?

✔ Blue-Green Deployments

• Blue = existing version

• Green = new version
  DIDO ensures smooth switching.

✔ Canary Deployments

• New version receives 1–10% traffic → Deploy In

• If stable → ramp up → Deploy Out old version

✔ Rolling Deployments

Pods/instances replaced one by one → gradual DIDO.

✔ Kubernetes Deployments

• New ReplicaSet created → Deploy In

• Old one scaled down → Deploy Out

🧠 Why DIDO Is Important?

📘 DIDO in One Line

DIDO = Introduce the new version safely → Validate → Remove the old version.