Introduction
Depuis plusieurs articles j’évoque le fait que nous (Negotium, la compagnie où je travaille) avons migré vers visual studio online (TFS Online). Ce service offre une majorité des fonctionnalités offertes par la version on premises de Team Foundation Server 2013 et même certaines fonctionnalités exclusives.
Si vous n’avez qu’une vague idée de ce que peut faire TFS2013/VSO et que vous voulez en apprendre plus je vous recommande très fortement Professional Application Lifecycle Management de chez Wrox.
Les grands axes de Visual Studio Online
De manière générale TFS2013/VSO s’articule et intègre fortement les uns avec les autres les axes suivants :
- Planification : Permet de planifier le travail à effectuer (agile ou cascade,…), suivre l’avancement, voir l’évolution de la capacité de travail…
- Code : Permet de centraliser le code, suivre l’évolution du code, tout ce que faire un contrôle de code source digne de ce nom de manière générale.
- Compilation : Permet de générer des versions compilées et versionées du code, suivies, avec un résumé des changements.
- Tests : Permet de s’assurer de la qualité des versions en exécutant des tests unitaires, des déploiements, des tests fonctionnels automatisés ou non.
Méthodologie de mise en place
Bien évidement tous ces éléments sont liés les uns aux autres ce qui permets des scénarios du genre « tel test automatisé utilise telle portion du code et a planté, remontée des rapports et des traces au développeur concerné et ajout des éléments pour suivre la correction du bug ».
Quand on commence à apprendre comment fonctionne cette industrie logicielle on s’aperçoit qu’il faut mettre les choses en place dans un certain ordre. En Juillet nous avons migré notre code existant (ok pas dans l’ordre mais dû à la migration), tout de suite après ça nous avons reconsolidé nos backlogs et réorganisé les équipes en scrum. Nous étions déjà en scrum par le passé mais suite à de nombreux mouvements d’équipes, la méthodologie s’était un peu relâchée.
Compilation automatisée – avantages
L’étape suivante était donc la mise en place de compilation automatisée avec les objectifs principaux suivants :
- Suivit, versionnement et constitution de notes de versions des livrables (déjà fait mais à la main)
- Avancer vers la mise en place de tests automatisés
- Gain de temps
Les options avec Visual Studio Online
Vous avez deux possibilités pour effectuer de la compilation automatisée avec Visual Studio Online :
- Utiliser le service de build préconfiguré en ligne
- Configurer votre propre machine et la connecter au service
L’avantage évident du service de build hébergé c’est de ne pas avoir à passer du temps en configuration de l’environnement et de ne payer que pour les minutes de compilation que vous consommez et non pour le reste du temps où la machine serait inutilisée.
Si l’on se fie à cette page https://www.visualstudio.com/en-us/get-started/hosted-build-controller-vs.aspx#software il est indiqué que SharePoint 2010 et 2013 (ainsi que de nombreux autres composants) sont installés sur les environnements de build fournis par Visual Studio Online. J’ai donc naturellement commencé à configurer mon plan de build pour utiliser ce service.
Cependant ce qui n’est pas préciser c’est que l’édition de SharePoint installée est Foundation. Mon projet se basant sur certains des dll’s de l’édition Server (publication, traduction…) deux choix s’offraient à moi :
- Embarquer une copie locale des dll’s manquantes sur mon contrôle de code source
- Monter ma machine de build
Il est évident qu’embarquer les dll’s manquantes va nettement alourdir le poids des sources, risque de causer des conflits et nécessitera de les mettre à jour régulièrement. Je me suis donc tourné vers la seconde option.
Configurer sa machine de build pour SharePoint Server 2013 (full trust)
Les étapes de configuration de la machine de build ne sont pas si compliquées que ça ce que j’ai eu à faire :
- Installer SharePoint server 2013 (uniquement les binaires, pas de psconfig à passer)
- Installer Visual Studio 2013
- Installer les Office dev tools (depuis web platform installer)
- Installer le contrôleur et l’agent de build TFS, puis le connecter à mon visual studio online (https://msdn.microsoft.com/en-US/library/ms181712#deploy )
Première erreur : version passée par MSBuild
Une fois terminé j’ai eu le droit à un beau message d’erreur de ce genre : cannot find build process template for project type SharePoint…
Ceci est dû au fait que pour je ne sais quelle raison, le framework MSBuild (c’est la technologie qui gère le processus de build) estime que c’est la version 11 (2012) de visual studio qu’il faut utiliser. Cela ne correspond pas à la version de visual studio et des outils de développement Office installés.
Pour fixer ce problème il suffit d’éditer la définition de build, dans l’onglet process, puis avancé, puis spécifier /p:VisualStudioVersion=12.0 pour MS Build Arguments.
Seconde erreur : Version du tooling SharePoint
Une fois que c’est fait, une autre erreur, principalement liée au même problème : avec l’arrivée de la nouvelle version de workflows, les process templates de workflows traditionnels ont été déplacés mais les références pas mises à jour. Je suis d’ailleurs surpris que 2 ans après la sortie des première versions des outils cela n’ait toujours pas été corrigé.
Commencez par faire un backup du fichier C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\SharePointTools\Microsoft.VisualStudio.SharePoint.Workflow.targets puis éditez le.
Au lignes 37 et 38 remplacez
<Import Condition="'$(Language)' == 'C#'" Project="$(MSBuildFrameworkToolsPath)\Workflow.Targets" />
<Import Condition="'$(Language)' == 'VB'" Project="$(MSBuildFrameworkToolsPath)\Workflow.VisualBasic.targets" />
Par
<Import Condition="'$(Language)' == 'C#'" Project="$(MSBuildFrameworkToolsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets" />
<Import Condition="'$(Language)' == 'VB'" Project="$(MSBuildFrameworkToolsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.VisualBasic.targets" />
Mot de la fin
Et voilà! Maintenant les builds automatisés de projets full trust pour SharePoint Server 2013 sont en place. A noter que c’est valable pour Team Foundation Server 2013 comme pour Visual Studio Online. Aussi ma machine de build est hébergée dans Azure mais qu’elle pourrait l’être on prem dans les deux cas de figure.
La prochaine fois je vous parlerai probablement d’incrémentation des numéros de version des assemblies et/ou de scripts pré/post build puisque ce sont les deux éléments qui me manquent avant de pouvoir commencer à mettre en place du test automatisé.