Oh la peine. Visual Studio 2003 et Cruise Control.NET. Simple et élégant. Un script NAnt de base pour créer la solution et vous êtes prêt à partir. Exécutez NUnit, la sortie est envoyée dans un format que CC peut comprendre et celui de l'oncle de Bob. Permettez-moi de quantifier cela. Notre serveur Cruise dispose d'un client Subversion (ligne de commande) et du SDK .NET 1.1. Visual Studio n'est pas installé car, duh, c'est un serveur et Cruise a juste besoin de quelque chose pour construire le système.
Entrez dans Visual Studio 2005. J'ai récemment configuré CI pour nos projets 2005, mais c'est tout simplement moche, à bien des égards. Il s’agissait d’abord d’essayer de construire le système à l’aide de MSBuild. C'était bien parce que vous pouvez simplement entrer ceci :
msbuild /t:rebuild solutionname.sln
(ou quelle que soit la cible de votre choix comme Debug ou Release)
Comme je l'ai dit, si c'est tout, ce n'était pas un problème mais ça devient vraiment moche très vite.
Il y a d’abord les projets de tests unitaires VSTS. L'équipe est entièrement équipée de Visual Studio Team Suite. Une proposition coûteuse, mais faite il y a longtemps par quelqu’un de plus sage que moi. Pas de problème cependant. Nous n'utilisons pas vraiment beaucoup le Test Manager, il n'y a pas de tests Web automatisés, nous écrivons donc simplement des tests unitaires (et les exécutons avec l'excellent TestDriven.NET de Jamie Cansdales). Cependant, lorsque MSBuild met la main sur une solution contenant un projet de test unitaire VS, il a besoin d'un ensemble supplémentaire d'assemblys (assemblés enfouis dans GAC_MSIL et à d'autres endroits). L'extrait du fichier ccnet.config permettant de lancer MSBuild était assez simple :
<msbuild>
<exécutable>C:WINDOWSMicrosoft.NETFrameworkv2.0.50727MSBuild.exe</executable>
<workingDirectory>D:ccnetprojectsProjectName</workingDirectory>
<projectFile>SolutionName.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=AutomatedBuild /v:diag</buildArgs>
<targets>Construire</targets>
<timeout>600</timeout>
<logger>C:Program FilesCruiseControl.NETserverThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
Grâce à la force brute (exécutez MSBuild, déterminez de quel assemblage il a besoin, allez le trouver, faites mousser, rincez, répétez), j'ai pu obtenir une solution 2005 (avec des projets de tests unitaires) à compiler. Cependant, exécuter les tests est une autre histoire. Encore une fois, la force brute a régné en maître ici alors que j'ai parcouru une heure ou deux d'exécution de MSTest.exe pour essayer d'amadouer quelques centaines de tests unitaires à exécuter. L'entrée cc.config permettant d'obtenir certains tests unitaires ressemble à ceci :
<exec>
<exécutable>C:Program FilesMicrosoft Visual Studio 8Common7IDEMSTest.exe</executable>
<baseDirectory>d:ccnetprojectsProjectName</baseDirectory>
<buildArgs>/testcontainer:SourceTestsUnitTestsbinAutomatedBuildUnitTests.dll /runconfig:localtestrun.Testrunconfig /resultsfile:testResults.trx</buildArgs>
<buildTimeoutSeconds>600</buildTimeoutSeconds>
</exec>
N'oubliez pas que j'ai dit que Visual Studio n'était pas installé sur ce serveur. Pour les solutions VS2005, je viens d'installer le .NET SDK 2.0 et c'était suffisant. Bien que MSTest.exe ne soit pas inclus, j'ai récupéré le fichier (et c'est un ensemble fou de DLL supplémentaires dispersées sur tout le disque dur) d'un autre système et je l'ai collé là où se trouvait l'EXE pour qu'il soit heureux.
Aucun dés pour exécuter MSTest sur un projet de test unitaire. Il a commencé par exécuter le test, mais a ensuite rencontré une erreur COM folle (CLSID non enregistré) et cela m'a suffi. Pas question que je traque tous les stupides paramètres de registre COM pour Visual Studio 2005. Et qu'est-ce que c'était que ça ? COM ? Je pensais que nous nous en étions débarrassés il y a environ 3 compilateurs ?
J'ai donc dû installer une Team Suite complète sur le serveur. D'accord, je vais mordre. Je veux dire, je n'ai pas besoin de tout, donc tout ira bien (je n'arrête pas de me dire en regardant un million d'entrées de registre se remplir). Quelques heures plus tard, je regarde à nouveau mon invite de commande et tape ma commande MSTest.exe. Et une boîte de dialogue apparaît. Ouais, une boîte de dialogue modale qui me dit que quelque chose ne va pas (je ne me souviens pas des détails mais ce n'était pas très informatif).
Visual Studio a été correctement installé et j'ai pu compiler, exécuter et créer la solution que j'essayais de faire, mais tester à partir de la ligne de commande avec MSTest.exe était impossible. Peu importe à quel point j'ai essayé, combien j'ai nettoyé ou combien de vierges j'ai sacrifiées, cela ne fonctionnera tout simplement pas. Et il y a un autre problème. Avec 2003 et nos tests NUnit, nous avons de belles statistiques. Des horaires, des messages informatifs, toutes ces bonnes choses. Avec MSTest, nous n'obtenons rien (à part un nombre x de tests exécutés et peut-être un échec, mais je n'ai pas pu aller aussi loin pour voir si cela donnerait les détails de l'échec). En plus de cela, l'enregistreur MSBuild mord et produit environ 10 000 lignes de charabia qui ne sont pas très utiles. Oui, je pourrais passer mon temps à écrire un nouveau xslt pour le rendre joli, supprimer les lignes "Tout allait bien" qui remplissent l'enregistreur de tâches MSBuild, mais je pense que ce n'est pas une valeur ajoutée à mes tarifs.
Voici un exemple d'e-mail que j'ai reçu de la construction et qui vous donne une idée de l'inutilité d'un combo CC.NET/MSBuild/MSTest :
BUILD SUCCESSFUL
Projet : NOM DU PROJET
Date de construction : 8/12/2006 8:08:30
Durée : 00:00:55
Demande d'intégration : intervalTrigger a déclenché une build (ForceBuild)
Erreurs (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1) : erreur MSB4041 : l'espace de noms XML par défaut du projet doit être l'espace de noms XML MSBuild. Si le projet est créé au format MSBuild 2003, veuillez ajouter xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " au champ <Project> élément. Si le projet a été créé dans l'ancien format 1.0 ou 1.2, veuillez le convertir au format MSBuild 2003.
Avertissements (1)
SourceReportsServerReportsServerReports.rptproj (,) : avertissement MSB4122 : l'analyse des dépendances du projet pour le projet "SourceReportsServerReportsServerReports.rptproj" a échoué. L'espace de noms XML par défaut du projet doit être l'espace de noms XML MSBuild. Si le projet est créé au format MSBuild 2003, veuillez ajouter xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " au champ <Project> élément. Si le projet a été créé dans l'ancien format 1.0 ou 1.2, veuillez le convertir au format MSBuild 2003. D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
Tests exécutés : 0, Échecs : 0, Non exécutés : 0, Durée : 0 seconde
Aucun test exécuté
Ce projet n'a aucun test
Modifications depuis la dernière version (0)
C'est moche. Vraiment moche. MSBuild produit une tonne de résultats fous. Écrire un nouveau fichier MSBuild n'est pas une promenade de santé et même pour quelqu'un comme moi qui connaît assez bien NAnt, je me demande toujours comment MSBuild fait les choses. J'ai dû créer une configuration spéciale dans Visual Studio pour omettre notre projet Report car MSBuild ne peut pas les construire (d'où la cible AutomatedBuild ci-dessus qui n'est pas la même configuration que celle utilisée par nos développeurs et quelque chose que je n'aime pas faire car c'en est une point d'un serveur CI, des builds cohérents pour tout le monde).
D'après le résultat ci-dessus, Cruise a déclaré que la construction était correcte, mais qu'un message d'erreur est sorti de l'enregistreur MSBuild (notre projet de rapport). Il s'agit d'un projet de 2005, donc l'information n'a aucun sens (je crois que c'est un bug qui est enregistré mais qui sait quand il pourrait être corrigé). Et je ne peux vraiment pas intégrer la sortie MSTest dans l’e-mail car, eh bien, il n’y en a pas. Il y a une centaine de tests dans ce projet mais l'enregistreur ne produit rien.
De plus, il existe certains types de projets que MSBuild ne peut pas gérer et encore une fois, il faut un génie pour créer un fichier MSBuild (même en utilisant quelque chose de sympa comme MSBuild Sidekick) qui peut appeler une autre tâche MSBuild et exclure certains projets. Ce n'est certainement pas aussi simple qu'en 2003, où vous veniez de créer une liste d'exclusion (nous avons exclu notre application client car il n'y avait pas de licence supplémentaire pour le contrôle de la grille et une boîte de dialogue modale est apparue lorsque la version d'essai a même été examinée par le compilateur).
D'accord, c'est surtout une diatribe, mais il y a une certaine sagesse ici. L'intégration continue n'a pas besoin d'être aussi difficile. CruiseControl.NET est un excellent outil et très flexible avec de nouveaux outils et intégrant les sorties de ces outils. Cependant, lorsque ces outils nécessitent un million de paramètres de registre et encore plus de DLL (placées dans des endroits très spécifiques, croyez-moi, vous ne pouvez pas simplement les jeter dans le GAC et en finir) et vider des quantités de XML que aucun simple mortel (enfin peut-être que DonXml pourrait) serait capable de traduire, c'est tout simplement faux. Et en ce qui concerne le Team Build intégré que vous pourriez nous proposer, il est tout aussi inutile que a) vous ne pouvez pas planifier les builds pour déclencher des enregistrements de code et b) encore une fois, cela nécessite l'installation d'un client Team Suite complet sur le serveur. . Dans le pire des cas, lorsque j'ai commencé à configurer les serveurs CC.NET, cela a pris 4 heures. Maintenant, je peux le faire en une heure (ce qui inclut le test de la version du premier projet). J'ai déjà passé une bonne journée à essayer de compiler quelque chose. Il est en cours de compilation mais le résultat est nul et aucun test n'est exécuté et ce n'est tout simplement pas assez bon pour moi. Vous pouvez faire fonctionner MSBuild et (peut-être) MSTest avec CruiseControl.NET. Ce n'est pas impossible. Si vous installez le client complet et que vos projets sont "parfaits", cela fonctionnera mais la sortie n'est pas si chaude et vous verrez le processeur de votre serveur claquer lors des compilations.
Mon conseil, évitez d'essayer de combiner MSBuild, MSTest et CruiseControl et tenez-vous-en à NAnt et NUnit (en utilisant MSBuild si vous devez le faire lors de la création de solutions 2005).
Inutile de dire que j'envisage une option en ce moment. Vider l'installation de VS2005 sur le serveur, redéfinir tous nos tests unitaires sur NUnit et utiliser NAnt pour tout faire (et simplement appeler MSBuild comme tâche d'exécution pour les projets VS2005). J'ai encore besoin d'exécuter des projets 2003 pour que notre serveur CI ressemble à un monstre de Frankenstein au moment où j'aurai terminé, en construisant des projets VS2003 et VS2005, en exécutant NUnit, MSBuild, NAnt, Simian, FxCop et tout ce que nous avons dans notre mélanger. Même étant donné qu'en utilisant NAnt, la sortie sera plus simple (et s'intégrera bien à CC.NET), la sortie des tests sera utile et informative, et je n'ai pas besoin d'installer un logiciel à 15 000 $ sur un serveur qui a la possibilité distincte pour afficher une boîte de dialogue modale un jour lorsqu'il ne trouve pas de clé de registre.
Grrr. Argh.