Automatiser la publication de sites Web
Dans un contexte de relation développeur / testeur il est pratique de mettre en place un système de déploiement continu permettant de garder les différentes versions d’un site Web accessibles en parallèle.
Il faut donc être capable d’automatiser le déploiement d’une application Web de manière quotidienne afin de permettre aux utilisateurs/testeur de naviguer sur les différentes versions et surtout de pouvoir accéder à tout moment à une version « à jour », le tout afin d’éviter ce genre de dialogue :
- Utilisateur Testeur : Je ne comprends pas, ce bug que j’ai remonté la semaine dernière n’est toujours pas corrigé ?
- Développeur : Si si, j’ai archivé la modification dans le contrôleur de sources, mais il faut que je publie en environnement de test pour que tu t’amuses
- Utilisateur Testeur : Ben vas y, publies !
- Développeur : Grumblbl je n’ai pas le temps la, je suis sur autre chose
- Utilisateur Testeur : Et ceci, je suis sur que cela fonctionnait dans la version précédante
- Développeur : non, non, impossible ce n'a jamais été développé
- Utilisateur Testeur : si, si, je suis sur de l'avoir vu
- Développeur : ...
Alors, comment mettre tout ceci en place ?
Visual Studio Team System offre tout l’outillage pour faciliter la mise en application, assisté du format de description de compilation MSBuild.
Le modèle de projet d’ASP.NET 2.0 (basé sur système de fichier et compilé à la volée) ne facilite pas l’utilisation de MSBuild. Pour palier à ce problème, il suffit d’installer l'add-in à Visual Studio 2005 Web Deployment Project (http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx), fourni gratuitement par Microsoft, qui permet de scripter avec MSBuild la compilation de site Web. Je ne vais pas m’attarder sur son utilisation, elle est très bien décrite ici dans sa documentation pour son utilisation de base, le tout au travers d'un exemple (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/web_deployment_projects.asp).
Attention par contre à un problème fréquent: étant donné que le site Web se retrouve dans un modèle de compilation classique (à la ASP.NET 1.1, tout dans une DLL), il faut bien veiller à ne pas posséder deux classes qui s’appellent pareilles sous peine d’erreur (éviter de posséder une classe Default dans chaque répertoire par exemple, ce qui se fait intuitivement dans ASP.NET 2.0… il faut donc les renommer ou ajouter des namespaces).
Pour détailler le fonctionnement, WDP est en fait composé d’un ensemble de tasks MSBuild que vous pouvez explorer dans le répertoire d’installation « C:\Program Files\MSBuild\Microsoft\WebDeployment\v8.0 ». Elles sont décrites dans le fichier MSBuild « Microsoft.WebDeployment.targets » et utilisent massivement la DLL « Microsoft.WebDeployment.Tasks.dll » dans laquelle elles sont développées (merci reflector).
Un projet de déploiement Web n’est donc rien d’autre qu’un script MSBuild portant l’extension *.wdproj et utilisant des tasks MSBuild spécifiques, le rendant ainsi compilable aux cotés de vos autres projet: DLL, applis consoles, composants et autres dotneteries.
Comme définit dans la documentation, le script permet, en plus de compiler et de déployer votre site Web sur une autre machine, de créer un répertoire virtuel dans IIS pointant sur le résultat de la compilation (pratique).
A ce niveau, deux problèmes me sont apparut :
- L’assistant de WDP permet de spécifier un répertoire virtuel, mais uniquement de le créer dans le « Default Web Site » de IIS, ce qui n’est pas pratique quand celui-ci tourne en ASP.NET 1.1 alors que le site à déployer est en ASP.NET 2.0 et encore moins quand celui-ci est utilisé par WSS.
- Comment paralléliser et conserver les versions et créer un répertoire virtuel pour chaque nouvelle Build ?
Tout simplement en modifiant, à la main, le fichier de déploiement *.wdprojet :
- En ajoutant la propriété « VirtualDirectorySiteId » afin de spécifier le numéro de site web (ID qui l’identifie dans IIS) dans WDP ou le répertoire virtuel doit être créé.
- En modifiant la propriété « VirtualDirectoryAlias » pour que le répertoire virtuel porte le nom du Build généré
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugSymbols>false</DebugSymbols>
<OutputPath>.\Release</OutputPath>
<EnableUpdateable>true</EnableUpdateable>
<UseMerge>true</UseMerge>
<SingleAssemblyName>site_deploy</SingleAssemblyName>
<VirtualDirectorySiteId>1905380947</VirtualDirectorySiteId>
<VirtualDirectoryAlias>$(BuildNumber)</VirtualDirectoryAlias>
</PropertyGroup>
Une fois le site Web compatible pour le déploiement, il ne reste plus qu’a utiliser l’assistant graphique de création de Build présent dans Team Explorer pour packager le tout (http://msdn2.microsoft.com/fr-fr/library/ms181716(VS.80).aspx ), et, pour rendre le build automatique et quotidien, de créer une tâche planifiée sur le serveur de Build (un .bat bien pratique est présent ici : http://blogs.msdn.com/abhinaba/archive/2005/11/21/495179.aspx )
Prochaine étape : créer une Task MSBuild pour ajouter automatique un lien pointant sur l'url de la nouvelle version dans une liste du portail d’équipe WSS. (A suivre…)
