update canary deployments sections in examples (#7363)

<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->

## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->

Cleaned up the canary deployment sections

<!-- Does it close an issue? Multiple? -->
Closes #

<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->

### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->


## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->

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.
 

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.
 

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.
 

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.
 

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:
+
+-   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 Ruby apps at scale:
 
--   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.
+-   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 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.
-
-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