Qu'est-ce Git et comment bien configurer un serveur GitLab pour la gestion de ses projets ?

GitLab est un outil de gestion de projets open source. Il reprend l’essentiel des fonctionnalités d’un logiciel de gestion de versions, tel que Git (ou Subversion que peu de gens connaissent, car peu à peu abandonné au profit de Git). L’outil est accessible en ligne et en mode SaaS. Il permet de gérer des projets multiples, à l’aide d’un système de branches et d’un système de labels.

Pour faire simple, GitLab est une plateforme collaborative pour le développement logiciel. Elle est conçue pour permettre à une équipe de travailler sur un projet sereinement, et d’avoir un historique clair des modifications réalisées.

Pour vous aider à améliorer votre confort de travail, je vous propose ici un petit tour de ma configuration de GitLab. Je vous expliquerai de quelle manière je l’utilise pour améliorer ma productivité et vous donnerai une vision d’ensemble de mes différents espaces de travail.

1. Qu’est-ce que Git et pourquoi est-il utile ?#

Git est un outil qui permet de versionner du contenu. Principalement employé pour les projets techniques, il est aussi utilisé dans plusieurs plateformes de gestion de contenus techniques pour justement garder une trace des différentes évolutions de ceux-ci, telles que les contrats, les conditions générales de vente, etc.

Pourquoi est-il utile ? Pour gérer le contenu de l’ensemble de vos projets. Cela permet de rester organisé et de savoir exactement ce que vous avez modifié dans votre code. Par exemple, vous travaillez sur un projet pour lequel le code est déjà constitué de plusieurs branches (par exemple : dev, qa, staging, production), en parallèle un autre développeur travaille donc dans une autre branche que la vôtre. Vous devez donc le rejoindre et effectuer une sorte de merge, afin que votre nouveau code puisse être intégré à son projet. Avec Git, vous pouvez très facilement voir ce qu’il s’est passé sur la branche en question et ce que vous avez modifié. Vous pouvez ensuite valider ces modifications ou les refuser afin d’éviter les problèmes de bugs.

Quelques bonnes pratiques à partager :

• Dès la création d’un projet, initialiser un repos git, même s’il ne sera pas nécessairement envoyé sur un repos distant. Cela vous permettra d’historiser votre développement.
• Faire des commits réduits au plus près d’une tâche. Nous avons tendance, en tant que développeur, à faire beaucoup de modifications à la fois pour au bout du compte ne réaliser qu’un unique commit, sans nécessairement prendre le temps regrouper les modifications par sujet. En suivant cette recommandation, il vous sera beaucoup plus simple d’identifier les éventuels bugs, de voir l’ensemble des modifications associées à une unique demande (et non mélangées à plusieurs) et de pouvoir revert uniquement sur ces modifications et non sur plusieurs.
• Toujours utiliser l’option -p lors de l’exécution d’un git add ou d’un git checkout. Beaucoup de développeurs on tendance à faire des git add . sans se relire et donc à mettre en production des éléments de debug ou même des commentaires impactant directement le résultat fianl attendu. L’option -p vous permettra de valider, morceau par morceau, les différentes modifications.
• Ajouter au projet un README.md qui contiendra quelques informations précieuses, comme les potentielles références externes utilisées pour l’écriture de certaines parties du code ou la manière d’installer le projet. Comme vous allez de toute manière le faire pour vous, il est pertinent de le noter en même temps pour d’éventuels autres collaborateurs.
• Mettre un .gitignore, fichier indispensable pour exclure les éléments inutiles. Cela concerne les fichiers d’environnement, les fichiers générés par l’ordinateur (.DS_Store , etc.), les fichiers compilés ou les répertoires des dépendances (vendors , node_modules , etc.).

2. Qu’est-ce que GitLab ?#

GitLab est un logiciel libre qui permet aux développeurs de gérer le code de manière collaborative avec leurs collègues, clients ou fournisseurs. C’est également un outil de gestion de projets, qui vous aide à planifier, organiser et suivre le travail, et à contrôler les modifications.

Il est composé d’un serveur Git, d’un outil de gestion des dépendances, d’un outil pour gérer les packages, d’un outil de gestion des changements et d’un outil de gestion des bugs. C’est l’équivalent de Github mais pouvant être installé sur ses propres infrastructures.

Il existe d’autres solutions permettant la mise en place d’un serveur Git intégrant plusieurs de ces composants, telles que Redmine, et d’autres beaucoup plus simples telles que Gitea. Toutefois, ces solutions sont beaucoup trop légères pour l’usage intensif qui en est fait par les sociétés gérant plusieurs centaines de projets.

3. Pourquoi GitLab ?#

Pourquoi avoir choisi de mettre en place GitLab au lieu d’autres solutions ? Car c’est une solution complète et facile à utiliser. En effet, il permet d’installer toute la configuration nécessaire pour faire du CI facilement, intègre tout un système de registry pour les containers, ainsi que, plus récemment, la possibilité d’avoir des registries pour les dépendances telles que NPM, Pip, Composer, etc., en mode privé.

GitLab nécessite une bonne prise en main pour la configuration initiale, la mise en place des divers runners et la sécurisation du serveur. Mais passé l’étape de son installation, cela devient un vrai plaisir d’utilisation. Il inclut en plus des intégrations aux divers outils externes tels que Sentry, Slack, etc. Il permet, également, d’économiser énormément de temps lors de la mise en place d’un nouveau projet.

4. Installation de GitLab#

Je passerai l’étape de l’installation du GitLab car ce n’est pas ici le sujet, et ce, d’autant plus qu’avec le temps les méthodes d’installation vont évoluer et que d’autres tutoriels en ligne feront largement l’affaire. Toutefois, voici quelques précisions sur les choix personnels réalisés :

• IPv4 et IPv6 : De plus en plus de connexions se font en IPv6. Il est donc primordial, lors de l’installation de votre GitLab, d’activer l’IPv6 et de bien vérifier qu’elle fonctionne.
• Sécurité : Sélectionner l’option obligeant tout compte à activer son 2FA. Pourquoi s’en priver, surtout que cela permet d’homogénéiser l’accès de tous les membres utilisant votre GitLab.
• Git Folder : Je vous invite fortement à enregistrer le dossier sur lequel se trouve l’ensemble des données sur un espace de stockage variable. Cela facilitera l’extension de l’espace au besoin et le backup des données. J’utilise personnellement un volume monté me permettant, à tout moment, de faire une sauvegarde de celui-ci et d’augmenter sa capacité si le nombre de projets le nécessite (ou la taille du registry docker).
• Backup externalisé : Avec l’arrivée du stockage S3, je vous invite fortement à configurer dès le début la sauvegarde quotidienne de votre projet sur un dossier distant, pour le cas où il y aurait un souci avec votre serveur. Le coût est extrêmement faible pour une sécurité qui peut s’avérer très utile.
• GitLab Runner / GitLab CI : Si vous prévoyez de mettre en place du CI via un fichier .gitlab-ci au sein de vos projets, vous disposez de 2 méthodes pour installer des runners, soit vous les dédiez à des projets, soit vous les mutualisez. Pour ma part, je dispose de plusieurs pools de runners (créés par gitlab-runner et sélectionnés en fonction de l’usage que je souhaite en faire), avec une majorité de runners mutualisés. Il est rare qu’il y ait besoin d’énormément d’instances tournant simultanément, même pour des projets nécessitant de grosses équipes.

5. Structure des différents projets sous GitLab#

Tout d’abord, dans une optique professionnelle, je vous invite à ne pas créer de projet au sein de votre utilisateur mais à toujours les mettre au sein d’un groupe. Tout simplement pour faciliter l’accès à ces projets à d’autres utilisateurs mais également pour pouvoir regrouper plusieurs projets au sein d’un même groupe.

Les groupes vont vous permettre, comme des dossiers, de bien structurer vos projets et de donner la main aux autres collaborateurs uniquement sur les projets auxquels ils ont besoin d’accéder. Lorsque je travaille avec des équipes externes, je crée un groupe (généralement reprenant le nom de la société) qui va contenir l’ensemble des projets sur lesquels nous collaborons. Cela permet ainsi de donner aux utilisateurs externes (à la société) les droits sur ce groupe et sur l’ensemble des sous-projets, sans pour autant avoir à le spécifier au sein de chaque projet.

La plupart du temps, l’accès des utilisateurs externes (même des CTO) au groupe n’est jamais de type administrateur. Je ne leur laisse ainsi pas la possibilité d’accéder à la configuration des secrets ou des tokens. C’est une séparation importante : il faut savoir restreindre l’accès de chaque utilisateur au strict nécessaire, sans quoi vous risquez de lui donner la main sur des données sensibles alors que cela n’a pas lieu d’être.

Retrouvez l’ensemble des points de ma configuration.

Prochaine étape : L’usage de Docker et de Docker Compose dans mes projets… À suivre !