Vous pouvez retrouver les slides de la présentation que nous avons faite hier soir avec Thomas Bureau du colombier sur la mise en place de Visual Studio App Center au sein de Chausson Matériaux. N’hésitez pas à me contacter pour toute question et/ou feedback sur cette présentation.
Rendez-vous en Septembre pour la rentrée du meetup .net Toulouse.
Si vous développez des applications mobiles avec une des technologies suivantes : Xamarin, Swift, React Native, Objective C, Cordova, ou encore UWP, n’hésitez pas à nous rejoindre le 18 Juin pour une présentation de Visual Studio App Center, la solution DevOps à destination des applications mobiles proposées par Microsoft.
Solution en très grande partie gratuite, j’aurais le plaisir de présenter la simplicité de mise en oeuvre de cette solution, et un retour d’expérience de sa mise en place pour la gestion de 2 applications mobiles développées par Chausson Matériaux.
Pour découvrir comment mettre en place une pipeline CI/CD et faire du monitoring de vos applications mobiles publiques et privées, n’hésitez pas à vous inscrire ici : https://www.meetup.com/fr-FR/Meetup-NET-Toulouse/events/250882280/
J’ai eu le plaisir de présenter hier soir une session au meetup .NET Toulouse sur l’ALM avec TFS/VSTS et plus précisément sur la mise en place de “vraies” pratiques agiles grâce à TFS et VSTS.
Vous pouvez consulter les slides sur mon slideshare :
J’ai rapidement abordé la problématique de mise à jour de schémas de BDD, vous pouvez également retrouver les slides de ma présentation du mois dernier aux Sql Saturdays via ce lien : https://patricelamarche.net/sqlsaturday-slides-de-ma-session-surle-versionning-et-la-mise-jour-de-bdd-avec-readyroll/
Après une session le mois dernier aux SQL Saturdays, j’aurais le plaisir de présenter une session sur l’ALM avec TFS et VSTS, lundi prochain 16 Octobre à la Cantine à Toulouse.
Au programme, retour d’expériences, bonnes et mauvaises pratiques sur la mise en place de différentes pratiques liées à l’ALM :
N’hésitez pas à nous rejoindre pour discuter de ces sujets ! Inscription gratuite ici : https://www.meetup.com/fr-FR/Meetup-NET-Toulouse/events/243940224/
Comme vous avez pu le découvrir via ma série de posts dédié à Docker :
A partir de Windows Server 2016, Microsoft propose une nouvelle édition de Windows nommée Nano Server. Cette édition permet d’avoir une image Docker 10 fois plus légère qu’une image Windows Server Core grâce à un refactoring important et une suppression de tous les services inutiles pour cette édition destinées à être utilisée au sein de conteneurs.
Cela avait été annoncé discrètement durant la Build, puis plus officiellement la semaine dernière, l’investissement de Microsoft continue dans cette même direction et va même plus loin puisque l’éditeur annonce que ses efforts vers cette nouvelle édition sont une priorité, et que la prochaine édition de Nano Server permettra de faire des images plus de 2x plus petites qu’actuellement (actuellement 300 Mo compressée) avec donc à la clé des chargements plus rapides, et bien sûr une densité de conteneurs sur vos machines hôtes plus importante.
Rendez-vous en automne (merci le nouveau rythme de livraison bi-annuel de Windows Server 
) pour le résultat final !
Pour plus d’infos :
Dans la série des erreurs que vous pouvez rencontrer lors de la mise en place d’une build Xamarin Android, après : [Tips] No agent could be found with the following capabilities AndroidSDK, MSBuild, Xamarin.Android, JDK puis, [Tips] Signature package Xamarin Android en erreur : jarsigner failed ENOENT
Le nouvel épisode concerne la tâche de zipalign indispensable l’optimisation de vos packages et pour s’assurer du bon fonctionnement de vos applications sur les devices.
Lors de l’activation de cette tâche sur votre processus de build vous pouvez vous retrouver avec l’erreur suivante :
##[error]ANDROID_HOME is not set
##[error]Return code: 1
Vous l’aurez vite compris, il est ici nécessaire de créer une nouvelle variable d’environnement nommée ANDROID_HOME contenant le chemin du SDK d’Android (ex : C:\Program Files (x86)\Android\android-sdk). Redémarrez ensuite les agents de build pour que la modification soit prise en compte.
A bientôt pour une nouvelle erreur Xamarin 
Lors de la mise en place d’une build Xamarin Android avec Team Foundation Server, vous pouvez vous retrouver avec une erreur lors de l’étape de Signature de votre package.
Une erreur “jarsigner failed. spawn jarsigner ENOENT” peut être levée.
En version détaillée dans mon cas :
##[error]Error: C:\Program Files\Microsoft Team Foundation Server 15.0\Search\Java\jre1.8.0_111\bin\jarsigner failed. spawn C:\Program Files\Microsoft Team Foundation Server 15.0\Search\Java\jre1.8.0_111\bin\jarsigner ENOENT
Comme l’indique l’erreur ENOENT, quelqu’un manque à l’appel, et dans le cas présent c’est tout simplement le jarsigner.exe qui est absent du dossier dans lequel TFS recherche l’outil de signature de package java.
TFS cherche en effet étrangement cet outil dans l’environnement java installé avec Code Search, la nouvelle fonctionnalité de TFS qui permet d’indexer le code présent dans les repositories et d’effectuer des recherches. Cet environnement ne comprenant pas l’outil jarsigner, toute signature est impossible depuis vos builds.
Vous pouvez donc rencontrer un conflit entre la fonctionnalité Code Search et les tâches de signature de Xamarin Android.
Pour corriger le problème, vous devez modifier la variable d’environnement JAVA_HOME afin de l’uniformiser avec vos autres variables liées à Java, dans mon cas :
Redémarrez ensuite les services windows correspondant à vos agents de builds afin que cette modification soit prise en compte.
Si après une migration de votre serveur TFS “On Prem” vers une nouvelle machine (et si vous n’utilisez malheureusement pas d’alias DNS pour accéder à celui-ci) et que vous souhaitez ne pas couper brutalement votre serveur TFS et ainsi laisser l’équipe avec des messages d’erreur bizarres s’ils ouvrent des projets mappés avec l’ancien serveur, vous pouvez utiliser une fonctionnalité de TFS : l’arrêt de collection.
Ainsi même si vous n’utilisez qu’une seule collection de Team Projects vous pouvez tout à fait l’arrêter via la console d’administration de TFS :
Lorsque vous l’arrêtez vous pouvez saisir un message d’information à destination de tous les utilisateurs de cette collection :
Ce message est alors repris dans Visual Studio lorsque vous connectez au Team project, mais surtout également depuis le Team Explorer pour chaque action effectuant un accès serveur à la collection :
S’il y a bien un thème important au niveau des avancées de l’offre ALM de Microsoft il s’agit bien de l’intégration continue et de la livraison voire déploiement en continu.
Nous y reviendrons au travers de plusieurs posts liés à TFS et VSTS, mais commençons aujourd’hui par deux petites nouveautés liées à Visual Studio 2017.
1ère nouveauté qui permettra de combler l’utilisation d’outil tiers tel que le logiciel Siren of shame par exemple, l’intégration d’un notifier de build directement au sein de la barre d’état de Visual Studio 2017.
Ainsi si après un push ou la soumission d’un PR vous souhaitez connaitre l’état de la build liée à votre/vos commits, plus besoin de se déplacer dans le Team Explorer ou encore dans le portail web, vous pouvez travailler sur une autre tâche et attendre patiemment que Visual Studio 2017 vous indique que tout est OK, ou vous signale que vous devez intervenir en urgence pour corriger le tir :
Autre nouveauté pratique, l’intégration de l’error list directement au sein du panneau des modifications de sources. Ainsi les informations de Warning, et d’erreur de compilation sont placées idéalement et mises en avant même que vous effectuiez vos commit :
Ces deux nouveautés sont proposés via une extension qui est pour le moment en preview, et qui sera disponible à terme dans l’édition Entreprise de Visual Studio.
Vous pouvez dores et déjà l’utiliser en l’installant : https://marketplace.visualstudio.com/items?itemName=VSIDEDevOpsMSFT.ContinuousDeliveryToolsforVisualStudio
Que cela soit pour comprendre le fonctionnement du code que l’on vient d’écrire, ou encore comprendre à posteriori les disfonctionnements de celui-ci, nous passons pas mal de temps avec notre ami le debugger.
Visual Studio 2017 propose quelques nouveautés qui, même si elles ne sont pas révolutionnaires, peuvent faciliter la vie au quotidien en fonction de vos habitudes et de vos besoins.
Si vous préférez le Ctrl+Alt+P pour s’attacher à un process existant (et peut être même distant), qu’un simple F5, les nouveautés suivantes vous sont dédiées !
La 1ère évolution se situe au niveau de l’ergonomie, puisqu’il est à présent possible de filtrer la liste des process locaux ou distants afin de trouver plus rapidement le process auquel on souhaite s’attacher :
Enfin deuxième nouveauté, le reattach to process qui permet de ne plus avoir à réouvrir cette même fenêtre pour que le debugger s’attache au “même” process.
Ainsi, un Shift+Alt+P permet de s’attacher automatiquement soit au même process que précédemment (identifié via son PID) ou alors au process portant le même nom ce qui permet d’avoir une souplesse d’utilisation intéressante.
Le Run To Click est une amélioration du Run To Cursor déjà présent dans Visual Studio depuis un certain temps.
Avec cette nouvelle fonctionnalité vous allez pouvoir piloter l’exécution de votre application en débug d’un simple click. Plus besoin d’effectuer plusieurs clicks avec le Run To Cursor, ou alors de créer un 980 ème breakpoint dans votre code pour vous arrêter où vous le souhaitez, un simple click est à présent nécessaire grâce à un nouveau picto présent durant vos sessions de debug :
A noter que cela n’a aucun autre impact sur vos sessions de debug, les breakpoints déjà posés et qui sont atteint durant le parcours du code jusqu’à la position de votre click seront bien évidemment déclenchés. Et vous clickez sur une ligne qui n’est pas atteinte durant l’exécution, il n’y aura pas de magie, vous n’obtiendrez aucune pause d’exécution.
Si vous préférez tout faire depuis VS, et souhaitez avoir la possibilité de ne plus utiliser les outils de dév intégré à Google Chrome, bonne nouvelle : vous pouvez à présent rester sous VS 2017 pour débugger votre code javascript/typescript exécuté par le navigateur.
Cette option est disponible par défaut et vous pouvez la définir au même endroit qu’habituellement :
