Sortie de Gitblit 1.4.x

Gitblit est un outil de gestion de dépôt Git, à l’instar de Gitosis ou Gitolite. L’idée est de permettre de partager ses dépôts, gérer des droits d'accès, fournir des sauvegardes… tout en restant dans les murs de l’entreprise si nécessaire.

Pour les entreprises, justement, qui n’ont pas toujours de compétences Rails ou de culture des clefs SSH, Gitblit possède certains atouts. Au niveau administration, avec une application légère en Java, autonome ou hébergeable dans un Tomcat ou dans le Cloud.
Au niveau de la gestion des utilisateurs, Gitblit offre, au choix, des solutions généralement appréciées des entreprises : LDAP ou Active directory avec gestion des habilitations basée sur les groupes, Windows, PAM, Conteneur type Tomcat ou personnalisé. La gestion par clefs SSH sera apportée par la version 1.5.

Associé aux autres fonctionnalités plus courantes, Gitblit offre la possibilité de mettre en place un Github-like dans son entreprise.

Sommaire

• Fonctionnalités précédentes
  • Gestion des Hooks
  • Fédération et réplication
  • Divers
• Nouveautés majeures apportées par la version 1.4.x
  • Tickets
  • Workflow de collaboration (pull-request)
• Licence et Contribution

Fonctionnalités précédentes

Gestion des Hooks

Un mécanisme de Hook (ou Trigger) est accessible, permettant de scripter des actions lors d’un push. Ils se programment en Groovy et ont accès au cœur de l’application. Quelques lignes suffisent donc pour créer une interaction avec une intégration continue ou une gestion de ticket. Des exemples utilisables sont fournis, entre autres, avec Jenkins ou Redmine.

Un aspect intéressant, c’est qu’il est possible de définir des Hooks systématiquement exécutés (comme avec Subversion) pour une intégration avec Jenkins, mais également des Hooks activables à la demande et par projet dans l’interface. C’est le chef de projet qui choisit la gestion de tickets utilisée sur ce projet.

Fédération et réplication

Un système complet de fédération de serveurs est utilisable. Les objectifs possibles peuvent être, par exemple, d’avoir un miroir permanent sur un autre site afin de permettre une reprise d’activité rapide en cas d’incident (PRA).

Ou, autre cas d’entreprise pour les grosses structures, d’avoir un dépôt dans chaque site ou ville, consolidé au niveau national.

Divers

Quelques autres fonctionnalités intéressantes :

• possibilité de n’être qu’un simple visionneur de dépôt d’un autre service Git, comme Gitolite avec SSH, ou Gerrit ;
• une indexation Lucene pour faire des recherches performantes sur un ensemble de dépôts ;
• des menus personnalisables pour les clients Git utilisables dans l’entreprise ;
• une API JSON-RPC, qui sera d’ailleurs largement complétée avec la version 1.5, afin de permettre des workflows avancés, comme des acceptations partielles par Jenkins de pull-request.

Nouveautés majeures apportées par la version 1.4.x

Tickets

Une gestion de Tickets similaire à GitHub/BitBucket a été implémentée mais un peu différemment. Il n’y a pas de distinction entre un ticket et un pull request.

Chaque ticket peut avoir un ou plusieurs commit(s) lié(s) à une branche et il n’y a pas nécessité de créer plusieurs tickets pour différentes versions (forks) du même code.

Au niveau de Gitblit, la conception tourne autour de quelques principes :

• gestion simple pour tracer les actions ou les rapports d’utilisateurs ;
• chaque ticket peut contenir des commits partagés par un contributeur ;
• le ticket doit être la source canonique de commits lié au ticket (et non les commits d’un fork) ;
• les contributeurs supplémentaires d’un problème doivent pouvoir développer des ensembles de patches pour un ticket, et non seulement le créateur du ticket. Le ticket rassemble donc l’ensemble des contributions et non seulement une revue de code ;
• pas de perte d’historique entre le mainteneur ou contributeurs.

Gitblit a pris son inspiration depuis GitHub, BitBucket, and Gerrit. Les différents mécanismes techniques sous‐jacents ont été implémentés et testés avant de faire les choix définitifs.

Workflow de collaboration (pull-request)

Les pull requests à la manière de GitHub demandent le workflow suivant :

• forker le ProjetA en MonProjetA ;
• cloner MonProjetA sur le poste de travail ;
• créer MonProjetA_Clone:topic_branch et travailler sur la contribution ;
• faire un push MonProjetA_Clone:topic_branch upstream vers MonProjetA:topic_branch ;
• Ouvrir une pull request depuis MonProjetA:topic_branch vers ProjetA:integration_branch ;
• Le propriétaire de ProjetA fait un pull MonProjetA:topic_branch vers ProjetA:integration_branch et inspecte la contribution ;
• Le propriétaire de ProjetA fait enfin un push de la contribution fusionnée vers ProjetA:integration_branch.

Le flux avec Gitblit ressemble à ceci :

• cloner ProjetA ;
• créer ProjetA_Clone:topic_branch et travailler sur la contribution ;
• faire un push ProjetA_Clone:topic_branch upstream vers ProjetA:refs/for/[new|id] ,
• le propriétaire de ProjetA fait un fetch et un merge de la branche ticket/[id] ;
• le propriétaire de ProjetA fait un push de la fusion vers ProjetA:integration_branch.

Le workflow Gitblit supprime la conception à 4 dépôts de Github (canonique, copie de travail canonique, fork, & copie de travail du fork) au profit d'une à 3 dépôts (canonique, copie de travail canonique, copie de travail du clone).

La conséquence de l’implémentation de Gitblit, c’est que pour le travail d’une nouvelle fonctionnalité donnée, il y a harmonie entre un ticket, les commits dans une branche liée, la contribution à plusieurs sur cette branche, les revues de code (avec notes) et la fusion.

Au passage, on économise les ressources système d’un dépôt supplémentaire et d’une étape dans l’interface Web.

Licence et Contribution

Gitblit est sous licence Apache 2.0 et est développé pour l’instant sur Github. Les contributions sont appréciées, via le mécanisme du fork et pull-request.

Une traduction en français de l’interface est commencée sur le fork listé dans les liens, n’hésitez pas à y contribuer. L’objectif premier est d’avoir une traduction gardant le nom des commandes Git intact et, peut‐être ensuite, une autre plus « québécoise » traduisant intégralement tous les termes. Les gens choisiront.

Aller plus loin

• Site officiel (1013 clics)
• Demo de la prochaine version (533 clics)
• Fork Github pour la traduction française (94 clics)
• Screencast de fonctionnalités liées aux Tickets (125 clics)