🇬🇧 10 Years of GitLab 🦊
The 8th of October of this year is a special day for GitLab. It’s the 10th birthday of the first commit!
For this #10YearsOfGitLab day, I decided to write this blog post about my journey with GitLab, and more specifically the GitLab platform.
The beginning
I have known GitLab for more than 5 years -I don’t remember how many years exactly- but simply as a source code manager. Whether in a personal or professional context, my usage was limited to committing source code and retrieving it. At conferences and in blog posts, I had vaguely heard that continuous integration was directly provided by the platform but I had never looked into it.
A new context
At my previous company, our team was assigned a project that had a different context from our usual projects. It was developed with front end and back end frameworks that I only knew by name and that were stored in another GitLab instance in which we had more rights than in our legacy instance. But the surprises were just beginning.
This application was run with docker-compose and was installed on different environments … manually! It was the first application we had to manage all the way from the test environment through to production.
After several deployments to production, I quickly realized that entering command lines, even if they are simple, is a waste of time and, above all, a source of error. Several times, I was surprised to find that I had restarted production instead of a test environment 😱. Luckily the restart of the docker-compose stack had no impact for our users. In an emergency or when you are doing several things at the same time, human error often happens. In order to differentiate each environment I added a color code to the prompt of my terminal, but these install operations could be automated!
The teams that usually managed the pipelines were not expected to work on our project. It was therefore time to get down to one of the tools at our disposal : GitLabCI!
Learning about GitLab CI
From this moment I was focused more on GitLab CI. I had heard that it was easy to get started, and as GitLab CI was available on our instance, there was no reason not to use it.
After a few weeks, our first pipelines were running. We built them step by step : ultimately, we built Docker images for each part of the application, used Ansible to modify the docker-compose file with the new version of the image and installed them on different test environments. As soon as merge requests were approved and merged, a new release was created and Docker images built. Then, we had to manually update and restart the application as soon as there was a period of quiet. It was not automatic as the teams wanted fine control over the moment when the actions were done.
The time savings were quickly noticeable as well as the greater stability of the operation.
A new pace
I really liked the installation of these first pipelines. This activity was not part of my daily life and it is a very pleasant discovery. It made me want to discover more about the GitLab CI part. The ease of integration was unsettling and I wanted to know more.
After reading more documentation and setting up other pipelines on my personal projects, I wanted to share my findings : I wrote several blog posts, made a few presentations of our work at local meetups and spent time translating GitLab. Moreover I helped people on the GitLab forum. Next, I discovered the GitLab Heroes program. I thought that I was not good enough to apply for it but after some discussion with other heroes, I decided to try and see what would happen. As we say in French: “100% des gagnants ont tenté leurs chances” which means that if you want to win you have to play.
But what a surprise when I received an email that confirmed my admission to the program. I am so happy to say that I’m a GitLab Hero 🎉!
Joining this program was exciting and made me want to get more involved in GitLab and share more of what I have learned about GitLab CI and its ecosystem. So, for the moment, I have written and published 8 articles which are mentioned and listed on the GitLab Heroes contributions page. They discuss GitLab CI, installing runners on a Raspberry PI or personal organization using GitLab boards.
And since this summer, I wrote a series of Cheatsheets for GitLab CI, in order to explain visually certain concepts like the structure of pipelines or the use of child-parent pipelines. The idea came to me when I was trying to explain some features to my colleagues. I tried doing this within a GitLab project, but having some quick visual aids on hand appealed to me.
This is how GitLab allowed me to change my daily life drawing on deeper knowledge of a DevOps platform, a welcoming community and discussing the subject with other experts. Thanks to all for this beautiful community 👏