GitLab Solutions Architecture, 26 Jan 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Using MR Labels for Deployments

Description

The intent is to think about how we could potentially deploy applications differently with GitLab. This also addresses the need behind the issue below

https://gitlab.com/gitlab-org/gitlab/-/issues/233289

Reference Project:

https://gitlab.com/poffey21/mr-rules

A

Hi, my name is tim poffenberger and I am a solutions architect at get lab, and I wanted to take some time to review a particular desired user experience that I was discussing with with a customer and proposed how we could potentially improve the release process for applications being developed and deployed through gitlab as a whole.

A

This project here, let's pretend that this is a developer project that has an application and will eventually be deployed to a particular set of environments and my intent with this cool new feature that I'm developing is to develop it in a future. Develop the change in a feature branch get it approved, mark which environments it would be deployed out to merge that change back to the mainline branch and deploy it to the environments denoted in the merge request that is marked up here.

A

So all of the non-deployment related activity is done in the merge request, but subsequently the deployment activity is available in the the mainline branch. The pipeline associated with that mainline branch.

A

So this change, uh I didn't, make a whole lot of changes. I removed a few comments and I will be marking it as ready and before I merge it. um Typically, I would seek approval.

A

So let's pretend that I got some approval, but I wanted to utilize these labels uh to dedu which environments this would be deployed out to, and you can see that I have a couple different environments, but let's go ahead and just click testing, so I'm going to apply this testing label, and this is to me indicating that I would like to deploy this out to the testing environment once upon merge.

A

So I'm going to click this merge button and uh the main branch is it's now being merged back into the the mainline branch we're having issues getting the pipeline status. But typically, I would see the the master branch pipeline status right here, but let's pull up the ci cd and you can actually see that there's a ci cd pipeline running on master- and I will dig into this and what's going to happen- is this job is going to it's going to go back into that.

A

Merge request that just we just merged from and grab all of its labels and it's using the get lab api, as well as a private or personal access token, and it's going to save those as a file. That file is then going to be used by this deploy mechanism, and this deploy mechanism is then going to trigger child pipelines for all of the labeled environments, and you can see that this child pipeline is kicked off and we can see that subsequently, this merge request.

A

So if I go back into the merge request, you can see that I set deploy, testing and subsequently there's only one environment that was deployed out.

A

Let's go ahead and pretend that I had also selected deploy staging and I will run a new pipeline for our master and, as this runs it's again going to go out to the murder quest that was associated with this merge and it's going to look for all the labels, and it will see that there was a new label applied and subsequently we'll see two two environments and what this uh it's a pretty simple uh file.

A

What we're doing is we're utilizing the end uh capability that we have so I'm echoing a a environment, variable designation, ci, merge request labels which the master branch does not have access to, and I'm just I'm curling some information out. This is essentially taking this commit sha and doing some intelligent sniffing on the merge requests that have been merged api endpoint and only returning a single all the labels that are associated with this particular job. You can see that that information is out there right now.

A

And I did not apply that so, let's go ahead and apply that again and retry this job.

A

I'll re-run, the pipeline for good measure.

A

And in the merge request, uh the the ci pipelines that are associated with the merge request have all these really fancy. Ci merge request labels milestone project id all this information is available when you're in the merge request, but the pipelines that are associated with the master branch post merge do not have any of these nice environment variables. So my intent here is to really recreate that experience, and you can see here that now the merge ci merge request. Labels show deploy, staging and deploy testing, and this was just something that I um cooked up.

A

It's saving that as a nv file and then I'm triggering uh I'm utilizing curl again to trigger a downstream pipeline and I'm also passing the the dot end environment variables within here, and um I can show you what that looks like right here.

A

So this deploy is uh sending these uh via the the post request. The ci merge request labels and it's just passing the environment variables from this needs jobs artifacts true, which is grabbing the dot end of environment variables. Ideally, I would just be able to use the dynamic child pipeline capability and the trigger syntax, unfortunately, dot n. uh Our end artifact support, does not work with the trigger syntax, so I can't use the dynamic child pipelines and it's not that big of a deal, but one of the problems with this model is now.

A

You can actually see that. Not only do I get the these master pipeline branch or pipelines running, but I'm also seeing subsequent deployment so staging and testing all the other deployments are created as a brand new pipeline, because they're not technically child pipelines, uh even though the user interface tells you that it's a child pipeline, it's still um still rolling back up into the mainline pipelines as well.

A

Another downside of this model is, you know, once this gets merged back in there's no way for me to lock these labels. I can lock within within a merge request. I can potentially um lock the merge request from receiving any changes. I believe, oh right here, um but this locking mechanism only changes the ability to comment. So if I lock it, it doesn't actually prevent me from changing the labels here.

A

Thanks for your time. Hopefully something struck a chord in this recording feel free to reach out thanks.