I recently talked to Rom Gaigi, DevOps team leader at Pecan AI company
(and one of our customers) about GitLab and GitLab CI and why they chose to use it.
The session was recorded and is available here:
Transcription:
Tamir: I am hosting here Rom Geigi, DevOps manager from Pecan AI,
who has been using GitLab for several years now.
Rom, I would love to hear feedback on GitLab and GitLab CI.
Rom: Thank you for having me. First of all, GitLab is an amazing product.
Its significant advantage over the competitors like GitHub is that it is mainly self-hosted on Kubernetes.
In addition, all GitLab updates that come out end up being self-managed, which creates a greater sense of security and safety, and gives a person peace of mind knowing that he is managing his own projects, behind a VPN.
That way no one can access them without permission.
Gaining full control using GitLab
Tamir: So it actually gives you full control?
Rom: Yes. I also choose when to apply updates.
At first it was challenging to do them, until we created an automation for the updates that runs every week to check if a new update is out, run tests and transfer to production – which solved all the problems.
Today I even enjoy updating, because I get features almost for free.
Tamir: Hot features out of the oven.
Do you also get security updates thanks to the automation you’ve applied?
Rom: Yes. This is why the update happens once a week and not once a month, because GitLab’s major releases come out once a month, but sometimes there are urgent security patches that come out more frequently. Besides, once we created our CI, we actually shortened the time for the code to arrive in production, and we also simplified the ability of developers to take a new project and put the CI into it and thus bring it to production quickly. Today, almost all of our projects have the same steps throughout their CI life, whether it’s commit, commit for merge request, merge train or add tests, which really helped us before we reach production, or during the production when releasing a version and updating all components.
GitLab as a Self-service
Tamir: So you actually give the developers self-service?
Rom: Today we work with Cookie Cutter so that as soon as a developer decides to produce a new service, the CI is already there, and if they want more parts, we have GitLab templates that sit in a certain repo, and those who want can use them to add or download more stages to – his pipeline.
This saves a lot of code, a lot of knowledge that the developers didn’t really need. All that is needed is to copy and paste the repeating templates for each project.
Tamir: So you don’t need to reinvent the wheel.
Rom: Exactly. Almost everything is the same, it helps us a lot.
In addition, because everything is concentrated in one place, if there is a problem, it can be arranged horizontally.
For example, we had a cache problem in Docker, and instead of going through each project and fixing it one by one, we fixed it in one place – and we got it in all the other places – this is the huge advantage of GitLab.
There are also new CI components out now that I want to try but I haven’t had the chance yet (CI Catalog).
GitLab has many cool tools such as premium, secret detection, SAST and DAST in Ultimate, check vulnerabilities and S bombs which are very helpful.
GitLab API
Besides, GitLab’s API is very convenient, and everything we’ve been waiting for from GitLab or open merge requests, today we can do it ourselves with a simple Bash or Python script that does the work for us.
In the past we had problems with coming and starting a rule for repositories or groups.
GitLab has a Feature Request that has been open for some time, and we couldn’t wait, so we simply developed for ourselves and defined the basic rules for a given branch to be merged into the main branch, and we applied it thanks to a simple Cron job.
Tamir: I assume you are talking about merge request approvals?
Rom: Yes.
Tamir: Are there any other capabilities in GitLab that you use, such as GitLabregistry and artifacts?
Rom: Of course. Today, all of our CI pipelines run on images we’ve created, and we use the GitLab registry to keep them as close as possible. That’s one thing we use.
We also use GitLab tags and releases.
We manage artifacts elsewhere, but in the whole process of releasing a package and passing it along into the next tool, it’s all in GitLab and it’s very easy to manage.
Tamir: Awesome! Thank you Rom! It was very interesting.
