Angular Canary Deployment Strategy Implementation

Canary deployment is a deployment strategy that reduces risk by gradually rolling out new versions of an application to a small subset of users before rolling it out to the entire user base. This challenge asks you to implement a simplified canary deployment mechanism within an Angular application to control which version of a component is displayed to different users.

Problem Description

Your task is to build an Angular application that demonstrates a basic canary deployment for a specific feature or component. You'll need to simulate the logic that determines whether a user sees the "stable" version or the "canary" (new) version of a particular UI element.

What needs to be achieved:

• Create an Angular component that has two distinct versions: a stable version and a canary version.
• Implement a mechanism to randomly assign users to either the stable or canary group.
• The application should render the appropriate component version based on the user's assigned group.

Key requirements:

• Two Component Versions: You will need to create two Angular components that represent the same logical feature but have different implementations or UI. For simplicity, these can be visually distinct (e.g., different background colors, text).
• Random Group Assignment: Implement a service or logic that assigns each "user" (simulated by a browser session) to either the "stable" group or the "canary" group. A simple random percentage split (e.g., 80% stable, 20% canary) is sufficient.
• Dynamic Rendering: The main application component should conditionally render either the stable or canary component based on the user's assigned group.
• Persistence (Optional but Recommended): For a more realistic simulation, try to make the group assignment persistent across page reloads for a given browser session. Local storage can be used for this.

Expected behavior:

• When a user first accesses the application, they are randomly assigned to either the stable or canary group.
• Subsequent requests from the same user (within the same browser session) should consistently display the version they were initially assigned.
• A significant majority of users should see the stable version, with a small percentage seeing the canary version.

Edge cases to consider:

• First-time user: How is the initial assignment handled?
• User with no prior assignment: Ensure a new assignment is made.
• Browser session termination/clearing: If persistence is implemented, what happens when local storage is cleared or the browser session ends? (For this challenge, simply re-assigning on a new session is acceptable if full persistence is too complex).

Examples

Example 1:

• Scenario: A new user visits the application for the first time.
• Input: No prior assignment in local storage.
• Output: The application displays the "Stable Component" (e.g., a blue button). The user is randomly assigned to the "stable" group.
• Explanation: Since this is the user's first visit, a random assignment is made. In this instance, they were assigned to the stable group.

Example 2:

• Scenario: A user who was previously assigned to the "canary" group revisits the application.
• Input: Local storage indicates the user is in the "canary" group.
• Output: The application displays the "Canary Component" (e.g., a green button).
• Explanation: The application checks the persistent assignment and renders the canary version as per the stored preference.

Example 3:

• Scenario: Simulating a deployment where 90% of users should see the stable version and 10% the canary.
• Input: A large number of simulated user sessions are initiated.
• Output: Approximately 90% of sessions render the "Stable Component" and approximately 10% render the "Canary Component".
• Explanation: The random assignment logic is applied across many simulated sessions, demonstrating the distribution.

Constraints

• The application must be built using Angular.
• The solution should be written in TypeScript.
• A simple random number generator should be used for group assignment (no complex A/B testing frameworks are required).
• The split between stable and canary users should be configurable (e.g., via a constant in a service). A reasonable default is 90% stable, 10% canary.
• The primary goal is to demonstrate the logic of canary deployment, not a robust, production-ready system.

Notes

• Consider creating a dedicated service (e.g., CanaryDeploymentService) to manage the group assignment logic and storage.
• For the component versions, you can keep them very simple. For instance, one component could display "Welcome (Stable!)" and the other "Welcome (Canary!)", with different background colors.
• Think about how you'll trigger the component rendering. An *ngIf directive based on a condition from your service is a common Angular pattern for this.
• You can simulate different users by opening the application in incognito mode or by clearing your browser's local storage and then reloading.