Understanding GitLab Components

GitLab is a huge, complicated web app that aims to be a “one-stop shop” for making every step of the software development life cycle easier: it helps you to plan, create, test, secure, and deploy software. And those are just the big tasks it covers! It also helps you track progress using a variety of workflows, document projects, create release notes, store Docker images or other types of software packages, host static web pages, monitor the performance of deployed applications, and watch for suspicious network traffic within Kubernetes clusters. This list could be much longer, but you get the picture: GitLab helps with most of the tasks involved in the standard software development life cycle.

In Chapter 1, we articulated key problems in the software development life cycle that GitLab was designed to solve. Now, we’ll introduce you to the key GitLab concepts and components that you’ll need to be familiar with in order...

Technical requirements

You’ll benefit most from this chapter if you’re able to follow along by logging into an account on a GitLab instance. This account can be an account on the instance hosted at gitlab.com (also known as a Software-as-a-Service (SaaS) instance), or an account on an instance hosted by your company (known as a self-managed, a self-hosted, or an on-premises instance). You could even host GitLab on your own hardware at home or on a virtual machine in the cloud, using a service such as AWS EC2, Google Cloud Platform, or Microsoft Azure.

Hosting your own instance is not as far-fetched as it sounds, thanks to surprisingly low hardware requirements—you can even host GitLab on a Raspberry Pi!—and a variety of “Omnibus” Linux packages that contain everything you need for an entire GitLab instance. We’ll refer you to the GitLab installation documentation at https://about.gitlab.com/install for more information if you want...

Emphasizing the “why” over the “how”

Before we get started, a word of warning. For the most part, this book will not lead you through step-by-step instructions on what to click in the GitLab GUI in order to perform various operations.

First, instructions for most operations are already well covered in GitLab’s official documentation, which is remarkably clear and thorough.

Second, because GitLab is in rapid development, its GUI often changes. These changes are rarely radical, workflow-breaking changes, but they are significant enough that screenshots, or even bullet-pointed instructions for how to perform operations, can quickly get stale. This means that any concrete instructions in this book could become confusing or impossible to follow, or potentially even lead to data loss, as the GitLab GUI drifts over time. To avoid that problem, we’ll mostly focus on why you might want to use different GitLab features. Although we’ll give...

Introducing the GitLab platform

What is GitLab?

The company called GitLab makes a single product: a web application that is also called GitLab.Behind the scenes, the GitLab web application is a complicated collection of tools, databases, queues, and glue code holding it all together, but as far as the user is concerned, it’s just a single, web-based tool for building software.

Different Meanings of “GitLab”

Throughout this book, the term “GitLab” refers to the tool rather than the company, unless we explicitly say otherwise.

As we discussed in the first chapter, GitLab’s single-tool model is much easier to install, administer, and upgrade than any collection of separate, more focused tools. It requires only a single set of credentials per user. It offers a consistent GUI for all of its features. It integrates all the software development life cycle tools, allowing data to flow smoothly and without loss or distortion from one feature...

Organizing work into projects and groups

Projects are the fundamental building blocks of GitLab. A GitLab project represents a single software product that you are working on or a single non-software project that you are working on. Projects are where you store your files, and they are the starting point for navigating GitLab’s different features. In short, projects are where you spend most of your time as a GitLab user.

Here are some examples of typical projects, and who might use them:

• A mobile phone app for finding a nearby car wash, used by development team #1
• A desktop version of the same car wash app, used by development team #2
• The documentation used by the technical writing team
• An upcoming conference, used by the event planning team
• Onboarding tasks for new employees, used by the entire company

As you can see, some of these examples are software-related, but others have nothing to do with software. You can use projects to plan, manage...

Tracking work with issues

If a GitLab project is where a single product or initiative lives, a GitLab issue is where a single chunk of work lives. If you’ve used tools other than GitLab for planning and tracking work, you might have run across terms such as “story” or “ticket” to describe components that are similar to GitLab issues.

Issues live within GitLab projects, with each issue only belonging to one project (although they can be moved between projects). In addition to being linked to projects, issues are also linked to a huge number of other GitLab components, as you’ll see when we introduce you to those components. In fact, these linkages are a big part of what gives GitLab its power to reach across all 10 stages of the SDLC.

The structure of a GitLab issue

GitLab issues consist of several parts, of which these four are the most important:

• A title
• A description
• Several optional metadata fields
• A threaded...

Editing files safely with commits, branches, and merge requests

In the last chapter, you learned about using branches and commits in Git, where a branch is a series of commits, and a commit is a snapshot that consists of edits to one or more files. Because GitLab is in some senses a wrapper around a Git repository (although of course, it’s much more than that), branches and commits are also an important part of using GitLab. There’s a third, related concept that you’ll use frequently in GitLab: the merge request (often referred to as an MR). In this section, we’ll explain what an MR is and show you how to work with all three components in GitLab.

GitLab often gives you more than one way to do something, and that’s true of working with commits and branches. You can either type commands into a terminal or use the GitLab GUI to perform most of the operations you’re likely to need for these two components. Because MRs are a concept that’...

Enabling DevOps practices with GitLab flow

Let’s end this chapter by seeing how issues, branches, and merge requests fit together in a realistic example. This shows GitLab’s recommended best practice for how to use all the components you’ve been introduced to in a smooth workflow that works for most situations. In fact, this workflow is so strongly recommended and so well proven over time that GitLab even has a name for this workflow: GitLab flow. As always, you’re encouraged to treat this workflow as a starting point when developing your own processes and procedures; feel free to tinker with it as needed for your team, product, and organizational culture.

While working on the Hats for Cats web app, you decide to add a feature that lets you filter the hats by cat breed. After all, a cowboy hat for a large-headed Maine Coon might swamp the dainty head of a Devon Rex. Here are all the steps prescribed by GitLab flow to bring that feature into existence...

Summary

You’ve been exposed to an awful lot of concepts and terminology in this chapter, so let’s do a quick review.

GitLab is a web application whose mission is to solve many of the problems faced by people involved with any of the 10 stages of the SDLC. So, GitLab doesn’t solve just one problem; it solves many problems that exist in many different facets of software development.

Working with GitLab happens mostly within a GitLab project, which represents one software product, one portion of your org chart, or one initiative. Projects that share a similar theme can be collected within GitLab groups, and groups can also contain subgroups.

Each individual task or chunk of work is recorded in a GitLab issue. Issues describe the work to be done, allow team members to participate in a discussion about the issue, and include many fields to store metadata about the issue. Issues usually represent software-related tasks, but can (and should) be used to describe...