What is Gitlab CI?

GitLab CI is one of GitLab’s most successful set of features. In GitLab lingo, GitLab CI is composed of features and capabilities that fall under two stages mainly: Verify and Package; although; there are elements of the Secure stage too. Stages are what GitLab calls each part of the DevOps lifecycle. In other words, they divide the  Software Delivery Lifecycle (SDLC), into  sequential sections: Manage, Plan, Create, Verify, Package, Secure, Release, Configure, Monitor, and Protect. While these are not industry accepted terms, most of them are self-explanatory, hence the solution Continuous Integration falling under Verify, Package, and to some extent, Secure. 

Complete GitLab CI Intro and Guide

GitLab was incorporated as a company in 2014. launching the Enterprise version of what was then a limited platform. Before that, the open source project had been running for awhile, but it was only wrapping a web-based GUI and some source code management features to the vanilla git discussion forum. That served as the first contribution to what later became GitLab CI in 2021.

GitLab CI, like many other CI products, aims to help software engineers, team leads, and DevOps engineers in many different ways. It aims to provide build automation, test automation, pipeline config management, artifact storage, and pipeline security in a single set of features. 

When practicing CI, teams collaborate to build software. They do so by using a shared repository to store, modify, and track frequent changes to their codebase. Developers aim to check in, or integrate, their code into the repository multiple times a day, and they rely on automated tests to run in the background. Developers don’t want code quality to be a trade off from build speed. These automated tests verify the changes by checking for potential bugs and security vulnerabilities, as well as performance and code quality degradations. 

Running tests as early in the software development lifecycle as possible is advantageous in order to detect problems before they intensify. Solid CI is the only way to achieve continuous deployment to a production environment. You can learn more about the benefits of implementing good CI practices in our blog detailing why CI is so important, and why it delivers so much value to companies delivering software efficiently.

GitLab CI’s main component is a runner. A GitLab Runner is an application that runs jobs in a pipeline. Its only limitation is that the environment that the runners operate in is able to compile Go language. The runner should be hosted in a separate instance than the GitLab platform itself, regardless of whether you run both or one in your own environments. GitLab Runner is the name chosen to manage the runners, which is the actual agent performing the jobs. Runners require an executor to determine the environment that the runner will be able to perform the jobs assigned to it. There are three types of GitLab runners:

• Shared: available to all projects
• Group: available to all projects and subgroups within a group 
• Specific: attached to individual projects.  

Jobs in turn can pass variables or artifacts to one another. These GitLab variables store values for later use and control the behavior of the GitLab jobs. They exist at the project, group, or instance level. Job artifacts, such as a Docker image, are the eventual result of pipeline execution. They are not stored in a GitLab repository, but rather in the package registry connected at the end of the pipeline. If the result of the pipeline execution is a Docker image, the existing container can be updated with a deploy job. This is the code deployed in the continuous deployment stage. 

Gitlab CI Features and use cases: just CI or continuous delivery?

One of GitLab’s main characteristics is its broad set of features. It’s a platform that aims for breadth and not depth. This makes the exercise of highlighting its main features under CI challenging. It’s difficult to assess if a feature is there in name only (too shallow) or if it really solves a problem. In any case, these are the most popular features in GitLab CI:

• Merge trains: A merge train is a queued list of merge requests each waiting to be merged into the target branch. Each merge request (MR) runs its own CI pipeline and gets merged against the target branch sequentially. Each merge request will be merged against the results of all previous merge requests. Think of it as running CI pipelines against the shelved result of a previously merged Merge Request. This result will not be merged into main (formerly known as master branch), but shelved, until the complete merge train has finished. 
• Auto-scaling CI runners: The ability to auto-scale runners provides the runners (or the runner manager, to be specific) with privileges to invoke and instantiate as many machines as they require. This will effectively let your GitLab CI farm scale elastically to meet your build needs, especially when running jobs or pipelines in parallel. Better watch your cloud provider invoice with this feature though.
• GitLab Container registry: GitLab CI has its own container registry. GitLab has embedded several open source package managers, which they wrap into their own package manager and container registry. Enabling Docker’s registry in the GitLab container registry, for example, will allow GitLab users to store and update docker images. Container registries share the same characteristics as the projects they belong to: if the project is private, the registry will be too, but if it’s public, there is no way to make the Docker images private. 
• Test coverage visualization: With this popular CI feature, GitLab provides users with the ability to understand visually how their current test suite is providing coverage to the source code of the project. It will allow GitLab users to consume the information coming from their favorite testing and code-coverage tools, parse the job in the background, and show the results to know which code lines are covered by tests and which are not. 

GitLab CI is used to solve for several different use cases, from the most traditional software development workflows (building software, small code changes, testing new features in your local machine for demonstration purposes, etc.) to broader, more complex ones, like what we call CI++ internally at Harness, or using a CI tool to perform the complete development cycle. That is stretching GitLab CI beyond the build stage to perform continuous deployments. The use of GitLab CI, through the use of auto DevOps, for the deployment stage is something that can also be seen performed with Jenkins and other legacy CI systems. In our view of software delivery, production deployments, or continuous deployments, are better addressed with different capabilities than those that GitLab CI offers. 

Gitlab CI Pricing: security comes at a cost

Some of the features listed above are premium features. GitLab sells its DevOps platform as one, regardless of what features, capabilities, or stages you plan to consume or make use of. GiLab has a free version with limited features. It then goes on to offer two paid-for plans: Premium and Ultimate. 

• Free: $0 user/month
• Premium: $19 user/month
• Ultimate: $99 user/month

The idea behind both price plans is that Premium is designed with scaling companies in mind. It will provide their clients with faster release cycles through CI and CD, release management capabilities, and code review features to enhance quality.  

To justify the huge spike on price that the Ultimate plan has, GitLab says that GitLab Ultimate is ideal for organizations aiming to optimize and accelerate delivery while managing priorities, security, risk, and compliance. It also includes support, technical account management, and live upgrade assistance. Pricing and vendor lock-in (given GitLab’s huge breadth) are usually the biggest concerns when it comes to considering GitLab as the DevOps platform of choice.  

Gitlab CI Review

GitLab CI is one of GitLab’s most successful set of features. Despite GitLab’s continuous effort to reduce the amount of free minutes available in its free version (it went down to only 400 free minutes of CI pipelines in 2020 and additions to that are around $10 per extra 1000 minutes), GitLab CI remains highly popular. It’s so popular that GitLab.com’s CI runners in public projects were abused by crypto miners to mine crypto currency with them at a cheap cost.  

‍

Usability ⭐⭐⭐

Likeness to Renew ⭐⭐⭐

Onboarding ⭐⭐⭐

Performance ⭐⭐

Verifications ⭐⭐⭐

Integrations ⭐⭐⭐⭐

Support ⭐

CI/CD Integration ⭐⭐⭐⭐

Scalability ⭐⭐

Security ⭐⭐⭐

‍

Pros

• Web-based GUI to create and understand CI pipelines, jobs and variables at a glance
• GitLab runner available is most OSs

Cons

• Paid runners are reported to be slower and run on Docker machine, which has been deprecated.
• Changes to GitLab’s runner minutes are becoming effective on Jun 1, 2022 and Jul 1, 2022. All free runners will have their free assignment of minutes to 400 per month for GitLab CI and CD, and all open source projects hosted for free will need to enroll in the compulsory open source program.

‍

‍
Looking to start a new project? Why not try Harness CI?

There are plenty of alternatives in the CI space. From the legacy systems such as Jenkins, TeamCity, or Bamboo to the more modern ones like GitLab CI or Drone, which was founded in 2012 and is now part of the Harness platform. Drone is the free and open source version of Harness CI module.

Harness CI is an enterprise ready, cloud native CI product. Developers can build at speed with self-service, cloud native pipelines that scale elastically. Easy templating, RBAC, and governance done programmatically, as code or through our GUI, ensures any code meeting all quality and security standards. 

Get started using Drone with this simple getting started guide written by Jim Sheldon, a Drone user and developer advocate at Harness.