Merge pull request #105063 from jpconnock/ac-freshness-2

Continuing freshness work on App Configuration

Author: v-albemi

articles/azure-app-configuration/concept-app-configuration-event.md

@@ -1,19 +1,19 @@
 ---
-title: Reacting to Azure App Configuration key-value events | Microsoft Docs
+title: Reacting to Azure App Configuration key-value events
 description: Use Azure Event Grid to subscribe to App Configuration events. 
 services: azure-app-configuration,event-grid 
 author: jimmyca
 
 ms.author: jimmyca
-ms.date: 05/30/2019
+ms.date: 02/20/2020
 ms.topic: article
 ms.service: azure-app-configuration
 
 ---
 
 # Reacting to Azure App Configuration events
 
-Azure App Configuration events enable applications to react to changes in key-values. This is done without the need for complicated code or expensive and inefficient polling services. Instead, events are pushed through [Azure Event Grid](https://azure.microsoft.com/services/event-grid/) to subscribers such as [Azure Functions](https://azure.microsoft.com/services/functions/), [Azure Logic Apps](https://azure.microsoft.com/services/logic-apps/), or even to your own custom http listener, and you only pay for what you use.
+Azure App Configuration events enable applications to react to changes in key-values. This is done without the need for complicated code or expensive and inefficient polling services. Instead, events are pushed through [Azure Event Grid](https://azure.microsoft.com/services/event-grid/) to subscribers such as [Azure Functions](https://azure.microsoft.com/services/functions/), [Azure Logic Apps](https://azure.microsoft.com/services/logic-apps/), or even to your own custom http listener. Critically, you only pay for what you use.
 
 Azure App Configuration events are sent to the Azure Event Grid which provides reliable delivery services to your applications through rich retry policies and dead-letter delivery. To learn more, see [Event Grid message delivery and retry](https://docs.microsoft.com/azure/event-grid/delivery-and-retry).
 
@@ -70,11 +70,12 @@ Here is an example of a KeyValueModified event:
 For more information, see [Azure App Configuration events schema](../event-grid/event-schema-app-configuration.md).
 
 ## Practices for consuming events
-Applications that handle App Configuration events should follow a few recommended practices:
+Applications that handle App Configuration events should follow these recommended practices:
 > [!div class="checklist"]
-> * As multiple subscriptions can be configured to route events to the same event handler, it is important not to assume events are from a particular source, but to check the topic of the message to ensure that it comes from the App Configuration you are expecting.
-> * Similarly, check that the eventType is one you are prepared to process, and do not assume that all events you receive will be the types you expect.
-> * As messages can arrive out of order and after some delay, use the etag fields to understand if your information about objects is still up-to-date.  Also, use the sequencer fields to understand the order of events on any particular object.
+> * Multiple subscriptions can be configured to route events to the same event handler, so do not assume events are from a particular source. Instead, check the topic of the message to ensure the App Configuration instance sending the event.
+> * Check the eventType and do not assume that all events you receive will be the types you expect.
+> * Use the etag fields to understand if your information about objects is still up-to-date.  
+> * Use the sequencer fields to understand the order of events on any particular object.
 > * Use the subject field to access the key-value that was modified.
 
 

articles/azure-app-configuration/concept-disaster-recovery.md

@@ -5,7 +5,7 @@ author: lisaguthrie
 ms.author: lcozzens
 ms.service: azure-app-configuration
 ms.topic: conceptual
-ms.date: 05/29/2019
+ms.date: 02/20/2020
 ---
 
 # Resiliency and disaster recovery
@@ -22,7 +22,7 @@ Your application loads its configuration from both the primary and secondary sto
 
 ## Failover between configuration stores
 
-Technically, your application isn't executing a failover. It's attempting to retrieve the same set of configuration data from two App Configuration stores simultaneously. Arrange your code so that it loads from the secondary store first and then the primary store. This approach ensures that the configuration data in the primary store takes precedence whenever it's available. The following code snippet shows how you can implement this arrangement in the .NET Core CLI:
+Technically, your application isn't executing a failover. It's attempting to retrieve the same set of configuration data from two App Configuration stores simultaneously. Arrange your code so that it loads from the secondary store first and then the primary store. This approach ensures that the configuration data in the primary store takes precedence whenever it's available. The following code snippet shows how you can implement this arrangement in .NET Core:
 
 #### [.NET Core 2.x](#tab/core2x)
 
@@ -65,17 +65,18 @@ From the Azure portal, you can push a change to another configuration store by f
 
 1. Go to the **Import/Export** tab, and select **Export** > **App Configuration** > **Target** > **Select a resource**.
 
-2. In the new blade that opens, specify the subscription, resource group, and resource name of your secondary store, and then select **Apply**.
+1. In the new blade that opens, specify the subscription, resource group, and resource name of your secondary store, then select **Apply**.
 
-3. The UI is updated so that you can choose what configuration data you want to export to your secondary store. You can leave the default time value as is and set both **From label** and **To label** to the same value. Select **Apply**.
+1. The UI is updated so that you can choose what configuration data you want to export to your secondary store. You can leave the default time value as is and set both **From label** and **To label** to the same value. Select **Apply**.
 
-4. Repeat the previous steps for all configuration changes.
+1. Repeat the previous steps for all configuration changes.
 
 To automate this export process, use the Azure CLI. The following command shows how to export a single configuration change from the primary store to the secondary:
 
+```azurecli
     az appconfig kv export --destination appconfig --name {PrimaryStore} --label {Label} --dest-name {SecondaryStore} --dest-label {Label}
+```
 
 ## Next steps
 
 In this article, you learned how to augment your application to achieve geo-resiliency during runtime for App Configuration. You also can embed configuration data from App Configuration at build or deployment time. For more information, see [Integrate with a CI/CD pipeline](./integrate-ci-cd-pipeline.md).
-

articles/azure-app-configuration/concept-feature-management.md

@@ -1,65 +1,63 @@
 ---
-title: Azure App Configuration feature management
-description: An overview of how Azure App Configuration can be used to turn on and off application features on demand.
+title: Understand feature management using Azure App Configuration
+description: Turn features on and off using Azure App Configuration 
 author: lisaguthrie
 ms.author: lcozzens
 ms.service: azure-app-configuration
 ms.topic: conceptual
-ms.date: 04/19/2019
+ms.date: 02/20/2020
 ---
 
 # Feature management overview
 
-Traditionally, shipping a new application feature requires a complete redeployment of the application itself. To test a feature, you likely must deploy your application many times to control when the feature becomes visible or who gets to see it.
+Traditionally, shipping a new application feature requires a complete redeployment of the application itself. Testing a feature often requires multiple deployments of the application.  Each deployment may change the feature or expose the feature to different customers for testing.  
 
 Feature management is a modern software-development practice that decouples feature release from code deployment and enables quick changes to feature availability on demand. It uses a technique called *feature flags* (also known as *feature toggles*, *feature switches*, and so on) to dynamically administer a feature's lifecycle.
 
-Feature management helps developers deal with the following problems:
+Feature management helps developers address the following problems:
 
-* **Code branch management**: Feature flags are frequently used to wrap new application functionality that's under development. Such functionality is "hidden" by default. You can safely ship the feature, even though it's unfinished, and it will stay dormant in production. By using this approach, called *dark deployment*, you can release all your code at the end of each development cycle. You no longer need to maintain any code branch across multiple cycles because of a feature taking more than one cycle to be completed.
-* **Test in production**: You can use feature flags to grant early access to new functionality in production. For example, you can limit this access to only your team members or to internal beta testers. These users will get the full-fidelity production experience, instead of a simulated or partial experience in a test environment.
-* **Flighting**: You can also use feature flags to incrementally roll out new functionality to end users. You can target a small percentage of your user population first and increase that percentage gradually over time, after you have gained more confidence in the implementation.
-* **Instant kill switch**: Feature flags provide an inherent safety net for releasing new functionality. With them, you can readily turn application features on and off. If necessary, you can quickly disable a feature without rebuilding and redeploying your application.
-* **Selective activation**: While most feature flags exist only until their associated functionalities have been released successfully, some can last for a long time. You can use feature flags to segment your users and deliver a specific set of features to each group. For example, you may have a feature that works only on a certain web browser. You can define a feature flag so that only users of that browser can see and use the feature. With this approach, you can easily expand the supported browser list later without having to make any code changes.
+* **Code branch management**: Use feature flags to wrap new application functionality currently under development. Such functionality is "hidden" by default. You can safely ship the feature, even though it's unfinished, and it will stay dormant in production. Using this approach, called *dark deployment*, you can release all your code at the end of each development cycle. You no longer need to maintain code branches across multiple development cycles because a given feature requires more than one cycle to complete.
+* **Test in production**: Use feature flags to grant early access to new functionality in production. For example, you can limit access to team members or to internal beta testers. These users will experience the full-fidelity production experience instead of a simulated or partial experience in a test environment.
+* **Flighting**: Use feature flags to incrementally roll out new functionality to end users. You can target a small percentage of your user population first and increase that percentage gradually over time.
+* **Instant kill switch**: Feature flags provide an inherent safety net for releasing new functionality. You can turn application features on and off without redeploying any code. If necessary, you can quickly disable a feature without rebuilding and redeploying your application.
+* **Selective activation**: Use feature flags to segment your users and deliver a specific set of features to each group. You may have a feature that works only on a certain web browser. You can define a feature flag so that only users of that browser can see and use the feature. With this approach, you can easily expand the supported browser list later without having to make any code changes.
 
 ## Basic concepts
 
 Here are several new terms related to feature management:
 
-* **Feature flag**: A feature flag is a variable with a binary state of *on* or *off*. The feature flag also has an associated code block. The state of the feature flag triggers whether the code block runs or not.
-* **Feature manager**: A feature manager is an application package that handles the lifecycle of all the feature flags in an application. The feature manager typically provides additional functionality, such as caching feature flags and updating their states.
-* **Filter**: A filter is a rule for evaluating the state of a feature flag. A user group, a device or browser type, a geographic location, and a time window are all examples of what a filter can represent.
+* **Feature flag**: A feature flag is a variable with a binary state of *on* or *off*. The feature flag also has an associated code block. The feature flag's state triggers whether the code block runs.
+* **Feature manager**: A feature manager is an application package that handles the life cycle of all the feature flags in an application. The feature manager also provides additional functionality, including caching feature flags and updating their states.
+* **Filter**: A filter is a rule for evaluating the state of a feature flag. Potential filters include user groups, device or browser types, geographic locations, and time windows.
 
 An effective implementation of feature management consists of at least two components working in concert:
 
 * An application that makes use of feature flags.
 * A separate repository that stores the feature flags and their current states.
 
-How these components interact is illustrated in the following examples.
+## Using feature flags in your code
 
-## Feature flag usage in code
-
-The basic pattern for implementing feature flags in an application is simple. You can think of a feature flag as a Boolean state variable used with an `if` conditional statement in your code:
+The basic pattern for implementing feature flags in an application is simple. A feature flag is a Boolean state variable controlling a conditional statement in your code:
 
 ```csharp
 if (featureFlag) {
     // Run the following code
 }
 ```
 
-In this case, if `featureFlag` is set to `True`, the enclosed code block is executed; otherwise, it's skipped. You can set the value of `featureFlag` statically, as in the following code example:
+You can set the value of `featureFlag` statically.
 
 ```csharp
 bool featureFlag = true;
 ```
 
-You can also evaluate the flag's state based on certain rules:
+You can evaluate the flag's state based on certain rules:
 
 ```csharp
 bool featureFlag = isBetaUser();
 ```
 
-A slightly more complicated feature flag pattern includes an `else` statement as well:
+You can extend the conditional to set application behavior for either state:
 
 ```csharp
 if (featureFlag) {
@@ -69,23 +67,11 @@ if (featureFlag) {
 }
 ```
 
-You can rewrite this behavior in the basic pattern, however. [Use feature flags in an ASP.NET Core app](./use-feature-flags-dotnet-core.md) shows the advantages of standardizing on a simple code pattern. For example:
-
-```csharp
-if (featureFlag) {
-    // This following code will run if the featureFlag value is true
-}
-
-if (!featureFlag) {
-    // This following code will run if the featureFlag value is false
-}
-```
-
 ## Feature flag repository
 
-To use feature flags effectively, you need to externalize all the feature flags used in an application. This approach allows you to change feature flag states without modifying and redeploying the application itself.
+To use feature flags effectively, you need to externalize all the feature flags used in an application. This allows you to change feature flag states without modifying and redeploying the application itself.
 
-Azure App Configuration is designed to be a centralized repository for feature flags. You can use it to define different kinds of feature flags and manipulate their states quickly and confidently. You can then use the App Configuration libraries for various programming language frameworks to easily access these feature flags from your application.
+Azure App Configuration provides a centralized repository for feature flags. You can use it to define different kinds of feature flags and manipulate their states quickly and confidently. You can then use the App Configuration libraries for various programming language frameworks to easily access these feature flags from your application.
 
 [Use feature flags in an ASP.NET Core app](./use-feature-flags-dotnet-core.md) shows how the .NET Core App Configuration provider and Feature Management libraries are used together to implement feature flags for your ASP.NET web application.