 Hello, my name is Cesar Cevedra and I'm a Technical Marketing Manager at GitLab. In this short demo, I'm going to be covering GitLab Release 13.10, and specifically, the Dora-related features introduced in this release. They are group-level API support for deployment frequency, and the second one is Dora 4-based lead time for changes. But before we jump into the demo, I'd like to cover what these Dora metrics are. Dora stands for DevOps Research and Assessment. It's a company created by Gene Kim and Nicole Forsgren. It's now owned by Alphabet Inc. They identify these four metrics, which measure the effectiveness of an organization's development and delivery practices. They are industry standard, and they are a simple and yet powerful tool to help leaders and teams focus on measuring and improving what matters in relation to their software delivery and operational performance within their organizations. There's one fifth metric, availability, which is usually measured via SLAs. But the other four metrics are here. The first one is deployment frequency and lead time for changes, and those are the ones that will be demoing. And the last two are time to restore service and change failure rate. To be able to demo the first one, we need to have a group that contains one or more projects. And then to demo the second one, we'll need a project, because this has to do with project level right here. So let's start. I've created a group called GL1310 CSDemos. And the group ID you can see here is 11585260. If we go back to the group level API support, this applies to groups. And you can actually measure the deployment frequency of projects that are within the group. Right now, the group doesn't contain any projects. So the API call should return an empty string. And there it is. It returns an empty string. So let's go ahead now and create a project inside this group. Let's just go ahead and click on template. And we can just create a sample node project. There you go. That's one project. So now let's enable auto DevOps in this project. This will start a pipeline that will deploy the application to production. Very good. The pipeline is now complete. So let's execute the API call again. And this time, the group returns one deployment, which is the one that just got deployed. So we have one project within the group called my node. Let's add another project within this group and then deploy that second project. And then check again, we should have two for the deployment frequency as a return value of the API call. So let's create another project. And let's create it from template, a Java project called my Java. And let's enable auto DevOps and select continuous deployment to production. This will start a pipeline that will deploy the application to production. The pipeline for the Java application is finished. So now we have two deployments within this group. There is two applications, one node application and one is a Java application. And we already checked earlier that at the group level using the group API for Dora metrics for the deployment frequency, we got one entry as a return value. So now if we rerun it, we should get two because we now have a second Java deployment that has gone to production. There you go. Now the value says two for the deployment frequency for two deployments. Also, I would like to call your attention to this number right here. Let me make the window a little bigger. This number here is the group number right here of this group, one, one, five, eight, five, two, six, zero. Okay, very good. So now we've covered this feature right here, the group level API support for deployment frequency. Now let's move on to the next one, which is the Dora for base lead time for changes. So this feature works at the project level, not at the group level. And it works in conjunction with merge requests. The EMR will provide an indication of how long it takes for code to be committed and deployed to your production environment. So let's go to the Java project and create an EMR to be able to exercise the API for lead time for changes. But before we do that, let's try the API and it should return a null value. It's returning null and notice that the number here that I'm using is the same as the project ID here that you can see for my Java project. So let's go ahead and create an issue first and we'll say update welcome message. I'll assign it to myself, create the issue and then we'll go ahead and create an EMR and then we'll go ahead and open the application in the web IDE. And we'll make a minor change. Spring Java is here. And we also need to change it here. Very good. So let's commit, we'll commit to the branch and this will launch the pipeline. Now that the pipeline is finished, I have actually waited a few minutes before I can go ahead and close the EMR or merge the EMR. So let's go to the EMR again and let's go ahead and mark it as ready and let's merge it. This merge is going to go ahead and kick off another pipeline. And when the pipeline is finished, we can check the lead time for change for this Java project by executing the API one more time. And here as you can see, this number here is in seconds, just about 11 minutes. And that's the lead time for changes for the specific project. This concludes the demo for these two features introduced in 13.10, the group level API support for deployment frequency and the Dora 4 based lead time for changes. Hope you enjoyed this video. Thank you very much. Until next time.