 Hello, my name is Sergio Svedra and I'm a technical marketing manager here at GitLab. In this short video, I'm going to show you a new feature introduced in GitLab 13.3, which is Edit Feature Flag User List from the UI. Here's the sample project. It's called DemoFFUL. This is a public project that you can access and clone. And it comes with its own instructions on how to set it up and run it if you want to clone it and replicate it in your own environment, GitLab environment. The back end is using a Kubernetes cluster that is running on GKE. And it has auto DevOps enabled. It also uses three environments. You will see that later. It uses a QA environment, a staging environment, and a production environment to be able to also show you the different capabilities of Feature Flags. So Feature Flags is a way to control the audience that will be getting new functionality that you're introducing in your application. And so let's go to the Feature Flags console. So here's where you configure Feature Flags. The configure information is you need the API URL and the instance ID of the Unleash capabilities. We're using Unleash, which is an open source project, to implement Feature Flags. This is installed on GitLab and it's a server. And you need the instance ID and the API URL to be able to call it from your application. So this information you need to include in your project variables. There's more information about how to set these up in the instructions and the written file. But here, for example, you see this is the Unleash URL and the instance ID, which is these are the values that were shown in the previous screen. You also need a PIMP file. You can follow the instructions again to go through the steps on how to get that. I've chosen to disable call quality in this project to make the pipeline faster. And I will also enable staging so that we can have that extra environment. Let's go back to the Feature Flags dashboard. So the new capability introduced in GitLab 13.3 is the ability to create new lists of users. So here we're going to create a new list. We can call it the FF for Feature Flags, user list two, create this new list. And then we can add users. And here we add user IDs or emails, in this case, let's add Pluto at gmail.com. And then we can also add a magic at cfl.com. There you go. So now we have these two users in this user list. And now once we have this user list, we can create a new Feature Flag to use this user list. We can call this FF test two. And then we need to add the strategies to the Feature Flag. So for QA, let's actually use our user list. And here we select the number two that we just created. And then we can add another strategy as part of this Feature Flag. And for this one we'll use staging. And for this strategy, we'll do it for all users. So let's just leave it like that. And then one more strategy for production. And for this one, we can do a percent of users. And we can do 80%. And then we create the Feature Flag. Good. So now we have FF test two. And to be able to use it within your application, we go to this Go module. And here this is how the Feature Flag is being unleashed or used within your application. So let's add, let's actually edit it. And we created a new Feature Flag called FF test two. So what this is going to do is going to check that if this Feature Flag is on for the specific users that we've designated, they will be the only ones seeing that new Feature. And if they are not part of that Feature Flag, then they will just see Hello World. Obviously, this is simple functionality. The idea is here that you will have a lot of logic here that is a modification to your application. So let's just commit to master. And this is going to fire up a new pipeline. So in this case, we're using auto DevOps and we've added a QA environment and also a manual stage and job here that will be deploying a running application within QA. We'll also deploy it to staging. And finally, we'll do a manual deployed to production. And as part of the project, we have a client that will be running. Here it is from the terminal, from my local laptop here. That is going to, it's basically a for loop and is going to loop over the different environments. So this one is going to be QA. The next loop around is going to be for staging. And the last one is going to be the production environment. And for each of the environments, what it's going to do is going to basically log in, register and log in the user. And the users are here. So these are the list of users, Pluto, Magic, Pluto at gmail.com, Magic at CFLR.com, Mickey at Disney.com and Hulk at Universal.com. And remember these first two were part of our feature flag for the user list that we created contained only these two usernames in there. So and in one of our strategies, we are targeting these two users only for the new feature. So you'll see when the script is executed that for part of the strategy, if I remember correctly that we did was for QA, so for QA we will see that only these two emails or users will get the new feature. And these two will not. They will get the old feature or the old application without any modification. And then it'll loop around again and it'll do the same thing for staging. For staging, we define that all users will get the new feature. So we should see that every one of these users, Pluto, Magic, Mickey and Hulk, will get the feature, the new feature. And for production, we define that only 80% of the users should get the new feature. And since it's four and it's 25%, so we should see the three of these folks, three of these users will get the new feature and one will not. Very well now that the pipeline has completed, you can see that the application has been deployed to QA staging and I manually deployed it to production and everything is green. So now let's execute the client. But before we go there, let's go back to the feature flag. The feature flag we're about to execute is this, FF test two. So let's execute the script and let's see for QA, according to the strategy, only the users in list two should get the new feature. So that should be Pluto and Magic and indeed Pluto and Magic got the new feature and not Mickey or Hulk. For staging, we had a strategy that all users would get the new features and new feature and they all did here, all four of them. For production, we had defined that 80% should only get it. So 80% of four should be three individuals. So and Pluto, Magic and Hulk got it and not Mickey. So what we've seen in this video is we were able to use the brand new feature of user lists and the ability to define them via the GitLab UI. In this case, we define a new user list called user list, FF user list two with two usernames in there to emails. From this screen, you can manage the lists, you can edit them or delete them. We were also able to create a new feature flag that made use of that user list called FF user list two and we were able to apply that to a strategy for QA. Very good. So I hope you enjoyed this video and we'll see you next time. Thank you.