Archives mensuelles : septembre 2013

Les liens de la semaine – Édition #48

Développement

Web

.NET

Technologie

Science et autres

Advertisements

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.

Les liens de la semaine – Édition #47

Développement

Web

Technologie

Science et autres

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.

Les liens de la semaine – Édition #46

Développement

Web

Technologie

.NET

Science et autres