Présentation

Un serveur GitLab est disponible au LIS pour l’hébergement des projets de développement logiciel.

Tout utilisateur disposant d’un compte informatique au LIS peut l’utiliser et créer de nouveaux projets en se connectant avec ses identifiants LIS.

Il est possible de constituer des groupes d’utilisateurs et de leur rattacher des projets (par exemple pour rattacher un projet logiciel à une équipe de recherche ou à un projet de recherche plutôt qu’à un individu).

La visibilité des projets peut être contrôlée : un projet peut être privé (en accès réservé à l’utilisateur ou au groupe propriétaire et aux utilisateurs invités), accessible pour l’ensemble des membres du LIS, ou en accès public.

GitLab permet notamment de disposer pour chaque projet des outils suivants :

• un dépôt Git et de nombreux outils en ligne pour en inspecter et modifier le contenu (visualisation, modification et recherche des fichiers, visualisation des modifications entre les commits, visualisation de l’historique des fichiers, consultation des différentes branches du dépôt et de leur hiérarchie, statistiques sur l’utilisation du dépôt, gestion des demandes de fusion de branches (merge requests) avec revue de code),
• un gestionnaire de tickets (issues) utilisant Markdown, un langage de balisage léger, pour sa mise en forme et pouvant être utilisé en combinaison avec un système de gestion d’étiquettes (labels) et de jalons (milestones),
• un wiki utilisant également Markdown pour sa mise en forme et reposant sur un dépôt Git propre pour la gestion de son historique,
• une plate-forme d’intégration continue (GitLab CI) configurable via un fichier utilisant le langage de balisage YAML.

Documentation

Si vous découvrez GitLab et Git, l’introduction présentée lors de la première session LIFTech’ vous aidera dans votre découverte et votre prise en main.

Pour aller plus loin, le serveur GitLab fournit une documentation intégrée.

Pour la documentation concernant l’utilisation de Git, consultez cette page.

Recommandations

Accès Git et configuration des clefs SSH

L’accès au dépôt Git associé à un projet GitLab peut se faire soit via le protocole HTTPS, soit via le protocole SSH.

En utilisant le protocole HTTPS, le nom d’utilisateur et le mot de passe doivent être fournis à chaque interaction avec le dépôt, alors qu’il n’est pas nécessaire de les fournir lorsque l’on utilise le protocole SSH.

Si vous souhaitez utiliser le protocole SSH il est nécessaire de configurer préalablement votre clef SSH dans GitLab.

La commande de clonage du dépôt dans le cas de l’utilisation du protocole HTTPS est de la forme :
git clone https://gitlab.lis-lab.fr/username/projectname.git

La commande de clonage du dépôt dans le cas de l’utilisation du protocole SSH est de la forme :
git clone git@gitlab.lis-lab.fr:username/projectname.git

Procédure de développement

Divers modes de gestion du flux de travaux (workflows) peuvent être mis en place avec GitLab :

• Tous les membres du projet ont un accès complet au dépôt Git et peuvent pousser leur code librement sur toutes les branches du dépôt.
  L’intérêt de cette approche est sa grande souplesse, mais elle implique une grande responsabilité pour chaque développeur qui doit individuellement garantir la qualité du code (bonne architecture du code, présence de tests, absence de bogues, respect des conventions de codage…).
  Cette approche est donc à réserver au cas où les membres du projet sont tous des développeurs expérimentés.
• L’accès aux branches principales dans le dépôt Git du projet est réservé à certains membres du projet qui en ont la responsabilité et les membres du projets travaillent dans des branches propres dans le même dépôt Git en faisant des demandes de fusion (merge requests) lorsqu’ils souhaitent que les responsables du projet intègrent leurs développements dans une branche principale.
  L’intérêt de cette approche est qu’une revue de code peut être faite avant l’intégration dans les branches principales, facilitant le contrôle de la qualité du code.
  Elle permet donc plus facilement l’intégration de nouveaux développeurs ou de développeurs moins expérimentés au projet.
• L’accès à l’ensemble du dépôt Git du projet est réservé à certains membres du projets qui en ont la responsabilité et les nouveaux développements se font dans des fourches (forks) du projet. Chaque projet fourche est un nouveau projet GitLab indépendant du projet principal. L’utilisateur travaille ainsi directement dans ce projet fourche et lorsqu’il souhaite intégrer ses modifications, il fait une demande de fusion qui est gérée au niveau du projet principal par ses responsables.
  Cette approche permet à la fois un bonne souplesse pour le développeur qui peut travailler librement au sein de son projet fourche, tout en permettant un très bon contrôle de la qualité dans le projet principal où l’on peut assurer que le dépôt Git reste très propre en n’intégrant que le strict nécessaire à l’avancée du développement.
  C’est cette approche que nous conseillons pour vos projets qui impliquent des membres non-permanents du LIS, et en particulier des stagiaires. Cette approche est décrite de manière détaillée sur cette page.

Ces différentes approches peuvent éventuellement être combinées, certains utilisateurs pouvant suivre un type de fonctionnement alors que d’autres suivent un autre mode de fonctionnement (par exemple en fonction de leur niveau de compétence en développement logiciel).

Choisissez le ou les mode(s) de fonctionnement convenant le mieux à votre projet en fonction de vos goûts, de vos besoins et de vos contraintes.

Notifications

Pour suivre facilement l’activité sur vos projets, vous pouvez configurer GitLab pour recevoir des notifications par courriel lorsque des événements ont lieu sur les projets.

Une petite finesse est à noter : le service de notification par défaut ne permet pas de recevoir de notification lorsqu’un utilisateur pousse ses modifications (commande push de Git) sur une branche du dépôt Git du projet GitLab. Si vous souhaitez recevoir une notification dans ce cas de figure, il est nécessaire de configurer le service « Emails on push » pour le projet. Pour cela, depuis la page du projet, il faut se rendre dans Settings / Integrations / Project services / Emails on Push.

Fusion et revue de code

Lorsque vous souhaitez fusionner deux branches du dépôt Git associé à un projet GitLab, plutôt que de réaliser cette fusion en utilisant directement Git dans votre dépôt local et en poussant la branche fusionnée sur le dépôt du projet, il peut être plus intéressant d’utiliser la fonctionnalité de gestion des demandes de fusion (merge requests) de GitLab.

En effet, cette fonction facilite la revue du code modifié notamment en permettant de visualiser facilement les modifications introduites et en fournissant un espace de commentaires qui reste archivé dans le projet. Elle peut donc être utile à la fois pour vérifier la qualité de la fusion avant de l’accepter, et également a posteriori en cas de besoin pour bien identifier et comprendre ce qui a été fait lors d’une fusion donnée.

Tickets

Notez bien que le système de gestion de tickets de GitLab peut être utilisé pour répondre à des besoins multiples, notamment :

• Rapports de bogues : Les tickets peuvent être utilisés pour signaler les dysfonctionnements du logiciel, et assurer le suivi de leur résolution.
• Améliorations et nouvelles fonctionnalités : Les tickets peuvent être utilisés pour identifier et spécifier les nouvelles fonctionnalités, ou spécifier l’évolution des fonctionnalités existantes, puis assurer le suivi de l’implémentation de ces évolutions.
• Gestion de projet (tâches, planification…) : Les tickets peuvent être utilisés pour faciliter la gestion de projet, en particulier pour identifier les tâches à réaliser et assurer leur suivi, répartir les tâches entre les membres du projet en utilisant la possibilité d’assigner les tickets aux utilisateurs, planifier la réalisation des tâches en s’appuyant sur le système de jalons (milestones) de GitLab.

Utilisez les étiquettes (labels) pour différencier les différents types de ticket (bogue, amélioration, tâche…). Plus largement les étiquettes permettent d’introduire des classifications libres des tickets en fonction de vos besoins.

Pour faciliter le suivi des tickets, prenez le réflexe de citer les tickets concernés par vos modifications sur le dépôt Git dans vos messages de commit. Pour cela il suffit de mentionner le numéro du ticket, sous la forme illustrée dans cet exemple :
git commit -m "Fix memory leak in function tralala, solving issue #9"

Wiki

Le wiki disponible avec chaque projet GitLab peut être utilisé de diverses manières en fonction de vos besoins, par exemple pour fournir tout type de documentation à destination des utilisateurs ou des développeurs, pour regrouper les notes liées au projet, pour rédiger les comptes-rendus de réunions des membres du projet, pour rédiger divers documents projet (spécifications, conception, planification, tableaux de bord…).

Notez que le wiki s’appuie sur son propre dépôt Git accessible et modifiable directement via Git. Cette fonctionnalité peut notamment être utilisée pour conserver une sauvegarde locale du contenu du wiki et de son historique. En installant Gollum, il est également possible de visualiser et d’éditer le wiki localement et de renvoyer les modifications en utilisant Git. Vous pouvez retrouver les informations concernant l’accès au wiki via Git dans l’onglet « Git Access » du wiki.

Intégration continue

La plate-forme d’intégration continue GitLab CI est disponible dans vos projets. Nous vous conseillons en particulier de l’utiliser pour vérifier systématiquement que votre code compile, s’installe, et passe sa suite de tests sans erreur. D’autres utilisations sont envisageables en fonction des besoins (analyse statique du code, par exemple pour contrôler le respect d’un convention de codage, création d’installeurs, déploiement automatique du code, test pour différentes architectures ou différentes versions du langage ou du compilateur…).

Les résultats de l’exécution sur la plate-forme d’intégration continue sont disponibles directement dans le projet, ce qui permet de facilement valider l’état courant du logiciel. Les résultats peuvent également être transmis automatiquement par courriel en utilisant le service « Builds emails ».