GitLab Technical Marketing, 27 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Edit Feature Flag User Lists from the UI - GitLab 13.3

Description

Edit Feature Flag User Lists from the UI

Introduced in Gitlab 13.3, Edit Feature Flag User Lists allow you to create and manage lists of users from the GitLab User Interface. Once created, you can target these lists in strategies inside your Feature Flag.

A

Hello, my name is vedra and I'm a technical marketing manager here at git lab 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 a sample project. It's called demo fful.

A

This is a public project that you can access in 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 um environment, gitlab, environment, the the backend is using a kubernetes cluster that is running on gke and it has auto devops enabled uh it also uses three environments.

A

uh You will see that later it uses a qa environment, a staging environment and a production environment to be able to uh also show you, the different capabilities of feature flags, so feature flags is a way to control the audience that will be getting uh new functionality that you're introducing in your application, and so let's go to the.

A

Feature flags console, so here's where you configure feature flags, the configure information is, you know 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 you. 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.

A

So this information you need to include in your.

A

Project variables.

A

There's more information about how to set these up in the instructions in the readme 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.

A

You also need a pen file. You can follow the instructions again to to go through the steps on how to get that. I've chosen to disable a call quality in this project uh to make it uh to make the pipeline uh faster, and I've also uh enabled staging so that uh you know we have. We can have that extra environment.

A

Let's go back to the feature flags, dashboard.

A

So the new capability introduced in gitlab 13.3 is the ability to create new lists of users.

A

So here we're going to create a new list. We can call it the ff for feature flags user list, two.

A

We 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.

A

And then we can also add a magic at cfl.com.

A

There you go so now. We have these two users in this user list.

A

And now, once we have this user list, we can create a new feature flag to use this user list and we can call this ff test2.

A

And then we need to add the strategies to the feature flag so for qa.

A

Let's do, let's actually use our user list, and here you 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.

A

Sorry about that staging.

A

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.

A

And for this one we can do a percent of users and we can do uh 80, and then we create the feature flag good. So now we have ff test two and to be able to uh use it within your application. um We go to this.

A

Go module, and here this is what's actually.

A

This is how the feature flag is being unleashed or used within your application. So, let's add, let's actually edit it.

A

And um we created a new feature: flag called fftest2, so what this is going to do is is going to uh check that if this feature flag is on uh for the specific users that we've um we've designated, they, 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 uh hello world.

A

Obviously this is this is simple functionality. The the idea is here that you will have. You know a lot of logic here. That is a it's a modification to your application.

A

So, let's just commit to master.

A

And this is going to fire up a new pipeline.

A

So in this case, we're using autodevops and we've added a qa.

A

Environment and and also stage and job here that will be deploying um a running application within qa. It will also deploy it to staging and, finally, we'll do a manual deploy to production and um and as part of the project. We we have a client that will be running.

A

Here it is from the terminal from my local laptop here that is going to it's basically a for loop and it's going to loop over the different environments. So this one is going to be qa.

A

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 login register and log in the user, and the users are here. So these are the list of users, pluto, magic, pluto, gmail.commagic.cflorr.com, mickey disney dot com and hulk universal.com, and remember these first two were part of our feature flag for the user list that we created contain only these two usernames in there.

A

So and in one of those strategies.

A

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 um the strategy, if I'm cur, 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 and then it'll loop around again and it'll do the same thing for uh staging and for staging.

A

We define that all users will get the new feature, so every 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 defined that only eighty percent of the users should get the new feature and since it's four- uh and uh you know each is 25, so we should see that three of these folks three of these um users will get the new feature and one will not.

A

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 the client, but before we go there, let's go back to the feature flag.

A

The feature flag, we're about to execute is this ff test2?

A

So let's execute.

A

The script and, let's see for qa according to the strategy, uh only the users in list two should get uh the new feature, so that should be pluto and magic and indeed uh pluto and magic got the new feature and not the mickey or hulk for staging. We had.

A

We had a strategy that all users would get the new features and a new feature, and they they all did here all four of them for production. We had defined that eighty percent should only get it so. Eighty percent of four should be three individuals so and pluto, magic and uh and hulk got it and not mickey.

A

So we 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 list2 with two usernames in there two emails from this screen. You can manage the lists you can edit them or delete them.

A

We were also able to create a new feature flag that made use of that user list, called ff user list 2., and we were able to apply that to a strategy for qa very good. So I hope you enjoy this video and we'll see you next time. Thank.

A