GitHub, GitLab et l’intégration continue

Chez Troopers, on gère le code source de nos projets grâce à git, c’est un logiciel de suivi de version. Cela permet à chaque personne travaillant sur un projet de récupérer le code source, d’y apporter des modifications puis de partager le résultat avec les autres personnes.

Il est possible d’utiliser git sans interface web, mais l’utilisation d’une plateforme en ligne présente de nombreux avantages : on peut facilement visualiser quels sont les changements apportés sur le code source, ajouter des commentaires ou suggérer des modifications et valider la liste des changements.

Il existe beaucoup d’acteurs fournissant ce service, et nous allons ici nous attarder sur deux d’entre eux que nous affectionnons particulièrement : GitHub et GitLab.

Nous allons voir comment nous tirons profit de ces services afin d’automatiser les tests et les contrôles qualité.

CI et CD, qu’est-ce que c’est ?

L’Intégration Continue (Continuous Integration ou CI) est un ensemble de processus qui visent à automatiser l’exécution des tests et contrôles qualité d’un projet informatique.

Le déploiement continu (Continuous Delivery ou CD) est une pratique qui consiste à déployer les derniers développements d’un projet facilement en quelques clics ou de façon automatique.

Plutôt que de confier la responsabilité de ces actions à l’équipe de développement, on automatise ces méthodes, ce qui prévient tout oubli. Autre avantage : déployer fréquemment permet de rendre cette opération routinière : l’équipe prend l'habitude de déployer plus souvent, de plus petits incréments de code. Les bugs sont détectés plus tôt et corrigés plus vite.

Voici concrètement comment cela se passe :

1. Le développeur ou la développeuse pousse son code vers GitHub ou GitLab et crée une demande de fusion
2. La CI est lancée automatiquement
3. Le résultat est affiché sur la page de la demande de fusions, il y a 2 cas possibles :

• Un test a échoué, il peut s’agir d’une régression sur une fonctionnalité existante ou d’un comportement qui nécessite que le test soit mis à jour (par exemple si le texte attendu a été modifié) ; la fusion du code est bloquée, le code doit être modifié jusqu’à ce que les tests soient valides
• Tous les tests ont été réalisés avec succès ; la fusion du code est possible

4. Après la fusion du code sur la branche de développement, le code est directement déployé sur un environnement de test, grâce à la CD

GitHub, la plateforme de référence

Ouvre une nouvelle fenêtreGitHub a été créé en 2008, c’est un service commercial dont les sources sont fermées.

Son utilisation est gratuite pour les projets open source, et une version payante amène Ouvre une nouvelle fenêtredifférents avantages. Ce service est rapidement devenu le plus populaire des services d’hébergement de projets, éclipsant par exemple SourceForge et BitBucket. Nous l’utilisons toujours pour nos projets open source.

Malgré les qualités de ce service, de nombreux projets open source choisissent de ne pas utiliser GitHub afin de conserver la souveraineté des données et de ne pas être dépendant d’un écosystème qui dépend entièrement de la société GitHub. Cela amène plusieurs risques : GitHub peut changer ses conditions d’utilisation du jour au lendemain, par exemple en supprimant l’utilisation gratuite pour les projets open source ou bien en décidant unilatéralement qu’un projet n’est plus le bienvenu chez GitHub.

Il est possible de déployer sa propre instance de GitHub grâce à l‘offre GitHub Enterprise Server pour 21 $ / mois / utilisateur (plus les frais d’hébergement).

GitLab, l'alternative open source

Ouvre une nouvelle fenêtreGitLab a été lancé en 2011, c’est un projet open source qui peut être utilisé de plusieurs façons :

• L’instance principale gitlab.com, qui a des fonctionnalités gratuites et payantes comme GitHub
• D’autres instances hébergées par des prestataires externes
• En hébergeant sa propre instance de GitLab (auto-hébergement)

Chez Troopers nous l’utilisons depuis 2017 en auto-hébergement. Notre instance de GitLab tourne grâce à Docker, et nous avons effectué les mises à jour au fur et à mesure des années.

Nous n’avons rencontré qu’un seul souci lors d’une migration vers un nouveau format de stockage des données git. Malgré ce problème, Gitlab est un modèle du genre : de nombreux logiciels ont des processus de mise à jour plus complexes.

Conclusion

Bien que chaque plateforme ait ses particularités, le choix entre GitHub et GitLab dépendra finalement des besoins spécifiques de l'équipe et du projet, ainsi que de la préférence pour un modèle plus ouvert ou plus intégré. Quelle que soit la plateforme choisie, l'automatisation apportée par ces outils peut considérablement accélérer le développement, améliorer la qualité du code, et permettre des déploiements plus fréquents et fiables.

Dans un prochain article, nous montrerons des exemples de mise en pratique d'intégration continue sur ces deux plateformes.

Alternatives à GitHub et GitLab

• Ouvre une nouvelle fenêtreGitea : un logiciel léger qui nécessite moins de ressources matérielles que GitLab (cela peut par exemple tourner sur un Raspberry Pi) mais n’intègre pas de système de CI
• Codeberg : un fork de Gitea, voir Ouvre une nouvelle fenêtrecet article chez LinuxFr