 Rachel, a release manager, wants to adopt a progressive delivery approach. This can be thought of as developer experimentation, and Rachel will be able to test in production while controlling who can access updates. To do this, she'll create and use a feature flag. Rachel creates a new feature flag and names it with a shorthand for products in alphabetical order feature flag. Feature flags have environment-specific strategies, which Rachel proceeds to define. She creates one for production and more strategies for other environments. Once she defines the strategies and creates the feature flag, she can enable or disable it by using a slider. In order for feature flags to be used by this project, the API URL and the instance ID of the feature flag service need to be shared with developers, so Rachel copies these for sharing. Rachel would like to exercise a feature flag, which segments who will see a new feature in a controlled manner in a specific environment. Here we have two running environments, production and staging, both running the same version of the application. Feature flags can be used with these environments and review environments. Let's see how feature flags are supported in GitLab. She checks the feature flag, Prods in Alpha Order FF, which has three strategies and a user list called Prods in Alpha Order User List with two users in it, Michael and Mary. The first strategy uses a percent rollout of 50% based on available ID for the production environment. The second one targets the feature to users in the user's list, Prods in Alpha Order User List for the staging environment. The third strategy serves the feature to a specific user, Thomas for the review environment, an ephemeral environment used for validating application updates before they are merged to the main branch. With developers working on concurrent feature branches, there are multiple review environments, so Rachel selects the correct one to which this strategy will apply. Feature flags help Rachel reduce risk, allowing her to do controlled testing and separate feature delivery from customer launch. To verify the feature flag strategy, Rachel opens the application in the review environment and logs in as user Thomas. She validates that Thomas gets a product list sorted in alphabetical order by product name. She logs Thomas out and logs in as Peter. Rachel confirms that Peter does not get a product list in alphabetical order because the feature flag strategy for the review environment is that only Thomas gets the feature. Rachel now opens the application in the production environment to see if the 50% rollout is being applied. There are six valid user names that this application supports. She logs in as each of these six users and confirms that three users get the feature and three don't, which is exactly this feature flag strategy for production. To verify the feature flag strategy in action in the staging environment, she validates that only Michael and Mary get the feature in staging. Rachel is interested in seeing how this feature flag is instrumented in the application. GitLab supports feature flags for a variety of programming languages, including Java, which this application is written in. She heads to the application source directory and views the file appcontroller.java. She notices a block of import statements for open source project Unleash, which is what GitLab uses for its implementation of feature flags. She finds the declaration of some variables that are needed for the instrumentation of a feature flag in this Java class. In the constructor method, she sees the definition of three of these variables. The Unleash instance ID and the URL values are generated when the feature flag is created and the GitLab environment name is a runtime predefined variable. An Unleash config object is then declared and defined, and that config object is used to create an instance of default Unleash. Once all these variables and objects have been instantiated, using the feature flag is as simple as an if-else statement. The if statement checks if the feature flag has been enabled. If so, it runs the if portion, which sorts the product list in alphabetical order. If the feature flag is not enabled, then it runs the else portion, which returns the product list in the order they were added to the database and not in alphabetical order. Feature flag instrumentation provides a straightforward and simple way to embed a feature flag in your code. Feature flags allow you to effectively test application updates safely in production. They can lower risk of unscheduled outages. They are simple to configure an instrument and are language agnostic and help you stay compliant and always audit ready.