DevOps with GitLab Tools: A Guild’s Journey

Implementing DevOps Methodologies with GitLab Tools

In today’s software development landscape, it is essential to adopt structured and efficient approaches for releasing applications and production updates.
The DevOps approach was created to bridge the gap between development (Dev) and operations (Ops), promoting automation, continuous integration, and smoother collaboration between teams.

For the DevOps Heroes Guild, the most experienced colleagues proposed GitLab as the ideal tool to demonstrate the effectiveness of the DevOps methodology in code delivery.
This choice is based both on the team’s hands-on experience with the platform and on GitLab’s strength as an all-in-one solution, capable of covering the entire software lifecycle: from coding to production deployment, including version control, CI/CD, and pipeline monitoring.

A Self-Hosted GitLab on Docker

For the first study sessions, we configured a self-hosted GitLab instance within a Docker container. Working with virtual machines and containers is a core skill for any IT/DevOps specialist. Compared to using a preconfigured GitLab environment, this approach has both advantages and drawbacks. On the plus side, it allowed us to experiment freely without worrying about group memberships or permissions, with the ability to reset and reconfigure the environment at will without interfering with normal production activities. On the downside, the chosen Docker image required several customizations to fit our needs—an educational but time-consuming process that occasionally disrupted our GitLab study sessions.

Theory and Practice with GitLab

The sessions alternated between theory and practice to maintain balance and avoid a purely academic approach. For the theoretical part, we relied directly on the official resources from
GitLab University, which offer free courses providing a complete overview of the available technologies along with quizzes designed to reinforce key concepts of the GitLab ecosystem. While valuable, these courses did not always manage to keep attention high; here, practical exercises, hands-on labs, and above all, the expertise and enthusiasm of some members made the difference.

On the practical side, we built simple pipelines around small code projects, an exercise that allowed us to apply the concepts learned in more “realistic” scenarios. This part turned out to be both engaging and educational, with some participants taking the opportunity to experiment with programming languages they do not usually use.

What We Learned

By the end of the Guild, we gained a solid understanding of DevOps principles and a strong familiarity with the ecosystem GitLab has built around this methodology.
The key concepts we explored include:

• Pipeline: an automated process that executes a sequence of stages, each consisting of multiple jobs.
  • Common stage examples: build, test, deploy, review, staging, production.
• CI (Continuous Integration): the practice of frequently updating code—often multiple times per day—by one or more developers.
  In GitLab pipelines, each push is tested to quickly detect bugs or regressions.
• CD (Continuous Delivery): the natural extension of CI.
  Its goal is to keep code always in a production-ready state. GitLab can automatically generate deployable packages once CI tests pass.

The following concepts specifically relate to GitLab CI/CD:

• Pipelines are defined through a YAML file called .gitlab-ci.yml, which specifies stages, jobs, execution order, variables, and conditions.
• GitLab Runner: an agent that executes the jobs defined in the .gitlab-ci.yml file. Each job runs in an isolated environment.
  Automation processes can be made dynamic using environment variables configured in the file or directly in GitLab settings.