Archives de catégorie : Développement

[Tips] Erreur ANDROID_HOME is not set lors du zipalign d’un package Xamarin Android

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

image

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 Smile

[Tips] Signature package Xamarin Android en erreur : jarsigner failed ENOENT

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

image

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 :

image

Redémarrez ensuite les services windows correspondant à vos agents de builds afin que cette modification soit prise en compte.

[Tips] Arrêter une collection TFS afin d’indiquer un message de coupure de service

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 :

image

Lorsque vous l’arrêtez vous pouvez saisir un message d’information à destination de tous les utilisateurs de cette collection :

image

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 :

image

Nouveautés de Visual Studio 2017 : #3 Améliorations sur l’integration continue

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 :

image

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 :

image 

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

Nouveautés de Visual Studio 2017 : #2 Nouveautés liées au debogage

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.

Améliorations pour s’attacher à un process

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 :

image

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.

Run To Click

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 :

RunToClick

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.

Deboggage Client Side sous Google Chrome

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 :

image

Nouveautés de Visual Studio 2017 : #1 Chargement léger des solutions

1er post d’une série sur les nouveautés de Visual Studio 2017 : Le chargement léger des solutions.

Si vous travaillez régulièrement avec des solutions comportant un grand nombre de projets (je suis toujours surpris de voir que certaines équipes travaillent avec des solutions contenant plus de 50 projets (!!) Sourire), voici une première nouveauté qui pourrait vous faciliter grandement la vie.

Visual Studio 2017 propose un nouveau mode de chargement de solutions qui permet de faire du chargement de projet en lazy loading. Ainsi, plus de perte de temps à attendre le chargement par VS de l’intégralité de la structure de l’ensemble de vos projets, vous pouvez plus rapidement vous mettre à l’oeuvre.

Pour des raisons de compatibilité (afin de ne pas avoir d’impact avec des plugin tiers qui s’attendent à avoir accès à l’intégralité des infos de l’ensemble de vos projets/fichiers, vous pouvez activer cette fonctionnalité dans les options de VS 2017 :

image

Lorsque cette nouvelle option n’est pas activée, vous arrivez avec le fonctionnement classique et un certain temps de chargement :

FullLoading

Une fois activé, vous pouvez constater la différence sur la vitesse d’ouverture de votre solution :

Lightweight

Chaque projet ne sera chargé qu’à la demande lorsque vous y accèderez depuis l’explorateur de solution.

Bye, bye les builds XAML !

C’est enfin officiel, nous avons à présent le planning définitif de l’arrêt du support des builds XAML au sein de Team Foundation Server et de Visual Studio Team Services.

Comme vous le savez, Microsoft a ajouté à partir de TFS 2015, une refonte complète du moteur de build serveur intégré à TFS, afin de ne plus utiliser celui basé sur les définitions de builds construites en XAML.

image

L’idée était simple : proposer un système de build beaucoup plus simple à personnaliser, extensible, et multi-plateforme.

Alors que les deux systèmes cohabitent encore jusqu’à aujourd’hui, Microsoft vient de publier le planning de l’arrêt du support des builds XAML. Tenez en bien compte pour migrer l’ensemble de vos définitions de builds si ce n’est pas encore fait !

En résumé pour Team Foundation Server (On-Premise) :

  • Dans TFS 2017, possible d’utiliser des builds XAML en utilisant un agent de build TFS 2015,  TFS 2017 n’étant pas livré avec un agent compatible
  • Dans la prochaine version majeure, plus de support des builds XAML, ni en intégré, ni via un agent TFS 2015

En résumé pour Visual Studio Team Services :

  • Arrêt du support des agents XAML au 1er Juillet 2017, si vous souhaitez utiliser des builds XAML à partir de cette date vous devrez installer votre propre serveur de builds privé.
  • Fin 2018, arrêt total du supports des builds XAML

Pour plus d’infos :  https://blogs.msdn.microsoft.com/bharry/2017/05/30/evolving-tfsteam-services-build-automation-capabilities/

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

Siren of Shame reste bloqué sur “Attempting to connect to server”

Ou comment se laisser abuser par un message d’erreur…

Siren of Shame est un logiciel de suivi de Builds qui vous permet d’être notifié du démarrage des Builds, du bon déroulement ou des échecs de Builds directement depuis la SysTray.

De plus, bonus non négligeable, il permet de se connecter à une sirène USB afin de signaler de manière visuelle et sonore, qu’il y a un problème.

J’ai décrit plus longuement ce système via ce post : http://patricelamarche.net/the-siren-of-shame/ 

image

Depuis quelques jours, je restais bloqué sur une erreur de connection, SoS m’indiquant en continu “Attempting to connect to server”.

Après désinstallation/réinstallation, session de sniff via Fiddler afin de déterminer la source du problème de connectivité, la solution a été beaucoup plus simple : Aucune des builds enregistrées n’était valable car je les avais renommés quelques jours auparavant. Au lieu d’indiquer un problème avec les définitions de Build, SoS me dirigeait donc vers une mauvaise direction.

image

Comment fonctionne le versionning de base de données ?

J’ai récemment décrit comment mettre en place de l’intégration continue afin d’intégrer automatiquement les modifications de schéma de bases de données sur des bases de données de test par exemple.

On m’a à cette occasion très justement indiqué que j’aurais pu décrire comment fonctionne le versionning de base de données.

Je vais donc décrire via ce post comment gérer dans un SCM une base de données, et je vais l’illustrer via l’utilisation de RedGate SQL Source Control. Les principes fondamentaux restent identiques pour les autres outils de la catégorie.

Cet outil peut être utilisé avec différents SCM : SVN, Git, Mercurial et bien évidemment avec TFS.

Une fois installé, vous disposez d’un nouvel onglet dans SQL Server Management Studio, celui-ci vous permet d’effectuer les principales tâches de gestion de version d’une base de données :

  • Définition du lien avec le SCM de votre choix
  • Opérations Get Latest et Commit

Première étape à réaliser donc, établir le lien entre une base de données et votre SCM :

image

A noter que ce lien étant stocké sur la machine où il est réalisé, il doit être réalisé sur chaque poste de développement.

Une fois le lien effectué, RedGate SQL Source Control va scruter en continu les modifications effectuées sur votre base de données. Il sera ainsi capable de vous indiquer les modifications effectuées lorsque vous souhaiterez faire un commit.

Le développeur peut donc effectuer les modifications qu’il souhaite sur sa base et va ensuite être capable de faire un commit dans le source control de ses modifications.

A noter qu’afin d’être capable de stocker les informations de schémas d’une base de données dans n’importe quel SCM il faut être capable de créer un ou plusieurs fichiers représentant ce schéma.

La plupart des outils de versionning de bases de données fonctionne de la même manière.

Un des objectifs de la mise en place de versionning étant la capacité de recréer from scratch une BDD propre, les outils crééent un script de création de chaque “objet” (Table, Vue, Procédure stockée, Trigger, etc.) et stockent ces fichiers dans le repository.

Ainsi le premier commit effectué depuis RedGate génère la structure suivante dans le source control :

image

Un petit tour dans le dossier de définition des tables et nous retrouvons notre table de test stockée sous forme de fichier .sql :

image

Ce fichier SQL contenant le script de création de la table avec l’ajout du champ et de la clé primaire :

image

A chaque modification de schéma, l’outil de versionning de BDD va ainsi générer le même script de création mis à jour en fonction des modifications de schéma effectuées. Ainsi un ajout de champ “nom_test” génère une nouvelle version du fichier Test.sql :

image

 

Vous retrouverez également ces scripts directement dans SQL Source Control lorsque vous effectuerez un GetLatest :

image

Bien évidemment, lorsque l’on effectue ce GetLatest, RedGate SQL Source Control ne vas pas bêtement remplacer la table en exécutant directement le script de création présent dans le source control mais il va générer un script de modification adéquat  afin de préserver les données présentes :

image

Cette génération de requête à partir du diff de deux requêtes de création est d’ailleurs la seule partie complexe de ce type de logiciels.