GitLab Release Group, 23 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Release Group - Categories & UX Overview

Description

Overview of categories for the Release Group, with examples for all key features for each of the categories.

Full content and links at: https://gitlab.com/gitlab-org/ci-cd/release-group/release/-/issues/101

A

Hello, everyone- this is daniel fosko, I'm the senior product designer on the release group, and this video is an overview of all the categories that we have in the release group and some examples and links to the ux of our features and what they look like. This is meant as a sort of onboarding guide for anyone that wants to get acquainted with all of the stuff that we work on here in the release and it's an overall list of links and useful resources.

A

If you want to understand our group, um the bulk of this video is based on this issue. uh Release group ux overview that lists all of our categories. uh By the time that you watch this video. It might be that the link has changed to a handbook page, but the content will be the same.

A

You can also see a sigma board that has all of the screenshots for this issue and other useful links are our planning page on the handbook, our group direction page and the deployment direction which I'll talk about in a bit.

A

um So, starting from the very top, the release stage is meant to put all the code that our customers developed uh into the hands of their customers right so after they have configured ci pipelines, infrastructure and everything uh putting all of that code uh as a result of their development work into the hands of their personal customers deploying uh to their infrastructure, be it in the cloud in something like aws, gcp or anything else or in their own infrastructure that they connect.

A

Gitlab to, um as I said, the handbook page uh has a lot of information about the release team itself. The release group you can see here uh there are team members and and a bunch of other useful information, uh there's also a planning page, as I mentioned, that breaks down a bit more in detail, how we develop our software and how we release our software.

A

So that's another good read, but most of all the deployment direction is a very interesting page that defines how we want to approach the topic of deployments and how we want to improve uh key capabilities in deployments uh in the near future. So this is really good stuff, and if you want to understand where we're going, this one is uh a page. You should definitely read read all right so going into the categories themselves in this.

A

In this issue, or in this page, you find each of the categories with a link to the direction page for it and for each screenshot that shows a product. You have a title. These usually will have links, and these links take directly to the page on an example project in gitlab, where you can see the the same screenshot you're seeing live for some of them.

A

You may need to sign in so so we might have a docs link or something like that, um but starting from release, orchestration then release orchestration is super interesting, because it is a very large category that a lot of work has happened in um so it is essentially the ability to coordinate, complex releases across projects um in a way that is either automated or automated, and also with manual steps right. So it's essentially all all of the coordination work that goes into release releasing the software and getting the tools to help customers do that.

A

So you can see here, there's some stuff about manual processes versus automation and and a lot of either research, uh competitive analysis or vision for the future on what we want. Our release, registration tools to look like uh so really interesting stuff, but in practice, what does? How does it look like right? So this is what this video is for. um So this is the releases page for the gitlab project, uh it's very complete, so it's a useful example- and you can see here it has source code as assets.

A

It has a bunch of change logs.

A

So these are all things customers can set up for their releases and all the way down here you can see the top commit of this release and the tag and some additional information um beyond seeing the release, you can obviously create a release, there's also a ui for that, uh where you choose a tab, one of one of the existing tags or create a new one, and then you add all the information that you just saw on the screen below you can create from here or from the api as well, which is also a possibility.

A

Another way to create a release is to create a release from tag right. So what that means is you create a new git tag and, while you're creating the tag, you add some release, notes on the release, notes, fields, and when you do that, you will automatically automatically create an associated release to your tag. So that's a shorthand way to to create a release. Bitlab.

A

Moving on to the next category, we have release evidence which is very connected to release orchestration, but it's a more specific thing in the sense that release evidence is about creating evidence that can be used on compliance audits right. So you can see here in the category direction. Release evidence is about addressing the means of the business to understand what is changing right.

A

So what is changing is changing from the point of controls and compliance to making sure that all the changes are compliant and meet the demands of the business in a way that can be auditable.

A

um So in this example, here uh we have this project git doc that has release evidence set up, and you see it creates this json file and also links to a sha uh identifier that pretty much lists everything that has been changed from this uh from this release. If you go back here in the documentation, there's a snippet that shows what this looks like right. So this is what the release averages object looks like, so it lists not only the the orders, uh the issues involved, the milestones, but also the commits themselves and the artifacts.

A

So it's really this complete package of everything that has changed and can be tracked by the business.

A

Next up is environment management, and this is a newer category. um It was created maybe a couple months ago, and it was basically cut away from release orchestration. So you see a lot of the pages and features that environment environment management takes, takes care of uh used to be in release orchestration, so there might be some overlap, but the ultimate goal of environment management is to enable organizations to operate and manage and manage many environments in complex setups through git lab.

A

So, for example, in jobs to be done when managing my deployment platform, I want to monitor and have historical context about the different deployed versions of code across my application. So what what can that mean right? That can mean having a deployments page that clearly shows you, sorry, an environments page that clearly shows shows you all the tips, different types of environments where you can drill down into okay for development. What has been deployed here? Let me see more details. Let me see this specific deployment.

A

Let me revert this specific deployment, so these are things that that we have. We are working on in environment management um and, as you can see, this is the current uh environments, page um with a list of environment holders within them the environments themselves.

A

If you click show all you will go into a page for the environment, folder itself um that lists all of the environments in that folder. That can be many. You see here there is even pagination, um and if you jump one level down into the environment itself, then you will see um lists of deployments that were deployed into that environment. In this case, it's main within this holder.

A

um Those are pretty much the screenshots that we have here um so the folder and the list of deployments, and then, if you go one one level deeper by seeing clicking here on the job, you could also take a look at the commit, but taking the job as an example, you see the job log for the deployment job. That did this specific deployment, and you can see here there's a piece of information that ties back to the environment's page saying this job is deployment deployed to this environment.

A

um Conversely, if you had failed, then you would see something like this right. The deployment of this job to production environment did not succeed.

A

If you just started a new project in gitlab, you would likely see this if you create an environment and doesn't have any deployment, that's what you're going to see and then the instruction this read more will take you to this documentation that gives you an overview of environments and deployments and how to set them up um and then with some examples to how to create your environment and and set up your deployments from your yaml file right.

A

So here's a simple example: here's a more complex example with dynamic environment names, which is also something you can do.

A

Another two two interesting features that are within this category are protected environments, essentially making sure that a production environment or maybe a 2a environment, cannot be deployed to by certain users, so you can define which users or which user groups can deploy to this production environment and set that up. We don't have a direct link to this because it links to the settings of a project. So you need to be maintainer of the project to get here, but there's a link to the docs that has more information.

A

Deployed freezes are again within the configuration, but essentially allow you to set a window of time where deployments cannot be done made sorry where deployment jobs cannot run for a specific environment right, so maybe there's a specific holiday or time zone or or specific time window. Where you don't want the team to deploy into production or anything else you can set them up set that up here.

A

If I'm not mistaken, you can also do it via api, but the docs have more information on that.

A

Next up we have continuous delivery and looking at the direction page continuous delivery is all about enabling development teams to improve their velocity right to make sure that they can deploy more effectively and faster in a really good cadence right, so adopting the best practices for for devops. Specifically, dora metrics is a big thing for this category um and and the features the the way they take shape is essentially dashboards right to show you either from from the developer's perspective, or maybe even from manager or director perspective. What is the velocity and what?

A

What is the the efficiency in a way of of the teams? So you can see here, release septic statistics, deployment frequencies of number of deployments over time, which can be useful and then also the lead time for merge requests right, and that means how long it took from merge requests to be merged uh and until they are deployed to a production environment.

A

So that can be seen into project analytics cicd the time- and I think it's nice to show this on the page itself. Yeah. It shows you here. There were no more requests during this period. So no lead time, and then here you have a few. So you have a data point again.

A

uh Up next advanced deployments, uh advanced deployments uh is also super interesting because it has quite an overlap with configure in the sense that there's a lot of kubernetes related features as well. um So the play boards is one thing that that advanced deployments implements.

A

It is essentially an extension of the ui on the environments page that shows you um the different kubernetes pods. They have set up for your environment um on this. I don't think they are running right now. um We can definitely find a better example for this, but it's it's also nice to see like that. It's here and you see there's additional information here as well on the statuses, so essentially each one of these squares is one pod and yeah.

A

They can have different states based on if you have deployed to them, if they're running they have failed, etc, and then, on top of that, another interesting feature is blue. Green deploys right. So essentially, as you have a deployment being made, you can choose between stable and cannery, like what is the the the mix right that you want. The the new deployment to take 90 of your pods and the old deployment to take 10 of your pods, and you can change that ratio here in the ui directly, which is pretty cool uh up next.

A

We have feature flags, um I think feature flags are very well known feature but essentially yeah. You can create a flag, wrap, a new feature or a new page within a feature flag and then define a group of users that will have that flag turned on for them and we'll be able to see that that feature. Everyone else won't be so in terms of how it looks like this is the feature flags page, there's a bunch of them configured and then beyond configuring, a flag right, here's the page to create a new flag.

A

You can also create what strategies right? What are the the parameters that will define for whom this flag is enabled? So you can choose for certain environments. The feature flag will be active. um You can also define a percent rollout, like a certain percentage of users, will see this feature flag um and combine different kinds of strategies, um and then the users, you define them in user lists right. So you essentially create a list of users.

A

Maybe it's your beta testers, your internal testers, maybe it's one specific customer, so you get the user ids for everyone who's within that customer. But essentially, within your application, you get a list of user ids and through the integration with gitlab feature, flags uh gitlab can turn on the feature flags just for those users based on the user list that you have submitted.

A

um There is something missing here screenshot, but I will show here um because this is a really cool feature. So it's essentially, uh you can relate feature flags to issues. So within an issue you can add which ones are the related feature flags for that issue and then on the feature flag. You have a link to the issue on the issue. You have a link to the future flag.

A

um I think I forgot the screenshot here, but I'll add it later, because it's it's a pretty good one and yeah here is the the full user list. If you edit it, you can go in this view and then you see all the ids for the user. Specifically um there's this this model for configuration as well. um As I said, the user lists they come from the application, uh so you need to to do some configuration to connect gitlab feature flags with your application itself, so you do that through this model.

A

um Next we have git lab pages and gitlab pages is like a category that is moving out from the release group uh it's in process, but the team still holds a lot of technical knowledge. uh So if you have questions a lot of the developers and members of our team know a lot about it, but yeah there's not a lot of ui for pages. You just go into your project settings pages um and then you either set up the domain or you set up the the page itself.

A

Again, I think there's a missing screenshot here, because this is the one to add a new domain. But let's go into the example itself to set edit.

A

So if we open up pages right, so this is what it looks like uh there is already gitlab pages set up for this project. So it's a small blog page, so the page that is being served could look like anything, but this is what the ui for the lab pages looks like, and if I want to set up a domain, then then it's that screenshot right where I added them, which I don't have. So I don't have that setup um and then at last.

A

This is another category that moved away from release, but still has a lot of overlap with how how your your code is deployed. So I thought it was interesting the example here, but it's review apps they run into your. They run in your merge requests to create an environment uh for you to review the code. That's in the merge request- and you can see here- that's that's stuff being deployed uh anyway.

A

There's a lot of connection to release still, um so you can see their direction page here with more details uh and then it's under the testing group, so you can see their vision here as well. um This is it for this list. um Let me scroll all the way to the top and again there's this figma board that has all of these screenshots feel free to to explore that. If you want to it's, it's just a different visualization, so here we have all of them in order yeah off of their categories.

A

uh Also, the deployment direction highly recommended- and this is the first version of this video- if you think something is missing or if there was something wrong or if our categories change that will most likely be new versions of this video so feel free to leave your comments on the issue, if it's there or if it's on the handbook already feel free to open a merge request and thanks for watching.