mai
2013
Un article de benji_dv
Commentaires fermés 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