Déployer un webjob avec VSTS

Publié par Fabrice Michellonet sous le(s) label(s) , , le 9 février 2018


Si vous avez déjà eu besoin de déployer un azure webjob via vsts, vous avez du tomber sur ce bon blog post de Thomas Hellstrøm. Néanmoins, en suivant telles quelles les instructions de notre ami Thomas, vous risquer de casser la webapp qui host votre webjob.

Ce blog post va prendre la tournure d’une recette de cuisine, d’un pense bête ; cela m’évitera de me reposer la même question dans quelques mois, et j'espère secrètement que cela puisse aider certains d'entre vous.

On commence donc par utiliser la fonction « Publish as Azure Webjob » à partir de Visual Studio 2017.



Pas la peine d’aller au bout du deploy, ce tool va ajouter le package nuget Microsoft.Web.WebJobs.Publish et créer le fichier « webjob-publish-settings.json » dans le répertoire properties de votre projet.

On passe ensuite sur le build sur VSTS. Thomas nous propose de définir les arguments suivants sur la tache msbuild :

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true 
/p:SkipInvalidConfigurations=true /p:Configuration=Release

Notez le paramètre « /p:WebPublishMethod=Package », qui produira un fichier zip.



Et en jetant un œil dans le fichier zip, mauvaise surprise, on est en train de packager le dossier bin avec des dll qui vont venir écraser celles qui appartiennent à la webapp.



Du coup j’vous propose de corriger ça.
On commence par changer les arguments de la tache msbuild.



/p:DeployOnBuild=true /p:WebPublishMethod=FileSystem 
/p:publishUrl="$(build.artifactstagingdirectory)" /p:DeployDefaultTarget=WebPublish 

Ce qui va produire le même contenu que le fichier zip mais directement sur le système de fichier.

Puis on ajoute une tache delete file, qui se chargera de supprimer le dossier /bin que nous voulons éviter de déployer.




Voila, cette fois ci nous y sommes. J’espère que cela pourra vous aider!

VSTS – Quand y’a plus de crédits, y’en a encore.

Publié par Fabrice Michellonet sous le(s) label(s) , , , le 30 janvier 2018

Ça, c’est la poisse: Your account has no free minutes remaining.

Le scénario est à se pendre, tu montes ton projet en intégration continue et après quelques (dizaines) de commit tu te retrouves dans l’impossibilité de complétera une PR ou juste vérifier que le dernier commit n’a pas introduit de régressions.

Du coup je me propose de présenter ici, comment créer à moindre frais un agent de build sur-vitaminé. Et le fait d’avoir une machine un peu costaud, n’est pas un moindre mal ; qui ne s’est pas arraché les cheveux en attendant que l’agent de build hosté veuille bien se lancer et faire son travail… ?

Plutôt que de créer nous même une vm, installer windows, msbuild et tout le nécessaire a un agent de build, on va plutôt utiliser azure DevTest Lab. L’idée est de tirer parti des template de vm qui sont mises a notre dispo.

Après avoir créé votre première instance DevTest lab, on ajoute une vm basée sur l’image Visual Studio Community 2017 (latest release) on Windows Server 2016 (x64).




On va vous demander un login et un mot de passe pour le compte admin de la future vm.
Je vous conseille de stocker votre mot de passe dans le coffre-fort « my secret » pour une plus grande sécurité. (ce n’est donc pas mon mot de passe que vous voyez 😊)

Bon il nous faut maintenant choisir les caractéristiques de la vm. J’ai opté pour 32 GO de ram et 8 vcpu, une D8S_V3, elle ne sera allumée que quelques minutes le temps de faire le build, donc elle ne nous coutera pas bien cher.

Place aux artefacts, il convient de voir cela comme des scripts additionnels qui installeront d’autres programmes/services sur votre vm. Ça tombe bien, l’artefact VSTS Build agent nous procure le service de build qui convient.




Quelques précisions, le champs VSTS account name doit se conformer au pattern suivant : https://{{vsts_account_name}}.visualstudio.com

Le secret correspond une clé privée que vous pourrez crée en vous rendant à l’adresse https://{{vsts_account_name}}.visualstudio.com/_details/security/tokens

Finalement, l’agent pool doit être un pool pré-existant. A vérifier/créer ici : https://{{vsts_account_name}}.visualstudio.com/_admin/_AgentPool

Petit plus, dans le cas ou vous envisagez de builder des projets front, profitez de cette étape pour ajouter l’artefact NODE JS.

Bon, aller y’a plus qu’a cliquer sur OK, attendre quelques minutes et l’agent devrait apparaitre dans le pool que vous avez choisi.



Quoi qu’il en soit pas de panique, si vous vous êtes trompé sur un paramètre des artefacts, il sera toujours possible de retenter l’installation a postériori ou bien de procéder a l’installation manuellement.

Dernier point, si vos crédits azure ne vous permettent pas de laisser cette vm allumée tout le temps, voici deux petites commandes qui vous permettront d’allumer et d’éteindre la vm a volonté. (a utiliser dans une console azure cli

az lab vm {{command}} --lab-name {{devtestlab}} --name {{vm-name}} 
--resource-group {{resource-group}}
command : start ou stop
devtestlab : le nom de votre instance DevTest lab
vm-name : le nom de votre vm
resource-group : le nom du resource group ou est installé la vm.