🦊 Modernize your CI/CD with CI/CD Catalog

For many years and specifically with the rise of DevOps, CI/CD has become the central point to our applications. CI/CD (Continuous Integration & Continuous Deployment) allows us to build and deploy projects easily and frequently, when you want 😁
At each step of our project, we use CI/CD : from building our project, checking security, and deploying our application.

CI/CD in GitLab can be very easy. Quickly, every developer can initiate a script of CI/CD. If we are in a new project, we can copy past a part of an existing project we work or we worked and the CI/CD runs, it’s great and our application can be built and deployed when or where we want.
Imagine the future, when you have done this copy paste on many, many, many projects. And your favorite language or library has a new version impacting your CI/CD, or I should say ALL your CI/CD scripts you create. And imagine several teams in your company make the same, you can have so many CI/CD scripts making the same things. That's hell !

⚠️ CI/CD is code and don’t underestimate your CI/CD scripts.

💡 CI/CD Catalog : definition

A good approach is to use a “CI/CD Catalog”. This term has existed since several years ago in some tools and for GitLab CI/CD, this approach has been introduced by different tools as “to be continuous” by Orange or R2DevOps (since 2025, they decided to remove their marketplace). The objective is the same, develop CI/CD scripts to be reused in CI/CD pipelines.
You want to make one action in your CI/CD? Check first into a catalog.

GitLab worked on their own catalog and they introduced a first version in the 17 version, released in 2024. It is available from this url : https://gitlab.com/explore/catalog/

All study is available in this epic : https://gitlab.com/groups/gitlab-org/-/epics/7462

On this catalog you can find components of CI/CD produced by GitLab Team, but also by GitLab partners, as Google

or also by creator verified by GitLab, as “to be continuous“.

➕ Benefits of a CI/CD Catalog

Using a CI/CD catalog has some benefits. First of them is the reusability of components.

• a common structure
• components visible and shareable
• Readability

stages: - say-hello - test - build - deploy 💬 say-hello: stage: say-hello script: - echo "👋 Hello Breizhcamp" include: - local: "test-and-build.yml" - local: "deploy-app.yml" - project: 'security-team/pipelines' file: '/backend-security/.gitlab-ci.yml' - project: 'deploy-team/deploy-on-cloud' ref: v1.0.0 file: '/provider-x/deploy.yml' 

• documentation
• testing unit
• a dedicated page to explore all catalogue
• versionning
• inputs controlled before the execution of pipelines

📝 Create your first CI/CD component

A CI/CD component can be simply and quickly implemented. After creating an empty project, the first thing to do is to check the CI/CD component option in the global settings:

This option generates a label near the title of your project, identifying quickly which project is a CI/CD component.

After implementing your CI/CD jobs, a release using semantic versioning has to be created to be available on the CI/CD Catalog.

💡 Since the release 18.0 of GitLab, a template of CI/CD Catalog is now available. It is a ready to use project’s structure.

🚀 Go further

Even if CI/CD components can be used on production, following the new versions of each component called in your project can be a repetitive task. Of course, this can be automated with tools such as Renovate (self promotion for a talk with Lise about the discovery of Renovate during DevoxxFR 2024). This is not available in Gitlab.

In some companies, there is no team dedicated to CI/CD. Development teams create their CI jobs depending on their needs, and everything concerning updates or security recommendations is in most cases not done, and this is problematic. CI/CD pipelines are an entry to security vulnerabilities. Attackers can then access your infrastructure (and make some very dangerous actions).
Currently, GitLab does not offer a global visualization and a control of all CI/CD across your projects.

🤖 Here comes R2DevOps

Created by Aurélien and Thomas (in 2021), R2DevOps is a powerful tool I used in some contexts that scans your projects to deliver insights into security and compliance of your CI/CD scripts. With graphics and dashboards, it enables quick and easy resolution of your project issues without leaving the platform.
R2DevOps also offers the possibility to configure some options such as the fact to allow or not some Docker image registries, adding some rules on them to avoid the “latest” tag.

In my opinion, this is an awesome tool, perfectly suited for persons or teams responsible of CI/CD jobs.

For more information about this project, my colleague Jules and me presented a talk at Devoxx France (in 🇫🇷) : https://www.youtube.com/watch?v=DXoGJmep1P8&list=PLbf9DSLhCPwSXKsENKDrFAdfzBiQpI-U6&index=6.

💪 A migration right now?

“Classic” CI/CD and catalog are compatible. You don’t have to migrate all your CI/CD scripts in one shot. A good option, in my opinion, is to migrate one action into a first component and import it into all your pipelines.
With tools such as Renovate and R2DevOps, the monitoring, the security and the upgrade of each component will be easier to keep up to date.