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