2009-06-12 11 views
5

Dans notre boutique de développement de logiciels .NET, nous avons créé CruiseControl.NET pour construire 28 projets, dont certains sont interdépendants. Chaque projet représente approximativement un projet Visual Studio ou une bibliothèque Flex associée à des tests unitaires. Ce que je suis ennuyé, c'est que je n'ai pas trouvé un bon moyen de s'assurer que les projets construisent dans un ordre représentant les dépendances.Créer une commande dans CruiseControl.NET avec des dépendances de projet

est ici ce que je fais:

  1. Tout est dans la même file d'attente de construction. Je l'ai fait pour que les versions soient séquentielles et que je puisse éviter d'avoir besoin de plusieurs répertoires de travail.
  2. J'ai défini des priorités de file d'attente sur les projets, ce qui, selon moi, influencerait leur ordre de construction. Mais après avoir lu la documentation plus attentivement, j'ai constaté qu'il ne contrôlait que la priorisation lorsqu'il y a plusieurs demandes de construction dans une file d'attente.
  3. En plus d'utiliser des déclenchements d'intervalle pour lancer une génération, j'utilise des déclencheurs de projet de sorte que lorsque les dépendances sont correctement construites, leurs dépendances se construisent également.

D'une certaine manière, cette configuration fonctionne. Le problème principal est que quelqu'un commet des changements au code dans le projet A et dans le projet B, où le projet B dépend du projet A. Parfois, le projet B sera construit avant le projet A. Comme le projet A n'a pas encore été construit, cela peut parfois provoquer la rupture du projet B Ceci est temporaire, car le déclencheur d'intervalle provoque la génération ultérieure du projet A, et sa construction réussie déclenche le projet B pour reconstruire et se corriger. Ce que je veux éviter, c'est que le projet B soit construit avant le projet A afin que la rupture intermédiaire ne puisse pas se produire.

Quelles pratiques utilisez-vous pour gérer correctement les interdépendances sur un serveur CruiseControl.NET? À ce stade, je ne suis pas prêt à passer à un package d'intégration continue non-free comme TeamCity.

Répondre

8

Vous devez contrôler l'ordre de construction du projet via le script NAnt. Vous n'avez pas besoin de construire sur un niveau de solution, vous pouvez construire sur un niveau de projet individuel.

<target name="Project1" depends="Projects2" description="Builds project 1"> 
    <msbuild> 
     <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
     <workingDirectory>C:\dev\ccnet</workingDirectory> 
     <projectFile>CCNet.sln</projectFile> 
     <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
     <targets>Build;Test</targets> 
     <timeout>900</timeout> 
     <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

<target name="Project2" depends="Projects3" description="Builds project 2"> 
    <msbuild> 
     <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
     <workingDirectory>C:\dev\ccnet</workingDirectory> 
     <projectFile>CCNet.sln</projectFile> 
     <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
     <targets>Build;Test</targets> 
     <timeout>900</timeout> 
     <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

<target name="Project3" description="Builds Project 3"> 
    <msbuild> 
      <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable> 
      <workingDirectory>C:\dev\ccnet</workingDirectory> 
      <projectFile>CCNet.sln</projectFile> 
      <buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs> 
      <targets>Build;Test</targets> 
      <timeout>900</timeout> 
      <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger> 
    </msbuild> 
</target> 

Vous pouvez exécuter vos tests unitaires sur un niveau de projet individuel, vous ne devriez pas besoin de faire double sur plusieurs pistes projets.

+0

En procédant ainsi, je devrais dupliquer les instructions de construction de chaque projet de dépendance dans chaque projet dépendant. Mais je suppose que s'il s'avère que je ne peux pas contrôler l'ordre de construction dans CC.NET, je devrais être redondant. Au moins, je peux utiliser le support de CC.NET pour les entités XML pour encapsuler les étapes de construction d'un projet. – Jacob

+0

Pas nécessairement. Utilisez un seul fichier cruise.build pour stocker le script NAnt. Partagez ce fichier cruise.build unique à travers les projets, de cette façon ils adhèrent tous à la hiérarchie des dépendances et vous ne dupliquez pas le script. –

+0

Bien qu'il soit à craindre que la boîte de construction doive encore faire un double bâtiment, on dirait qu'il n'y a pas de bonne solution. Cette réponse ressemble à la meilleure. – Jacob

2

Je vous suggère de ne pas croiser le concept d'un projet CruiseControl avec un projet de studio visuel! En règle générale, je mets en place un projet CC qui englobe un ensemble de travaux. Pour moi, cela signifie que le projet CC exécutera un script NAnt. Le script NAnt a un contrôle très fin sur ce que je fais et quand. Cela signifie que je peux construire ma solution (qui sait quel projet construire en premier!), Lancer mes tests unitaires, réinitialiser une base de données, déployer du code, envoyer des emails, faire du code (NDepend et NCover sont géniaux!), etc. Cela signifie que j'ai un projet apparaître dans CCTray et cela rend les choses plus fidèles à ce qu'ils sont réellement. Je peux ensuite créer un nouveau projet en CC pour contrôler quand je pousse de DEV à STAGING et de STAGING à PROD pour que nous puissions "appuyer sur" cette tâche. Mais cela ne donne que 3 projets en contrôle de croisière et est considérablement plus convivial. Ne placez pas la dépendance dans les paramètres du projet CC.NET

+0

D'accord. Le concept d'un fichier de solution VS est beaucoup plus analogue à ce que nos CC sont construits. Nos projets CC représentent chacun un «produit» et chaque produit contient de nombreux fichiers .csproj. – womp

+0

La principale raison pour laquelle je ne fais pas cela est parce que j'ai des tests unitaires qui "appartiennent" à chaque projet VS, et je ne veux pas exécuter les mêmes tests unitaires pour chaque solution qui partage le projet. – Jacob

2

Bien que vous ayez déjà accepté une réponse, je suggérerais autre chose: vous ne devriez pas avoir de dépendances directes entre deux projets. Par "direct" je veux dire que chaque fois que les binaires dans le projet A changent, cela ne devrait pas signifier que vous les utilisez automatiquement pour construire le projet B.

Le processus de mise à jour de ces références devrait être contrôlé (par vous), sinon vous finirez inévitablement avec beaucoup de builds cassés pour le projet B.J'ai tendance à garder tous les binaires externes sous lib répertoire (et sous-répertoires) sous le contrôle de la source et les mettre à jour uniquement lorsque je décide de le faire. Et par "externe", je veux dire à la fois les bibliothèques tierces et ceux d'autres projets dans mon entreprise (exemple: http://code.google.com/p/projectpilot/source/browse/#svn/trunk/lib)