Change sometimes progresses rapidly: Just a year ago, Jenkins was the undisputed continuous integration and continuous deployment (CI/CD) king of the hill for the teams at DB Systel GmbH, Germany. Now, some groups are using GitLab CI with growing enthusiasm.

In this article, I highlight why this change is taking place. The best practices described here result from daily work as a network of DevOps experts who support the transformation of groups that are looking to work as DevOps teams in the future or are already doing so. I describe the processes we use that you can also apply to your setup.

CI/CD and SCM

With every new release, an impressive number of new features are introduced to GitLab [1]. The core team has obviously taken up the cause of mapping the entire software life cycle and, in the process, GitLab has become a versatile tool for DevOps teams. From planning to monitoring, the source code management (SCM) software offers a variety of components, the configuration of which varies depending on the edition.

In this article, I refer to the freely available GitLab Community Edition [2]. I also describe scenarios that are particularly relevant for the DB Systel DevOps teams and that have already been successfully implemented with the help of GitLab (i.e., for CI/CD, security, and compliance).

GitLab CI is a GitLab Community Edition component, and thus open source. In particular, GitLab integration boosts the user experience compared with the use of several standalone applications, thus reducing the amount of training required.

Thanks to GitLab, the DevOps team uses container images for each step in the pipeline, which accelerates delivery times. The use of clearly defined and versioned containers allows for pipelines with largely decoupled steps. Dedicated containers for building, testing, and delivering applications can be quickly integrated into other pipelines and used across team boundaries. Each container covers one step in the pipeline.

The basis of every CI/CD pipeline is a source code repository. En route toward GitOps [3] and the associated "everything as code" paradigm, no DevOps team can do without version management. GitLab fully covers the requirements with Git integration and associated features, such as code reviews, comment functions, and web GUIs that allow editing directly in the browser.

Agile Methods

The modules in GitLab (e.g., the issue tracker and the issue boards; Figure 1) currently support all common methods of agile software development from Scrum, through Kanban, to SAFe. The GitLab blog contains a post on the subject of GitLab for agile software development [4] that provides a useful overview of how teams can map agile processes to GitLab features.

Figure 1: The issue boards in the GitLab Community Edition help with agile development.

However, not all modules are in the Community Edition, so it is often worth taking a look at the existing interfaces to third-party software. Our teams use Jira integration, among others. If a developer adds the Jira issue ID to a merge request, it automatically ends up as a comment in Jira.

At the same time, GitLab inserts a link to the commit through the Jira interface, thus ensuring easy navigation between the two systems. If the developer enters Closes <Jira-Issue-ID> in the description field of the merge request, Jira will close the corresponding issue after the merge in GitLab – but not without leaving a reference to the corresponding commit.

Various markups can also be bundled. These smart commit commands [5] give instructions for comment, status, and time posting simultaneously.

GitLab Runner

One basic building block of the GitLab CI architecture is the GitLab Runner [6]. According to the pull principle, a Runner communicates with the GitLab server via an API, executes declared jobs, and sends the results back to the GitLab server.

Runners run in different environments, but Docker and Kubernetes are preferred by our teams, because they fit seamlessly into our target image of a "shared nothing architecture." By combining different Runners and environments, we map pipeline security and compliance requirements. On this basis, a dedicated team provides Continuous Delivery as a Service (CDaaS) for the integration of GitLab CI into Amazon Web Services and OpenShift. With the use of parameterized deployment templates, we configure the Runners and roll them out on the corresponding platforms.

By tagging Runners and declaring them in the pipeline job, we can assign them to different environments. The configuration itself is created in TOML format [7]. The Runner documentation [8] provides a comprehensive overview of the available parameters.

Runners can be registered in three variants: shared, specific, or group. In contrast to the specific variant, shared Runners are suitable for projects with identical requirements. Group Runners offer all the projects in a group access to the defined Runners. And all Runner types support the Protected option. If this is set, they only execute pipeline jobs declared in protected branches or tags.