5 most important GitLab features for DevOps engineers that you can’t use for free in GitHub
Every code has many variants and versions, and the more functional it becomes, the more control of the development process is required as well as the documentation of the changes. The functionality and convenience of the Git hosting platform are very important.
Most typical tasks are now successfully solved with the help of well-known cloud services such as GitHub and GitLab. Approaches to pricing and methods of setting up in GitHub and GitLab sometimes differ significantly.
As a company that provides DevOps services, we evaluate the capabilities of a specific Git hosting platform in terms of:
a) how convenient and functional it is for a specific client,
b) if the costs of its maintenance are optimal
c) how convenient it is to work with it for us.
Many of our customers host their code repositories on GitHub. They take advantage of the support of a huge community and organize joint work on projects. Recently, there appeared an opportunity to use free private repositories and GitHub Actions services, which provide CI/CD functions for GitHub. Before, you had to connect external services.
However, GitLab for DevOps support today is more organic and functional, from our point of view, and has several advantages that greatly facilitate and streamline the workflow. Here are, some important features of GitLab that are functionally limited or too expensive in GitHub tariffs:
1) Free self-hosted installation on a private server
GitLab CE can be installed for FREE on your own servers or cloud instances. This is often important for companies who can’t pace the data on public services, according to internal regulations of commercial security. GitLab can be installed through Helm for Kubernetes or in its own container. It provides an official docker image, which for DevOps support means:
a) the ability to manage several GitLab systems in large companies;
b) In case of need or malfunctions, raise the system on other servers;
c) quickly move to/from the cloud or transfer the system between clouds.
Of course, you can buy an enterprise license for a self-hosted installation on GitHub, but its cost often overshadows all the advantages of the solution and makes this option available only to a limited number of corporate clients.
2) Terraform registry
Terraform modules are used for creating standard components in the infrastructure. GitLab has a built-in Terraform module registry with support for semantic versioning to update and maintain modules. You can also publish modules using GitLab CI/CD. This approach simplifies the process of updating and managing your Terraform modules.
GitHub, so far, does not have an analog of the GitLab Terraform registry and only provides an opportunity to organize a regular Git repository of Terraform modules, which gives you less flexibility while updating the versions from a Terraform code.
3) Helm registries in GitLab
Using a helm chart is part of the CI/CD pipeline stages. When you have an integrated registry of helm charts, along with registries of containers, and Terafom modules, it allows you to create a full-fledged automated production deployment platform in your Kubernetes cluster in one place, instead of assembling homemade designs for DevOps support to get the same functionality. It saves a lot of time.
4) Free integrated CI and Container registry
An integrated Container Registry in GitLab makes it easy for developers to build, test, and deploy Docker images using GitLab CI. The use of the built-in GitLab CI in combination with the container registry is not limited to the free GitLab tariff, as it is in GitHub Actions, and the tariff plans for most services are much lower here.
GitLab has a convenient built-in CI/CD and all the necessary registers for DevOps, so there is no need to connect any external ones. Also, with the help of GitLab Container Registry, you can create a registry of private images, for use within the company, or, for example, images for launching and running tests.
5) Attractive pricing plans for startups
Recently, both services have increasingly encouraged their users to switch to paid tariff plans, promising improved support conditions and a stable SLA, limiting the resources of free tariff plans. But even at first glance, comparing GitLab’s tariff plans and GitHub’s subscription terms, it can be seen that some GitHub services are up to several times more expensive. Compare, for example, the space under Packages storage (500 MB in GitHub versus 5GB in GitLab) and the allocated limits in the free and nearest tariff plans and subscriptions of both services.
Today, more and more clients who come to our ServerBee company for help in cost optimization, migrate or consider the possibility of migrating their projects to GitLab precisely for reasons of loyal pricing without losing the functionality of the platform. Many new startups that have deployed their projects on GitHub due to its startup subscription plan consider migrating to GitLab in the cloud or in a self-hosted version later.
With GitLab, you always have the opportunity to move from the cloud to your own server or vice versa as needed, without any particular problems, because the license does not limit you, unlike GitHub, whose influence from its owner (Microsoft) will increase every year, focusing on products and services for enterprises more than the open source tools. With GitLab, you can save significant money without sacrificing the functionality of the platform and save your time without migration in the future.
