Archives mensuelles : janvier 2016

News de la semaine #5

 

image#ALM
VSTS New work item form futures (January 2016)
2016-January 25 Release Notes | Visual Studio Team Services
Getting Started with Selenium Testing in a Continuous Integration Pipeline with Visual Studio – Microsoft Visual Studio Team Services – Site Home – MSDN Blogs
Identities and Work Item Tracking in TFS 2015

#WEB
Running Asp.Net Core with IIS on Nano Server
Announcing TypeScript 1.8 Beta – TypeScript – Site Home – MSDN Blogs
FontAwesome Fonts and Mime Types in IIS and other Web Servers – Rick Strahl’s Web Log

#XAML
Magically format your XAML with XAML Magic (Channel 9)

#CLOUD
Announcing the first Technical Preview of Microsoft Azure Stack

#MISC
Moving to a Plugin-Free Web (Java Platform Group, Product Management blog)

#HUMEUR
How to Use Open Source and Shut the Fuck Up At the Same Time
Why can’t you just communicate properly?

Dépasser les limites de planification de Team Build

Team Build permet de planifier le déclenchement de Builds via un scheduler assez basique :

image

Nous avons la possibilité de planifier à intervalles régulier le déclenchement d’une build selon deux critères : le jour et l’heure.

Impossible donc de planifier depuis cette interface une build afin qu’elle soit déclenchée toutes les deux heures, toutes les demi-journées ou selon des critères plus complexes.

Afin de pouvoir déclencher une build à sa guise il est donc nécessaire d’utiliser une technique. Il est par exemple possible de lancer un build grâce au SDK de TFS, grâce aux services web, ou aux API REST, mais encore plus simplement via l’outil en ligne de commande TFSBuild.exe.

Il est donc possible de programmer vos builds comme vous le souhaitez grâce aux tâches planifiées proposées par Windows !

Exemple de commande :

« C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\TFSBuild.exe » start https://moncompte.visualstudio.com/DefaultCollection TeamProject NomDefinitionBuild /queue

ASP (.net) a un cycle de 6-7 ans

Comme annoncé par Scott Hanselman ASP.net 5 actuellement en RC (et annoncé comme étant “production ready) est renommé en ASP.net Core 1.0.

Le nommage rejoint ainsi celui de .NET Core et se distingue plus clairement d’ASP.net 4.6 en ne laissant pas supposer qu’il s’agit d’une mise à jour de cette version mais bien d’un nouveau produit.

Cela est maintenant bien plus clair et peut donc inquiéter les développeurs qui n’avaient pas encore assimilé ce saut technogique entre ASP.net 4.6 et l’ex ASP.net 5 : “Encore une nouvelle version, qu’il va falloir assimiler, encore des réécritures/refontes/migrations en vue”.

Oui, cela est tout à fait vrai, c’est bien un nouveau produit qui devrait prochainement être disponible en RT(M/W), mais les plus grosses ruptures ne sont pas si fréquentes que cela, si l’on analyse les versions 1.0 de chaque technologie de développement web proposée par Microsoft, on se retrouve avec un cycle plutôt stable de 6-7 ans :

image

Cela peut sembler être une vision un petit simpliste car plusieurs changements ont été apportés notamment entre les différentes versions d’ASP.net MVC mais est quand même représentatif des ruptures auxquelles nous avons eu droit pour le moment.

La solution la plus simple pour définir la version des assemblys générées

Que cela soit pour la maintenance technique ou même pour le support fonctionnel d’un produit, il est souvent important d’être capable d’identifier la version d’une application en cours d’exécution.

Ce numéro de version est souvent défini avec la structure suivante :

Major.Minor.Build.Revision

Pour ma part, j’ai opté pour le nommage suivant :

Année.Mois.Jour.Revision

D’un point de vue technique, il existe plusieurs techniques pour définir le numéro de version des assemblys :

  • Modification Manuelle des fichiers AssemblyInfo (il n’y a donc rien d’automatique)
  • Modification des fichiers AssemblyInfo via une activité MSBuild ou une Activité Workflow Foundation, et pourquoi pas checkin de la modification pour que le source control reflète bien le numéro de version
  • Modification des fichiers AssemblyInfo via un script en pre-build

Et sur cette dernière solution que je vais m’attarder aujourd’hui car elle est très simple à mettre en oeuvre ! Vous pouvez en effet appliquer un numéro de Version à toutes les assemblies que vous compilez en moins de 10 minutes de mise en oeuvre grâce à cette méthode.

L’idée est simple, comme la plupart des systèmes de builds, TFS vous permet d’appeler des scripts batch ou powershell en action pre-build ou post-build.

Dans notre cas, nous allons exécuter un script Powershell qui va effectuer la modification des fichiers AssemblyInfo récupéré via un Get par le processus de Build, fichiers qui une fois modifiés seront compilés de manière traditionnelle.

Afin de récupérer les informations du numéro de Version à injecter, ce script va récupérer quelques variables d’environnement fournis par TFS.

1ère Etape : Mise à disposition du script d’injection de numéro de Version

J’ai indiqué que cette solution était simple et rapide à mettre en oeuvre pour une raison simple : il existe un script Powershell d’injection du numéro de Version prêt à l’emploi et fourni par des MVPs ALM à cet emplacement : https://github.com/tfsbuildextensions/CustomActivities/blob/master/Source/Scripts/ApplyVersionToAssemblies.ps1

Télécharger ce fichier, et faites un checkin de ce fichier dans un dossier sur votre source control afin qu’il soit disponible par votre serveur de build.

2ème Etape : Paramétrage de votre définition de Build

Et enfin dernière étape, rendez vous dans le paramétrage de votre définition de build, et plus précisément dans le paramétrage du process, définissez votre script en pre-build et définissez le format de numéro de version souhaité.

image

Et c’est terminé, lors de votre prochaine Build vous pourrez constater que vos assemblys possèdent bien le numéro de version souhaité.