From 803a55d103765d18a1b4f3a6b0e0e67c695cbd25 Mon Sep 17 00:00:00 2001 From: Nnenna Ndukwe Date: Fri, 14 Jun 2024 07:22:19 -0400 Subject: [PATCH] update canary deployments sections in examples (#7363) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## About the changes Cleaned up the canary deployment sections Closes # ### Important files ## Discussion points --- .../dotnet/dotnet-examples.md | 24 +++++++++++++---- .../java/spring-boot-examples.md | 24 +++++++++++++---- .../feature-flag-tutorials/python/examples.md | 24 +++++++++++++---- .../feature-flag-tutorials/react/examples.md | 18 ++++++++++--- .../ruby/ruby-examples.md | 26 ++++++++++++++----- 5 files changed, 91 insertions(+), 25 deletions(-) diff --git a/website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md b/website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md index 96902eeb99b9..9f56075370a9 100644 --- a/website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md +++ b/website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md @@ -67,19 +67,33 @@ Learn more about [gradual rollouts in our docs](/reference/activation-strategies ### What is a canary deployment? -Canary deployments are a way to test and release code in different environments for a subset of your audience. +Canary deployments are a foundational approach for deploying new software versions with high confidence and low risk by exposing the new version to a limited audience. Canary releases are a way to test and release code in different environments for a subset of your audience, which determines which features or versions of the platform people have access to. + +### Why use canary deployments? + +Canary deployments are a safer and more gradual way to make changes in software development. They help find any abnormalities and align with the agile process for faster releases and quick reversions. ### How to do canary deployments with a feature flag in .NET? -Canary deployments help find abnormalities, and align with the agile process for faster releases. And quick reversions, if necessary. +Feature flags provide the same benefits as canary deployments but with more granular control: + +- Precisely target specific user segments for feature rollouts. + +- Maintain session consistency (stickiness) if needed. + +- Test multiple features independently on different user groups simultaneously. + +- With feature flags, you can separate feature releases from deployments. + +Often, canary deployments are managed at the load balancer level while feature flags act at the application level. In some instances, rolling out groups of features together behind a feature flag can serve the purpose of a canary deployment. Unleash has a few ways to help manage canary deployments for .NET apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we implemented in the [previous section](#gradual-rollouts-for-.net-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-net-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. -- [Strategy constraints](/reference/strategy-constraints) or [segments](/reference/segments) (which are a collection of constraints) to determine which user receives which version for more control than a gradual rollout. +- Using either [constraints](/reference/strategy-constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout -- [Strategy variants](/reference/strategy-variants) for more advanced use cases. For example, if you want to test 2 different versions of a feature, you can use a strategy variant to split your population of users and conduct an A/B test with them. +- [Strategy variants](/reference/strategy-variants) are used to do the same canary deployment, but can be scaled to more _advanced_ cases. For example, if you have 2+ new features and are testing to see if they are better than the old one, you can use variants to split your population of users and conduct an A/B test with them. Let’s walk through how to utilize **strategy constraints** in our .NET app. diff --git a/website/docs/feature-flag-tutorials/java/spring-boot-examples.md b/website/docs/feature-flag-tutorials/java/spring-boot-examples.md index 0bf934392e3b..30c67cd85443 100644 --- a/website/docs/feature-flag-tutorials/java/spring-boot-examples.md +++ b/website/docs/feature-flag-tutorials/java/spring-boot-examples.md @@ -55,19 +55,33 @@ Learn more about [gradual rollouts in our docs](/reference/activation-strategies ### What is a canary deployment? -Canary releases are a way to test and release code in different environments for a subset of your audience, which determines which features or versions of the platform people have access to. They help find abnormalities and align with the agile process for faster releases and quick reversions. +Canary deployments are a foundational approach for deploying new software versions with high confidence and low risk by exposing the new version to a limited audience. Canary releases are a way to test and release code in different environments for a subset of your audience, which determines which features or versions of the platform people have access to. + +### Why use canary deployments? + +Canary deployments are a safer and more gradual way to make changes in software development. They help find any abnormalities and align with the agile process for faster releases and quick reversions. ### How to do canary deployments with a feature flag in Java? -Canary deployments are a safer and more gradual way to make changes in software development. They help find abnormalities and align with the agile process for faster releases and quick reversions. +Feature flags provide the same benefits as canary deployments but with more granular control: + +- Precisely target specific user segments for feature rollouts. + +- Maintain session consistency (stickiness) if needed. + +- Test multiple features independently on different user groups simultaneously. + +- With feature flags, you can separate feature releases from deployments. + +Often, canary deployments are managed at the load balancer level while feature flags act at the application level. In some instances, rolling out groups of features together behind a feature flag can serve the purpose of a canary deployment. Unleash has a few ways to help manage canary deployments for Java apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in the previous section](#gradual-rollouts-for-java-spring-boot-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-java-spring-boot-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. -- Using either [strategy constraints](/reference/strategy-constraints) or [segments](/reference/segments) (which are a collection of constraints) to determine which user receives which version for more control than a gradual rollout +- Using either [constraints](/reference/strategy-constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout -- [Strategy variants](/reference/strategy-variants) are used for more advanced cases. For example, if you have 2+ new features and are testing to see if they are better than the old one, you can use strategy variants to split your population of users and conduct an A/B test with them. +- [Strategy variants](/reference/strategy-variants) are used to do the same canary deployment, but can be scaled to more _advanced_ cases. For example, if you have 2+ new features and are testing to see if they are better than the old one, you can use variants to split your population of users and conduct an A/B test with them. Let’s walk through how to use strategy constraints in our Java app. diff --git a/website/docs/feature-flag-tutorials/python/examples.md b/website/docs/feature-flag-tutorials/python/examples.md index c38ed9e1ccbb..8fb3d3298610 100644 --- a/website/docs/feature-flag-tutorials/python/examples.md +++ b/website/docs/feature-flag-tutorials/python/examples.md @@ -71,19 +71,33 @@ Learn more about [gradual rollouts in our docs](/reference/activation-strategies ### What is a canary deployment? -Canary releases are a way to test and release code in different environments for a subset of your audience, which determines which features or versions of the platform people have access to. +Canary deployments are a foundational approach for deploying new software versions with high confidence and low risk by exposing the new version to a limited audience. Canary releases are a way to test and release code in different environments for a subset of your audience, which determines which features or versions of the platform people have access to. + +### Why use canary deployments? + +Canary deployments are a safer and more gradual way to make changes in software development. They help find any abnormalities and align with the agile process for faster releases and quick reversions. ### How to do canary deployments with a Python feature flag? -Canary deployments are a safer and more gradual way to make changes in software development. They help find abnormalities and align with the agile process for faster releases and quick reversions. +Feature flags provide the same benefits as canary deployments but with more granular control: + +- Precisely target specific user segments for feature rollouts. + +- Maintain session consistency (stickiness) if needed. + +- Test multiple features independently on different user groups simultaneously. + +- With feature flags, you can separate feature releases from deployments. + +Often, canary deployments are managed at the load balancer level while feature flags act at the application level. In some instances, rolling out groups of features together behind a feature flag can serve the purpose of a canary deployment. Unleash has a few ways to help manage canary deployments for Python apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we implemented in a [previous section](#gradual-rollouts-for-python-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-python-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. -- Using either [strategy constraints](/reference/strategy-constraints) or [segments](/reference/segments) (which are a collection of constraints) to determine which user receives which version for more control than a gradual rollout. +- Using either [constraints](/reference/strategy-constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout -- [Strategy variants](/reference/strategy-variants) are for more advanced use cases. For example, if you want to test 2 different versions of a feature to see which will perform better with your users, you can use strategy variants to split your population of users and conduct an A/B test with them. +- [Strategy variants](/reference/strategy-variants) are used to do the same canary deployment, but can be scaled to more _advanced_ cases. For example, if you have 2+ new features and are testing to see if they are better than the old one, you can use variants to split your population of users and conduct an A/B test with them. Let’s walk through how to utilize **strategy constraints** in our Python app. diff --git a/website/docs/feature-flag-tutorials/react/examples.md b/website/docs/feature-flag-tutorials/react/examples.md index c54a423c3d63..2c2b728a9941 100644 --- a/website/docs/feature-flag-tutorials/react/examples.md +++ b/website/docs/feature-flag-tutorials/react/examples.md @@ -12,7 +12,7 @@ Applications evolve, and teams must manage all aspects of this evolution, includ - [What is a canary deployment?](#what-is-a-canary-deployment) - [Why use canary deployments?](#why-use-canary-deployments) - [How to leverage feature flags for canary deployments in React?](#how-to-leverage-feature-flags-for-canary-deployments-in-react) - - [Configure strategy constraints for canary deployments](#configure-strategy-constraints-for-canary-deployments) + - [Configure strategy constraints for canary deployments](#configure-strategy-constraints-for-canary-deployments) - [A/B Testing in React](#ab-testing-in-react) - [Feature Flag Analytics and Reporting in React](#feature-flag-analytics-and-reporting-in-react) - [Enable feature flag impression data](#enable-feature-flag-impression-data) @@ -74,7 +74,7 @@ Learn more about [gradual rollouts in our docs](/reference/activation-strategies ### What is a canary deployment? -Canary releases are a way to test and release code in different environments for a subset of your audience, which determines which features or versions of the platform people have access to. +Canary deployments are a foundational approach for deploying new software versions with high confidence and low risk by exposing the new version to a limited audience. Canary releases are a way to test and release code in different environments for a subset of your audience, which determines which features or versions of the platform people have access to. ### Why use canary deployments? @@ -82,6 +82,18 @@ Canary deployments are a safer and more gradual way to make changes in software ### How to leverage feature flags for canary deployments in React? +Feature flags provide the same benefits as canary deployments but with more granular control: + +- Precisely target specific user segments for feature rollouts. + +- Maintain session consistency (stickiness) if needed. + +- Test multiple features independently on different user groups simultaneously. + +- With feature flags, you can separate feature releases from deployments. + +Often, canary deployments are managed at the load balancer level while feature flags act at the application level. In some instances, rolling out groups of features together behind a feature flag can serve the purpose of a canary deployment. + Unleash has a few ways to help manage canary deployments for React apps at scale: - Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-react-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. @@ -92,7 +104,7 @@ Unleash has a few ways to help manage canary deployments for React apps at scale Let’s walk through how to utilize strategy constraints in our React app through the Unleash platform. -#### Configure strategy constraints for canary deployments +### Configure strategy constraints for canary deployments We will build a strategy constraint on top of our existing gradual rollout strategy. This will allow us to target a subset of users to rollout to. diff --git a/website/docs/feature-flag-tutorials/ruby/ruby-examples.md b/website/docs/feature-flag-tutorials/ruby/ruby-examples.md index 8fdebed3f076..4bd82ac02c17 100644 --- a/website/docs/feature-flag-tutorials/ruby/ruby-examples.md +++ b/website/docs/feature-flag-tutorials/ruby/ruby-examples.md @@ -70,21 +70,33 @@ Learn more about [gradual rollouts in our docs](/reference/activation-strategies ### What is a canary deployment? -Canary deployments are a way to test and release code in different environments for a subset of your audience. +Canary deployments are a foundational approach for deploying new software versions with high confidence and low risk by exposing the new version to a limited audience. Canary releases are a way to test and release code in different environments for a subset of your audience, which determines which features or versions of the platform people have access to. + +### Why use canary deployments? + +Canary deployments are a safer and more gradual way to make changes in software development. They help find any abnormalities and align with the agile process for faster releases and quick reversions. ### How to do canary deployments with a feature flag in Ruby? -Canary deployments help find abnormalities, and align with the agile process for faster releases. And quick reversions, if necessary. +Feature flags provide the same benefits as canary deployments but with more granular control: -Unleash has a few ways to help manage canary deployments for Ruby apps at scale: +- Precisely target specific user segments for feature rollouts. + +- Maintain session consistency (stickiness) if needed. -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we implemented in the [previous section](#gradual-rollouts-for-ruby-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Test multiple features independently on different user groups simultaneously. + +- With feature flags, you can separate feature releases from deployments. + +Often, canary deployments are managed at the load balancer level while feature flags act at the application level. In some instances, rolling out groups of features together behind a feature flag can serve the purpose of a canary deployment. + +Unleash has a few ways to help manage canary deployments for Ruby apps at scale: -- [Strategy constraints](/reference/strategy-constraints) or [segments](/reference/segments) (which are a collection of constraints) to determine which user receives which version for more control than a gradual rollout. +- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-ruby-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. -- [Strategy variants](/reference/strategy-variants) for more advanced use cases. For example, if you want to test 2 different versions of a feature, you can use a strategy variant to split your population of users and conduct an A/B test with them. +- Using either [constraints](/reference/strategy-constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout -Let’s walk through how to utilize **strategy constraints** in our Ruby app. +- [Strategy variants](/reference/strategy-variants) are used to do the same canary deployment, but can be scaled to more _advanced_ cases. For example, if you have 2+ new features and are testing to see if they are better than the old one, you can use variants to split your population of users and conduct an A/B test with them. ### Configure strategy constraints for canary deployments