CI/CD and Deployment Strategies

An automatic pipeline that builds, tests and deploys from code commit to production, plus ways to release a new version without downtime.

Manual deploys are error-prone and slow; with CI/CD you can deploy safely 10-100 times a day.
CI (Continuous Integration): automatic build + unit tests on every commit, so bugs are caught early.
CD (Continuous Delivery/Deployment): a tested build moves automatically to staging/production.
With the right deployment strategy (canary, blue-green) a new bug hits only a few users and the whole site does not go down.
With a fast rollback, the damage of a bad release is contained within minutes.

Pipeline stages: Checkout -> Build -> Unit test -> Security scan -> Docker image push -> Deploy staging -> Integration test -> Deploy prod.
Rolling update: replace old instances with the new version batch by batch; no extra infra needed, but rollback is slow.
Blue-Green: two identical environments; test the new version on Green, then switch the load balancer/DNS so all traffic goes to Green; rollback = go back to Blue.
Canary: send 1-5% of traffic to the new version first, and if metrics (error rate, latency) look fine, raise it to 25%, 50%, 100%.
Feature flags: the code is deployed but the feature flag stays OFF; later turn it ON/OFF without a deploy, or ON for only some users.
GitOps (ArgoCD): the Git repo is the source of truth; ArgoCD keeps the cluster state matching the YAML in Git.
Rollback: redeploy the old image tag (kubectl rollout undo) or turn the feature flag OFF; DB migrations must stay backward compatible.

CI/CD pipeline: checkout service, commit to prod

CI = build + test on every commit. CD = a tested build goes automatically to staging/prod. GitOps: Git = source of truth.

Canary release: v2.3.9 stable to v2.4.0 new

Smallest blast radius: a bug reaches only 1-5% of users.

Rolling vs Blue-Green vs Feature flag

1.Rolling: step 1 v1 v1 v1 v1 -> step 2 v2 v1 v1 v1 -> step 3 v2 v2 v2 v1; no extra infra, K8s default, slow rollback, mixed versions run together for a while
2.Blue-Green: the Load Balancer switches from Blue v1 (old) to Green v2 (tested); rollback = back to Blue in seconds, 2x infra, keep DB migrations backward compatible
3.Feature flag: v2.4.0 deployed with the 'one-click pay' code inside, Flag OFF (for nobody) -> Flag ON (at 12 midnight); deploy and release are separate, rollback = flag OFF instantly (LaunchDarkly / Unleash)

Tool	Type	How it is used
Jenkins	Open-source CI/CD server	Self-hosted, pipeline via a Jenkinsfile; 1800+ plugins, very common in older enterprise setups.
GitHub Actions	Hosted CI/CD	YAML in .github/workflows in the repo; build-test-deploy on push/PR, ready-made marketplace actions available.
GitLab CI	Hosted / self-hosted CI/CD	Pipeline via .gitlab-ci.yml; GitLab repo, registry and security scans all in one place.
ArgoCD	GitOps CD for Kubernetes	Syncs the K8s cluster as soon as YAML changes in Git; Argo Rollouts adds canary/blue-green.
AWS CodePipeline / CodeDeploy	AWS managed CI/CD	Rolling and blue-green deploys on EC2, ECS, Lambda, with automatic rollback on an alarm.
LaunchDarkly / Unleash	Feature flag service	Turn a feature ON/OFF by percentage, region or user group, without a redeploy.

Point	Rolling	Blue-Green	Canary	Feature Flags
How it works	Replace instances in batches	A whole new environment, switched in one go	A little traffic first, then raise slowly	An if-condition in code, ON/OFF at runtime
Extra infra	No	2x infra (temporary)	A little extra	No
Rollback speed	Slow, another rolling update	Seconds, traffic goes back to Blue	Fast, canary traffic to 0%	Instant, flag OFF
Risk / blast radius	Medium, mixed versions run together	All users at the moment of the switch	Lowest, only 1-5% of users	Very low, only chosen users
Complexity	Low, K8s default	Medium, DB sync is tricky	Higher, needs metrics + traffic split	Medium, flag cleanup is a must
Best for	Normal small releases	Big releases that need instant rollback	Risky changes, high traffic sites	Business feature launches, A/B tests

GitHub Actions/GitLab CI: easiest for CI if your code is hosted there; Jenkins when you are on-prem and need heavy customisation.
ArgoCD: on Kubernetes, GitOps is the best CD; what is deployed is visible in Git.
Canary: when traffic is huge and one bug can cost crores (payment, checkout).
Blue-Green: when you need instant rollback and can afford 2x infra temporarily.
Feature flags: when deploy and release must be separate, for example turning a sale feature ON at 12 midnight.

A canary release of the checkout service (an illustrative scenario, Amazon-like).

A developer opens a PR; GitHub Actions runs unit tests, lint and a SAST scan.
On merge a Docker image is built and pushed to ECR with the tag v2.4.0.
The pipeline updates the image tag in the Helm values in the Git repo; ArgoCD sees the change and syncs staging.
After automated integration tests pass on staging, Argo Rollouts starts the canary in prod: 5% of traffic on v2.4.0.
For 10 minutes Prometheus checks error rate and p99 latency; if the error rate is under 0.1% it goes 25%, 50%, 100%.
If 5xx errors rise even at the 5% stage, Argo Rollouts aborts automatically and sends 100% of traffic back to v2.3.9.
The new 'one-click pay' feature is in the code but the flag is OFF; on sale day at 12 midnight the product team turns the flag ON.

Explain the difference between Continuous Delivery (prod deploy with manual approval) and Continuous Deployment (fully automatic).
Common mistake: not keeping DB schema changes backward compatible; after a rollback the old code breaks on the new schema (use the expand-contract pattern).
Running a canary without an automatic metrics check is pointless, since nobody is watching.
Never deleting old feature flags turns the code into a jungle of flags. Number to quote: canary 5% -> 25% -> 50% -> 100%, promote while error rate < 0.1%.