Gitlab CE, l'outil ultime de gestion de projet web & open source ?

Historique rapide de gitlab

Initialement un simple système de gestion de code source, Gitlab est devenue en quelques années et sous licence MIT une plateforme permettant de gérer des projets web de A à Z.

À l'origine, le produit était nommé GitLab. En juillet 2013, le produit est scindé en deux : GitLab Community Edition et GitLab Enterprise Edition. Si GitLab CE reste un logiciel libre, GitLab EE passe sous licence propriétaire en février 2014 et contient certaines fonctionnalités assez intéressantes et non présentes dans la version CE.

Par rapport à Github ?

J'ai découvert Gitlab il y a plusieurs années et je n'en avais vraiment pas un bon souvenir. C'est pourquoi, lorsque nous avons envisagé Gitlab il y a un an, nous avions des aprioris négatifs. Nous pensions, au regard de ce que nous avions observé dans le passé que Gitlab était une version low cost de Github et qu'il fallait forcément l'héberger sur son propre serveur et donc maintenir une infrastructure.

En fait, Gitlab présente presque les mêmes fonctionnalités que Github et offre même un avantage fort sur le sujet primordial pour nous :

En effet ! Gitlab vient avec GitlabCI, un système d'intégration continue très puissant et gratuit.

Pour l'avoir testé sur plusieurs projets et pendant quelques temps, ce système est tout à fait remarquable, n'a presque rien a envier à TravisCI ou CircleCI.

Au contraire, grâce à son système innovant de Runners, il est possible de paralléliser l'exécution des tests et d'accélérer significativement le processus de pull request (ou plutôt Merge request dans le jargon de gitlab). Nos runners sont installés sur des serveurs ubuntu classiques... pas des foudres de guerre ni un cloud hors de prix... mais des serveurs qui font largement l'affaire ; et ensuite on configure le runner afin qu'il autorise plusieurs lancements.

En bref, le CI de Gitlab est mieux que les concurrents car:

• Intégré gratuitement dans toutes les versions, version SAAS comme version hébergée CE
• Scalable: Le système de runners permet de distribuer l'exécution des tests sur plusieurs machines
• Jobs parallèles: Cette fonctionnalité coûte vraiment très cher chez CircleCI ou Travis puisqu'on paye le runner 50$. Pour nous, cela nous couterait 1000$ par mois...
• Continuous Delivery (CD): définition d'environnements multiples, déploiements manuels ou automatisés... on n'a pas encore joué avec ça mais ça donne envie bien évidemment !

Pour l'organisation et le suivi des projets : les boards

Gitlab avec les boards n'invente pas grand chose ! Ce n'est ni plus, ni moins qu'un système de tableaux comme font tous les systèmes de gestion de projets agiles comme Trello, Taïga et Jira avec le plugin Agile scrum et même Github depuis quelques mois maintenant avec leur Projects.

Mais c'est une des briques qui manquait à Gitlab afin de pouvoir l'utiliser en tant qu'outil de gestion de projet. Le système de ticket a le mérite d'exister mais on ne gère pas un projet de grande ampleur avec une liste de choses à faire procédurale. On a besoin de faire passer un ticket dans des états différents afin de notifier aux collègues, clients ou plus généralement partenaires de l'avancée des travaux sur la tâche et qu'une intervention est peut-être requise pour continuer l'avancée.

<iframe src="https://www.youtube.com/embed/UWsJ8tkHAa8" frameborder="0" allowfullscreen=""></iframe>

Suffisant pour la méthodo SCRUM ?

Chez Troopers, nous sommes très attachés à la méthodologie Agile SCRUM qui consiste en quelques mots à séparer un projet en plusieurs blocs (appelés sprints) de taille équivalente et d'itérer, sprint après sprint, afin de construire le projet. L'enjeu est de garder une forte relation entre le client et l'équipe de développement afin d'assurer de bonnes interprétations du cahier des charges.

Pour des projets d'envergure, il est primordial de planifier plusieurs sprints d'avance afin de réussir à définir au mieux le planning ainsi que le périmètre fonctionnel des sprints à venir.

Dans Gitlab ou Github, pour parler d'un sprint SCRUM, la bonne pratique est d'utiliser les Milestones. On utilise ensuite le système de Board pour filtrer sur la milestone en cours et cela fonctionne bien et le résultat va ensuite être très intéressant !

En effet, les User stories vont être reliées aux branches de développement et aux Merge requests.

Cela va simplifier grandement le processus de validation d'une fonctionnalité et permettre de toujours garder l'historique des développements pour une User story donnée.

Mais aujourd'hui, pour satisfaire pleinement la méthodologie appliquée ici, chez Troopers, il manque plusieurs choses :

1. un système de time tracking comme on peut l'avoir sur JIRA par exemple
2. un système d'export csv afin de récupérer des rapports (liste des tickets relatifs à une recherche, période, milestone/sprint, catégorie, auteur...)
3. des graphiques d'analyse de projet en méthodo agile par exemple (burndown chart...)

La bonne nouvelle, c'est que le système de time tracking (avec des hooks dans les messages de commits et de merge requests) est prévu pour la prochaine version: https://gitlab.com/gitlab-org/gitlab-ee/issues/92... ; et qu'un système d'export de rapport est aussi prévu dans cette même release.

La mauvaise, c'est que ces points seront réservés à l'édition EE (Entreprise Edition) qui n'est pas la notre...

Nous ne boudons tout de même pas notre plaisir. Il s'agit d'un produit d'une qualité rarement égalée et qui plus est gratuit. Aussi nous ne serons pas trop gourmands et continuerons donc de mesurer notre temps avec des outils externes comme les excellents RescueTime et Toggl.

Version SAAS (gitlab.com) ou version CE / EE ?

Pour tester quelques jours, utilisez la plateforme gitlab.com, vous aurez un apercu de toutes les fonctionnalités en très peu de temps et pourrez prendre conscience du potentiel de l'outil.

Néanmoins, gitlab.com est victime de son succès.... le site est lent... horriblement lent aux heures de pointes (quand tout le monde fait son commit entre 16h et 18h30) et parfois instable. Si le produit vous plait, sautez le pas plus rapidement que nous ! Installez-la version CE chez vous. Cela nous a pris une demi-journée pour le faire de A à Z et l'installation par docker est d'une simplicité déconcertante et les performances seront au rendez-vous.

De plus, passer sur un système hébergé vous permettra d'avoir la main complète sur les Runners partagés et vous permettront de vraiment tirer partie du système d'intégration continue qui est bridé à 1 Runner partagé dans la version SAAS.