 Hello, my name is Cesar Severo and I'm a technical marketing manager here at GitLab. In this short demo, I'm going to go over a feature introducing GitLab 13.11 called environment specific variables at the group level. Before this release, you could define environment variables that were at the group level, but they applied to all the environments of projects that were contained in that group. With this new feature, you can now target a variable to a specific environment. So let's see a specific example of this new feature. So here I have a group called apps. And as you can see, I have multiple microservices here. And what I would like is to create two variables that are targeted to one to stage in and one to production. So we're going to go to settings, CICD, we're going to add a variable called database connection URL or DB call URL is preceded by the prefix Kubernetes secret because we want this variable value or variable and its value to be passed to the running application once it's deployed to Kubernetes. And for this specific variable, we'll target this variable to production or this value of this variable to production. And then we'll create another variable again with the same name. So let's do this. But this time, this is going to go to staging and notice that the value is different in that the database name is app DB2. There you go. You can see the values here. You're going to see that although the variable name is the same, they have different values. In here, you have the app DB2 variable and the one, the value here is just app DB. And app DB is going to be targeted to production and app DB2 is going to be targeted to staging. That means that all these projects here will be able to see these variables or will inherit these variables. So let's go into Spring MVC JPA and let's go into the application itself. And here is how the application uses the variable that which is defined. It doesn't have the prefix and you can see here DB connection URL is going to be assigned to this Spring data source URL variable within the application. And that way, the application will be able to connect to the corresponding database. So now let's run the, but before we run anything, let's go to AWS console and see the databases. Indeed, there are two databases here, app DB and app DB2. And app DB here, this is app DB and app DB, the product table and the application as you will see in a minute is actually like an inventory application. There are three products already populated in the product table. And app DB2, which will be used in staging environment, there are none, there are no products populated in there. So now let's deploy the application or redeploy the application. Let's run the pipeline here. Let's wait until the pipeline finishes. Very good. Now the pipeline is finished. As you can tell, there was a build stage staging and production. And now the application is running in staging and production. So let's go check the environments and let's see the application running in staging. There you go. And as you can tell here, Pluto is logged on in the staging environment. And there are no products to be listed here. Remember earlier, we checked that the staging database has no products in there. So let's log out as Pluto. And now let's go to production and let's log back in as Pluto. And Pluto here is hitting a database that has three products in it. And that database is this other database that is even used in production, which has these three products in there. If we go back to the project itself and check the variables, you will see here that this database connection URL variables are actually defined, are inherited by this project, but have been defined in the apps group, which we did in the very beginning of this demo. Very good. So what this helps you with is the ability to manage variables at the group level. So in the case where you have, for example, a group that contains many microservices like here, you can define variables at this group level. And all of these microservices will inherit that variable. In the case of the Spring NBC JPA, it inherited the connection URL. And we targeted one to staging and another one to production. So all microservices, when running in staging, will hit a specific database. And in production, they will hit the production database. So this way, you can actually lower your risk by using a database that is not running in production, for example. And while in staging, you can check and validate your application, make sure that the connectivity to the database is fine. You can add data to the database if you want, and delete, and make sure that the application is behaving well before you roll it out to production. So this concludes the demo. I hope you find it useful. And thank you for watching. And until next time.