GitLab : fonctions et premiers pas avec Git
Auteur : Rédaction Domeny.ForSale Publié le
En bref : GitLab est une plateforme permettant de stocker du code, de collaborer sur les modifications et d’automatiser les tests ainsi que le déploiement des applications. Elle utilise Git, un système qui conserve l’historique des modifications apportées aux fichiers, et y ajoute des outils d’organisation du travail et de contrôle qualité. Vous pouvez utiliser le service GitLab.com ou installer GitLab sur votre propre infrastructure.
À quoi sert GitLab et en quoi diffère-t-il de Git ?
Git permet de savoir qui a modifié les fichiers et quand, de comparer leurs versions et de rétablir un état antérieur du projet. Il fonctionne aussi localement sur un ordinateur, sans compte sur un service en ligne. GitLab, en revanche, est une plateforme qui offre un espace de travail partagé aux personnes utilisant Git.
Un projet repose sur un dépôt, c’est-à-dire un ensemble de fichiers accompagné de l’historique de leurs modifications. GitLab permet de consulter le dépôt dans un navigateur, de gérer les accès et de discuter des corrections proposées. Outre le code, on peut y conserver de la documentation, la configuration d’un serveur ou les fichiers texte d’un site web.
GitLab n’est ni un éditeur de code ni un système de gestion de contenu comme WordPress. En général, le développeur écrit le code dans son éditeur, puis envoie les modifications au dépôt. La plateforme aide à les vérifier et à les transférer vers l’environnement dans lequel l’application fonctionne.
Comment collaborer sur les modifications ?
Travailler dans GitLab n’implique pas de modifier directement la version principale du projet. Un membre de l’équipe crée une branche, c’est-à-dire une ligne de développement distincte, et y enregistre ses modifications sous forme de commits : des ensembles de modifications accompagnés d’une description. Cela permet de préparer une nouvelle fonctionnalité sans affecter immédiatement la version utilisée par les autres.
Une fois prête, la proposition est présentée dans une merge request, une demande de fusion des modifications avec une branche choisie. Les autres membres peuvent comparer le code, laisser des commentaires et demander des corrections. Les modifications sont fusionnées lorsque les conditions définies sont remplies ; les approbations requises et les règles d’accès dépendent de la configuration et des fonctionnalités disponibles.
Prenons l’exemple d’une agence qui améliore le formulaire de contact du site d’un client. Un développeur prépare la modification dans une branche distincte, une autre personne vérifie la gestion des erreurs et un test automatique contrôle que les données sont correctement envoyées. Ce n’est qu’après ces vérifications que l’équipe fusionne la correction avec la version principale et la déploie sur le site.
Les issues servent à signaler des bugs et à planifier les tâches. Ce sont des tickets comprenant une description, une discussion et une personne responsable. Relier un ticket à une merge request permet de retrouver non seulement ce qui a été modifié, mais aussi pourquoi.
Qu’apporte l’automatisation CI/CD ?
CI/CD désigne l’intégration continue ainsi que la livraison ou le déploiement continus des modifications. L’intégration continue consiste à réunir fréquemment le travail de l’équipe et à vérifier automatiquement le code. La livraison prépare le logiciel à une nouvelle version, tandis que le déploiement peut en plus le publier automatiquement dans l’environnement cible.
Dans GitLab, ces opérations sont généralement décrites dans le fichier .gitlab-ci.yml placé dans le dépôt. Elles constituent un pipeline, un ensemble de tâches exécutées selon des règles définies. Ces tâches sont lancées par un runner, un programme qui exécute les commandes sur l’infrastructure qui lui est attribuée.
Un pipeline simple pour un site web peut :
- Vérifier la syntaxe et le formatage du code.
- Exécuter les tests.
- Générer les fichiers prêts à être publiés.
- Les envoyer sur un serveur de test, puis, après une validation manuelle, sur le serveur de production.
Le simple fait de placer un projet dans GitLab ne lance pas un processus de déploiement complet. Il faut configurer les tâches, disposer d’un runner disponible et accorder les autorisations nécessaires. Les mots de passe et les clés d’accès ne doivent pas être enregistrés dans le code : utilisez pour cela des variables CI/CD correctement protégées ou un système de gestion des secrets. Les tests automatiques ne détectent que les problèmes couverts par leurs vérifications ; un résultat au vert ne garantit donc pas l’absence de bugs.
GitLab.com ou une installation sur votre infrastructure ?
GitLab.com est un service géré par le fournisseur. Vous n’avez pas à installer la plateforme, à la mettre à jour ni à administrer son serveur. Vous restez toutefois responsable des paramètres du projet, des comptes utilisateurs, des autorisations et de la protection des identifiants d’accès.
Une installation sur votre propre infrastructure, appelée GitLab Self-Managed, vous donne davantage de contrôle sur l’infrastructure et sur l’emplacement de stockage des données. En contrepartie, elle exige des mises à jour, une surveillance, des sauvegardes et la sécurisation du système. L’installer sur un serveur de l’entreprise ne garantit pas automatiquement une meilleure sécurité.
Pour une petite équipe sans administrateur, un service hébergé est généralement plus pratique pour commencer. Une installation sur votre infrastructure peut se justifier par des exigences particulières concernant le réseau, les intégrations ou les données. Avant de choisir, consultez la documentation officielle et les tarifs de GitLab pour vérifier les limites actuelles de stockage, les règles de facturation des tâches CI/CD et la disponibilité des fonctionnalités nécessaires dans la formule envisagée.
GitLab et GitHub : différences et premiers pas
GitLab et GitHub sont deux plateformes distinctes qui utilisent Git. Toutes deux permettent de stocker des dépôts, de relire les modifications, de gérer les tickets et d’automatiser le travail. Dans GitHub, l’équivalent d’une merge request est une pull request, et l’automatisation passe notamment par GitHub Actions.
Il vaut mieux fonder votre choix sur les intégrations et les autorisations nécessaires, les coûts de l’automatisation et l’expérience de l’équipe. Transférer le dépôt Git lui-même peut être relativement simple, mais la migration des tickets, des discussions et de la configuration des déploiements demande une préparation distincte.
Pour commencer, créez un projet privé avec un fichier README décrivant son objectif. Préparez ensuite une petite modification dans une branche distincte et ouvrez une merge request. Cet essai vous permettra de découvrir le fonctionnement de base avant d’ajouter l’automatisation et l’accès aux serveurs.
À lire aussi
