Comment utiliser Gitlab CI/CD pour optimiser vos projets ?

Les bases de la ci/cd dans GitlLab : définir ses stages, construire et déclencher sa pipeline.

GitLab CI/CD s'est établi comme un outil essentiel dans l'automatisation des processus de développement. Son utilisation efficace permet de simplifier les étapes de construction, de test et de déploiement des logiciels. Il permet d’enregistrer un gain de temps significatif pour les équipes tech, une diminution des erreurs, et une amélioration notable de la qualité des applications. GitLab CI/CD se présente comme un outil robuste pour la création et l'optimisation de ces pipelines CI/CD. Victor Lennel, co-fondateur de Pumpkin et de Zeliq et CTO, nous explique comment l’utiliser.

Quels sont les éléments fondamentaux à considérer lorsqu’on met en place une première version de ci/cd dans GitLab ?

Je considère qu’il faut évaluer trois points clefs lorsqu’on commence à lancer sa première version de ci/cd GitLab.

1. D’abord, il est fondamental de définir ses différents stages, afin de comprendre quelles peuvent être les grandes parties de la CI/CD que l’on souhaite engager, puis de savoir comment les organiser.

Les stages permettent de grouper des jobs entre eux et d’organiser leur ordre de déclaration.

2. Ensuite, il est essentiel de définir assez tôt la fréquence à laquelle on souhaite déclencher notre pipeline. Pour définir cette fréquence, il est notamment important d’effectuer un ratio entre le nombre de déploiements que l’on souhaite effectuer et le coût de ces derniers.

3. Enfin, il faut envisager de construire plusieurs pipelines qui écoutent plusieurs types d’évènements, tels que des push, merge, resquest.

Pourquoi choisir GitLab pour la mise en oeuvre de ci/cd par rapport à d’autres plateformes comme GitHub ? Quels sont les avantages ?

1. Customisation des jobs : Dans GitLab, la plupart des jobs sont customisables. Il est possible d’aller relativement loin dans l’écriture, avec des requêtes qui peuvent être très faciles à ajuster.
2. Importance du docker : GitLab est très orienté autour de Dockers, particulièrement appréciés par les milieux DevOps. La prise en main est largement facilitée. Avec GitLab, il devient possible d’abstraire assez facilement les différentes couches de systèmes d’exploitation, d’utiliser moins de ressources et différentes instances Linux, d’isoler des containers les uns par rapport aux autres, de réaliser des chaines d’intégration continues grâce à un « Container Registry » Docker directement intégré à Gitlab ci/cd.
3. Une documentation riche et open source : La documentation GitLab est particulièrement complète. Elle offre de nombreuses informations et un grand nombre de solutions et d’astuces y sont décrites. GitLab prône aussi une belle philosophie. Leur GitLab Handbook est open source. Les membres de la communauté tech apprécient généralement beaucoup cette mentalité.

Les bonnes pratiques et écueils à éviter pour réussir à mettre en place sa ci/cd avec GitLab

Quelles sont les étapes clefs pour configurer une pipeline ci/cd dans GitLab pour un projet typique ?

Pour bien configurer une CI/CD, nous le disions plus haut, il est essentiel de définir ses différents stages. Une fois ces stages définis, il faut alors les découper en plusieurs jobs, ou tâches dédiées à la réalisation d’une action. Les jobs représentent l’ensemble des commandes à executer, l’ensemble des applicatifs à déployer, et sous quelles conditions.

Quelles sont les bonnes pratiques à suivre lorsqu'on met en place un ci/cd avec GitLab ?

Il est important de bien monitorer le temps d’exécution de ses pipelines et ce dès le départ. Les minutes accordées chaque mois sur GitLab ne sont pas illimitées. Si l’on souhaite s’éviter des coûts supplémentaires il est important de comprendre assez vite ce qu’il faut optimiser dans sa CI/CD.

Pour cela, quelques astuces simples que j’évoque dans ma session Pollen existent :

1. Penser à utiliser du cache : réfléchir au lancement de chaque job dans le pipeline, réutiliser du cache ou un artifact précédemment généré.
2. Restreindre l’exécution de certains jobs lors de la modification de certains fichiers seulement. Sur une codebase assez large, avec des pipeline complexes, il est rare que l’ensemble des jobs aient à être lancés pour n’importe quelle modification dans ladite codebase.

C’est notamment le cas pour les mono-repo. Si seul le front a été modifié, il n’est pas essentiel de reconstruire le back pour cela. L’exécution de la CI/CD doit être conditionnée à nos besoins stricts.

Et les pièges à éviter ?

À première vue, la CI/CD de Gitlab peut paraître un peu longue à être lancée, mais il existe des tailles de runners différents. Autrement dit, si le temps de lancement est trop important, c’est qu’il faut sans doute passer sur un runner différent, pour aller trois fois plus vite.

Le type d’instance de runner a une incidence sur le nombre de minutes consommées.

De plus, engager ses propres valeurs occasionne des coûts cachés, de la maintenance, du temps homme à consacrer. Cette stratégie n’est donc pas toujours la meilleure solution.

Un second piège est de ne pas considérer sa CI/CD dans le temps. Il est aussi important de revenir régulièrement sur sa CI/CD et de résister à la tentation de se lancer immédiatement sur l’élaboration de la meilleure version possible. Avec le temps, votre CI-CD finira par s’améliorer.

Et ce de deux façons :

1. En passant par la factorisation du code. Certains jobs vont avoir des steps assez communs, il est donc intéressant de les rassembler.
2. En privilégiant le lancement de sous-jobs et en valorisant l’utilisation d’ancres.

Après ses études, Victor a travaillé sur plusieurs projets tech avant de se passionner pour le secteur de la Fintech. Cela l'a amené à co-fonder Pumpkin, une application de paiement et de remboursement entre amis, dans laquelle il occupait le poste de CTO (2M+ utilisateurs, 100+ employés, dont une équipe de 25 tech).

Actuellement, Victor est le cofondateur et CTO de Zeliq, une solution SaaS facilitant la prospection commerciale.

Depuis les débuts de Pumpkin jusqu'à aujourd'hui, Victor a été confronté à plusieurs problématiques liées à l'intégration et le déploiement de ses apps. A chaque fois, il a mis l'accent sur une CI/CD capable de tester, build et déployer de manière automatisée. Son objectif pour les gros projets est que le temps de déploiement n'excède pas plus de 15 minutes.