Benjamin Devuyst » TFS

TFS 2010 – Build WF > CheckIn dll

benji_dv — Mon, 13 May 2013 10:25:43 +0000

Dans le cadre de gros développements, nous séparons les projets en plusieurs solutions.

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

TFS et workflow de build

benji_dv — Tue, 07 May 2013 08:46:50 +0000

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 !

Multi solution Visual Studio et dépendances

benji_dv — Tue, 26 Mar 2013 09:51:57 +0000

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 !