Ce billet propose une solution pour éviter ces fréquentes modifications.

Le contournement est assez simple : il suffit de

• créer une itération nommée « Current »
• modifier les requêtes « Current » pour pointer vers cette itération
• Ensuite, lorsque l’itération actuelle change, il suffit de déplacer la nouvelle itération sous l’itération « Current » préalablement créée

Info : Le but du jeu n’est pas de compter le nombre d’occurrence du terme itération dans ce billet

Voyons cela en détail :

• Préparation

  1. Création de l’itération « Current » dans TFS

     Ouvrir l’éditeur d’itérations de TFS (la capture d’écran traite de TFS 2013)
     
     Créer une itération nommée « Current » sous Releases.

  2. Edition des requêtes

     Ouvrir le module WIT (WorkItem Tracking) de Visual Studio.
     
     Pour chaque requête traitant de l’itération actuelle, modifier le filtre pour pointer vers « Current »…
     
     Enregistrer

• Lorsqu’une itération débute

  1. Ouvrir l’éditeur d’itérations de TFS (la capture d’écran traite de TFS 2013)
     
     Ci-dessus, l’itération est nommée : « 2015-03-04 Sprint 1″

     
     Déplacer l’itération (drag-drop), de son emplacement vers « Current »
     TFS synchronisera les workitems concernés (modification de l’itération) dynamiquement.

     
     Le résultat…

• Lorsqu’une itération se termine

  Il suffit de déplacer l’itération terminée pour la repositionner sur son parent. Dans mon exemple, Le résultat sera :
  

Enfin, si vous souhaitez ne pas devoir effectuer la phase de préparation à chaque création d’un teamproject, vous pouvez toujours modifier le template TFS afin d’intégrer l’itération « Current » et les requêtes modifiées. Les projets TFS créés intégreront alors la notion d’itération courante et les requêtes liées.

La notion a été trouvé ici : Transitioning Between Sprintsiterations With TFS,

Enjoy !

Solution #1 : Utiliser l’activity présente dans la librairie tfsbuildextensions.
Inconvénients :

• L’utilisation de l’activity est peu documentée… Il convient donc d’ouvrir avec iLSpy l’assembly pour pouvoir la paramétrer.
  Cela pourra faire l’objet d’un autre billet.
• L’implémentation de l’activity impose à la build de ne contenir (au plus) qu’une seule application !

  En effet, la création du package ClickOnce est réalisée à la main.
  Les grandes lignes du processus sont les suivantes :
  1. Copie du contenu du répertoire binaries de la build dans le répertoire du package
  2. Renommage des fichiers en .deploy
  3. Manipulation de Mage.exe pour créer le manifest de déploiement et le signer.

  Etant donné que sous un build TFS, le répertoire des binaries est commun à tous les projets de la build, si votre solution contient plus d’une application, le package ClickOnce généré contiendra également les binaires des autres applications…

  Dans ce cas, il ne vous plus reste qu’à passez votre chemin et à évaluer la solution #2 !

Solution #2 : Modification du template pour ajouter la génération du package ClickOnce par l’appel MSBuild.
Étapes :

1. Configuration ClickOnce dans le projet concerné
   Cela consiste à ouvrir les propriétés du projet, et a paramétrer la publication ClickOnce.
   Ensuite, à exécuter le wizard de déploiement afin de tester le paramétrage, et le corriger le cas échéant.
   Attention a ne pas oublier d’archiver les modifications sur TFS !
2. Trouver les bons paramètres en ligne de commande msbuild
   L’idée est la suivante : il est possible de générer un package ClickOnce à partir d’un appel MSBuild à condition de disposer des bons paramètres.
   La ligne de commande est la suivante (dans mon cas) :
   msbuild  chemin-vers-fichier-projet.csproj
     /t:build;publish
     /p:ApplicationVersion=1.2.3.4
     /p:BootstrapperEnabled=true
     /p:IsWebBootstrapper=true
     /p:Configuration=Release
     /p:ManifestKeyFile=chemin-vers-fichier-signature.pfx
     /p:OutputPath=chemin-vers-repertoire-sortie
     /p:InstallUrl=http://url-installation-clickonce

   /t:build;publish	MSBuild doit exécuter Build et Publish
   /p:ApplicationVersion	Propriété indiquant le numéro de version ClickOnce du déploiement Le format : Majeur.Mineur.Build.Revision
   BootstrapperEnabled	Valeur indiquant si le bootstrapper (setup.exe) doit être généré.
   IsWebBootstrapper	Valeur indiquant que le déploiement ClickOnce doit pouvoir être effectué par le Web (manifeste de déploiement xxx.application)
   Configuration	Valeur indiquant la configuration de build (Debug, Release).
   ManifestKeyFile	Chemin vers le fichier pfx qui signe le manifeste ClickOnce
   OutputPath	Chemin vers le répertoire de destination du package (pour la génération)
   InstallUrl	URL cible de l’installation ClickOnce Ex. : http://server/monapplicationClickOnce

   Attention : Si le fichier de signature a besoin d’un mot de passe, il est indispensable d’installer le certificat de l’autorité racine dans le magasin correspondant du poste de travail, et d’installer le certificat de signature dans le magasin my de l’utilisateur courant.

3. Modification du template de build
   Elle consiste à ajouter une activité de type « MSBuild » après la commande MSBuild native au workflow en renseignant les paramètres obtenus à l’étape ci dessus.
   Il peut être nécessaire de préciser une condition d’exécution (« If ») si plusieurs fichiers solution sont indiqués dans la build afin d’éviter que l’action de packaging soit exécutée plusieurs fois.
   Exemple d’utilisation dans un workflow :
   

   La paramétrage de l’activité msbuild de packaging ressemble à ceci :
   
   
   J’attire votre attention sur les deux points suivants :
   – Les paramètres /p: … sont injectés dans la case « CommandLineArguments »
   – Le contenu de « CommandLineArguments » formatte la chaine à l’aide de string.Format (d’où la syntaxe {x})
   – Les paramètres /t: … sont injectés dans la case « Targets »

   Je vous laisse consulter la MSDN pour la documentation relative aux paramètre d’une activité de build

Enjoy

Nativement, il n’est pas possible d’exécuter des tests 4.5 sous une machine de build TFS 2010.
En effet, le log d’exécution des builds atteste qu’il tente d’utiliser mstest en version 2010 :

 »
Exécuter MSTest pour les assemblys de tests
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe …
 »

La solution consiste à indiquer aux agents de build quel est le chemin de mstest 2012, à savoir :

1. Faire une copie du template de build $\BuildProcessTemplate\DefaultTemplate.xaml
   Exemple de nom pour la copie : DefaultTemplate-MsTest2012
2. Ouvrir le template DefaultTemplate-MsTest2012 et rechercher les occurrence d’activités nommées
   soit « Exécuter MSTest », soit « Run Test »
3. Renseigner dans l’argument « ToolPath » des activités d’exécution de MSTest le chemin du répertoire qui contient mstest pour la version 2012 sur les machines de build
   Chemin par défaut :
   « C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\ »

Enjoy

Exemple :

• Solution 1 : Composants extérieurs ne disposant d’aucune interaction avec les couches de services métiers (drivers, interfaces avec des systèmes extérieurs, etc)
• Solution 2 : Composants de la couche de services métiers, ou utilisant la couche métier (excepté les applications finales)
• Solution 3 : Composants affectant les applications finales (exe, applications web, configuration unity, controles graphiques, reporting, etc.)

Pour plus d’informations sur le multi sln : tfsguide.codeplex.com

Les dll’s générées par les projets non finaux (Solution 1 et 2 ci dessus) sont alors archivées, afin que les membres de l’équipe ne soient pas obligés de re générer les sorties de projets à chaque modification de source effectuée par un collègue.
Les références entre projets de solutions différentes étant par dll dans le repository correspondant.

Lorsque l’intégration continue est en place, un build par solution est installé.
Dès lors, lorsqu’une source est archivée, le contrôleur de build initie un build de la solution concernée.

Etant donné que le build se produit à chaque archivage, il est de bonne augure de le responsabiliser afin qu’il réalise lui même la mise à jour des dll lors des archivages (cela décharge donc les développeurs de cette tache).

Le workflow TFS 2010 situé dans l’archive Template-de-build-TFS-2010-CheckIn-dll-multi-sln.zip réalise cela sur base du DefaultTemplate.xaml

Attention

• le compte utilisateur exécuté par les services de build doit disposer de droits d’extraction / archivage sur le répertoire !
• Nous vous conseillons de ne pas exécuter deux identiques simultanément (mode continu avec un délai de xx minutes entre deux démarrages; le délai préconisé correspond à la durée d’exécution des builds)

Edit : J’ai modifié le WorkFlow pour permettre d’éviter l’évènement de CheckIn ( via RepositoryConstants.NoCICheckInComment) afin d’éviter les builds en cascade (la solution 2 utilise les dll produites par la solution 1, du coup, si CheckIn dll Sln 1 > Build Sln 2).

Enjoy

]]> 0 https://blog.developpez.com/bdevuyst/p11956/dotnet-net/tfs-et-workflow-de-build https://blog.developpez.com/bdevuyst/p11956/dotnet-net/tfs-et-workflow-de-build#comments Tue, 07 May 2013 08:46:50 +0000 http://blog.developpez.com/bdevuyst/?p=67 Cette fois ci, je ne vais pas épiloguer… car cela ne sert à rien de reprendre un contenu déjà existant et correspondant à mes attentes : clair et complet !

Customize Team Build 2010

Edit 2013-05-16 : Petite précision, dans la partie Part 5 : Increase AssemblyVersion, l’auteur précise dans le code de l’activité check out l’instruction  » workflow.Folders  » pour récupérer les répertoires mappés dans le workspace.
Ensuite,  » folder.LocalItem  » pour récupérer le chemin local (dans la boucle « pour chaque folder contenu dans le workspace »).
Le problème est le suivant : si le workspace contient un folder cloaked, il est bien contenu dans la liste retournée par la propriété workspace.Folder, mais la propriété LocalItem est nulle ! (ce qui est logique !)
Donc, lorsqu’il est nécessaire de lister les répertoires : il faut ajouter un filtre sur soit folder.IsCloaked soit sur string.IsNullOrEmpty(folder.LocalItem) afin de ne récupérer que les folders mappés dans le workspace courant !

Enjoy !

]]> 0 https://blog.developpez.com/bdevuyst/p11860/dotnet-net/multi-solution-visual-studio-et-dependances https://blog.developpez.com/bdevuyst/p11860/dotnet-net/multi-solution-visual-studio-et-dependances#comments Tue, 26 Mar 2013 09:51:57 +0000 http://blog.developpez.com/bdevuyst/?p=56 Les projets informatiques de taille conséquentes sont notre quotidien (refonte de SI, utilisation de nombreuses interfaçages extérieur au projet initial, etc).
Si on ajoute le respect des bonnes pratiques (ex : couplage faible entre couches > l’utilisation de mécaniques d’injections de dépendances – en d’autres termes, Article sur les IOC),

On obtient des fichiers solutions Visual Studio dont le nombre de projet excède largement la douzaine projets…

ce billet propose juste une piste de travail pour ce genre de problématiques…

Or, d’après les cahiers blancs MS (Un bon guide de mise en place des pratiques TFS), des fichiers SLN de plus d’une douzaine de projet ont des conséquences fâcheuses sur le projet :
– Absence d’optimisation des assemblies à la compilation, (je confirme)
– Temps de compilations excessifs sur les machines des développeurs (je confirme)
– Temps de compilations excessifs sur les agents de builds (intégration continue), (je confirme)
– Piètre performance au chargement de la solution (je confirme)
– …

La solution consiste à considérer les stratégies décrites dans le cahier blanc, pour éventuellement aboutir sur un Multi SLN.
Exemple :
– SLN1 : Projets totalement indépendants des projets de la solution (drivers, API client de partenaires extérieurs, API commune à l’entreprise)
– SLN2 : Projets de la couche de services, la DAL, etc.
– SLN3 : Projets propres à la couche de présentation

L’exemple ci-dessus est une stratégie, d’autres stratégies existent.

La règle, en termes de références entre projets, est la suivante : tous les projets situés au sein du même SLN peuvent se référencer entre eux, les liens entre projets de solutions différentes doivent se réaliser par DLL.
Dès lors, les outputs des projets des solutions (excepté celle de présentation) doivent être archivées (par solution) afin de ne pas forcer les développeur à devoir régénérer toutes les SLN lorsqu’un autre membre de l’équipe modifie une couche intermédiaire.
En d’autres termes :
– les outputs des projets de la SLN1 sont redirrigés en postBuild Event vers un répertoire (ex : $SlnRoot\_Build-SLN1) puis archivés.
– les outputs des projets de la SLN2 sont redirrigés en postBuild Event vers un répertoire (ex : $SlnRoot\_Build-SLN2) puis archivés.

La commande xcopy à placer dans le postBuild Event du projet est la suivante :
xcopy /E /Y /D /R « $(TargetDir)*.* » « $(SolutionDir)_Build-SLN-1-[SlnName] »

/E : Copie les répertoires et sous-répertoires, y compris les répertoires vides
/Y : Supprime la demande de confirmation de remplacement de fichiers de destination existants
/D : Copie les fichiers modifiés à partir de la date spécifiée. Si aucune date n’est donnée, copie uniquement les fichiers dont l’heure source est plus récente que l’heure de destination
/R : Remplace les fichiers en lecture seule

La dernière option est très importante, car les dll’s de destination sont en Read Only (puisque archivées sur TFS)… Sans le /R, on peut avoir des erreurs comme :
Error 3 The command « xcopy /E /Y /D « E:\DEV\…\MonProjet\bin\Debug\*.* » « E:\DEV\_Build-SLN-1-SlnName » … exited with code 4.

Astuce : Pour vérifier le message d’erreur réel : copier la commande remontée par Visual Studio lors des erreurs de build liées à xcopy dans une invite de commande et l’exécuter !

Un dernier point : Si vous êtes confronté à ces problèmes de solutions complexes, je vous invite à
– lire le document cité ci dessus afin d’élaborer une stratégie de multi SLN (non trivial),
– échanger avec les membres de l’équipe, car en définitive ce sont eux qui exploiteront les SLNs !

Enjoy !

]]> 0 https://blog.developpez.com/bdevuyst/p11195/alm/tfs/work_item_viewer https://blog.developpez.com/bdevuyst/p11195/alm/tfs/work_item_viewer#comments Tue, 31 Jul 2012 08:30:47 +0000 Je cherchais un petit outil permettant de visualiser graphiquement les liens entre workitems TFS, et si possible open source…
« Work Item Visualization » du CodePlex correspond parfaitement au cahier des charges !
Cerise sur le gâteau : le fichier graphique en sortie est un dgml !

http://visualization.codeplex.com/

Enjoy !

]]> 0 https://blog.developpez.com/bdevuyst/p11179/alm/tfs/tfs_visual_studio_excel_office_lenteur_s https://blog.developpez.com/bdevuyst/p11179/alm/tfs/tfs_visual_studio_excel_office_lenteur_s#comments Fri, 27 Jul 2012 13:34:24 +0000 Depuis la réinstallation de mon portable, les accès TFS avec des outils clients tels que Visual Studio 2010 ou application office (Excel) étaient lent… trèèèès lent…

Après recherche, la solution pour Visual Studio 2010 (trouvée ici ) fut appliquée :
Modifier le fichier de configuration de Visual Studio 2010 (devenv.exe.config) pour lui ajouter la ligne suivante :
1: <system.net>
2: <defaultProxy enabled= »false » /> <!– Nouvelle ligne –>
3: <settings>
4: <ipv6 enabled= »true »/>
5: </settings>
6: </system.net>

Ceci résolut le problème sous VS mais par sous Excel.

Après investigation dans le répertoire d’Office, j’ai trouvé un fichier manifest excel.exe.manifest
Bonne nouvelle : cela a l’odeur de .net !
Dès lors :

1. Création d’un fichier nommé excel.exe.config
2. Ajout des lignes suivantes :

0: <configuration>
1: <system.net>
2: <defaultProxy enabled= »false » /> <!– Nouvelle ligne –>
3: <settings>
4: <ipv6 enabled= »true »/>
5: </settings>
6: </system.net>
7: </configuration>

Et… cela fonctionne : les problèmes TFS Excel sont résolus !

Bon à savoir !

]]> 0