GitLab Think Big! - Release Management, 3 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 3-year vision: Design presentation for Release stage

Description

Showing initial progress on creating mockups/prototypes for the 3-year vision for the Release stage combining features from both Release Management & Progressive Delivery.

https://gitlab.com/groups/gitlab-org/-/epics/3825

A

All right, uh to recap, a little.

A

um What has been done until now is where we have the epic with the idea of a three-year vision box and to create this prototype for various purposes, and then it was set out to be made by me and hayana, and there were some existing flows detailed out and there were like the bigger picture.

A

We decided like me and ayanna met up last week and we decided to go over the overall kind of like how things align, how things correlate, and then we also found that there were already existing flows that were meant to be prototyped out. So that's where we focused on this week in order to see how far we could get and bring something to the table for today's discussion.

A

How about uh I give to you ayanna uh to kind of walk us through the flows.

B

Awesome, let me open up the issues here. um All right, I'm gonna go over flow b. First, because um most familiar with it, let me share my screen and then what I want is really um feel free to interrupt me. uh Give feedback ask questions, um because, while I was prototyping this, I felt like I need some.

B

You know a pair of extra eyes here to see if the context of the information that I'm adding to the screens makes sense, and also, if uh from um from my brother point of view, if the flows would actually connect.

B

So as we know, the flow b was about deployment approvals from books, review, apps, feature flags and the release page, and I try to adapt to the the overall like the overarching goals. This uh this exercise is to create this experience that embeds the the flow in gitlab.

B

um So the first step here would be that the user receives a notification or an email saying that hey you have a deployment to approve. For this example, I used on a pre-production deployment again if the information doesn't make sense on the screen. It's because I need more context on what specific steps the user would be so.

C

Fine, this looks okay from my perspective, or do you have any thoughts.

D

uh So far, so good, let's walk through it.

B

The email good all right, so the user receives the email saying yeah. You have this thing to approve. You can approve or reject from here and then we'll take you to the different view or you can click view details so.

D

Let's say right: um this is like on the pipeline itself. Where do I see this window on your email? This is, uh I might even okay, because it does look exactly like the email notification.

B

D

B

Yeah we did, I didn't really find uh that's another thing from the ux uh uh assets. We don't have emails uh prototypes, so I just had to create from an email.

D

By the way, that's like a feature that I've heard many many customers ask for: how do I customize the email, but not our problem.

B

But it is a problem indeed, so I just created this based on yeah an email I had in my uh my inbox, so user clicks view, detail and then they're taken to this view. um That shows what I understood and we're also looking at the things that would be more or less like the cycle of this release. That could be yeah.

D

I do want to ask a question: the previous email can I approve and reject directly from the email, or do I need to go through gitlab to do that, because I think in terms of permissions and security, I would prefer people to actually go through git lab and not through the email itself, because an email can be forwarded and stuff like.

A

D

I think that's something to think about. That's.

B

A good point in this prototype I'll get there, because I want to show the different flows all right type when you hit, for example, approve you get to the review app and then you can approve from there. So you ideally need to need to log in to gitlab before you can access the view app.

D

But the review app, you don't have to be logged in. That's like you, don't have anyone can use it. It's just a url.

C

Yeah, so I I think that when I wrote this load, the intention was that the approve would take you inside of this view, um and it wouldn't make you it wouldn't actually send like a curl to click that button for you. It would take you to the screen to then approve.

D

Yeah, so I think it's a little bit confusing, I think jackie spot on that's exactly what we need to do get back to gitlab and then do that approval from git lab when you're already logged in you get audit log and everything is inside the system. So I think it's just a little bit confusing because to me. If I had that button, I would think that's what it's doing in the email. So that's kind of a pattern.

C

Though, in other companies where, like you are you click a button and it takes you to the next step, so maybe it's um maybe approve slash, reject like yeah, like maybe just one button that says exactly go to get lab to approve, slash, reject.

D

Yeah, like in the bottom of the any email that we get from gitlab, it says view it on gitlab. I think that's a good convention to keep.

C

Right or maybe we just remove the approve, I like the approve and reject buttons. I do like that, but I think that maybe view details is the only button that we should yeah, maybe be something like that exactly for project yeah, there you go okay. This is going to take a lot, let's go through the flow and um I'll capture our feedback notes, because I want us to get as much through this as possible.

B

Yes and if you're free to you can leave comments on these files, so feel free to drop comments here and then I'll make the updates, async cool. So let's say user clicks up and reject they're taken to this uh uh the view on uh the group release um and then you have your pre-deployment approvals and you can see here a list of things that are pending again the data. It's not really, I think what we should display here. I put the um the issue and then yeah the.

C

B

Pipeline everything and you can see what's spending what's approved, you can click view app or from this page approve or reject. If you click approve or reject, you have to um confirm the approval rejection. We can definitely do this in a different direction, still on the screen without a model, but the model is a partner that we have right now and then you confirm your action. um You leave a comment and the status change on this screen right so, for example, proof by hayan.

B

Now, if I click on view app and that's where I felt like a little bit of adventures, if you click on view app, I'm taken to the view app um which in this example is yeah and the view app of gitlab so um of our own product, so it might be a little bit odd, but you see that okay, you are looking at the pending deployment number whatever by gendo you hit approval, reject and then you're going to have the same interaction with the model where you can enter more details.

B

We also have an example um in the in the flow that says: okay, so in my video there's a feature flag enabled right and then you have to approve with or without the feature flag. um This example just shows that the message is different. You still have the option to approve or reject, um but when you do you get a different model now, just you have the the option to add notes here, but I forgot and then you choose.

B

Okay, do you want to disable the feature flag with your approval so enable or disable that's going to define uh the status right for this for the deployment and then, after you did the approval or the rejection from this view or from the the list view um you can see in the merge request um status of for your pipeline.

B

So here I try to play around a little bit with uh what it would look like mocking what we have for the merge request approval. But in this case let's say the deployment was approved and now the pipeline starts running for that specific uh step, and then you can see who approved the pre-deployment and potentially see more details about yeah. If there was a comment or what other approvals exist, who approved it, etc and for the different use cases when um it's approved with the future flag enabled.

B

I just thought it would be nice to show some things here in the ui and if you reject the pipeline doesn't run and then you can see there was rejecting and the reason for rejecting it. So this is the flow b um that will connect, deployments, uh run books a little bit uh future flags and um approvals.

D

So I have some questions because I was holding back not to stop.

D

uh So one thing that I wanted to ask is the second screen: you showed that one yeah, so this will only be showed if the previous steps succeeded right in the pipeline. So let's say I have like a bunch of jobs uh stages and then the previous one failed. I won't get to this right.

D

It's pending on the success of the previous stage.

A

I think um I think where uh there is some confusion here, is that we're not looking at a pipeline.

C

Here, step, right, like this, would be kind of like a mom.

D

Okay, so let's say notify slack failed. I won't.

B

D

To pre-deployment approval right, I understand this isn't a pipeline, but that is anything that comes before. If it fails, it shouldn't continue correct.

C

I think if you, you can have like pre-deployment approvals populated with stuff, but you won't be able to approve or reject unless if the steps are completed before but there'll be information in that. I think in my head, like there'll, be these pending items and approve and reject will be grayed out, because you can't do anything with it.

D

Yeah, that's but they'll, be there I think. Okay, um now can you go to the next, I'm not sure exactly which one so just go through the flow um okay. I really really like this idea of having the proven reject buttons on the review app. However, um most of the review apps are a website outside of gitlab, so I'm not sure how we want to do that.

D

um If you think about the way, visual reviews reviews work today, um which is kind of similar, because you take action and you look at write comments that goes back to the merge request.

D

You actually have to add snippets to every single page in your project, which is really difficult, and I think that's why a lot of people don't use it. um So the question is: are we going to change review apps so that the url is open from within gitlab and then you can still stay in that context? If not, I'm not sure that this is feasible.

C

This is a three-year vision, though I feel like if we can say that this is like a moonshot where we'd want to take review apps. I think that that's definitely something that we can incrementally deliver to. The intent of the screen to to me orient is that you can actually do something from the review app yeah.

D

And I really like that.

C

And I think what would be cool is if we make a feature improvement on review apps, to allow this to be like a an aggregation of your changes so like you're not having to review just a point by point change. So if there's like a way to group review apps for review, um that could even be like a future enhancement that we make in year. Two from now you know, but I completely agree like there's some solutioning that we'll have to do from this um but directionally.

C

I think it's important that this is a moonshot and, of course, like it's planning ambitiously, and I do feel like it captures something that you've said before around people wanting to interact with you apps more meaningfully.

D

Yeah yeah exactly 100; okay, let's go to the next uh one.

D

D

Yeah there's a pipeline here and then there was something with feature flags.

C

So, there's that modal that says, enable disable feature flags.

D

You're, okay, with that, I'm fine with that you can continue. The the other question is that this is per environment right because the feature flag, I could have a feature flag on staging, but I'm you know doing production. So it's not right, and then um this is very cute.

D

I don't know if we need to add into the three-year plan that we want to have all of this like in an audit log and so on and so forth, because we do.

C

uh I love where your head's, at though that kind of ties into our compliance narrative, which was like a flow c. um So maybe that's something that we can look at down. The road like all of this stuff then takes you to um the audit.

D

Anything you do, especially if it's manually you have to have it logged, have to.

C

D

C

If we use the merge request widget- and this is as we're extending the merge request widget then that would probably be um you know, like merge. Request. Approvals are included inside of the audit logs, so maybe we would gain that benefit if we're.

D

C

Merge requests widgets to include deployments.

D

Maybe maybe not you never know um hayan. I wanted to ask you if you could make the feature flag here, like a url in the.

B

Text uh a link here yeah. Let me.

D

Because I I think it just needs to link so that if someone wants to know what feature flag they're talking.

D

About no uh very cool, and then what was the next.

B

One uh just the last one and the next one was a failed like rejected.

D

No well rejected is rejected. Okay,.

C

I think what would be interesting here is if it is rejected, um linking back to like the get lab runbook being like what steps have to happen in order to get this approved kind of thing, bringing it full circle to how do we? How do we operationalize like a rejection or approval.

B

Something like um some some action, I'm just gonna put a placeholder here, yeah exactly then you have a button to to the rumble right. Another.

D

Cute thing that we can add is another email notification once this is approved.

C

Look at you or even slack notification like allowing.

D

Whatever notification.

C

B

I love that india in the second floor, dimitri is going to show we have uh the with the slack prototypes. Then you can have a look at it. um That's it should I jump. uh We jump to the next one. The media stop sharing. Then you can take over.

B

This was awesome. Thank you for the feedback.

A

Sure, let me let me get to it.

C

Well, actually, this is awesome to see it's cool, that some of these ideas that we've kind of flirted with or talked about are materializing. It's really cool.

D

I really like the fact that you can visualize it, because um I think you know a picture is worth a thousand words.

A

All right here we are with floyd.

D

And we won't get stuck with that competition now that they have with find over goals, because there's no text.

A

D

There's a competition now to find like ambitious goals inside the handbook and get rid of them. I guess for the ipo, but uh since there's no text, no one can nail us on that. Yeah.

C

We're just visuals.

A

um All right, let's get to flow a uh flow, a is not as complete as the first one we're missing out a little bit more information, or at least having a little bit of problem with how to visualize certain things in later steps, but beginning from a similar, similar beginning point where the user receives a notification from slack or email.

A

I took the liberty to begin from an email here, but this could have been a slack notification for all that we care and that a deployment has been rolled back automatically would link to the failed job, an option to see the environment. So that's what kind of what we see here. We see here the failed deployment and then actually what has been done to kind of like resolve that you know it's been automatically rolled back to previous deployments.

A

So we see here where we are in the gitlab.com marketing page website project and we've rolled back to a 1.3.1 release in this case.

A

So you can view your environment make sure that everything is all right, but you can also go into the alert which has been highlighted here as well then, on to the next point here, I've been uh going a little bit, you know, being creative here, see how we can adjust the deployments page of an environment to be a little bit more informational, highlight the failed deployments immediately and also to kind of see hey, which deployment is currently active.

A

So here we see that the failed deployment has actually been rolled back. So when you click here on view, environment you'll be redirected to this page, and you can see all right. This is my currently past successful deployment, and this is the failed deployment that kind of triggered the auto rollback.

D

Well before we continue, I think, there's a problem with the terminology of failed deployment, and that might be my problem like because I started that terminology, uh but the deployment is successful, but there's something wrong post deployment, so the deployment isn't really failed like it could be, as we talked about yesterday, like cpu exploded all of a sudden, but the pipeline is green and in all sense it's successful deployment. So I think we need to think about the terminology. There.

A

Yeah, so you would say like this would be a successful one, but.

D

Yeah but there's a critical there's, a critical alert, so I.

C

Think there's two use cases, though there could be an area where there is a failed deployment. So, for example, if you do have like a dependency that you're looking to deploy first and that dependency doesn't happen, then you would have a failed deployment.

D

It wouldn't get the deployment stage in the pipeline.

C

You're totally right, it would, but it would be a it would be another status, that's separate from um a rollback. You know.

D

Yeah, so that's exactly it it's a little bit the terminology. It's confusing here.

A

C

I also wonder if it's deployments versus releases you know like um how do we wanna? We don't have a deployment inside of like gitlab. Today, really right I mean we have like a. We have something that's deployed on an environment. We don't have like the deployment object in the ui. We have the deployments api right, no.

D

But we have, when you go into the environments, there's a tab with deployment, so we do have the information we can.

C

Bring it in okay, keep going sorry.

A

All right, um so this is this is kind of the view that that does that. um So, when you go into more detail on this, we kind of go towards the next step, and we see here, for example, that three issues have been created from this. You know: failure to deploy- or this rollback. That kind of you know created these issues.

A

um There is, then, a um like a let's see that hyanna is moving around this thing. um There is this kind of pop out that you can hover over see, you know hey. Do I want to find a assignee or a milestone directly from this view, but you also have the alternative to go into detail um in this view. So you, you are redirected back to the run book. um Hey I'm now in I'm only in common mode, so you can see r8.

A

I repurposed the view from hyanna here a little bit and say all right. We got three open issues, for example security issue here and some other things that have gone wrong. You can select your assignee, you can select your milestone, you can view the issues that have been created and kind of. You know make sure that we continue to progress the release in in such a way. I love this yeah. This makes sense. I I was. I was wondering.

D

Yeah this combines monitor and security altogether, which I think is really really awesome. um The one thing that I'm going to ask again- and I know we talked about this before, but we need to make sure that whatever we're showing here now, which may be an incident response event or it may be a security event that it's relevant to the specific environment that we're trying to do the runbook for and not just have all the alerts again like it has to be specific to the specific environment and deployment that we're talking about.

A

um Yes, but I I, as far as I know, this run book can be across multiple environments right, so this is within a group view.

C

A

C

This auto rollback remediation needs to have like the uh the details and context that it's for that specific job that you're rolling back like you're rolling back that job to a previous deployment.

A

To the specific.

D

Environment, uh jackie, just a question for you. So um if we have one of these security issues like the cv, something something something which is too small and I'm too old to read, um someone may select to skip you're allowed to say like ignore this, I'm not dealing with it now. That's.

C

D

um How does that come to play in terms of the run book.

C

I think it would be an approver reject, which was the same stuff that you saw before, and it would just be like hey. Are you sure you want to approve this? uh It has no invulnerabilities, and it would just be a manual override, which would going back to your previous point would be audited, um would be in an audit log and an activity track. And then we can have a note that says approved with vulnerabilities by so that that's visually indicated in here going back to like high on his first flow, like that approval screen.

A

So, just to get a little bit more like into this design here how what kind of changes? What kind of information are you missing here specifically.

C

I think that um this view on a rollback remediation.

C

I think it's good, that you can assign people and select a milestone, but we do need to have acknowledgement that a rollback has been accepted so like we may want to um add a formal acknowledgement, a formal approval of a step that shows that, like okay, this back is okay. We don't need to like fast forward a deployment.

A

ah That's interesting because my assumption here was that you know you have your pre-deployment approvals. Those have been accepted. Then the rollback has gone in progress that turned out to be wrong. Then our other rollback has been created and like that is like an accepted process. So.

C

That you can immediately.

A

Kind of pull forward towards all right: how are we going to re-remediate and solve this solution to progress our release towards them.

C

I see a couple of uh different ways to think about this, so on a continuous delivery cycle there might be three or four pre-release candidates that somebody could select. Are there stable releases that they would want to promote to- and this case it's going back to the last stable build, but somebody could actually say actually we fixed this in 1.33, so, let's fast forward to 1.33, um but from like a missing information standpoint, I'll defer to ori since rollbacks are kind of like her wheelhouse.

C

But from this view we need like a formal acknowledgement and approval that this is an okay step, because it's a system rolling back our code that we need to have like acknowledgement that that's that that that happened as expected.

A

D

um I think we should actually generalize this even more so this step is called auto rollback remediation, but this could also be a manual step, so maybe skip the word auto and just have roll back remediation and definitely if you have a manual step, if you have a manual step, uh you definitely want that as part of the runbook and the manual acknowledgement.

D

I think we can make a lean acknowledgement system. Like I don't know system is the right word, but you know just the thumbs up thumbs down, I can hear, would be really really cool and then you could know exactly who who wrote it down and then maybe if we won- and this is more of jackie's expertise if someone rejects it and gives it a thumbs down, you uh you're obligated to write why.

C

Exactly and then you're formally acting that that behavior I I do think what would be interesting here. Dimitri is if we were to show related um alerts or incidents from this like um well. I.

D

Think, actually, that's not needed and I'll tell you why, because what dmitry's showing here sarah already is doing like automatic issues from from the alerts. So if we have all that in place, it's just an issue. So I'm not sure if we actually have to go back all the way to the alerts which.

C

I guess is what this view issue is for right. Yes, okay, perfect, then that's captures it perfectly. Okay,.

A

I would say that this, for example, this resolve cve uh 1750 issue, is tied to a security alert.

C

Love it perfect. Okay,.

D

uh Sorry, just full of ideas today: what about adding the severity or some kind of label here, so that someone knows like just at a glance how serious this problem is? That's really good.

A

uh To be added, that sounds all great. I have to note by the way that this issue, this meeting, is now one minute left in our time, and the next meeting is about to start. So do we want to continue this later.

C

We should have another follow-up um on this. I think. um Maybe we can incorporate the feedback that we received on the flows and then have a second follow-up meeting to continue.

A

Yes, I would like I'd love to invite both of you to kind of leave these kind of like little common dots all over our designs, because, especially for the later on views, we are missing out some details or would love some additional explanation of what is actually expected here and kind of how it relates from one view to the next. It would help a lot.

C

And dimitri I'll engage you in the flow b or the flow, a issue that I created, um and maybe we can iterate in that issue on the last couple, steps too. If we need clarity on that.

A

Yes, that would be great.

C

Okay, perfect all right! Thank you all this was fantastic, I'm so proud of you. This is amazing. Thank you.

D

It's really really exciting, so thank you. Both.

C

I'm just in love. Thank you guys,.

C

Bye y'all, bye.