Have you considered migration from Jenkins to GitLab? While working on CI/CD pipelines in Jenkins, you probably didn’t like coding them in Groovy. You wondered if any simpler CI/CD platform exists where you just have to worry about what commands to run in the pipelines. We’ll review important things to consider while planning migration from Jenkins to GitLab.
What is GitLab?
GitLab is a CI/CD platform which offers ready to use CI/CD pipelines, infrastructure to run them (runners) and dependencies (container registry, build cache storage, etc…).
You may use GitLab SaaS (GitLab.come website) or self-host it by installing it either on-prem or on the cloud.
To run CI/CD pipelines for a project, one can use GitLab auto-devops feature. You can see GitLab auto-devops in action on Airflow code-base on my GitLab account. Fork the project, open sample pull-request and see the pipeline runs. Seems like magic. Note also how simple it is to run CI/CD pipeline. I just included
Auto-DevOps.gitlab-ci.yml template whose implementation was done by GitLab and is here.
include: - template: Auto-DevOps.gitlab-ci.yml
As you can see, it’s really Auto DevOpos, because it auto-detects the project’s language, builds and tests the application with no effort from your side. Even if you decide to tailor CI/CD for your needs, GitLab auto-devops templates serve as a great basis for customization.
Migration from GitLab to Jenkins
- Jenkinsfile =
gitlab-ci.yml. You’ll code your GitLab pipeline there.
- In contrast to Jenkins, all GitLab jobs in a single stage run in parallel, while stages run in sequence.
- If you deploy Jenkins in a modern way, e.g. on Kubernetes cluster, then you probably already use custom Jenkins agents for running your CI/CD pipelines. The pipelines just specify labels of agents they need to run on. You may have different agents for different languages and technologies. For example, Jenkins Docker agent. The great news is that you may reuse these Jenkins images after migrating to GitLab. This is mainly because Jenkins agents are essentially container images you specify in Jenkins helm chart configuration. If you migrate to GitLab, you will have to run self-hosted runners, e.g. by installing a helm chart provided by GitLab. Next, register self-hosted runners on your GitLab instance regardless of where it runs (SaaS or self-hosted). Then, GitLab pipelines may specify the image where they will run and which runner (selected by tag) should trigger the images on demand (as a container inside Kubernetes executor ). That’s it! GitLab pipeline will run inside the container in the same way it runs in Jenkins. The only difference is that GitLab runners are long-running. They regularly poll GitLab instance for jobs and trigger pipelines on-demand inside dynamically provisioned pod’s containers where the pipelines run.
- There are no plugins in GitLab as there were in Jenkins. So, there’s no built-in credentials store in GitLab that Jenkins Credentials Binding plugin provides. Instead, you’ll need to use an external credentials management solution like HashiCorp Vault.
- GitLab offers several pipeline types. Basic pipeline type seems to suffice for most standard use-cases.
Install GitLab on Cloud
GitLab offers 30 days trial of its ultimate license. If you’d like to self-host GitLab and try its features you can install GitLab on Linode’s managed Kubernetes cluster. Check out how easy it is to create Kubernetes Cluster on Linode and how run self-hosted GitLab runner there. Linode is a cloud service provider recently purchased by Akamai. With this purchase, Akamai became a competitor in the cloud providers market. Create a Linode account and get 100$ credit using this link.
That’s it about migration from Jenkins to GitLab. As always, feel free to share.
You may find below articles interesting:
- Auto Tag Releases with Semantic Versions
- CI/CD using Jenkins and Docker
- Terraform Pipelines on GitLab
- Clone Private Repositories in GitLab Pipelines