In this video, learn what GitLab is and how it can be used to improve your productivity.
- [Instructor] So what is GitLab? GitLab is a web-based code management and CI/CD system. It's core is free and open source, but there are commercial options available for additional features and for a hosted solution. Initially, GitLab was focused on code management, but has expanded to include a powerful continuous integration and continuous delivery system. Let's take a minute to cover what those features actually do. Source control is a way of keeping track of and collaborating on code. In the case of Git, which is a software that GitLab uses on the back end, it keeps track of changes to files, rather than entire copies of files. That might not seem like an important distinction, but we'll cover the implications a little deeper in a later lesson. The important thing about it is that 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 as you're working on different features. In Git, you can often do that in less than a second. A good source control system should also 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 the 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 defacto 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. The other major GitLab features we'll be learning in this course and continuous integration and continuous delivery, or CI/CD. You've probably heard these terms, but you might not know what they actually mean. I've noticed that these terms often get thrown around, usually as though they're a single thing, and almost always without any explanation of what CI and CD actually are. We'll cover each topic in-depth in later chapters of this course. Let's start with CI, continuous integration. I think the best way of understanding this concept is to unpack the name. CI is first and foremost continuous. That means that it can't be a manual process. Not unless you're paying a team to only focus on integration. 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 those changes so you don't introduce new bugs. That means CI needs to involve some form 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 bit 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 CI pipeline completes. It's the process of building your app and deploying it. If it's a packaged software application, deploying it might mean just uploading the files somewhere that users can download it. For web-based applications, CD is a bit more complex. It's the process of first 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 the end users. One important thing about CD is that it doesn't always have to be entirely automated. In fact, it rarely is. Usually, there's some kind of release event, where code is pushed out at a specific time that's either chosen for being low-impact to end users or when the development team is around to deal with any issues that crop up. Some companies 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 very well-established companies that have been able to invest in developing automated testing that they can trust to catch issues.
- Navigating the GitLab interface
- Using GitLab for collaboration
- Merging requests
- Continuous integration and continuous delivery
- Creating and running a pipeline
- Deploying a project using GitLab