GitLab Digital Experience, 4 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DEX Walkthrough of Merge Requests and Review Apps

Description

Walk through of how the Digital Experience team uses merge requests, review apps, where to find them, and when to use them.

MR used for walkthrough: https://gitlab.com/gitlab-com/marketing/digital-experience/buyer-experience/-/merge_requests/1097

A

Okay, all right we're gonna, walk through and talk about, merge, requests and review apps, which are so cool um all right, so merge requests. um What are they.

B

A

uh So merge requests those, um so we have like our main branch right and that ships and builds our main marketing site and that that's production when we want to make a change to it. We have to batch those changes into a new branch that ships up.

A

We create something called a merge request which creates an interface for everyone to work through those changes in git lab and see like what code changes have happened in order to make those changes and that's how we collaborate on changes that are released like to production on the marketing site. So super key thing, one of the best one of the neatest features that gitlab has are these things called review, apps, which essentially spins up a whole replica um of the marketing site, but then also includes the changes that are in that merge request.

A

So it fires up a whole production, build and ships it off to the cloud into the internet somewhere and gives you a nice URL where you can actually view that new version of the the whole marketing site with those changes, um and that is like the coolest thing. So, instead of having one dedicated staging server, you know staging dot whatever we have staging sites for every merge request that is open um for buyer experience. Now you take that over to the www version that we could have a thousand merge requests open.

A

So it's a thousand staging sites which allows us to like really scale. All of them gets a little tricky because then you have all those changes happening at the same time and you can have many different versions of the site based off of review apps and that can get a little tricky when coming into review. You can review one merge request and it looks totally different than the other and that can that can be.

A

Why um any questions there we're good all right, so review apps I'm going to share my screen and walk through this merge request. I've been working on, so this is for creating the support services, template and um here's the the merge requests. We're working on that.

A

B

When do we use it, how did you start the merge request, or how did you create a merge request? How.

A

Do we create a merge request? Well, let's see what is the best way to do that? Oh okay, we can go.

B

To you don't need to create anyway, just like what are the steps.

A

Yeah, actually I can create one so I'm going to go back to our epic here for the support services and it's comprised of three issues. The first one is the we're planning the support services template. We we've completed that step. What we're doing right now is we're creating this template, but the next one once we create the template and we push that to the Repository we're going to actually release the template, so turn it on. So it's live in production and we have a separate issue for that here, which is releasing it um now.

A

One of the other super cool super cool gitlab feature this one's actually, my favorite, um because we now have our own digital experience group and our buyer experience repositories in the digital experience group and the issues where these code changes are happening are in the Repository.

A

We get this super freaking cool button called create, merge, request and I can do that. Right now, bam wow, look at that and it puts this draft on it, which also signals like hey like this is not. This is not ready, don't look at it and then it's putting our boilerplate template in it.

A

um We've added um this website change template which I'm gonna just go ahead and add it, and this goes through what our four approvals are and who you need to add in order for it to go, live, and since this is going to be actually releasing the new template to production, we need to make sure we get profit, proper approval, um and so it's going to apply a whole bunch of labels and stuff I'm going to leave it unassigned because um John's the one who's gonna be working on this next iteration.

A

um But here now we can see, we've got a marriage request and um what it's going to do is take an exact replica of what is in production. Right now create a new version, and that is it there's once John starts working on it. There will be the actual changes pushed to this. That turn it up live and we can actually bring the the main branch up to date, because what the marketing side is going to look like next week will be different than what it looks like this week.

A

There will be new changes, um we're pushing about 400 changes a week for engineering, um so it's really important. We keep that code up to date, so we have the next merge request for releasing this created, but we're not going to do it. That answer the question. Awesome I'm going to come back to this one that we have uh for creating the template, and this is work we've done to actually build the template.

A

um So first, the next thing I want to go over is like review apps. How do I find the review app for this?

A

Now we have I have been having the engineers put like direct links to the page, so you can go look at it, but every merge request is going to have this really cool button down here it says view app The, View, app button. Wow now.

B

When you push it, sometimes it's not there, but maybe sometimes it.

A

Isn't but yeah most times.

B

It should be okay, what are the situations in which it's not there? Foreign.

A

If the you know, maybe.

B

So this next time, I find one- maybe I'll just send it to you to ask.

A

Yeah like if the pipeline hasn't run yet so you can see here, there's no pipelines, so it hasn't built the site, it's kind of kind of stalled, and this is probably because there are no changes yeah. So it's like yo, you don't need a review app. There's no changes go look at production, um but most of the time that button should be there.

A

um So if you click on that, it's going to take you to this version of the marketing site from that those code changes, and it's going to give you. Oh it goes. My earbud um you're gonna see this big long URL, and this is actually the branch name.

A

So in our code, when we're going down to pull down this version, we're going to go, get checkout one three one, six one dash create sir, and it pulls down that whole version and- and then it's you know, we have this other part of the URL about get lab Dash review app.

A

um This part will change for every review app and um the tricky part is, if you click on it, it's always going to take you to the home page home page. Is there so you'll need to go back to the merge request and it should be? You know this says: Support Services creation I would like to see instead of like review. App like this is the URL of the pages that need to be changed, and you can just come over here and go snap services and it opens up the page.

A

It's been changed and you can also navigate to any other page, and this is what our Engineers do and filza and product designer should also do this. Just like making sure there are any regressions. You know if we've updated the hero component, because this Services template and that hero component is used Elsewhere on the site.

A

Probably we need to like kind of double check and make sure there aren't any regressions, because that same code is repeated throughout the site.

B

um Is there any automation, testing we can build so we're not having progression every time. Oh yeah, we can yeah.

A

There's all kinds of stuff we can build to uh make that more thorough and we should yeah.

A

um So I'll go back to here. Is this template we've built it's not um John popped out, um so it's mostly there. There are still definitely some final tweaks. We need to do um which we'll do um actually next week, um all right when we use review apps and when do we not use review apps.

A

um This is the big one. If a merge request is open, review app is valid. We can use it if the merge request is closed, is gone. It's in the trash and it's not valid for stakeholders or anyone to look at it's now out of date.

A

B

Sorry, a question yeah when we're looking at the review app or we're sending it to stakeholders. Where would you like feedback on that app in the merge request? 100.

A

Yeah yeah always once there's a merge, request, open and Associate it with changes.

A

um And there's feedback on those changes that should all happen in the merge request.

B

And how will we know that those changes have been made? Will the engineer have to comment on our response to say I've made these changes yeah.

A

They they should say I've made these changes um there's also or the other thing is. They can resolve a thread. So this is not related to changes, but let's say it, you know hey. We need to make these chains here's some more changes. They can come and say resolve thread and you can't merge unless all the threads are resolved. Okay, that is a that is a blocker for merging something to to production, um yep and all right commits pipelines, changes tab.

A

This I think will be really good for you all to just like understand what these are and also maybe take a peek every once in a while um commits this is a cool one. This shows the the different like we batch. Our changes into a commit so we'll make a bunch of changes and then make a commit says what we've changed and then push it up.

A

um It's kind of like versions of word, doc, I guess is a way to do it, um and so we can see that John made um three commits to the services page here last week and then I've done three this morning, one adding the form component to this template.

A

um One for ignoring the services template build, so it doesn't actually build into production, but this code will ship and then this one is like we, we do a yarn, lint thanks and always gets me every time, I'm pushing something up and I have to do that. No one's annoying, but it's important, um but this also kind of tells you the amount of work that has been going into a template. So if you open a merge request and you see- 100 commits red flag like we generally want less than like 10 commits per merge requests.

A

Sometimes that goes up to 20. You start seeing like 40 50., it's like oh something's, going on there uh pipelines every commit um well looks like almost every. um If you do, a bunch of commits close together only be one, but this is like every commit and you push it up. That's going to kick off a new pipeline which is going to rebuild the review app and push that up. So then the review app will have changed from the last time. You've looked at it.

A

So if you're looking at a review app and then you go and look at it tomorrow and you see, there's 10 more commits that review app has changed since the last time. I've looked at it now. Hopefully those are the changes you've asked for that you've made in the thread um and if you know, they're labeling their commits easily.

A

You should be able to actually go in here and say: oh okay, I can see those are the the design changes that they've been making um gives you another way to check in on those changes, and then this last one changes changes. These are the actual files that have been changed in order to make this change. Well, it changes, uh and this is just a good one to like peruse down again. We want to see this changes tab uh lower the number the better. You know.

A

We don't want to see a hundred changes per merge request, because that means we have to go and review all those hundred changes.

A

One piece of code is used many places on the site like it just gets real messy.

A

uh So you see we got six changes. We've got this hero component. This is the one. You know that as I'm reviewing it that I'm clued into this is a global. Well, I know we use this component on our Solutions pages, so I'm gonna go spot check the solution pages and make sure they still look good, like Enterprise.

A

um Don't worry about like all this code stuff um and then again, support copy markdown, that's a big one. That's like all of our markdown copy on all the support pages definitely need to go regression check out that whole bunch of stuff a lot of changes.

A

Now this is the the big one content services yaml. This is the actual content for our new page. So we can see you know, Professional Services, a description and.

A

This is where all the content is living. um So, if we, you know see it, let's see we'll go. It's reduced, Market Time, by accelerating the option I come over to the review. App I can see. Oh there, it is cool. Let's say: I want to like come a little farther down, I notice. Let's say: oh, that title's, wrong and I know it's wrong.

A

You can come over this yaml file and find oh here is where that actual title is, um and you can even make a comment directly in this file. Saying yeah, not yo hi.

A

um Please change this to um something else and that'll. Let us know exactly like that's the content that needs to change now, that's kind of like a power user move.

A

um We can grow into that, but it's a really it's a really cool one um and there's even this other insert suggestion button which will actually, let's instead of doing this, you can hit this insert suggestion and it'll duplicate it and you can actually change this to say. uh I want this title and uh add comment now and you can see I've made a suggested change.

A

Here's what it is now here's what I want and then the Creator can actually come in here and actually apply that suggestion and it'll make a commit and make that change. So that comes in really handy, because Engineers aren't copywriters, you know it and it helps when people can just contribute those changes directly to a merge, quests and you get a commit and commit graph and you're a little Emoji shows up. It's really cool.

A

um All right. I went over that any. That was a lot hahaha any questions there.

A

All right jump into the next part.

A

Right I know a lot. um Why do I want to do next? When is the review up no longer current yeah? This is a good one. um Silver merge request is open and you're. Reviewing the changes to that merge request, make sure you're navigating to it always from that merge request.

A

um It can get tricky if you start bookmarking like I, I, wouldn't bookmark a merge request, review app I would always just navigate from the merge request. I.

B

Have a question: um one thing that I struggle with in the way that we have organized our project is like the multiple issues that we have, because I find that one thing changes in like the design issue.

B

It may not necessarily carry over to engineering, etc, etc, and, like one thing that I was doing with like the working group that we have with the CMO communication thing, one thing that they pointed out was like a lot of people are not using gitlab in the way that it's intended and I asked what they meant by that, and they said that the issue should always constantly be updated, based on what's happening in the comments So based on that I'm curious, how other teams have structured it like it?

B

Should there only be one issue where we have the design everything and then Engineering also makes the Mr within that issue, like I'm curious, why we aren't doing that versus the way that we're doing it now.

A

um We we're not operating in that function right now, one one issue and the Mr comes from it yeah. That would be great, but that is just not the way we're set up right now um and not the way. We're organizing work amongst the groups so issue boards wouldn't work. Yeah.

B

That's that's a fair point because like yeah, then the burn down chart would be very irrelevant because the issue would not close for like two months. uh Yeah. That's fair.

A

And we we need to get a lot uh crisper with our label usage and so Carrie would work on the design in that issue and get it all ready to go, and maybe that's the the plan label and then once the create label is applied to. It carries unassigned from the issue and the engineer gets assigned to it. But.

B

In that world, the issue would not be closed for a.

A

Month, no yeah, you know yeah, that's a yeah right now we have sep. We have different issues for each each step of it. That makes sense. Yeah um the.

A

Once once we start designing something and it and or once we start building it and the design has changed like we won't know. Unless we're told in the the engineering issue, um I would almost recommend creating that new.

A

A new engineering issue for the next iteration of the template, yeah.

B

Yeah, it's just because it's really hard to like track work when there's like four or five issues per like one body of work, but I also see the other side of the burn down cards and the impact to our metrics.

A

Yeah I, like um epics.

B

A

The the way that I've been able to to work with that.

A

um So back back to that the support services template can see that there will be the the three issues um and then that's the way that be able to split that work amongst who's, doing it um and plan accordingly. I think there's another one: that's actually a good demonstration of we had.

A

Oh yeah, this support when we actually built the support template. There's an epic and there's many issues like you're, saying um related to this, um and so.

A

Now I can see like all the work, that's gone into this template and now it's closed, there's there's actually a new one that came in and so I just labeled it regression, and so now we're going to start working on the regressions related to that and that's a new chunk of work, a new block of work that I need to plan and there might be design issues that come out of that yeah and if there are we'll need to create new ones.

B

um I've got another meeting, but this was helpful.

B

um I'll touch base with you, Lauren um and Carrie a little bit later just around what our next search nav support priorities are and just how we want to structure it, because Michael also gave me feedback that, like the Epic, should have information but I'm like unclear of what we would have in the Epic because to me I'm, just using that as like an organization vessel for the other issues, yeah yeah, okay. Well, thank you.

B

A

Was there anything well all right, bye.