Solution for My Deployment Goals: Canary Deployment with Vercel

Discussions
1

Hi

I’m exploring the adoption/s of a Canary deployment strategy for my application hosted on Vercel. After reviewing available resources and experimenting with the blue-green deployment template, I’ve come across two insightful guides:

  1. Implementing Blue-Green Deployments on Vercel

  2. Implementing Canary Deployments on Vercel

From my perspective, both approaches essentially describe a Canary deployment strategy. Am I missing a key distinction between the two?

I’ve outlined a high-level deployment plan below and am looking for input to validate my approach. Specifically, I need guidance on implementing the whitelisting of internal testers as part of the strategy. Here’s the draft plan:

Deployment Plan

Assumptions

• Active Skew Protection enabled.

• Deployment Protection Bypass is active.

• Auto-assignment of the custom production domain is disabled.

• Middleware described in the referenced articles is implemented.

• The current production deployment is live on the custom domain for all users.

Steps

  1. Build Trigger: On a push to main in GitHub, Vercel automatically creates a staging production deployment, initially available to 0% of users.

  2. Internal Testing: A predefined set of whitelisted IPs (internal testers) is routed to the staging deployment when accessing the custom production domain.

  3. Canary Rollout: Testers (or automated processes) can initiate gradual, percentage-based traffic splitting, incrementally directing users to the new deployment.

Rollback Procedure

• t0: Set trafficCanaryPercent to 0%, ensuring only whitelisted IPs access the new deployment.

• t1: All non-whitelisted users revert to the original (old) deployment.

Why I Like This Approach Works

• Simplified Branching: No need for a complex GitHub branching strategy; I can always roll back to the prior production version on Vercel and fix forward on the code side with a new version.

• Consistency: All deployments are treated as production, avoiding the drift between preview and production environments.

• CORS Simplicity: No cross-origin issues when testing since I’m working with consistent Vercel domains.

Where I Need Help

I need guidance on the whitelisting of internal testers. How can I effectively implement this? Specifically:

• What is the best way to define and enforce IP-based rules in the middleware?

• Are there any Vercel-specific features or integrations that simplify this process?

Additional Context

• We proxy requests through Cloudflare.

Looking forward to feedback, particularly on optimizing this strategy and implementing the final rollout control mechanism.

Thanks!

2

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.