Experiments and IsProduction

There are 2 ways to toggle a features availability in Windows Admin Center.

IsProduction Flag

The IsProduction flag indicates if the Windows Admin Center environment was initialized in production mode or not. In angular implementations, this is usually the inverse of "IsDevMode". You can get this flag using:

MsftSme.self().Init.isProduction

Experiments

Experiments are meant to be available in the production environment to any user that knows the experiments key. Each key is a custom string identifier that the user appends to the extension name that owns the experiment followed by a ".".

For example:

My experiment key is "key" and my extension name is "myCompany.extension" The user will need to use the key "myCompany.extension.key" to enable features hidden behind this key.

Some keys are global in nature and provided my the shell. These keys use the extension name: "msft.sme.shell"

The user can configure extension keys under the application settings in Windows Admin Center

Using Experiment Keys

You can check if an experiment is enabled using the following MsftSme method:

function isExperimentEnabled(key: string, shellExperiment?: boolean): boolean;

By default, this function will search for your key in your extensions own namespace. However is the "shellExperiment" argument is provided as true, then the shells namespace will be searched.

Keeping Track of Experiment Keys

It is strongly recommended that you define your experiment keys in a single well known constant and reference them from there. For example, we might have a file called constants.ts that looks something like this:

export class Constants {{'{'}} /** * Experiment keys for this extension */ public static readonly experimentKeys = {{'{'}} /** * Key for making the product cool */ coolKey: 'coolKey', /** * Key for making the product cooler */ coolerKey: 'coolerKey', /** * Key for making the product as cool as it can be */ coolestKey: 'coolestKey' } }

Using flags

Code that is littered with feature flags can become unruly and hard to maintain. Usage of these flags should be short lived. Keep in mind that the purpose is to eventually remove that flag, or remove the feature.

There are 2 primary ways that you can use the flags. Here are some examples using the key: "key" from my own extension

In Code:

This example would enter the if statement only if the feature is enabled, regardless of production mode

if(isExperimentEnabled('key')) {{'{'}} /* Do feature specific logic*/ }

This example would enter the if statement only if the not in production mode

if(!MsftSme.self().Init.isProduction) {{'{'}} /* Do dev mode specific logic*/ }

Route Guards

It can also be useful to block entire sections of your extension off based on a flag. To do this 2 route guards are provided:

Dev Guard

The dev guard will block routes and redirect when the IsProduction flag is false. the entry in your angular routing table will look something like this:

{{'{'}} path: 'dev', canActivate: [DevGuardService], data: {{'{'}}redirectTo: '/'}, loadChildren: '...' },

Experiment Guard

The experiment guard will block routes and redirect when an experiment or set of experiments is enabled. the entry in your angular routing table will look something like this:

{{'{'}} path: 'experiment', canActivate: [ExperimentGuardService], data: {{'{'}}redirectTo: '/', experiments: ['key']}, loadChildren: '...' },

you can also provide a "shellExperiments" property to the data parameter of a route guarded by the ExperimentGuardService. It follows the same format as "experiments"

Note that in both cases, we provided the guard with a data parameter that told the guard where to redirect. In the experiment guard, we also provided the experiment keys