La réussite de vos projets SharePoint passe par une intégration continue (Part 2/2)
Par Lionel Limozin, posté le 11/11/2011
Profil : Développeur | Niveau : Confirmé (300)
Tags : Sharepoint, TFS, Tests unitaires |
Partager : 
La première partie de cet article se trouve ici : http://labs.bewise.fr/Article/La-reussite-de-vos-projets-SharePoint-passe-par-une-integration-continue--Part-1-2-/
4 - Le projet SharePoint de démo
Le projet de démo est simplissime et se présente ainsi :
Un WebPart qui affiche une interface pour saisir une addition avec un bouton qui permet de lancer le calcul :
Et une classe "outil" dans une dll externe permettant de réaliser le calcul à proprement dit :
L'objectif étant de valider le fonctionnement du process complet, il nous faut un petit projet simple mais si possible représentatif.
Vous remarquerez que le projet SharePoint contient aussi un fichier "Deploy.ps1". Il contient le script PowerShell décris au chapitre précédent. ATTENTION à penser à indiquer que ce fichier doit être copié dans le dossier de sortie lors de la compilation ! Nous allons en avoir besoin côté "Contrôleur de Build". :
Enfin qui dit intégration continue dit tests unitaires, tout du moins tests automatisés. J'ai donc ajouté un projet de type "Tests" avec :
un test unitaire qui test les méthodes de la classe Computing 
et un WebTest qui valide la partie IHM de la calculette à la recherche du bouton ''=' 
Cependant les WebTest (ou web performance tests) ne sont pas exécutés lors d'un déploiement par une Build Auto. Seuls les tests par code et tests "code UI" le sont. Heureusement pour nous il est possible à partir d'un WebTest de générer une classe faisant la même chose, mais par code ! Donc on retrouve ici la classe WebTest1Coded.
5 - Mise en place de la Build
Nous pouvons maintenant paramétrer la Build. En plus du paramétrage de base vous aurez 2 étapes importantes à faire :
· ajouter le paramètre MSBuild pour générer le WSP
· modifier le workflow pour intégrer l'appel au batch Deploy.ps1
Commencez par créer la Build en passant par le Team Explorer et en faisant un clic droite sur le noud "Build" puis "New Build Definition":
Donnez-lui un nom puis passez à l'étape suivante permettant de choisir à quel moment la Build peut se déclencher :
Selon vos besoins la Build peut être lancée uniquement manuellement, de manière régulière ou bien à chaque check in d'un développeur.
Notez la nouveauté de la version 2010 qui propose le "Gated Check-in" qui permet de réaliser la compilation et les tests avec la version que le développeur vient d'archiver, donc déclenchement automatique, mais si la Build fini en erreur, l'archivage est annulé. Donc en cas d'archivage une version d'une source disons "pas compatible" avec le reste du projet, nous n'aurons pas les autres développeurs de l'équipe impactés.
A l'étape suivante vous indiquez quel contrôleur de Build va prendre en charge cette Build :
Il faut aussi fournir un dossier partagé où les fichiers de sortie sont stockés sur le serveur de Build. En principe lors de l'installation de TFS Build Service ce dossier est créé et par défaut correspond au C:\Builds\
Il est nécessaire que les membres de l'équipe aient accès en lecture à ce partage réseau pour qu'ils puissent consulter les logs des Builds par exemple.
Enfin la page de configuration la plus importante est la configuration du process :
Ici vous choisissez quels projets sont compilés et si il faut exécuter les tests. Par défaut c'est le cas, à partir du moment où le nom de votre projet de test contient le mot "Test".
Premier point important, ajoutez l'argument MSBuild suivant : /p:IsPackaging=True
Cet argument permet de dire à MSBuild de faire l'équivalent de ce que fait Visual Studio lorsque vous faites un clic droite / deploy sur un projet de type SharePoint.
Second point, il faut un modèle de process. Ce process est un workflow (WF 4.0) qui réalise toutes les étapes de la Build : récupération des dernières sources, nettoyage des binaires, compilation, exécution des tests, création de WorkItems, etc. C'est ici qu'il faut rajouter l'exécution de notre script PowerShell qui va déployer notre solution SharePoint. L'emplacement idéal étant après la compilation '(et donc packaging) et avant l'exécution des tests.
Commencez par créer un nouveau modèle à partir de celui par défaut :
Avant d'éditer ce nouveau modèle vous pouvez configurer la politique de rétention des Builds et de leur résultat (attention à l'espace disque !) et enfin enregistrer cette définition de Build.
Le fichier correspondant au workflow se trouve dans un dossier nommé "BuildProcessTemplates" à la racine du projet TFS :
Pensez à faire un "check out" avant de l'ouvrir dans Visual Studio.
Une fois le fichier chargé (c'est assez long) il faut repérer le bon emplacement. Ce n'est pas forcément évident du premier abord vu la quantité d'étapes et de conditions imbriquées. Trouvez le bloc "Try Compile, Test, and Associate Changesets and Work Items " qui se trouve en seconde moitié du workflow (attention pas celui de l'étape de "Clean" se trouvant un peu avant)
Puis juste un peu plus bas vous trouverez la boucle qui exécute MSBuild pour chaque projet, suivi de l'étape qui va gérer l'exécution des tests :
Il faut donc ajouter à cet emplacement intermédiaire l'appel à notre script PowerShell. Pour cela il faut utiliser une activité "InvokeProcess" 
fournie dans les "Team Foundation Build Activities". Faites la glisser à l'emplacement repéré précédemment.
L'utilisation de cette activité est assez simple. Il faut lui fournir un "filename" c'est à dire l'exécutable, ici "powershell", ainsi que les paramètres de ligne de commande. Concernant ces derniers nous allons pouvoir utiliser une variable disponible dans le Workflow qui est "outputDirectory". Comme vous vous en doutez, cette variable contient le chemin où les binaires sont placés lors de la compilation.
Il se trouve que si vous avez bien suivi les étapes précédentes, ce dossier contiendra le ou les fichiers wsp de votre/vos projets SharePoint, ainsi que le fichier "Deploy.ps1". Pour rappel ce dernier attend en entrée un dossier contenant des wsp.
Il ne reste plus qu'à utiliser tout ça dans la propriété "Arguments" : "-Command ""& '" & outputDirectory & "\Deploy.ps1' '" & outputDirectory & "\'"""
Attention : les propriétés de l'activité doivent être renseignées avec du code VB.NET. D'où le & pour la concaténation de chaines.
Vous pouvez maintenant enregistrer le fichier. Pensez à faire un "check in" sans quoi la Build sera exécutée avec la précédente version de ce workflow.
6 - Tests du processus mis en place
Avant d'exécuter une première Build, il faut prévoir le déploiement de la solution sur le serveur d'intégration, l'activation de la feature, la création d'une page de webpart contenant la calculette. Tout cela est faisable soit dans le script PowerShell soit pourquoi pas directement dans l'initialisation des tests unitaires en utilisant le modèle objet de SharePoint.
Afin de simplifier l'exemple j'ai fait un premier déploiement manuel et j'ai créé une page de test. J'ai d'ailleurs modifié mon test web "codé" pour lui donner l'adresse de cette page sur le serveur d'intégration.
Vous pouvez lancer une première Build en passant par le "Team Explorer / Build / votrebuild" et en faisant un clic droite / queue new Build :
Validez le paramétrage et faites "Queue"
Vous arrivez ensuite sur la fenêtre "Build Explorer" vous permettant de voir la liste des Builds en cours :
Un double clic sur la Build vous permet de consulter l'évolution en direct :
Une fois la compilation terminée, si tout se passe bien, vous retrouvez un résumé indiquant le résultat de la compilation et des tests:
Vous avez même la possibilité de consulter le résultat des tests en détails !
Afin de vérifier l'efficacité de mon process de Build, je vais introduire 2 "erreurs" dans le projet:
· une erreur de code dans la classe Computing : 
· une erreur d'ihm dans le webpart : 
Je fais un "check in" de tout ça et je relance la Build. Après quelque minute le résultat tombe : la Build est en échec car des tests ont échoués. En regardant dans le détail j'ai la raison de l'échec de ces tests :
Un double clic sur le WebTest me permet d'aller voir en détail la raison de son échec :
On constate qu'effectivement le signe = dans le bouton n'est pas trouvé. C'est bien que ma nouvelle version "bugée" a bien été correctement déployée sur mon serveur d'intégration.
Conclusion
Dans cet article je me suis focalisé sur la mise en place de l'aspect Build automatique et exécution des tests unitaires. Je vous ai montré comment installer les outils nécessaires ainsi que le paramétrage et les techniques utiles.
Cependant tout ceci n'est qu'une introduction au regard de ce que propose cet outil d'intégration continue en particulier sur les possibilités de personnalisation du workflow du processus d'intégration continue lui-même.
L'avènement de Visual Studio 2010 et l'intégration efficace d'outils dédiés aux développements SharePoint 2010 ainsi que cette souplesse et ces nombreuses options permettent d'adapter assez simplement de telles pratiques (industrialisation, processus qualité, tests, etc.) à des projets SharePoint. Et c'est tout simplement une révolution !
Merci à ceux qui m'ont soutenu, aidé, relu, en particulier : Ben, Stephan, Alex et Alain !
