Processus recommandé pour les revues de code avec Mercurial

Nous avons généralement utilisé Perforce et SmartBear's Code Collaborator chez Big Corpet maintenant nous allons également utiliser Mercurial pour certains projets.

Code Collaborator prend en charge Mercurial (nous utilisons la version 5) et j'essaie de déterminer quand le meilleur moment (pendant le commit / push vers le serveur) est le meilleur moment / efficace pour une revue de code

Merci

En fait, nous avons vécu presque la même chose récemment dans mon entreprise. Voici ce que nous avons fait:

• Nous conservons une copie centrale définitive de tous nos référentiels sur un seul serveur. Lorsque les développeurs souhaitent "extraire" du code, ils se rendent sur ce serveur et clonent à partir des référentiels qui s'y trouvent. De même, lorsque le cycle de développement est terminé, le code est également poussé dans le référentiel approprié.

• Nous séparons les référentiels stables des référentiels de développement . Nous exigeons que le code soit revu avant d'être poussé dans un référentiel stable. (Ceci est important car nous exigeons également que nos référentiels stables contiennent le code qui est actuellement en cours de production, ne différant que par les promotions de code en attente.)

Pour appliquer la révision du code, nous avons écrit un pretxnchangegrouphook (documenté dans le livre HG ). Nous tirons parti du fait que lorsque ce hook s'exécute, il peut voir le référentiel comme si les modifications de code étaient permanentes, mais nous donne également la possibilité d'empêcher la transmission. Fondamentalement, le processus est le suivant:

1. Le développeur lance une poussée vers le référentiel stable (oui, c'est vraiment la première étape)
2. Le hook s'exécute et récupère une liste de tous les ensembles de modifications inclus dans la transaction (en exécutant le journal HG). Il interroge ensuite une base de données que nous avons créée pour voir si ces changements ont été inclus dans une révision de code. (Le tableau correspond au hachage d'un ensemble de modifications avec un ID de révision de code).
   • Si c'est la première fois que l'un de ces ensembles de modifications est vu, nous créons une nouvelle révision de code (à l'aide de la ligne de commande Code Collaborator), puis enregistrons ces ensembles de modifications dans la base de données avec l'ID de cette révision de code.
   • Si nous avons vu certains (mais pas tous) des changements, nous exécutons la commande (Code Collaborator) pour attacher les nouveaux changements à la révision existante et enregistrer ces nouveaux changements dans la base de données.
   • Si toutes les modifications ont été trouvées dans la base de données (c'est-à-dire qu'elles ont toutes été ajoutées à la révision du code), nous vérifions que l'état de la révision du code est terminé. Cependant, s'il y avait de nouveaux ensembles de modifications (ou la révision du code n'est pas terminée), le hook se termine avec un code d'état différent de zéro (obligeant Mercurial à annuler la transaction) et génère un message convivial sur l'erreur standard expliquant au développeur que la révision du code doit être terminée.

En substance, cela fournit au développeur un processus assez rationalisé (tout ce qu'ils ont à faire est une poussée hg) et automatise complètement la création de la révision du code (et le téléchargement de fichiers modifiés supplémentaires dans la révision), tout en garantissant que tout le code est examiné .

Remarque: Il s'agit d'un processus assez simple (et relativement nouveau pour nous), il peut donc ne pas fonctionner pour tout le monde, et il peut y avoir des bogues de conception que nous n'avons pas encore rencontrés. Mais jusqu'à présent, cela a très bien fonctionné.

Cela dépend de la façon dont vous avez votre structure de référentiel et de ce que vous essayez d'accomplir. Nous préférons faire des revues «pré-commit», ce qui dans le monde du DVCS signifie vraiment «pre-push». Les DVCS sont plus agréables dans cet environnement (par rapport aux SCM traditionnels) car ils ont une fonctionnalité intégrée pour enregistrer vos modifications locales et récupérer votre espace de travail afin que vous puissiez travailler sur autre chose.

Si vous souhaitez effectuer des révisions post-push, le flux de travail idéal dépend fortement de la structure de votre référentiel. Par exemple, supposons une structure de référentiel qui ressemble à celle discutée dans cet article sur les dispositions de référentiel Git . Dans ce cas, vous souhaiterez peut-être examiner les modifications qui sont fusionnées develop. Les validations individuelles sur les branches de fonctionnalités peuvent ne pas être pertinentes à examiner. De toute évidence, tout hotfixesdoit également être revu en même temps que lesmaster .

Si, au lieu de cela, vous avez une seule branche d'intégration où les gens se connectent directement, vous voudriez revoir toutes les poussées vers cette branche. C'est probablement un peu moins efficace, mais cela pourrait quand même fonctionner. Dans cet environnement, vous devez vous assurer que toutes les modifications qui ont été poussées sont examinées avant de couper une version. Cela peut être plus délicat.

En ce qui concerne b) la seule chose que je suggérerais est d'envoyer directement un e-mail au support SmartBear ([email protected]). Nous (oui, je travaille pour SmartBear) serons heureux de vous aider à résoudre vos problèmes de chemin, mais il n'y a pas suffisamment d'informations dans cette question pour résoudre votre problème. Le processus normal consiste à simplement exécuter le programme d'installation et tout fonctionne correctement. Apparemment, quelque chose s'est mal passé dans ce processus.