GitLab Customer Success Group, 13 May 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How Does GitLab CI/CD Work

Description

Steven Terhar, TAM at GitLab, walks us through what we need to know about GitLab CI/ CD

A

Hi I'm steve kerr car and the sal LevelUp video is about jet lab see I CD continuous integration is one of the things that get lab does best. Today, I'm going to talk about continuous integration as well as continuous delivery and deployment. Then we'll talk a little about how we do CI CD at gate, lab and finally have CI c can help us sell, get that so.

A

First, a little context in the bad old days, separate developers and groups of developers would work for weeks or months or longer, and then they would try to integrate all that together at the end, despite documentation that attempted to lay out interfaces and things like that, it never actually worked really well. It was a painful time consuming process that was often called integration hell. The solution to it is continuous integration, so in continuous integration, the key is that developers commit small code changes more frequently, rather than large changes less frequently.

A

So what we want to see with continuous integration is developers committing code to the repo, possibly several times a day. The reason is because changes that are small or easy to understand and manage easier to make sure there aren't bugs easier to make sure there aren't security vulnerabilities and not trying to integrate at the end also tends to lead to overall faster delivery times. So it's not just about moving that integration work back. It really actually makes everything go faster overall.

A

So how does this actually work in practice? So the developer checks their code out of the source code repo and then the idea is that they do the smallest amount of work. That makes sense. Typically, you want to have the have the code be able to build and pass all of its tests. Then, when they're happy with the code, they check it back in right away.

A

Then your continuous integration software is watching the source code repo. It notices. The developer has checked in some new code and it gets to work immediately on a series of tasks that we call a continuous integration or C pipeline. So, first off, if the codes written in a language that has to be compiled like Cee C++, something like that, the pipeline will compile the code into an executable.

A

Otherwise it will run tests on the code you often written by the developer, alongside the code itself, to make sure that no bugs have been introduced. So if the build fails or if any of the tests failed and then the pipeline fails and the developer gets notified, so they can fix it after the build and tests portion of it. Often we run scams on the code so, for example, security scans to look for vulnerabilities or code quality scans.

A

It really depends on the specific situation and then, finally, the results of that pipeline, which might be an executable file, it might be a container for a web application, is stored so that it can be deployed later.

A

So that's continuous integration. Let's talk a little about CD, of which there are two different versions: continuous delivery and continuous deployment. So in continuous delivery, what you want to do is make sure your code is always production ready. So you want to have a process set up the produces code, that's ready to go to production, but the deployment itself.

A

You still want to make a manual step, because you want to make sure that things are going through all the processes you've decided as an organization you want to have a person in the right role make that call that it should go to prod in continuous deployment, you've gotten to the point where, if every build goes through, the process, you're comfortable having it in production, so in that model the CI CD pipeline actually ends in your production environment and at the end of that process, the new code you've written is in production and being used by your end-users.

A

So how do we all? How do we do all this there's three components to our solution? The first is get lab itself, so the get lab server coordinates the process, watches repos. It starts the pipeline, it monitors reports, etc. Then there's the get lab Runner the get lab Runner the component that actually executes the steps in the process, whether they are build steps or testing or deployment or scanning, because we have customers that do all sorts of different things. You know we have customers that make web applications mobile apps.

A

We have ones that do scientific computing and kick off scientific computing jobs from get lab. You know we have customers that do Hardware firmware testing and development, so you've got to have a very flexible CI runner and ours definitely is. It will run anywhere that the programming language go supports, so it can run on bare metal. It can run in virtual machines, kubernetes Macs, Windows Linux boxes, you name it and then the third component is a get lab, CI mo, which is a human-readable configuration file.

A

That has all the steps for your CI pipeline and those steps are in the form of shell commands. So the same commands that your developer uses on their laptop to do a build or kick off the deployment they can use. Those commands with with relatively minor modifications, usually just a few extra steps to set the environment up in their file, so these files are really easy to make. They don't require the developers to totally you know, change around their approach, so this files in get lab itself.

A

So it's versioned right alongside your code, which makes it very convenient to work on the results of your CI pipelines can be stored right in get lab. If you want- and this whole process is typically done in docker containers, in terms of where the CI runners are actually executing these projects and that's great because docker containers allow you to guarantee that every time you run a pipeline, the environment will be exactly the same, whereas if you're running them on your laptop, maybe a library is different.

A

Maybe something else has been changed and then it can throw away the environment when you done and you can get a fresh one next time, so that works really well. Okay. So how can this help with your cell of get in many organizations? It's actually already helped, because it has helped get get lab into that organization. It's helped us get a foot in the door.

A

Our CI solution helps developers, developers like it in for the most part, and so it is a driver of demand from the bottom up where the developers are asking management hey. You know we really want to use, get lab, it works great and then you know sort of on the other side of this. The bad news is that all these features for the most part or even get LabCorp, so your biggest competitor when you're selling- this is is, you know, might well be get LabCorp and some organizations. So how do we sell in that?

A

You know in that situation? The key is, as we often do, to focus on how everything is integrated and how that integration leads to a really great end-user experience. So, for example, you can kick off a security scan which is an ultimate feature from a get lab, see ICD pipeline that scan will run and then the results will be automatically pushed back into the merge request and tracked there, and you can go to the merge request. You can see the results you can see the pipeline because everything is tied together.

A

You don't have to cobble together a patchwork of different products to get this done, so it requires less time to maintain your tool chain and everything just works together. If you want to add a new scan to a to an existing project, you just open your get web CI ml and it can be as easy as just dropping one extra line into that file and then that scan will run. So that's what you want to focus on, and hopefully this was helpful. So thank you very much for listening.