GitLab Solutions Architecture, 13 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Automating Git Flow made popular by nvie

Description

https://gitlab.com/gitlab-silver/tpoffenbarger/commit-from-develop

A

Hey this is tim poffenberger and I had a customer that was asking about utilizing. The nv get flow that was made popular about 10 years ago, and this is the graphic that most people that were in the git community probably saw hundreds of times it even made its way into a formalized pdf. So you know it's taken seriously, but essentially you have feature branches. Then you have this develop branch and then things get merged back into master and there's a subsequent release, branches and hotfixes, and this particular customer was asking.

A

Let's say that we have these feature branches and we want to then build out this develop branch and the feature branches will have short-lived ci, so very quick runs and the develop branch will have a longer ci pipeline that will also be executed, and the approval process from the feature branch to develop will be a manual process. The approval process from develop into master will be an automated process.

A

So so don't we don't necessarily need to use the the merge request process within gitlab for this develop to master, because really we would like that to be as automated as possible.

A

So I have this uh kind of mapped out and you have these feature branches with a manual approval process. The feature branches should always have the short pipelines. The develop branch should have a long pipeline and then there's an automated merge upon successful pipeline into this master branch.

A

So, let's begin I'm going to go ahead and create a feature request and the features are designated in this particular instance. With this feature forward, slash and then the forward test run, and you can see that I've updated my default branch to develop.

A

So that way it is able to be quickly created, and so we have this issue and the branch is created and let me go ahead and just add a file, so three hyphen test run and the only reason I'm creating this file is to indicate that there's a change being made and we're creating it committing this to the test run branch.

A

This is going to kick off a pipeline and again this should be the short build process, so the ci pipeline is going to kick off and I'm going to go ahead and head over to my merge request as well.

A

And you can see that this merge request is running and I think I'm pretty good with it. So I'm going to also just say merge when pipeline succeeds. Ideally, you know there'd be some approval process within here, because again this is merging from the feature branch into that develop branch and upon successful completion of this pipeline, things should be automatically merging back in. So let's hang out for a little bit while this gets merged in.

A

And it looks like it just got merged, and so subsequently this should be kicking off in a subsequent pipeline.

A

And you see this pipeline getting kicked off right here, so let's go ahead and pop that pipeline open and we can see that now, there's a longer build process and again uh the intent behind here is: you know there might be additional tests or you know other other things within this pipeline, but at the very end of this pipeline, there's this merge domain job and the intent behind this merge domain job is to actually manage the the merging of back to the main job.

A

So you can see that these are being set up and we have this merge domain job and this merge domain.

A

A

And uh while it's running I'll I'll kind of walk you through what this is going to.

A

A

So the merge domain is, is really uh only performing git commands and uh it's gonna take a ssh key and an ssh public key and set up your gitlab username and email fetch. The origin, checkout master, set the origin to the ssh based git url and then merge the default branch, which is our our develop branch back into master and then push that change back up.

A

And you can see that this merged successfully. So now, when we go to our main or our master branch, we should see that that test run file has successfully made its way in. If you want a little bit more details, this page kind of walks you through how this is set up. One we've updated the default branch to develop.

A

We've created a key ssh key private and public key pair and we've registered that as a deploy key. So the public key was taken and registered as a deploy key, and this can be associated with any user that you would like, and then the private and public ssh keys stored as ci variables.

A

So you have the merge, ssh key and the merge ssh public key, and uh this originally was set up within here, but I went ahead and just updated the um the files here, so these two things are might be useful might not be, but the the get lab yaml. That's following that merge domain is all right here and subsequently you can again see on the pipelines how this runs. So thanks for your time.