 Besides advanced deployment techniques like canary, blue-green and incremental deployments, all the progressive delivery approaches, like feature flags, can be used to reduce risk when practicing progressive delivery. Progressive delivery is a facet of continuous delivery and it is the ability to test in production while controlling your audience of who can exercise or see updates to your application with a high level of granularity. This approach can also be thought of as developer experimentation. The benefits of using feature flags are lowering risk by preventing and schedule outages, controlling your audience in a fine-grained fashion, and by optionally using feature flags in conjunction with canary deployments. These are used by its simple configurability, support of user lists, built-in feature flag service and simple instrumentation. Our feature flag implementation is language agnostic since it supports all of the main programming languages and better compliance and audit via the automatic recording of all feature flags actions by the GitLab platform. In this technical demo, we will see how Rachel, a release manager, creates and uses a feature flag in her effort to adopt this progressive delivery approach. Rachel creates a brand new feature flag and names it with a shorthand for products in alphabetical order feature flag. Feature flags have environment-specific strategies that need to be defined, so Rachel proceeds to define these strategies. She creates one for production and proceeds to create strategies for other environments. Once she defines all of the strategies and creates the feature flag, she can enable it or disable it by using a slider in the feature flags window. Also, 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. Rachel copies these two values for later sharing. Rachel would like to exercise the feature flag, which segments the audience of who are going to see a new feature in a control manner in a specific environment. She opens up the feature flag window and checks the feature flag products in alphabetical order feature flag, which has three strategies and a user list called product in alphabetical order user list with two users in it, Michael at CFL.arr.com and Mary at CFL.arr.com. 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 users list products in alphabetical order user list for the staging environment. The third strategy serves the feature to a specific user, Thomas at gmail.com for their review environment, which is an ephemeral environment used for validating application updates before they emerge to the main branch. Since there are multiple review environments due to the number of concurrent feature branches developers are working on, Rachel searches among the existing review environments and selects the correct one to which this strategy will apply. Feature flags help Rachel reduce risk, allowing her to do control testing and separate feature delivery from customer launch. Rachel would like to verify the feature flag strategy in action in the review environment. She opens the application in the review environment and logs in as user Thomas at gmail.com. She validates that Thomas gets a product list sorted in alphabetical order by product name. Also noticed that in the review environment the application has an orange background. She logs Thomas out and this time she logs in as Peter at gmail.com. 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% rollup based on available ID strategy is being applied. There are six valid user names that this application supports. She first logs in as Peter and sees that he does not get the feature. Next, she logs in as magic and he does get the feature. She proceeds to log in as Michael and he gets the feature. She then logs in as Henry and confirms that he does not get the feature. She logs in as Mary who does not get the feature. And finally she logs in as Thomas who does get the feature. If you have been keeping track of who got and who didn't get the feature you realize that three users got the feature and three didn't which is exactly this feature flag strategy for production. Rachel would like to verify the feature flag strategy in action in the staging environment. She opens the application in the staging environment and logs in as user Michael at cfl.rr.com. She validates that Michael gets a product list sorted in alphabetical order by product name. She logs Michael out and this time she logs in as Mary at cfl.rr.com. Rachel confirms that Mary also gets the feature in the staging environment. Remember that Michael and Mary were in the user's list allowed to see this feature in staging. She logs Mary out and still in staging she logs in as Peter at gmail.com. Who should not be served the feature? Indeed, Peter does not get a product list in alphabetical order. 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 in which this application is written. She heads to the source directory of the application and views the file appcontroller.java. She notices a block of import statements for open source project and leash which is what GitLab uses for its implementation of feature flags. She finds a 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 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 then that config object is used to create an instance of default and leash. 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 and if so, it runs the if portion which stores 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 updates to your application safely in production. They can help you lower risk of unscheduled outages, they are simple to configure an instrument, they are language agnostic and help you stay compliant and always be audit ready. Thank you for watching and until next time.