GitLab Release Stage, 11 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Deployment Approvals UI Overview – Pipeline, Jobs and more

Description

An overview of the many UIs that need to be updated to match the upcoming deployment approvals feature, and the different ways we can tackle this challenge

Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/345683

Epic: https://gitlab.com/groups/gitlab-org/-/epics/6832

A

Hey team: this is daniel the senior product designer on the release group. This video is a quick overview of the ux work being done, and that has to be done on the improved pipeline job ui for deployment approvals now for a better context around this. This issue is about the ux improvements that are needed across different uis, including the pipeline job page, that has to happen to support the manual deployment manual deployment approvals, um epic.

A

So essentially, uh we are implementing a feature where you can go to the environments page and approve or reject a deployment right. So that's the core of it and there will be links if you want to see more about it beyond that, though, deployments that have to be approved are in practice, manual, jobs that target protected environments so as manual jobs as pipeline jobs, they are represented in many other interfaces across gitlab.

A

So, as we update this capability, we have to move away from a ui that shows just a manual job with a play button, so ui that shows a deployment job that needs to be approved and the appropriate ui. For that. So, let's jump into figma to explore the problem a little bit.

A

um We can see here that all we see right now right, even if this is a deployment job, you see there is a manual status. It also says here: it is manual and there's display button clicking. This will run the deployment drop.

A

Now, that is the capability we have today. You can approve by the perspective of running these jobs right and if the jobs are targeting a protected environment like production can be, uh then only the people with the right approvals will be able to click this button.

A

So you have that protection, but you don't have the capability to reject it or to set very detailed permissions or to leave comments and that's what our work on the epic is all about, but even if we update that on the environments page, it won't be reflected here until we do that work and there's many other places pages that reflect the same thing right here on the pipelines page. You also can run the production job if you have the permission for that.

A

Also on the pipeline page there's another drop down that also lets. You run the job again pipelines graph has the same thing.

A

The job page can also run it. If you have the the permission for it, uh even the commits view, you can run the job from here, but you're representing the status of the pipeline. That right now is skipped because the deployment job hasn't been approved, so we could also change the representation of the status here. So that's another touch point, and even within the commit page right, you also have the pipeline stage.

A

So that's another place where we could improve our representation of deployment jobs. Now, let's go to a more practical example of how we could update these representations.

A

In this very very brief, prototype.

A

Right, so what we can see here is the current jobs page right, there's no change from what's in production, um as I showed in the previous ones. The first step we could do is update the representation of the state right. So the way we decided is a new state called blocked has been created on the back end on the front end, it will be represented as waiting and then waiting needs approval. That's what we have on the environments. Page, that's what we can represent here. So it's sure it is still manual.

A

It still has the little gear that represents a manual job and still has the manual label, but it is not blocked or skipped. It is waiting because it needs approval, but we still have the play button here. So in theory, if you have the permission to run it, you could still run it here, but you wouldn't be able to reject it from here.

A

Another step would be to replace a run button for these instances with a thumbs up button, which is the the icon we're using for approvals, um but to avoid having to maintain the same approval ui everywhere. One thing we could do is just redirect the user to the environment page to approve this.

A

This copy is, is working copy has to improve, but that's the idea right, just a link, so the approval or rejection always happens on the environments page and we don't have to replicate the ey all over and then the the most advanced uh idea would be to just have our approval drop down everywhere.

A

uh The um the job can currently be run right, so, instead of running you would be able to approve or reject from everywhere. um So these are different steps.

A

I don't think it's necessarily from the perspective of starting from an mvc until a completed state, because these are different approaches, so we might not want to do this regardless of mvc or not. So this is the overview I'll share this in the issue, as well with additional comments. So let me know your feedback and your thoughts on this. Thanks for watching.