Nous avons vu dans un précedent article comment installer un serveur de Build et lancer des compilations automatiquement, aujourd'hui nous allons nous servir de ce serveur pour déployer une application ASP.net.

Encore une fois, cet article est basé sur mon usage personnel. Il ne faut pas voir cet article comme un "tutorial" pas à pas, mais comme un exemple des possibilités apportées par TFS Build, à vous ensuite d'en tirer le maximum pour vos projets !

Automatisation du déploiement

Pour pouvoir déployer, je me base sur Web Deploy, qui permets de déployer une application dans IIS directement depuis Visual Studio. La configuration de Web Deploy dépasse le cadre de cet article, je vous renvoie donc sur la documentation officielle si vous souhaitez plus d'informations. (Vous pouvez utilisez un autre système de déploiement, tant que vous passez par les profils de publication Visual Studio)

Maintenant, dans Visual Studio, faites un clic droit sur le projet, et "Publish". Un assistant de publication va se lancer, qui va vous permettre de configurer le déploiement.

Assistant de publication

Mettez les bonnes valeurs, et fermez l'assistant. Un fichier .pubxml est créé dans le répertoire /Properties/PublishProfiles/ de votre projet. C'est ce fichier qui va permettre au serveur de build d'effectuer le déploiement.

Maintenant, retournez dans Team Explorer, et créez une nouvelle définition de build. Si vous ne vous souvenez plus comment faire, je vous laisse relire mon précédent article.
Il va falloir faire des changements par rapport au mode intégration continue : déjà changez le trigger (il est rare de vouloir déployer à chaque check-in), pour passer en manuel.
Ensuite, allez modifier la section Process, à Build-Advanced, vous pouvez spécifier des arguments à faire passer à MSBuild. Ajoutez la ligne suivante :

/p:DeployOnBuild=true;PublishProfile=[nom du profil de publication];Password=[mot de passe du serveur]

MSBuild arguments

Les arguments passés sont les suivants :

  • DeployOnBuild=true : demande à MS Build d'effectuer le déploiement lorsque la compilation est terminée
  • PublishProfile : le nom du profil de publication créé dans Visual Studio (le nom du fichier .pubxml, sans l'extension)
  • Password : le mot de passe de l'utilisateur pour se connecter au serveur (nécessaire ici, car il n'est pas enregistré dans le fichier .pubxml)

Et c'est bon, vous devez avoir maintenant deux définitions de Build : une qui compile le projet à chaque check-in, et une qui compile et déploie le projet à la demande.

Pour effectuer un déploiement, vu qu'on a mis un trigger manuel, il faut faire un clic droit sur la définition de build et "Queue new build" (dans Visual Studio ou sur l'interface web).
Vous pouvez aussi par exemple faire un déploiement automatique quotidien sur un serveur de test (ou de prod, si vous êtes joueur) en changeant le trigger.

Déploiement à heure fixe

Quand j'ai parlé de déploiement automatisé, on m'a posé la question suivante : est-il possible de programmer un déploiement pour qu'il se fasse pendant la nuit ?
En effet, l'application qu'ils développent utilise de nombreuses variables de sessions, qui sont détruites lors du déploiement, et provoquent des bugs chez les utilisateurs. Pour déployer, ils restent donc tard le soir jusqu'à ce qu'il n'y ait plus d'utilisateur connecté.

La bonne solution à ce problème serait de stocker les variables de session sur un serveur d'état ou dans SQL Server ; mais cela nécessite de nombreux tests et corrections sur l'appli existante (tout objet stocké en session doit être sérialisable, ce qui n'est pas forcément le cas).
En attendant de terminer tout ça, j'ai donc fait un système de programmation de déploiement.

Si vous utilisez Git ou TFVC pour stocker vos codes sources, la manoeuvre sera différente. Nous allons voir les deux.

Avec Git

Lors de la création de la définition de build, vous avez sûrement vu dans la section Source settings que vous pouviez définir la branche à compiler. On va se servir de cette option pour notre déploiement.

Créez une nouvelle branche publication, et demandez à la définition de build de récupérer le code dans cette branche-là.

Branche de publication

Et modifiez le trigger pour que la publication se fasse chaque nuit. Ne cochez pas la dernière case, afin de ne pas lancer une publication s'il n'y a pas eu de modification dans la journée.

Trigger de publication

Votre définition de build est prête, lorsque vous souhaiterez déployer l'application, il vous suffira de pousser votre code dans la branche publication de TFS. Vous pouvez continuer à travailler sur d'autres branches sans problème.

Avec TFVC

Avec Team Foundation Version Control, on ne va pas pouvoir utiliser les branches, ça va être un peu plus compliqué. Comme il n'existe pas de moyen natif pour programmer une build, on va devoir ruser.

Au début de cet article, je vous ai fait faire un profil de déploiement utilisant Web Deploy. Il va falloir le changer : changez la méthode par Web Deploy Package. Au lieu de déployer directement, on va simplement créer un package.

Assistant de publication - package

Inutile de définir l'emplacement du package, TFS ne tiendra pas compte de cette valeur, il stockera le package avec les binaires compilés sur le serveur - par défaut dans C:\Builds.

Lancez une compilation, et allez chercher le package dans le serveur de Build. Le chemin devrait ressembler à quelque chose comme ça :

C:\Builds\12345\Projet\Deploiement différé Projet\bin\_PublishedWebsites\Projet_Package

Le chemin semble compliqué, mais vous devriez retrouver facilement. Les dossiers correspondent à l'id du serveur de compilation dans TFS, le nom du projet TFS, le nom de la définition de build. Le reste représente le résultat de la compilation.

Ce dossier contient plusieurs fichiers, les plus importants sont le fichier .zip, qui contient l'application prête à publier, et le fichier .cmd qui est un script qui effectuera le déploiement. Un fichier deploy-readme.txt est aussi présent, avec la documentation nécessaire au déploiement en ligne de commande.
Pour programmer notre déploiement, on va créer un fichier .bat qui va faire le déploiement, et créer une tâche planifiée dans Windows qui l'appellera tous les jours, à un horaire où personne n'est connecté.

cd C:\Builds\12345\Projet\Deploiement différé Projet\bin\_PublishedWebsites\Projet_Package

if exist Projet.deploy.cmd (
	Projet.deploy.cmd /Y /M:http://app.lacasa.fr/msdeploy.axd /U:deployUser /P:toto1234
	del Projet.deploy.cmd
)

Dans ce fichier .bat, on appelle le fichier .cmd en lui passant les paramètres nécessaires au déploiement : l'url du service Web Deploy, et le nom d'utilisateur et mot de passe du server.
Une fois le déploiement terminé, on supprime le fichier .cmd, pour ne pas republier le même projet chaque jour.

Enregistrez ce fichier, et ouvrez le planificateur de tâches (Exécuter - taskschd.msc). Créez une nouvelle tâche planifiée, qui se déclenche tous les jours, et qui exécute le fichier .bat

Trigger tâche planifiée Action tâche planifiée

Et c'est bon, vous pouvez lancer cette définition de build, qui va compiler le projet et créer un package, qui sera déployée tout seul la nuit prochaine.