GitLab vs Jenkins – Which CI/CD tool should you choose?

Many changes keep happening in software daily, especially when it is big, like Netflix, Amazon, Facebook, etc. Such software contains a lot of modules, and there are different teams working on them that might never know each other’s names. But they still affect the same software even if they do in different ways. Along with working on features and enhancements, some people work on bugs and regularly rectify them to integrate the new code.

When so many integrations are happening on different modules at different stages, how can we be sure that the integrated code of everyone works correctly when pushed to production? The only way to stamp this guarantee is to build and attach a CI/CD pipeline to your software development cycles, and this is what we are here to talk about.

In this post, we will introduce CI/CD by taking reference to two of the most popular tools used in software development today: GitLab vs Jenkins. With their benefits to methods of working, we will explore more of CI/CD and why it is an integral part of SDLC today.

A brief introduction to CI/CD

CI/CD is an acronym you will commonly hear in software development. It is short for continuous integration (CI) and CD may mean either continuous deployment or continuous delivery, depending on what the team is using.

CI is a direct result of agile software development and the fact that when so many people merge their code regularly, we can neither achieve this task manually nor skip it from the process as the failure of CI may lead to software malfunction at the user’s end. Continuous integration enables multiple developers to merge the code changes into a single central repository. These changes get validated by running automated tests before integration.

CD in CI/CD may refer to continuous deployment or delivery. Continuous delivery is delivering the code into the repository once the CI part is completed. This means we merge our code into the repository as we know by CI results that there are no failures. This step can often be found to be done manually, depending on the organization.

Continuous deployment, however, is one step ahead of continuous delivery. When the code is merged into the repository, the continuous deployment part deploys the code to production automatically.

When these concepts are attached to one another to work in automation on a project, we call this a pipeline. A “pipeline” because it is serial like a pipe and no state can be jumped or skipped. You cannot achieve continuous delivery when continuous integration is not achieved. However, for this post, we can limit ourselves to just this brief introduction of CI/CD pipelines. Although, with the detailed analysis of GitLab vs Jenkins, we will touch on the concepts at various places.

Introduction to GitLab CI/CD

GitLab is a software package that contains version control system-related software such as a repository for saving codes, collaboration at a centralized platform, code pulling and pushing capabilities, etc. Along with it, GitLab also provides CI/CD-related functionalities that are attached to its version system for smooth pipeline execution. It was started in 2014 and is open-core in nature. This means that it offers a part of its software package as a free service while charging money for others.

GitLab’s one selling point has always been its user interface which helps achieve things quicker than other tools. If we talk just about CI/CD, it has its own advantages and disadvantages as compared to Jenkins CI/CD. However, before listing them down, an introduction to a small concept is required.

GitLab CI/CD pipelines depend on GitLab runner. It helps run the jobs in a pipeline. It is open-source and is written in GO. So, the installation and compilation capabilities of GO are required. This will come across a lot of the time when a tester is working with CI in GitLab. Just remember that GitLab runner should not be hosted on the same machine in which the GitLab instance is hosted for security reasons. The team can either install GitLab runner on a different operating system, Docker container, or even deploy in a Kubernetes cluster.

Features of GitLab CI/CD

GitLab has been known to release new features very quickly. Therefore, this calls for a separate section to highlight the most popular ones:

Chat based CI

GitLab CI job can be triggered directly from chat. The results of the job execution are then sent back to the channel without visiting the CI configurations.

Docker linking

Docker containers can be linked with the base images within the platform. The tester can then use GitLab and GitLab runner for the application testing.

External repo connect

The GitLab CI/CD pipeline system can be used with repositories located outside of GitLab such as on GitHub or BitBucket.

Controlled deployment

The GitLab continuous deployment can be controlled and released to only a specific number of users rather than released to all. This can be achieved by deploying to only specific pods from within GitLab CI.

Auto-scaling CI runners

Runners in GitLab CI/CD can be auto-scaled according to the need. If more machines are required, the runner can instantiate more machines so that the efficiency does not drop and the build or any other job execution can be done smoothly.

Along with these highlighting features, GitLab CI/CD does come with general standard features expected from any CI/CD tool today. This may include release features such as release notes or auto deployments.

The downside of using GitLab CI

A major downside of using GitLab CI is that a lot of its powerful features are wrapped inside the premium package, which the company charges. With open-source trends flowing around the development world and alternate open-source choices available to developers, they might not be able to use GitLab to its full strength.

For someone who has already started working with the free version and later wants a premium feature, they may have to recalculate their budget or go through the pain of transferring everything to a new CI. No organization would want that!

How to setup GitLab

To manage and maintain our CI/CD pipeline in GitLab, we first need to set it up on the system. This can be easily achieved in a few ways as described below.

Prerequisites

Before starting, please ensure the tester already completes the following two steps:

• A project is created (preferably in GitLab for beginners).
• The person setting up GitLab has appropriate roles like “Owner.”

Step 1 – Installing a runner

A runner will help us execute jobs in the CI pipeline. So, obviously, we should have one in our project already set up and ready to be used.

To verify if you have any runners already enabled, visit Settings -> CI/CD->Runners.

If you do, you can move on to the next step. If you do not, you need to install the runner in the form you require. The tester can choose to install from the following options:

• Through GitLab repository.
• Through direct binaries.
• Through containers such as Docker service, Kubernetes, etc.
• Through autoscaling enabled options.

All the links to all types of installation of GitLab runner can be accessed from its official link.

Step 2 – Create a YAML file

The instructions for running GitLab CI/CD needs to be written inside a YAML file called .gitlab-ci.yml file. The instructions in this file should be written by taking care of two things:

• The orders of job execution.
• Conditions that can occur and decisions to take in such scenarios.

The .gitlab-ci.yml file should be present at the root of the directory. To create it, select Repository -> Files.

Select the branch in which you wish to commit (Here, we consider “master” or “main”).

Next, write the filename as .gitlab-ci.yml, and in the content box, write the following:

build-job: stage: build script: – echo “Hello, $GITLAB_USER_LOGIN!” test-job1: stage: test script: – echo “This is my first test job.” test-job2: stage: test script: – echo “This is my second job.” – echo “Sleeping for 20 seconds.” – sleep 20 deploy-prod: stage: deploy script: – echo “This is deployment job.” environment: production

Please refer to the official page where you can find reserved keywords and syntax related to the file.

Once the file is saved, that’s it. We are done!! We can now just verify our CI pipeline once and can get back to work.

Step 3 – Verify the CI pipeline

To verify the status of the GitLab CI pipeline, just go to CI/CD-> Pipelines, and it will be visible to you as follows:

Expand it to see the visual representation of it as follows:

If you are at the same stage as shown above, then you have constructed the pipeline successfully.

Introduction to Jenkins CI

One of the most popular names in continuous integration and development is Jenkins. Started in 2004 by Hudson, Jenkins is an automation server used for CI/CD and other SDLC phases such as testing and building the software. It is open-source and is extensively based on plugins and integrations provided by third-party developers or Jenkins itself. It could easily be said as the primary source of power for Jenkins and ultimately all the work that it does.

With over 150k installations and millions of users, Jenkins provides a lot of benefits as a CI/CD tool.

Features of Jenkins CI/CD

Jenkins makes it extremely easy for a user to use the tool in their own methods and ways. It provides the following features:

Extremely flexible – Plugin ecosystem

Jenkins is extremely flexible due to the plugin system that allows a tester or a developer to install only those features that are required for the project. This way Jenkins can be used as a customizable personal CI/CD tool.

Free

Jenkins is free to use as it is open-source in nature. With so many powerful features, being free can add on as a bonus to all, especially individuals and medium-sized enterprises.

Rich reporting feature

Jenkins comes with a rich reporting feature that creates highly detailed reports which can easily be shared with other team members.

Keeps work centralized

Jenkins believes in keeping everything synchronized and centralized. Due to this, the changes are reflected to everyone instantly, and there are no personal environments.

The downside of using Jenkins

The only downside of using Jenkins, ironically, is what makes it super powerful – its plugin ecosystem. While you can choose to customize and install any functionality using the plugins, you may not have any other choice if the plugin is not available. So, if a lot of demand is there for a particular plugin, the developers might go for it, otherwise, there are no second choices other than developing one yourself.

Secondly, the plugin space is a shared space and not private to Jenkins developers. As a developer, you can also develop and post a plugin like hundreds of other developers do. But that might not mean they all are maintained as is done by the Jenkins community. Some might be uploaded and left stranded when their developer’s work is finished. If you find such a plugin, you may encounter a series of issues with the latest Jenkins version, and it is just a pain to work with.

How to setup Jenkins

Jenkins is installed as a standalone application on any platform that is supported by it. For now, Jenkins can be installed on the following platforms:

• Docker
• Kubernetes
• Linux
• macOS
• Windows
• Other Systems
• WAR file
• Other Servlet Containers (Not recommended as it is error-prone)

For this demonstration, we will be using the Windows operating system.

Pre-requisites

There are only two pre-requisites to install Jenkins and enable the CI pipeline:

• Servlet containers (Recommended and preferred container – Jetty).
• Java is installed on the system.

Apart from this, there are a few platform-specific requirements, such as minimum hardware specifications, etc. Since we are using Windows here, for Windows, the following are the specifications required:

Minimum hardware requirements:

• 256 MB of RAM.
• 1 GB of drive space (although 10 GB is a recommended minimum if running Jenkins as a Docker container).

Recommended hardware configuration for a small team:

• 4 GB+ of RAM.
• 50 GB+ of drive space.

After this, we move on to downloading Jenkins on our systems.

Step 1 – Downloading Jenkins

Jenkins can be downloaded as per your platform from the official download page.

Step 2 – Installing Jenkins

To install Jenkins after downloading it to the system, open the installer and click Next:

Select the folder where you want Jenkins to be installed and click “Next”:

Enter credentials on the next screen based on the type of service you choose for Jenkins run. Click “Run” after that:

On the next screen, enter the port number on which Jenkins will run. The “Test Port” button will let you check if the port is free or not.

Set the Java directory on the next screen to run Jenkins. Remember to install Java before proceeding with Jenkins installation.

On the next screen, enable or disable the feature install types as per your requirements:

Click “Install” to install Jenkins:

Step 3 – Unlocking Jenkins

After the installation is done, Jenkins needs to be unlocked. This can be done by visiting the localhost address with the post defined during the installation. If the port was 8080, then type http://localhost:8080 in the web address.

The following page should appear:

The administrator password can be found inside a file located in the installation directory of Jenkins:

Enter this password in the above unlock screen, and Jenkins is all set up for building a CI pipeline.

GitLab vs Jenkins – Point-by-Point Comparison

For a quick reference for testers and developers, we have created the following table that highlights GitLab vs Jenkins comparison:

Parameter	GitLab	Jenkins
Development method	Open-source	Open-source
Price	Free version + Paid Version	Free
Language	Ruby	Java
Working Architecture	GitLab CI and GitLab Runner	Master-Slave
Plugins	Limited plugins.	1700+ Plugins to choose from
Community Size	Comparatively Smaller	Large Community
Platform Support	Only Unix-based	Windows, macOS and Linux

Icebreaker between GitLab CI/CD vs Jenkins

While GitLab CI/CD and Jenkins both are exceptionally good software that currently rules the market but there can be an ice-breaking point that can help you decide clearly which tool to choose.

Firstly, GitLab’s main strength comes from being cloud-based and having good monitoring features. Be it branch monitoring or performance monitoring, GitLab has a really good UI and great metric system that help analyze things clearly at any point in software development. This is not true with Jenkins or maybe with any other CI tool currently available. However, it all comes at a price as GitLab comes in free and premium packages. The main point of this section is to let you know that if monitoring and metrics are your priority, your bucks will be well spent on GitLab.

On the other hand, Jenkins is completely free to use and is a popular choice just for this part. As free software, it gives you a lot of things that the majority of paid CI tools do not give. The main strength of Jenkins comes from its plugins, which are thousands in number. As a tester, whatever you may need can be found in a plugin which gives a lot more flexibility.

Another good thing about having an open-source plugin-based system is that you can build your own if feasible. It has a good UI (which is rare in CI-based systems) and is continuously updated by developers. Jenkins should be your first choice when the team is satisfied with the available plugins, and there are no major requirements that Jenkins can’t suffice. It is also extremely easy to learn and use for a beginner.

Alternatives to GitLab CI/CD and Jenkins

For people who wish to explore a few more tools other than GitLab and Jenkins for CI capabilities can refer to the following list of five most preferred:

• Circle CI
• Bamboo
• Teamcity
• Travis CI
• Codeship

Let us know in the comment section if you are a user of one of these tools and how it compares with GitLab vs Jenkins.

Conclusion

The concept of continuous integration and continuous development has seeped too deep into SDLC that even smaller companies of just a few developers also find it relevant. It helps merge code smoothly and run various tests upgrading the application’s quality and minimizing the chances of errors at the user’s end.

In this post about Gitlab vs Jenkins, we took two of the most popular tools that help us achieve just that. GitLab CI/CD and Jenkins are equally efficient with uniquely different features that help us make a clear choice between them.

Starting with why to choose each of them to how to set them up on your machine, I hope this post will help you start your journey with the best CI/CD tools in the market. For any clarifications and suggestions, do let us know in the comment section. Thank you for giving this post your valuable time.

Frequently Asked Questions

Does GitLab use Jenkins?

No. GitLab and Jenkins are two popular tools used for continuous integration and continuous development/deployment features. They both offer their own set of pros and cons which are discussed in this post. None of the tools takes the help of another; they work independently.

Can GitHub Actions replace Jenkins?

GitHub actions and Jenkins both provide great workflow features to build, test, release, and deploy your code. For a developer, they both are equally popular and equally powerful. In the end, the question comes down to which one you should choose between Jenkins and GitHub actions rather than which one will replace what.

Is GitLab good for CI-CD?

Yes, GitLab is a very powerful CI/CD tool with tons of features crafted just for developers and testers. It has excellent UI and monitoring capabilities.

How does Jenkins connect to GitLab?

GitLab is available as a plugin system for Jenkins. To add GitLab to Jenkins, visit the plugin section and install GitLab and Git plugins to enjoy Jenkins along with GitLab.