Gerrit est l'outil d’analyse de code utilisé par des projets open source comme Android ou Eclipse et “Learning Gerrit Code Review”, de Luca Milanesio, est le guide de référence pour débuter.
Le projet est né d'une réimplémentation de Mondrian et Rietveld, mais repose sur un runtime Java plutôt que Python. Son but est de fournir un outil de revue de code qui sécurise la branche principale d'un dépôt avec des revues d’utilisateur et automatisées.
Dans le premier chapitre, Luca présente les rôles et les avantages que les revues de code peuvent apporter à un projet en s’attardant sur les raisons de ces bénéfices qui vont de la propreté du code au partage des connaissances, en passant par un retour rapide sur les résultats de tests, qui font partie intégrante des revues de code.
La mise en place de son propre serveur Gerrit est ensuite abordée dans les trois chapitres suivants. En commençant par les recommandations de logiciels et la configuration initiale des bases de données jusqu’aux méthodes d'authentification et d'accès en comparant par exemple les protocoles SSH et HTTP. Les trois chapitres qui suivent abordent les questions de configuration, comme les paramètres globaux du projet, les autorisations individuelles ou bien les différents types de soumission des règles et leurs effets.
Les annexes livrent des informations utiles sur l'intégration de Gerrit avec GitHub, grâce à des outils de compilation, tels que Jenkins, ainsi que quelques informations sur Git pour les utilisateurs qui ne seraient pas encore familiers avec la façon dont les dépôts sont stockés sur le disque. Étant donné les liens forts entre Gerrit et Jenkins, il est peut-être un peu surprenant que l'intégration de Jenkins ait été reléguée dans une annexe, mais c’est une addition bienvenue au livre dans son ensemble.
Ce livre sera utile à ceux qui n'ont pas l'expérience de l'installation ou de la configuration de Gerrit mais souhaitent tout de même mettre en place un processus de travail basé sur celui-ci. Le livre fourmille d'exemples sur le fonctionnement et la configuration de Gerrit sous un système Unix. Bien qu’il soit possible d'exécuter Gerrit sous Windows, le seul clin d'œil du livre aux technologies Microsoft est sur la capacité à intégrer Active Directory comme une source utilisateur/groupe.
Pour ceux qui veulent essayer Gerrit sans avoir à le configurer, l’entreprise de Luca, GerritForge, héberge un site, GerritHub.io, aidant à intégrer Gerrit avec le mécanisme de pull-request de GitHub pour ensuite obtenir une revue de code.
InfoQ a eu la chance de s’entretenir avec Luca Milanesio au sujet de son livre "Learning Gerrit Code Review" :
InfoQ : Combien de temps avez-vous été impliqué dans Gerrit et comment avez-vous été impliqué ?
Luca : Gerrit a attiré mon attention en 2010, alors que je dirigeais une migration de Subversion vers Git pour Vodafone au Royaume-Uni et en Allemagne. J'ai vu beaucoup de lacunes à combler pour soutenir Git en entreprise et j’ai commencé à m’investir sur la plateforme. Nous avons lancé GitEnterprise.com début 2011, mais Gerrit semblait avoir un avenir très intéressant, car il était non seulement une solution déjà testée et éprouvée, grâce à son adoption par le projet Android, mais aussi un projet OpenSource très prometteur. À l'automne 2011, nous avons lancé la première intégration en entreprise de Gerrit avec CollabNet TeamForge, qui a par la suite inspiré le nouveau nom de notre Société. Mi-2012 nous avons arrêté le développement de GitEnterprise pour consacrer nos efforts sur le projet OpenSource Gerrit Code Review.
InfoQ : Quels sont les principaux avantages de Gerrit dans le processus de développement ?
Luca : D'après mon expérience, l'aspect le plus important de Gerrit est la collaboration autour de la propriété collective du code: les gens sont encouragés à inspecter le code et se sentent plus à l’aise pour exprimer leurs opinions ! Cela comporte un certain nombre d’avantages immédiats et à long terme pour l'équipe et le projet. Le principal effet positif visible, c’est la réduction du nombre de builds cassés. Même si cela peut paraitre dérisoire à première vue, il s'agit d'un avantage énorme pour réduire le temps perdu de l' équipe à aller chercher le changement dans le code qui a cassé le build ou le temps perdu pour réparer l’intégration continue cassée à cause d’un patch défectueux. A moyen terme, le fait de lire continuellement le code, répand la connaissance dans toute l’équipe. Avec le temps, les membres de l’équipe connaissent mieux la structure du code et deviennent par conséquent, plus précis et efficaces quand ils développent de nouvelles fonctionnalités ou lors des phases de maintenance. A plus long terme, le niveau de l’équipe deviendra naturellement plus uniforme, la qualité du code s’améliorera, et la volonté de ses membres de collaborer et d’étendre toutes les parties du projet devrait s’accroître. Les commentaires portent souvent sur la façon dont le même algorithme pourrait être implémenté avec un code plus concis et plus maintenable. Les gens vont donc passer moins de temps dans la réécriture et plus sur l'extension d'une base de code beaucoup plus uniforme et claire.
InfoQ : Comment peut-on comparer Gerrit avec le système de revues de branche ou de pull-request en place dans GitHub ?
Luca : Il ya une différence importante entre les Pullrequest GitHub et les CodeReview Gerrit. GitHub, à mon avis, est plus approprié pour un projet de "one-man band" où, souvent, il y a un responsable de projet et de nombreux contributeurs extérieurs qui souhaitent fusionner leur propre «version» de la base de code. Dans GitHub vous devez fusionner et créer votre propre version du projet si vous voulez laisser une contribution. De plus, la demande de PullRequest n'est pas régie par un ensemble commun de règles et cela peut entraîner de la confusion et du bruit lorsque le projet prend de l'ampleur. Gerrit est conçu dans le but d'amener les gens à travailler ensemble sur un projet, pas à forker dans de multiples sous-projets. Avoir beaucoup de gens sur un projet comme Android requiert plus d'organisation, de coopération et des règles sur la façon dont les changements sont opérés. Ces règles peuvent être définies projet par projet, puis la «démocratie» de l'équipe approuve et note les changements. Du point de vue de la simplicité, si on regarde le nombre d'étapes nécessaires pour contribuer à un projet, Gerrit est plus simple et direct par rapport à GitHub.
GitHub nécessite de :
- forker le projet
- cloner le projet
- créer un commit
- pousser sur le projet forké et
- faire une demande de PullRequest
Avec Gerrit, vous pouvez seulement :
- cloner le projet
- créer un commit
- pousser pour une revue de code
Du point de vue de l’expérience utilisateur, il est clair que Gerrit a été écrit pour les développeurs par les développeurs: l'expérience utilisateur actuelle est basé sur GWT et n'est ni aussi jolie, ni aussi élégante que celle de GitHub. Le côté positif, c’est la capacité de personnalisation de Gerrit grâce à CSS et des plugins qui le rendent plus adapté aux grandes entreprises qui ont besoin d'intégrer Gerrit avec leur écosystème : le “look and feel” doit alors être en accord avec la charte graphique de la marque plutôt qu’avec celui de GitHub.
InfoQ : Qui est en train d’adopter Gerrit ? Qui est impliqué dans le développement du projet ?
Luca : Gerrit est la norme de facto pour les grandes entreprises, les secteurs des télécommunications, du mobile, des micro puces tels que Motorola, Sony Mobile, Intel et Qualcomm aux grandes usines de logiciels comme SAP et HP et même plus récemment des grandes banques. Gerrit a été fondé initialement par Shawn Pearce (Google) comme outil de développement pour Android, parce que les outils de contrôle de version utilisés en interne à Google n'étaient pas appropriés pour les contributeurs externes. Ensuite, les entreprises qui contribuent au développement de l'écosystème Android, comme Qualcomm IC et Sony Mobile, ont commencé à contribuer au développement de Gerrit pour mettre en commun dans la Communauté OpenSource les améliorations apportées localement. Un soutien important est par la suite venu de SAP et d'autres entreprises axées non-Android comme Spotify. Gerrit a maintenant plus de 80 contributeurs venant même d'autres initiatives Open Source, grâce à son adoption dans des projets importants tels qu’Eclipse, Wikipedia, LibreOffice et Openstack.
InfoQ : Qu'est-ce qui vous a décidé à écrire un livre sur Gerrit ?
Luca : Après avoir travaillé pendant plus de 2 ans sur ce projet, j'ai compris le potentiel et la valeur potentielle de cet outil, qui n’étaient pas mis à profit par la plupart des gens qui le regardaient de l'extérieur. La documentation de Gerrit a toujours été très compréhensive mais trop technique pour un novice. Cela a donné la fausse impression que "Gerrit est cool mais difficile à installer et à utiliser". Je voulais démonter le mythe et montrer comment vous pouvez commencer à partir de zéro connaissances de Gerrit et obtenir des configurations prêtes à l’emploi après seulement un week-end de lecture. Être obligé d’écrire moins de 150 pages était un gros défi, et un pavé de 500 pages aurait été un exercice beaucoup plus simple! D’après les premiers retours que j’ai eu, il semble que l'objectif de l'ouvrage ait été réalisé. J'espère que le livre va accroître la popularité de Gerrit et va encourager les gens à l’utiliser, voire à y contribuer.
InfoQ : Pourquoi avez-vous créé GerritForge? Qui y est impliqué?
Luca : Nous avons changé le nom de notre société LMIT pour GerritForge en 2011, lorsqu'il était clair que l'avenir d'Agile ALM (notre entreprise initiale) était guidé par les revues de Code et le déploiement continu: nous avons investi dans le développement et les services Gerrit et il était alors naturel de refléter cette mise au point dans le nom de l'entreprise. Au sein de GerritForge, il y avait la convergence et l'expérience de LMIT Ltd et Louis UrbanLtd, deux sociétés de conseils, spécialistes du développement logiciel et de l’Agile.
InfoQ : Comment le London Gerrit Hackathon s’est-il créé ? Était-ce un succès ?
Luca : La proposition d'un Gerrit Hackathon est sortie en 2012, proposée par la European Gerrit Contributors venant d'Allemagne, de Suède et du Royaume-Uni. La proposition fut bien accueillie aussi bien par les membres du projet basés aux États-Unis que ceux en Extrême-Orient. Google aussi, était heureux de montrer par des faits concrets que Gerrit n'était pas un «business privé» destiné à Android, mais une plateforme de coopération Open Source en bonne santé, à l'échelle mondiale, ouverte à l'innovation de chacun. Je pense que c'est le principal avantage d'une plateforme telle que Gerrit par rapport à d'autres initiatives populaires, mais fermées.
InfoQ : Quand aura lieu le prochain Hackathon ?
Luca : Le prochain Hackathon et la conférence des utilisateurs de Gerrit aura lieu au début du printemps 2014, probablement dans les locaux de Google à Mountain View. Et il existe aussi une proposition pour le premier Hackathon à Tokyo organisé par Sony Mobile. Selon Indeed.com, l’essor de Gerrit est à venir et je suis sûr que le nombre de participants des prochaines conférences augmentera de manière significative en 2014 et au-delà. L'introduction de plugins initialement proposée par GerritForge en 2011, et maintenant entraînée par la communauté, a augmenté la capacité d'intégrer Gerrit dans l'écosystème de déploiement continu ou de gestion de cycle de vie des applications. Je suis convaincu que cela améliorera la façon dont nous travaillons et coopérons dans le cycle de développement Agile !
Note: Learning Gerrit Code Review est publié aux édition Packt, qui est aussi l'éditeur du livre d’Alex Blewitt : Eclipse Plug-in development book.
À propos de l’Auteur
Luca Milanesio est le directeur et cofondateur de GerritForge, le leader des centres de compétences Git et Gerrit pour l'entreprise. Il a plus de 20 ans d'expériences dans la gestion de développement, la gestion de configuration logicielle, et le cycle de vie de développement de logiciels dans les grandes entreprises à travers le monde. Luca Milanesio est l'auteur de "Git Patterns and Anti-Patterns", un guide indispensable pour échelonner Git en entreprise avec 16 patterns et anti-patterns.