La réussite de vos projets SharePoint passe par une intégration continue (Part 1/2)
Par Lionel Limozin, posté le 11/11/2011
Profil : Développeur | Niveau : Confirmé (300)
Tags : Sharepoint, TFS, Tests unitaires |
Partager : 
Connaissez-vous l'intégration continue ? Avez-vous des doutes sur ses intérêts et avantages ? Je ne chercherais pas à répondre à ces questions dans cet article car vous en trouverez certainement des dizaines voire même des centaines bien plus pertinents que le mien. Malgré tout, afin de planter un minimum le décor, voici pour faire simple la définition de Wikipédia :
Par contre, une fois que vous aurez fait ces recherches, je ne doute pas que vous soyez au moins autant convaincu que moi. Alors peut-être à ce moment vous vous demanderez : « Comment mettre en place ce type de processus d'intégration continue avec des projets SharePoint ? ». Dans ce cas, cet article est pour vous !
Je vais vous guider sur les outils à utiliser et comment les utiliser pour mettre en place une compilation, un déploiement et des tests, tout ceci de manière automatique, pour vos projets dédiés à la plateforme SharePoint 2010.
Ce processus fera appel à la plateforme Team Foundation Server, en particulier l'aspect "Build" automatique permettant de séquencer un ensemble d'actions telles que « compilation », « exécution de processus externe », « création de WorkItems », « exécution de tests unitaires ».
1 - Pré Requis
Ferme SharePoint :
Le but du jeu est de pouvoir compiler une solution de code pour SharePoint 2010. Les projets Visual Studio 2010 pour SharePoint 2010 sont des projets de type Libraire de classes (DLL .NET) "classique", ou presque. En général le code embarqué dans ces solutions utilise l'API SharePoint 2010. Donc il faut que ce code soit compilé et éventuellement exécuté sur un serveur SharePoint pour bien fonctionner. Sinon le processus MSBuild ne va pas trouver les références de notre projet et donc la compilation échouera.
Il est donc nécessaire de disposer d'une ferme SharePoint 2010, à minima une seule machine, qui va être dédiée à cette phase d'intégration continue. Selon votre politique et fréquence de compilation de vos projets, vous pouvez (ou pas) prévoir d'utiliser cette ferme pour que les testeurs fonctionnels viennent tester directement les développements intégrés. Cependant soyez vigilants de ne pas leur compliquer la tâche en leur demandant de réaliser des tests alors que des compilations, déploiements, tests unitaires peuvent être déclenchés au même moment par le processus d'intégration continue.
Je ne détaillerai pas l'installation de SharePoint, ce n'est pas le sujet de l'article, mais il vous faut une installation correspondant à vos besoins d'intégration, donc dans la mesure du possible qui se rapproche d'assez près à la ferme de production finale.
Visual Studio :
Vous devez installer un Visual Studio 2010 sur la machine que vous dédiez à l'intégration afin que l'agent de Build soit capable de compiler correctement vos projets. De plus il est recommandé que la version du Visual studio soit la même que celle de votre équipe de dev en particulier en terme de service pack.
Team Foundation Server 2010 :
Enfin vous devez aussi disposer d'une plateforme Team Foundation 2010 avec le contrôleur de code sources, les WorkItems, les tests, etc. Là encore je ne détaillerai pas la partie installation de TFS Server.
Compte utilisateur :
Il vous faudra un compte de service (compte A.D.) qui sera à la fois :
· membre du groupe TFS autorisant l'exécution de Builds (et à fortiori accès aux sources des projets à compiler)
· membre du groupe administrateurs de la ferme sur votre SharePoint d'intégration (afin d'autoriser le déploiement des solutions SharePoint)
De plus afin de permettre à cet utilisateur d'exécuter des opérations SharePoint via PowerShell (ce qui nous sera utile) il faut prévoir de lui accorder les droits via la commande Add-SPShellAdmin. (Voir KB http://labs.bewise.fr/kb/Donne-moi-les-droits-de-developper-sur-mon-serveur-SharePoint-2010/)
2 - Installation de Visual Studio Team Foundation Server 2010 (Build Service)
Vous devez installer, sur l'un des serveurs frontaux de votre ferme SharePoint, Visual Studio 2010 et Team Foundation Server (uniquement le Build Service). Cette étape est relativement simple. Il vous faut le programme d'installation de Microsoft Team Foundation Server 2010 qui inclut la partie "service de Build". Ce service est un exécutable capable de piloter les processus MSBuild et MSTest.
L'installation de TFS 2010 est simple, il faut suivre les étapes de l'assistant
A cette étape il ne faut sélectionner que la partie "Build Service"
A la fin de l'installation, vérifiez que vous avez coché la case permettant de lancer l'assistant de configuration de TFS :
L'assistant va vous permettre de configurer le contrôleur et l'agent et de décider sur quel serveur TFS vous vous connecterez :
Première étape : on choisit à quel serveur TFS on se connecte :
2nd étape : on choisit sur qu'elle collection on travaille. Cela signifie que le contrôleur de Build ne pourra déclencher des Builds sur ce serveur que si les sources sont placées dans cette collection. Pour le coup la notion de collection dans TFS nous permet de "limiter" quels projets peuvent êtres compilés sur quels serveurs.
Une étape de recherche d'éventuels autres contrôleurs / agents
Ici on configure le nombre d'agents. Ce qu'il faut savoir à ce propos:
· il n'y a qu'un seul contrôleur : c'est lui qui "déclenche" et pilote les Builds
· il y a de un à N agents : ce sont eux qui exécutent à proprement parlé les Builds et donc qui consomment de la ressource système. Le nombre d'agent vous permet de déterminer le nombre de processus de Build qui peuvent tourner en parallèle. Il vous faut donc trouver un juste milieu entre "temps d'attente" pour les développeurs (qui attendent de voir si la compil est passée ou pas) et "performance" du serveur. De toute façon les agents peuvent être ajoutés après coup, donc commencez par la valeur par défaut:
Il vous faut ici un compte utilisateur qui a accès aux sources dans votre serveur TFS mais aussi à qui vous devrez donner accès type "Administrateur de la ferme" à vos sites SharePoint sur lesquels seront exécutés les déploiements et tests automatiques (voir Pré requis) :
Cette étape lance une série de vérifications afin de valider votre configuration :
Si tout c'est bien passé vous avez droit à cet écran :
Enfin vous pouvez lancer la console d'administration de TFS :
Cette console vous permet de vérifier que le contrôleur et le(s) agent(s) sont opérationnels. Vous pouvez aussi modifier ici les propriétés que vous aviez configurées via l'assistant.
3 - Mise en place du script de déploiement de wsp pour SharePoint 2010
Le processus de compilation automatique saura compiler notre projet SharePoint 2010 : il sera exécuté sur un serveur où sont installés SharePoint et Visual Studio.
Le processus d'exécution des tests unitaires saura exécuter nos tests unitaires : encore une fois nous avons les prérequis nécessaires.
Mais il nous manque une étape intermédiaire afin que les tests soient pertinents :
Le déploiement de la solution SharePoint. En effet suite à la compilation, un fichier WSP est produit. Ce WSP doit être déployé au sein de la ferme SharePoint. Ce déploiement peut être fait via stsadm ou bien depuis 2010 via PowerShell. Ici l'objectif étant d'automatiser au maximum, nous allons utiliser un script PowerShell qui va déterminer s'il s'agit du 1er déploiement de ce WSP ou d'une mise à jour par exemple. Vous pouvez aussi avoir besoin d'activer des features qui sont déployées via cette solution. Selon les types d'éléments dans votre projet, les paramètres utilisés lors du déploiement sont à spécifier.
Bref il est difficile d'imaginer un script qui prend en charge tous les cas. Le mieux que j'ai trouvé pour l'instant est de m'imposer une règle de nommage sur un fichier ps1 qui sera inclus dans mon projet. Comme cela, pour chaque projet SharePoint différent, les développeurs peuvent inclure dans ce fichier le script adapté spécifiquement au déploiement de ce projet, et côté Build on cherchera systématiquement un fichier ps1 d'un nom particulier (par exemple deploy.ps1) et on l'exécutera.
A titre d'exemple je vous propose ici un script qui prends en entrée un chemin de répertoire et qui cherche à déployer tous les WSP présents dans ce répertoire :
$snappin = get-pssnapin | where-object {$_.Name -eq "Microsoft.SharePoint.PowerShell"}
if($snappin -eq $null)
{
& "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\sharepoint.ps1"
}
$initialDirectory = $args[0]
Write-Host "Searching wsp in " $initialDirectory
$wsps = Get-ChildItem $initialDirectory\*.wsp
foreach($wsp in $wsps)
{
if($wsp -ne $null)
{
Write-Host "Start installation process for solution " $wsp.Name "..."
$solution = Get-SPSolution | where-object {$_.Name -eq $wsp.Name}
# check to see if solution package has been installed
if ($solution -ne $null)
{
# check to see if solution package is currently deployed
if($solution.Deployed -eq $true)
{
Write-Host "retracting " $solution.Name
Uninstall-SPSolution $solution.Name -AllWebApplications -confirm:$false
while ( $solution.JobExists )
{
Write-Host "."
sleep 1
}
}
Write-Host "uninstalling " $solution.Name
Remove-SPSolution $solution.Name -confirm:$false
}
Write-Host "installing " $wsp.Name
Add-SPSolution $wsp
$solution = Get-SPSolution | where-object {$_.Name -eq $wsp.Name}
Write-Host "deploying " $solution.Name " on all webapps"
Install-SPSolution -Identity $solution.Name -GACDeployment -AllWebApplications -Force
while ( $solution.JobExists )
{
Write-Host "."
sleep 1
}
$solution = Get-SPSolution | where-object {$_.Name -eq $wsp.Name}
if($solution.Deployed -ne $true)
{
Write-Host "deploying " $solution.Name " on no webapp"
Install-SPSolution -Identity $solution.Name -GACDeployment -Force
while ( $solution.JobExists )
{
Write-Host "."
sleep 1
}
}
Write-Host "Ended installation process for solution " $wsp.Name
}
}
Nous verrons plus loin comment on utilise ce script.
Suite de l'article ici : http://labs.bewise.fr/Article/la-r%C3%A9ussite-de-vos-projets-sharepoint-passe-par-une-int%C3%A9gration-continue-part-2-2/
