Turbulences Admin
Turbulences Admin
Agile
6 août 2020

Un NuGet pour les référencer tous

Azure permet de lier un site web avec un projet TFS de façon à pouvoir déployer à chaque check-in. Pas de magie dans tout ça, c’est juste un build qui contient une étape pour déployer. Le build est configuré en mode intégration continue donc déploiement à chaque check-in. C’est un peu extrême mais on peu changer la définition du build pour le faire passer en mode manuel afin de déployer au bon moment (depuis que je fais plus de dossier d’affaires que de code, c’est fou comme j’ai appris à exprimer clairement les idées).

L’avantage de cette façon de déployer, c’est qu’on peut faire un rollback directement à partir du portail Azure. En fait, c’est un nouveau build qui est lancé avec la version des sources qui ont été utilisés dans le déploiement original.

Jusqu’à date, j’étais le seul à développer et déployer des solutions dans Azure pour novIQ, donc je déployais directement à partir de Visual Studio. Mais comme je suis en train de préparer l’environnement de développement novIQ pour travailler en équipe, j’ai décidé d’essayer de déployer avec le build server.

Donc, je suis la recette, je lance le build…. FAILED. Comme si ça allait marcher du premier coup… La cause de l’erreur, c’est une référence que j’ai faite localement; tant que je déployais à partir de mon poste, je ne provoquais pas l’erreur donc j’avais oublié que j’avais une référence locale.

Bon, comment régler ça? Dans un de mes derniers mandats, j’ai eu à monter une solution de build avec TFS. On avait décidé d’inclure dans TFS les binaires et de les référencer à partir de TFS. Comme ça, quand le build fait son « get », il obtient également les binaires et les références se font donc naturellement. Gestionnaire de code source… ça m’a toujours buggé de conserver du binaire dans un gestionnaire de code source. Pour une question de principe et également parce que pour chaque version, on doit stocker le binaire au complet, c’est pas possible de conserver seulement le delta comme pour le code. Mais quand tu ne connais pas d’autre solution, ben tu conservers les binaires dans le gestionnaire de code source.

De retour à mon bug de compilation; je réfère environ une dizaine de bibliothèques externes et le build a fonctionné pour ces références; quel est l’élément commun pour l’ensemble de ces outils? Je les ai inclus dans ma solution par le biais de NuGet. Si ça marche pour références les outils de la planète entière, ça doit bien marcher pour référencer nos propres packages internes.

Google un peu et j’ai suivi la recette de Phil Haack pour monter un feed NuGet et je l’ai déployé sur Azure. J’ai suivi les instructions de cet article pour produire un paquet NuGet pour ma librairie à référencer. J’ai enlevé la référence local, replacé la référence à partir du feed NuGet de novIQ, relancé le build…. SUCCESS!!!

Donc, l’utilisation de NuGet est peut-être la bonne solution pour référencer les paquets, que ce soit pour les librairies open-source ou du marché ou pour les librairies de notre propre organisation. Bon, c’est sûr que ça fait un gros répertoire rempli pour contenir tous les packages de la solution. Et si on a plusieurs solutions qui réfèrent les mêmes packages, le packages va être situé à plusieurs endroits sur le disque du développeur. Non non, c’est pas une raison pour faire une seule solution pour l’ensemble de nos projets. L’espace disque, ça coûte plus rien, donnez en à vos développeurs.

Et bien honnêtement, ça règle pas le problème des binaires dans TFS parce que pour que le build fonctionne, je dois archiver le contenu du répertoire packages dans TFS. La prochaine étape, c’est de réussir à obtenir les paquets au moment de la compilation par le build directement des serveurs NuGet. À suivre….