What is GitLab?

- [Instructor] GitLab is a web-based code management and CI/CD system. Its core>> is free and open-source, but there are commercial options available for additional features or for a hosted solution. Initially, GitLab was focused on code management, but has expanded to include a powerful continuous integration and continuous deployment system. You're probably familiar with GitHub, which is the most popular web-based code management system. GitHub is GitLab's primary competitor. And well, GitLab has worked toward providing a similar experience, they have differentiated their product by adding a lot of features that aren't part of GitHub. GitLab is really striving to be an end-to-end solution in a way that GitHub is not. So adapting GitLab over GitHub might let you replace Jenkins for example. That said, GitLab doesn't force you to use their solutions, so it's perfectly fine to plug it in as your source control solution without using the other features. In this course, we'll take a look at using GitLab for continuous integration and continuous delivery. As part of that, we'll also use some of GitLab source control features. Let's start with continuous integration. CI is first and foremost continuous. That means it can't be a manual process. But what exactly is integration? Integration means code integration and feature integration. It's the process of combining updates into an existing code base. And more importantly, testing that those changes don't introduce new bugs. That means CI needs to involve some sort of automated testing and validation. This could be as simple as testing for syntax errors, or as complex as a full simulation of a user interacting with the software. In GitLab, CI centers around the concept of pipelines, where code changes are passed through a series of steps before they can be merged into the main code base. Continuous delivery is a lot like continuous integration. First of all, it's continuous, that is automated. But what exactly is delivery in this context? That actually depends a lot on what your software does. I'll often use the word deployment as the D in CD, because it's the most extreme example of CD. CD is the step after your pipeline completes. It's the process of building your application and deploying it. If it's a packaged software application, deploying it might be just uploading the file somewhere that users can download it. For web-based applications, CD is usually a bit more complex. It's the process first of updating one or more pre-production environments, validating the application and pushing those changes out to the customer facing production environment. And again, validating the change. Essentially, CD is the process that picks up where CI leaves off and gets the updates into the hands of end users. One important thing about CD is that it doesn't have to be entirely automated. In fact, it rarely is. Usually, there's some kind of release event where the code is pushed out at a specified time. That's either chosen for being low impact to end users or when the development team has around to deal with any issues that might crop up. Some companies do practice true CD, where changes are released as soon as they're ready. But this is usually either brand new startups where agility is more important than reliability or well established companies that have been able to invest in developing automated tests that they can trust to catch issues. Finally, let's take a quick look at the core of GitLab, source control. Source control is a way of keeping track of and collaborating on code. In the case of Git, which is the software that GitLab uses on the backend, it keeps track of changes to files rather than entire copies of files. Well, that might not seem like an important distinction, keeping track of changes makes Git significantly faster than a lot of other source control software. Subversion, which is an older source control system, might take several minutes to switch between two versions of code you're working on. In Git, you can often do that in less than a second. A good source control system should allow developers to easily integrate their work. Git was designed to do this from the ground up. So it's usually trivially easy to integrate work from two different developers. Even when they're working on the exact same file, Git can often merge their changes without any additional intervention. Source control is essential for modern software development. And Git has become the de facto standard in the industry. Git itself can be a little tricky to use, especially at first. But tools like GitLab and GitHub make it a lot more user friendly.