Deployment Strategy

[ap786771]

🚀 Deployment Strategies in DevOps & Kubernetes

In today’s world of always-on applications, deploying new versions without breaking user experience is critical. That’s where Deployment Strategies come in. They define how we roll out new versions of applications safely, efficiently, and with minimal downtime.

Here’s a breakdown of the most widely used strategies:

1️⃣ Recreate Deployment

How it works: Stop the old version → Start the new version.

Pros: Simple, no resource overhead.

Cons: Causes downtime during deployment.

Best for: Non-production or internal apps where downtime is acceptable.

2️⃣ Rolling Update

How it works: Gradually replace old pods with new pods (one by one or in batches).

Pros: No downtime, gradual rollout.

Cons: Rollback can be slow.

Best for: Most production workloads in Kubernetes (default strategy).

3️⃣ Blue-Green Deployment

How it works: Two environments → Blue (current) and Green (new). Traffic switches to Green once it’s stable.

Pros: Instant rollback (just switch traffic back).

Cons: Double infrastructure cost.

Best for: Critical applications requiring zero downtime and quick rollback.

4️⃣ Canary Deployment

How it works: Release new version to a small % of users first → Monitor → Gradually increase rollout.

Pros: Low risk, real-world testing with actual users.

Cons: More complex monitoring & routing needed.

Best for: Large-scale applications where user impact must be minimized.

5️⃣ Shadow Deployment

How it works: New version runs in parallel, but traffic is duplicated (mirrored) to it without impacting users.

Pros: Safe, tests performance under real traffic.

Cons: Requires extra infra, results don’t affect users.

Best for: Performance testing & validating new versions in real-world conditions.

✅ Key Takeaways

Choose your strategy based on downtime tolerance, rollback requirements, infra cost, and risk appetite.

Rolling Updates are great defaults, while Blue-Green and Canary shine in production-grade environments.

Pair strategies with strong monitoring + observability (Prometheus, Grafana, ELK, etc.) for safe rollouts.

Summary by CodeRabbit

• Chores
  • Updated the Online Shop service to use a new container image aligned with the latest build.
  • No user-facing functionality changes expected; routine maintenance to keep the runtime and dependencies current.
  • Improves consistency across environments for ongoing operations.
  • Deployment behavior remains unchanged for end-users.

[coderabbitai]

Walkthrough

Updated the Kubernetes Deployment manifest to change the container image for the online-shop container from amitabhdevops/online_shop to abhishek450/online_shop. No other fields were modified.

Changes

Cohort / File(s)	Summary of Changes
K8s Deployment Image Update Deployment_Strategies/Recreate-deployment/recreate-deployment.yml	Switched container image in spec.template.spec.containers[0] from amitabhdevops/online_shop to abhishek450/online_shop; no other spec changes.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Pre-merge checks (3 passed)

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title "Deployment Strategy" is directly related to the PR objectives which focus on documenting deployment strategies and updates under the Deployment_Strategies path (including the Recreate-deployment YAML), so it accurately reflects the main theme of the changeset; it is concise but does not call out the specific container image update.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

Poem

A bunny taps the helm with cheer,
Swaps one ship’s image, crystal clear.
Pods hop out, then back in line,
New tag gleams—deployment fine.
Carrot logs show green—all clear! 🥕✨

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 76a0375 and e1773bf.

📒 Files selected for processing (1)

• Deployment_Strategies/Recreate-deployment/recreate-deployment.yml (1 hunks)

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}