GitLab Tanuki Tech, 20 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TT310: Demoing GitLab (Abridged Developer Flow)

Description

This is a sample customer demo for TT300.

For more on Tanuki Tech, see here: https://about.gitlab.com/handbook/marketing/revenue-marketing/sdr/tanuki-tech/

For more on the speaker, see here: https://www.linkedin.com/in/christopher-wang-0835b226/

A

Hey, uh I know that we've been talking about some of these different concepts, but um even though I don't have a great technical background, would you be interested in you know just seeing some of these things that we've been talking about firsthand I'm happy to walk you through a quick developer flow if you're interested all right yeah great. Let me just share my screen. Real, quick and um you know I'll walk you through a simple developer flow.

A

All right. Can you see my screen all right? Great? Okay? So let me just walk you through. um You know some things that pertain to simple development flows over here you can see that this is the gitlab sas and specifically we're looking at is get lab source code itself. um So this is our versioning software and it's basically a complete full solution. So if you're used to github or bitbucket, then everything that you'd expect out of that scm tool. It's something that we have here here.

A

You can see all the different files that are in my project and we have a complete versioning solution. So what we mean by that is, we can go into the history view and see all the changes that are happening. um So all of these chat changes have happened in the last couple of minutes and who's made these changes and when giving me accountability and transparency to my organization- and I can also see a history view of each individual file as well.

A

So if I go down over here under this docker compose file- and if I click on this history icon, then you can see the different changes that have happened here so over here. um There's actually hasn't been any changes. So, okay, so now that we have a good example of our repo view, let's take a look at issues so once again, issues are basically just discrete units of work for our engineers, and so um you know, issue could be creating a new chart.

A

It could be creating a new button, it could be adding in some new functionality and we have really great project management solutions here as part of gitlab over here you can see.

A

This issue is has to do with adding in our chart to another part of our website, and you can see that over here, they're discussing what this work involves um and over here, our individual engineers are collaborating right, and so um one of the things that get lab is really great at doing is increasing collaboration across your organization simply because so many different teams can use gitlab we're one tool for the entire devops life cycle, which gives us the ability to increase collaboration across your business unit.

A

So yeah the engineers are going back and forth. One person saying uh you know things would be better. If you did it this way, another person could be saying hey. I did this exact same thing. If you take a look here, then you can save yourself some time, so it's just a great example of collaboration across the different teams. Here, let's take a look at some of the things on the right here too.

A

So it's really important to have transparency and accountability in your organization, and so that's what we have here time tracking is basically going to give your engineers the ability to log the amount of time that they've spent in this issue. So management and leadership can have a better indicator of exactly where we are in any sort of project.

A

We can also assign due dates and give it labels, so labels could be by engineering team labels could also be by business unit.

A

We can give this uh issue weight too. So, basically, what weight means is that this is a really really big work item. Then we could give it a higher weight than if it's something small and surgical like changing a button and um so yeah. This is an issue at gitlab after engineers feel like they've solved their issue. Then they submit what we call a merge request and so over here is my merge request.

A

And over here, once again, here's the overview of the description. The engineer comes in and explains what he did and there's a lot of collaboration that we allow um through the gitlab platform itself. So anyone has the ability to come in and write comments and basically suggest things, and this whole iterative process makes sure that the changes that are being made are really the best quality changes for our code. So um the different engineers are just proofreading his change requests and you can see the exact changes that are here.

A

So all this green text, you're trying to add in the red text, they're trying to subtract out and then add in the screen text- and this is how my engineer has attempted to solve this issue over here- is the pipelines view- and this is really one of the fundamental values of gitlab- is the fact that we have all of this ci. That runs in the back, uh in the background automatically, ultimately making sure that my changes are higher quality and also saving my engineers a bunch of time. So ci is completely built, indicate lab itself.

A

You don't need multiple tools, doing different things and tying them together. Gitlab does everything for you, and so you can see how this is giving our engineers valuable feedback. So these tests over here they're passing with warnings um over here. You can see that we've cancelled some tests.

A

If tests failed, then it would surface that too, and all of this once again is giving our engineers high quality feedback, so that we can make the best informed decision about whether or not we should change this code in the manner that's described in this merge request itself over here. You can see an example of some of these pipelines that are running in my environment and, as you can see, there's many different stages to it.

A

So the first stage we're preparing our environment, then we're building images, and I really just want to call it attention to this test environment. This excuse me this test phase over here. This is really where all the magic happens and where my developers get feedback on whether or not they're going down the right path or not so unit tests are running here.

A

Integration tests are running here and also one thing that really sets us apart is our security tests that are running here as well, so things like sas and das, and even things like uh you know, checking for security vulnerabilities and are dependencies, so all of that is built into the gitlab ci process itself, ultimately making sure that my engineers have high quality feedback on the changes that they're proposing through their merge requests.

A

So one thing that you may be you know wondering about is like hey: I have a very specific environment. You know I can't do all of this stuff. I want to do subset of it or you know. I want it tailored to some other process and that's really where the magic of the dot get lab. Ciemo file comes in, so this is the file that determines what happens in the pipeline view. So if I didn't want some of these items or if I wanted additional items, all I have to do is change this file.

A

This is a file that lives in my repo itself, making things version controlled and really easy to see from accountability perspective. So that's a simple flow for excuse me. Developer flow for gitlab.