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.
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:
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.
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:
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.
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.
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 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.
Likeness to Renew ⭐⭐⭐
CI/CD Integration ⭐⭐⭐⭐
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.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.