Application lifecycle management : automated builds and testing for SharePoint projects

Session animée par Chris O’Brien & Mike Morton

Dans cette session, nous allons voir comment automatiser les builds de solutions et mettre en place des tests unitaires sous SharePoint.

Les challenges des gros projets: il y a beaucoup de dépendances entre les projets (code, features, timer jobs, …). Les déploiements restent assez complexes (il y n’y a pas de rollback de sur les wsp nativement), et les tests unitaires dans le monde de SharePoint ne sont pas très courants.

Les problèmes inhérents aux projets conséquents : le tracking (difficile de garder une trace des deploiements/correctifs, les développeurs sont nombreux), la difficulté de garder un environnement à jour par rapport à celui des autres développeurs, les builds inconsistants…

On nous présente maintenant la recette magique pour parer à ces difficultés.

D’abord, il faut automatiser la compilation des assemblies et des wsp.

Il faut utiliser un contrôleur de sources (TFS par exemple) et prendre l’habitude des commenter les check-in pour faciliter les retours arrières.

Il faut aussi penser à incrémenter automatiquement le numéro de version des assemblies, c’est plus facile pour le tracking des déploiements/des correctifs.

Les wsp doivent être déployés sur des machines de tests, pas sur les machines des développeurs.

Il faut faire des tests unitaires afin d’empêcher le build en cas d’échec d’un test unitaire.

Quelques ingrédients : TFS Team Build Workflow pour définir l’ordonnancement des étapes, Powershell pour déploiement des wsp, Remote Powershell pour exécuter des actions sur des serveurs distants (commande « Invoke-Command »).

On doit se poser la question : quand déclencher les builds ? Manuellement, schedulé, à chaque check in…

Le Workflow des étapes du build doit être cutomisé.

On passe maintenant à une démo.

Tout ce que nous allons voir ici nécessite l’édition Team Build de Team Foundation Server.

On ouvre Visual Studio (qui est planté au passage J), on crée une Build definition dans laquelle on définit  les triggers (manuel, schedulé, …) pour savoir quand builder, on définit les chemins d’accès aux ressources, on définit ensuite le contrôleur de build utilisé. ..

Replantage mais le coupable est IE cette fois ci. On kill le process !

On définit maintenant le dossier de sortie, la solution utilisée, s’il s’agit d’un build debug ou release (meilleur pour les performances sur un environnement de production), les arguments à envoyer à notre build (ici packaging=true) pour builder le wsp en plus des assemblies.

Maintenant, on sélectionne un template de  build/workflow ( fichier xaml). Un certain nombre de templates sont déjà présents dans TFS. Un designer de workflow permet de définir les étapes (exécution de code par exemple). Très intuitif tout ça J

Un agent est visible dans la barre des tâches pour consulter rapidement l’état des builds.

On lance le build et visualise les logs des builds directement depuis Visual Studio.

Après cette démo, nous passons aux tests unitaires.

Les tests unitaires peuvent être assez poussés : générer des bouts de code (pour envoyer des données), générer des cliques pour ajouter une webpart à une page, …

Retour à une démo…

Ce que nous allons voir nécessite la version Ultimate ou Premium de Visual Studio.

On crée un « Test project » dans VS. Les possibilités sont nombreuses : un test qui exécute du code, un autre enregistre nos  actions (par exemple un clique sur un bouton du ribbon.

Il est même possible de sélectionner des éléments html dans la page et d’indiquer la valeur qu’ils doivent avoir après le clique: par exemple, le message de succès qui doit apparaitre sous le ribbon.

On lance le test, VS clique tout seul, le message apparait… succès!

Nous avons ensuite droit à quelques exemples de codes Powershell qui font des appels distants, des builds de wsp…

On passe en revue toutes les possibilités des tests unitaires. Si un test échoue, on peut par exemple avoir un screenshot du navigateur au moment de l’échec ou même une vidéo, …

Il est possible de faire quasiment ce que l’on veut: exécuter SPDisposeCheck sur la solution ou tout autre utilitaire.

Les tests unitaires peuvent être exécutés avec MSTest.exe.

Les best practices :

  • Mettre en place ce process dès le début du projet (trop compliqué et couteux à mettre en place après coup)
  • Faire des builds automatiques le plus souvent possible pour avoir un feedback rapide

Pour conclure, les builds automatiques et les tests unitaires représentent un réel intérêt pour que la réalisation du projet se passe sans encombre, même si leur mise en place augmente sensiblement la durée des développements.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s