GitLab GitLab 13.7 Release Kickoff, 12 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 13.7 Kickoff - Release:Release

Description

GitLab 13.7 Kickoff - Release:Release
https://gitlab.com/gitlab-org/ci-cd/progressive_delivery/-/issues/26

A

Hi, my name is enrique lewinsky and I'm the senior product manager for the release date here at gitlab. Today, I want to walk through some of the issues that we have planned for the 13.7 milestone. You can walk along and view it with me. It's issue number 26 under the progressive delivery project. It's called release, 13.7 planning issue. So let's get started.

A

You can see here all the top priority deliverables that we're going to start working on so the first one that I want to talk about is called chill deployment status in the environment page today, when you look at the environment page there's no way for you to know what's going on with your deployment. So what we want to do in this milestone is add that status for you.

A

So what we're going to do is bring the badge that you're used to seeing from the deployments page into the environment page, so you can view it directly from there and know if your deployment has been successful or if it hasn't failed.

A

The next issue that I want to talk to about is api support for deployment frequency, and we're really excited about this, because this is one of our first steps into supporting the door of four metrics for the project in group level view.

A

So um we're planning on adding a bunch of diff all the door, four metrics uh under different uh areas, so that you can view it both in the project level and the group level, and even in the instance level- and this is um the first thing that we're doing is adding api support for deployment frequency, so deployment.

A

Frequency is how often you deploy to production from your project and that's the information that we already have in gitlab, and we want to bring that and have it available for all for all the users and the first step is, is actually supplying this for api. So you may want to bring this information into another tool, and this is also going to be the base for our implementation of the ui.

A

I'm going to show you a sneak peek of what this is supposed to look like at the end for you to see exactly the quantum frequency on the project level. So today, under ci cd analytics on the project, you can see the pipelines and we're adding the ability to uh to also see the deployment frequency. So you will have different tabs for pipelines and different types of deployments, and you will be able to toggle between them and see your deployment frequency for the last week last month and last year. So really really excited about that.

A

And then our next issue that I want to talk about is called set deployment, traffic weight via ui and the previous milestone. We worked on setting the deployment deployment traffic via api. So today, if you're using canary in gitlab, you control the the weights and the rollout through the yaml file in the previous milestone, we added the ability to control this external to the ammo through the api and we're really excited to follow through with also adding this in the ui.

A

So, directly from the deploy board itself, you can set the weights for your stable or canary version and change them scale up and scale down as needed.

A

Now, our next issue is provide a configuration option to prevent maintainers from adding or editing environments to projects. This is for our more highly regulated users, and this is something that has been requested.

A

It's for segregation of duties, that, if there's a maintainer that is not allowed to deploy to production or to a protected environment, they should also not be able to add or remove environments to project and override that ability. So what we want to do here is we're we're going to start implementing it, and this milestone is allowing the configuration or setting to actually prevent this from happening and, um as I mentioned, we're going to start with api.

A

But what we want in the future to see in the ui is actually under something similar to under protected environment, setting to have this checkbox that allows you to enable or disable the setting which prevents maintainers from editing environments.

A

So, as I mentioned api first ui second- and this will enforce this new setting.

A

As part of our dora 4 metrics that we discussed, we also understand that seeing these metrics on the project level uh our only partial solution for this- and we understand that the next level up is to see all the metrics on the group level. So what we want to do is introduce the cicd analytic, analytics navigation at the group level and not only on the project level like it appears today um so again really excited about all the door. Four metrics uh uh coming together and taking shape here in gitlab.

A

We're gonna, consistently see more and more issues that we're going to tackle and address in the upcoming milestones.

A

The next issue that I want to discuss is show aws deployment success code in blogs, and the idea behind this is that, instead of having a user toggle between different tools to understand the status of the deployment, we're going to bring all the deployment information into gitlab itself, so if you're doing a deployment of aws through gitlab, you will also be able to get the error or success information in the git lab itself. So you don't have to go to an external tool.

A

You'll get it directly from from the tool that you're doing the deployment from, and the last issue that I want to talk to about today is see which commits and pipelines are run in the fork project versus the parent project.

A

So a few milestones ago, we added the ability to run forked projects in the parent pipeline by requesting someone with appropriate permissions to do that, for you, and- um and this is what it looks like today- so there's really not enough information for you to understand which pipeline you're looking at or where it actually ran, was it in the parent or was it in the fork.

A

So what we want to do here is actually add this new information, so you can see there's a new badge that tells you that this has run in the fork project and- and you can understand from there. So that's all for me today. I'm really really excited about this uh release and being able to start working on all these cool features. um As always, if you have any feedbacks or comments, uh please ping me on the issues or email me at olgowinski at github.com, and I will see you next time. Thank you.