Communauté Française des utilisateurs de BizTalk - BizTalk 2009 et l'intégration continue avec TFS 2010 (Partie 2)

Dans la première partie de cet article j’avais installé le contrôleur TFS sur la même machine que le server TFS et ce n’était pas une ‘bonne pratique’.

Dans cette partie, je vais essayer de vous décrire les étapes par lesquelles je suis passé pour intégrer les tests et l’analyse du code dans mon processus d’intégration continue.

Première étape : Installation du contrôleur sur une deuxième machine

Lancez le 'Build Service Configuration Wizard' :

Sélectionnez votre TFS dans 'Project Collection'

J’ai choisi de migrer la configuration existante sur le nouveau contrôleur dans 'Build Services'

J’ai gardé le compte service Dans 'Settings'

Vous pouvez vérifier votre configuration avec le bouton 'Verify' dans 'Review', dans mon cas j'étais avertis d'arrêter le contrôleur de la machine qui est hébergé sur le serveur TFS.

Appliquez votre configuration dans 'Readiness Checks'.

FIG1

Voilà tout semble correct, j’ai procédé donc à mon premier test de build et le résultat est KO.

FIG2

C’est du déjà vu, j’applique sur la deuxième machine ce que j’ai décrit dans la première partie de cet article, cad : Réinstallation du SP1, team explorer et le forward compatibility.

Deuxième essai :

C’est bon, ça marche … mais je ne comprends pas pourquoi j’ai des warnings :

FIG3

J’ai cherché sur le net l’erreur BTP0008 et j’ai trouvé une seule réponse disant que les warnings sont du au fait que le projet pipelines ne trouve pas les dll du projet schéma. J’ai trouvé que c’était bizarre parce que j’ai un projet maps et un projet orchestration qui se compilaient sans warnings et ils ont aussi des references sur le meme projet schéma. Mais bon j’ai voulu tester la solution.

J’ai ajouté dans le ‘post-build event’ "On Successful build" pour mettre les dlls dans le GAC :

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe" /i "$(TargetPath) "

J’ai testé et ça ne marchait pas, j’avais un problème de droits.

J'ai donc changé le compte qui exécute le contrôleur:

FIG 4

Une deuxième erreur, le compte n’avait pas les droits sur le répertoire du build.

Encore un essai et une autre erreur cette fois ci, j’ai eu un message disant que le répertoire est déjà mappé.

J’ai changé donc le répertoire du build et hourra ça marche … mais toujours les warning :/ (Pour info je n’ai pas trouvé de solution encore à ce problème).

Nous pouvons dire que la phase de migration du contrôleur est terminée.

Deuxième étape : analyse du code

Voici la configuration à faire pour analyser le code lors du checkin:

FIG5

Sélectionnez 'Add Check-in Policy' puis 'Code Analysis'.

FIG6

Sélectionnez BizTalkCop (que vous pouvez trouver sous codeplex).

J’ai fait un test, en essayant de faire un 'check-in' sur une orchestration qui ne suit pas les régles de BizTalkCop.

FIG 7

Troisième étape : les tests unitaires

Ajouter un projet de type 'Visual C#' 'Test Project' dans votre Solution BizTalk.

Pour ce qui est du code des tests, je vous renvoie à ce blog qui est très bien.

J’ai réalisé un test en local est le résultat était Ok.

À cette étape nous allons ajouté les tests dans notre processus d’intégration continu :

Sélectionnez 'Process' dans 'Build Defintion' puis 'Automated Tests' et 'Add'
Cliquez sur 'Test metadata file' et Sélectionnez votre fichier vsmdi
Cochez 'Run all tests in this ...' et 'Fail build on test failure'

Mon premier essai de build a échoué avec le message suivant :

FIG 8

J’ai chargé le résultat dans 'Visual Studio' et le détail du message d’erreur indiquait que le fichier input de la map (mapIn.xml) était introuvable.

J’ai changé le code du test afin de trouver le répertoire de travail du build pour les tests puis j'ai lancé un autre test:

FIG9

J’ai changé le chemin dans mon code et après cette dernière modification tout était OK.