This post is available in english.
Construire des applications pour Windows Phone 7 de manière agile encourage l'utilisation de l'Intégration Continue, et cela peut être fait avec Team System 2010.
Il y a cependant quelques éceuils à éviter pour y arriver, mais une fois évités cela donne de bons résultats !
Je ne couvirais pas toutes les bonnes choses des builds automatisés, cela a déja été couvert largement.
Ajouter des Tests Unitaires
Avec l'intégration continue pour faire des builds qui terminent avec succès après chaque "Check-in" de code source, il y a aussi l'exécution automatisée de tests unitaires. Team System donne la possibilité de connaitre la couverture de code des tests unitaires qui ont été executés, et d'en faire des rapports avec Reporting Services, ou des statistiques peuvent être consultées et qui donnent quelques bons indicateurs de la santé du projet.
Cela dit, malheureusement pour nous, il n'existe pas pour le moment de moyen pour automatiser l'exécution de tests en utilisant le runtime de Windows Phone 7. Mais si une bonne approche MVVM est utilisée, les View Models peuvent etre compilés sur plusieurs plateformes, puisqu'ils ne dépendent pas de composants spécifiques à la plateforme WP7. De cette manière, il est toujours possible de tester le code en utilisant le runtime de .NET 4.0 avec MSTest et les Projets de test de visual Studio 2010.
Pour éviter de répeter le code, des fichiers "Multi-targeted" peuvent être intégrés dans plusieurs projets qui ne visent qu'une seule plateforme soit en :
- Utilisant l'outil Project Linker, en liant plusieurs projets,
- En créant plusieurs fichier de projet dans le même répertoire et en utilisant le menu "Include File" dans le "Solution Explorer". Il faut aussi s'assurer de changer le nom de sortie de l'assembly pour quelque chose comme "MyAssembly.Phone.dll" pour éviter les conflits.
Les fichiers "Multi-Targeted" peuvent utiliser la directive #if, et le define WINDOWS_PHONE ou bien son absence, pour compiler pour la bonne plateforme.
Il est existe aussi d'autres options comme la création de projets avec l'add-in Portable Library, mais il y a quelques problèmes d'intégration et contraintes en utilisant cette méthode. Vous auriez probablement besoin d'externaliser du code qui n'est pas supporté.
Tester avec MSTest permet de s'assurer que le code s'execute correctement sur le runtime .NET 4.0, mais ne s'assure pas de son bon fonctionnement sur le runtime WP7. Pour en être certain, et puisque Windows Phone 7.0 est construit sur Silverlight 3, des outils comme le Unit Test framework pour SL3 peuvent être utilisés pour executer manuellement les test dans l'émulateur.
Cela ne peut pas être intégré dans le processus de build pour l'instant. Cette étape devra donc être intégrée dans votre processus de QA.
TeamBuild avec le Toolkit WP7
Pour pouvoir compiler des applications WP7 sur une machine de build, il faut installer le SDK puis un controlleur et/ou agent de Team Build.
Créer une définition de build se fait de la même manière que pour des builds normaux, à l'exception d'un seul détail. Vous devez configurer le paramètre MSBuild platform à x86 au lieu de Auto si la machine de build est un Windows 64 Bits. Cela force MSBuild à utiliser le runtime 32 bits et non 64 bits ou le SDK ne fonctionne pas proprement.
Si vous le ne faites pas, lorsque le projet sera compilé, vous aurez d'étranges messages comme celui ci :
Could not load file or assembly 'System.Windows, Version=2.0.5.0'
Qui est vraiment étrange puisque le SDK est installé, et que ce fichier est bel et bien disponible.
Vous pourrez aussi voir que si vous installez cette DLL du SDK dans le GAC, vous aurez ce beau message :
Common Language Runtime detected an invalid program.
Message très commun lorsque l'on mixe des assemblies 32 et bits, en particulier lorsque l'architecture a été spécifiée explicitement, au lieu de "Any CPU". N'installez donc pas cette DLL dans le GAC et assignez l'architecture à x86.
C'est tout pour cette fois, et bon WP7 building !
