At Microsoft Teams, we frequently hear the question, “I am running the same version as my coworker, but they have a feature I don’t. Why don’t I have that feature now? And how can I get it now?” Before we answer that question, we want to shed some light on our overall release processes so that the answer makes sense.
As a productivity tool connecting hundreds of millions of people around the world and enabling remote work, remote learning, and connections with family and friends, we take a very orchestrated approach to how we roll out and enable new features. We have multiple updates that get rolled out: web, desktop (Windows, Mac, Linux), mobile (iOS, Android), packages for conference room devices, and our backend services. Each of these packages are backed by feature flag configurations that let us ship a new Teams version and enable features separately.
When we roll out features, it consists of two activities:
- Shipping the version (Teams application version with code for new features included)
- Enabling the feature through the feature flag
Both activities happen progressively, but at different times. We first ship the build with the feature flags turned off. We progressively roll out the build to users, wait for the build to be picked up and used by users, and reach certain penetration rates. We’ll run scorecards for key performance and usage metrics between the prior build and the new build to ensure we are not introducing any form of regression with our latest version.
Once we have scorecards and confidence in the version, we can then begin to progressively enable our feature flags – making the new features available for users. For our larger, external customer facing rings, this is a multiple step process that usually happens over a few days.
Below is a high-level view of our audience segmentation. Each ring represents an audience with specific gating criteria to allow us to exit the build and the feature flag, and to progress them to the next ring.
When we begin rolling out feature flags within a ring is where you will usually see differences in features within the same version. We roll features and versions out on in increasing % tranches at user level (considering the worldwide user pool and not at an organization/tenant level) as it gives us the best cross section of use cases, hardware configurations, software configurations, network topology, bandwidth availability, etc., to validate our changes and the user experience they provide – but this does mean that co-workers on the same build can see differences in their features. Rolling out feature flags by organization introduces the potential to bias our results with similar hardware, bandwidth, and usage patterns, so we focus on getting a cross section of users and usage patterns with our rollouts.
In December 2020 we announced the availability of Teams Public Preview. Public Preview is a great mechanism to expose a subset of your user base to features a little ahead of everyone else. This allows you to get familiar with new features before they are available to all users.
Public preview in Microsoft Teams – Microsoft Teams | Microsoft Docs
Teams-Updates – Microsoft Teams | Microsoft Docs
Source link
