Les liens de la semaine – Édition #76

Développement

.NET

Web

Technologie

Science et autres

Les liens de la semaine – Édition #71

Développement

.NET

Technologie

Web

Science et autres

Histoire vécue – comment ne pas gérer son historique de développement Git

Depuis l’automne passé, les équipes de développement chez Absolunet utilisent Git à temps plein. Sans réserve, je peux dire que l’on vit le rêve Git à temps plein. Branches à volonté et modèle de travail asynchrone et déconnecté sont au rendez-vous. 

Ce que je suis sur le point de documenter est un truc que j’ai dernièrement sorti du derrière de ma manche afin de me sortir du pétrin. Lorsque je dis que je me suis sorti du pétrin, il s’agit de se mettre dans le même état d’esprit que l’image ci-dessous.

shoot
Résolution de problèmes informatiques

Rien n’arrive pour rien dans ce beau monde. La réalité vient parfois vous frapper en plein visage. Dans mon cas, il s’agit de la réintégration d’une branche restée en développement pendant trop longtemps sans être réintégrée graduellement.

Je peux vous dire que ça a été pénible jusqu’à la mise en ligne.

Un seul commit

En théorie, il ne devrait pas y avoir d’obstacles à réintégrer une branche, peu importe la période de temps où le développement s’est fait en parallèle. Point à la ligne. Les révisions branchées sont appliquées par-dessus celles où vous désirez réintégrer. Validez les conflits, testez votre code et c’est la fin de l’histoire.

Là où la réalité est venue me rattraper, est que lors de la réintégration de cette branche, une très grande majorité des fichiers nouvellement ajoutés lors du développement en question était considérée en conflit. Cela ne devrait pas se passer ainsi, n’est-ce pas?

Or, il s’avère que la source de cet incident est relativement anodine, mais a une importance capitale. Par erreur, une réintégration de la branche de développement avait été effectuée et soumise à l’historique de développement commun. Lorsque nous avions réalisé notre bourde, le commit en question avait été annulé (revert).

Vous me voyez venir? Tous les changements, même s’ils sont des fichiers nouveaux vis-à-vis la branche dans laquelle je tentais de réintégrer, puisqu’ils avaient été précédemment annulés Git ne pouvait déterminer ce qu’ils devaient conserver comme modification.

Ce qui fait mal dans toute l’opération est le volume de fichiers à résoudre. Il y en avait des centaines. En plus de cela, les changements étaient dispersés à travers quelques centaines de commits et une bonne proportion d’entre eux contenaient des changements mixtes. C’est à dire des fichiers qui avaient évolué à la fois sur la branche stable et celle de développement.

Aux grands maux, les grands moyens

Je ne vais pas raconter d’histoire. La solution que j’ai retenue est loin d’être élégante et très loin d’un modèle reposant sur les bonnes pratiques du versionnage de code source.

Ce que j’ai fait ressemble à ça :

  • prendre une copie de la branche master
  • coller son contenu dans ma branche de développement.

Je dois avouer que ce n’est pas très élégant.

Toutefois, avec tout cela, mon problème de réintégration de branche n’est pas résolu. Considérant que j’ai réintégré manuellement le contenu de ma branche, il faut soumettre ces changements à l’historique public.

Pour y arriver, il faut forcer un push de l’historique de développement de la branche master afin qu’elle pointe sur le plus récent commit de l’historique. Ceci se fait en deux étapes : 

Vous devinerez que l’image choisie en préambule est drôlement appropriée pour cette opération en particulier. Une fois cela réalisé, le tour est joué et vous pouvez aller prendre un café!

Astuce git : comment intégrer la révision courante à la DLL de son application

Vous vous souvenez de mon billet au sujet de l’extraction de la révision courante d’un repository git et de l’enregistrer dans un fichier texte prêt à déployer?

Ce n’est pas vraiment un problème lorsque vous utilisez une automatisation des déploiements pour votre application. Dans le cas où vous n’en avez pas, cela implique que vous devez manuellement déployer ce fichier. Les chances de l’oublier sont relativement grandes.

L’alternative à cette solution est de permettre d’inclure cette information dans le fichier AssemblyInfo.cs de votre application. Cela aura pour principal effet de pouvoir consulter cette information à même les propriétés de la DLL de votre site web. Si cela se fait implicitement, vous n’avez aucune chance de passer à côté.

Il n’y a pas de solutions parfaites. Celle-ci implique que vous avez deux options pour récupérer la révision git utilisée sur votre site en ligne.

  1. Télécharger la DLL de votre site localement et consulter les propriétés de celle-ci.
  2. Développer une page web vous permettant de consulter les propriétés de votre DLL.

La dernière option est élégante, mais ne fonctionnera pas si votre site est mort. Il s’agit du principal désavantage, à mon avis. Toutefois, il s’agit d’un compromis avec lequel je suis à l’aise de vivre avec.

La façon d’y arriver est exactement la même que dans le billet cité en introduction. Il suffit d’inclure un script PowerShell à l’événement de précompilation de votre projet et le tour est joué. Cependant, vous devinerez que le script à utiliser est sensiblement différent.

Dans l’ordre, il faut réaliser les étapes suivantes pour être en mesure d’inclure le numéro de la révision git à la DLL de son projet.

  1. Mettre la main sur le script PowerShell suivant : https://github.com/pparadis/FrenchCoding/blob/master/GitVersionLogger/Build/git-version-extract.ps1
  2. Ajouter la commande suivante à l’événement de précompilation de votre projet : powershell.exe $(ProjectDir)\Build\git-version-extract.ps1 -FilePath $(ProjectDir)
  3. Compiler

Si vous allez consulter les propriétés de votre DLL, vous allez maintenant avoir des informations ressemblant à ceci :

dll-git-properties

Dans la propriété File description, on peut y voir, dans l’ordre, les informations sur la date, la branche utilisée ainsi que la révision utilisée, dans son format court. D’ailleurs, à ce sujet, la mention dirty dans le numéro de révision indique que des changements n’étaient pas versionnés au moment de récupérer le numéro de version.

Avoir une stratégie de gestion pour ses branches git

branchAfin de pleinement profiter des fonctionnalités offertes par git, il faut un peu structurer son utilisation. En plus de sa rapidité d’utilisation, le principal avantage de son utilisation est relié à sa capacité de gérer de multiples branches parallèlement et de permettre l’échange de l’historique de développement entre chacune d’elles.

Ce billet est le fruit direct d’une réflexion tirée d’un projet assez complexe sur lequel j’ai mis en place une stratégie de branchage et de déploiement tirant profit de git.

Anciennement, nous utilisions Subversion afin de gérer l’évolution des sources de nos projets. Heureux hasard, notre hébergeur de sources impose une migration à git pour l’automne. C’est de cette façon que git est arrivé dans le portrait.

Vous l’avez probablement vécu. L’histoire est toujours la même. Le travail concurrent sur un projet souvent annonce une source potentielle de conflits dans le code et perte de productivité potentielle en raison d’une erreur ou d’un oubli. C’est pour cette raison qu’il faut structurer l’utilisation de git. D’avoir une stratégie pour la gestion des branches pour votre projet.

En une phrase, avoir une stratégie de branchage git revient à savoir quoi mettre où, au bon moment. Il faut cependant savoir qu’une recette peut ne pas fonctionner pour tous les scénarios. Le moule ne fonctionne pas toujours pour tout le monde.

Lorsque vous utilisez git, le principal intérêt est d’être en mesure de tirer profit de la capacité de git à gérer efficacement plusieurs branches de développement simultanément. Cela veut dire qu’avec git, vous pouvez dire au revoir au modèle de développement utilisant un nombre limité de branches.

Les règles que j’ai mises en place dans notre équipe de développement sont basées sur le principe que les développements à compléter sont d’une durée variable et que leur date de mise en ligne n’est pas fixée dans le béton. Cela veut dire que nous devons travailler parallèlement et sans créer de dépendances entre les différents livrables.

  • Une branche doit être créée par par fonctionnalité à livrer ou user story (pour ceux utilisant une méthodologie agile).
  • Vous pouvez créer des branches locales pour le développement de petits segments de fonctionnalités ciblées comme les sous-tâches, par exemple.
  • rebase d’une branche locale avant le merge dans la branche principale peut-être réalisé, mais n’est pas obligatoire.
  • Réaliser un pull des branches sur origin au moment jugé opportun ou à volonté.
  • Une branche par étape de déploiement est créée : zone de développements, démo, staging ou production.
  • Les tags sont encouragés pour signaler l’évolution de la livraison de votre site.
  • Le merge d’une ou des branches sera réalisé sur master uniquement lorsque la mise en ligne est complétée.
  • Lorsqu’une branche a subi son merge final, sur master, elle peut être supprimée définitivement.

Avec ces règles, vous pouvez travailler à plusieurs sur le même projet sans que vos développements nuisent à ceux des autres. Depuis que nous l’avons implanté dans notre équipe, la capacité à gérer de multiples développements en même temps sur un site a augmenté. Nous sommes maintenant en mesure de développer en se souciant uniquement de l’intégration de nos changements au moment de les intégrer sur la zone de développements.

L’autre point positif est que nous avons introduit la notion de planification de la livraison de nos changements lorsqu’il est temps de définir les livrables pour la période à venir. Avec cette façon de penser la gestion de nos changements, il est maintenant plus évident de discuter du séquencement des demandes à venir et de la façon de les mettre en ligne.