Vous connaissez la pyramide des besoins de Maslow? Comme le dit Wikipédia, il s’agit de la représentation, sous la forme d’une pyramide, de la hiérarchie des besoins. Selon la théorie, vous devez satisfaire les besoins des paliers du bas afin de pouvoir penser au niveau suivant.
Il est important de pouvoir combler ses besoins primaires afin de progresser. L’analogie de la pyramide a permis de définir beaucoup d’aspects de la psychologie de l’humain. Dans beaucoup de cas, vu que l’acte du développement logiciel est aussi fait par des humains, je crois que la même analogie s’applique pour le développement.
Confiance
Le lien de confiance entre un programmeur et son gestionnaire de code source est primordial.
Elle doit faire foi de tout.
Êtes-vous déjà retrouvé dans une situation où vous devez mettre à jour une application en production et de réaliser que ce qui est en ligne n’est pas à jour avec vos changements? Ou même que vous l’avez appris une fois vos changements en production, car votre application est maintenant hors d’usage? Douloureux, n’est-ce pas?
C’est à ce moment que vous devez retourner en arrière et tenter de deviner ce qui s’est passé.
Laisser un indice
Lorsque vous êtes un développeur ASP.NET, comme moi, il n’y a pas beaucoup de mécanismes naturels vous permettant de déterminer la version de votre application. Tout ce que vous avez à portée de main est la taille du fichier DLL principal de votre application web et la date de mise à jour de celle-ci.
Ces données ne vont pas très bien lorsque vous n’êtes pas le seul programmeur sur un projet. Il est très difficile de déterminer ce que contient votre application et qui l’a mis à jour.
C’est à cet instant précis que doit intervenir votre gestionnaire de code source, car il est possible d’extraire la version associée aux changements que vous avez en main, de les incruster à votre projet et de les consulter à partir de votre application.
Dans ce cas-ci, le sujet sera abordé en utilisant SVN. Toutefois, sachez qu’il est possible de le faire avec n’importe quel gestionnaire de code source.
La recette
Premièrement, si vous êtes du type visuel, le projet que j’ai utilisé afin de préparer cet article est accessible ici : https://github.com/pparadis/FrenchCoding.SVNVersionLogger/. La magie va s’opérer uniquement lorsque la solution sera intégrée à un repository Subversion.
Ce que je désire accomplir est de pouvoir enregistrer la révision SVN du moment au moment où le projet sera compilé. Cela sera possible en tirant profit de l’événement précompilation mis à notre disposition. La solution que j’ai trouvée à mon goût assume que vous avez déjà à portée de main une installation de TortoiseSVN. Que vous l’utilisiez ou non, il y a un seul exécutable (SubWCRev.exe) et cinq librairies qui vous seront nécessaires.
SubWCRev.exe permet l’analyse d’un repository SVN et de permettre d’y inscrire certaines informations dans un fichier texte en se basant sur un gabarit qui lui sera fourni. Par exemple, dans le cas qui nous intéresse, nous allons utiliser la valeur $WCREV$ afin de récupérer la révision du jeu de changements que nous avons en main.
Pour arriver à faire cela, voici les étapes :
- Copier les fichiers nécessaires pour le fonctionnement de SubWCRev.exe dans votre solution. Moi j’ai utilisé le répertoire /lib/tortoisesvn.
- Accéder au panneau de configuration des Build Events et inscrire la ligne suivante dans la boîte de texte Pre-Build event command line : $(ProjectDir)lib\tortoise\SubWCRev.exe $(SolutionDir) $(ProjectDir)version.tmpl $(ProjectDir)version.txt.
- Compilez votre projet.
Note : L’étape #2 assume que, dans votre projet, il y a un fichier nommé version.tmpl qui contiendra le fichier gabarit pour générer le fichier final.
Au final
Lorsque le projet sera compilé, un fichier version.txt sera créé et mis à jour. Le contenu du fichier sera le suivant : 0-1.0.16-2013/05/05 14:54:37 .
Les informations, qui sont séparées par un trait d’union, permettent de déterminer les informations suivantes :
- Est-ce qu’il y avait des informations qui n’avaient pas été soumises au serveur (1 ou 0)
- Le numéro de la révision en vigueur lorsque la compilation a eu lieu. Dans ce cas-ci, dans le numéro de version 1.0.16, le 16 est le numéro de révision SVN.
- La date de la compilation.
Notez que ces informations ont été inscrites dans un fichier texte brut afin d’être en mesure d’y accéder même lorsque l’application web est hors-ligne. Il est possible d’en générer un fichier AssemblyInfo.cs pour que votre DLL y contienne le numéro de version, par exemple.
French Coding 