Ce billet est la troisième et dernière partie de cette série sur l’intégration et le déploiement continu avec TeamCity, Bitbucket et Azure. Pour comprendre ce billet, vous devez lire les deux billets précédents dont voici les liens :
- Intégration et déploiement continu avec TeamCity, Bitbucket et Azure, partie 1 : intégration continue
- Intégration et déploiement continu avec TeamCity, Bitbucket et Azure, partie 2 : Packaging
Désormais que nous sommes en mesure de générer un package de déploiement de notre application à chaque Build, il sera maintenant question de procéder au déploiement de ce dernier sur Azure.
Pour cela, nous allons ajouter une nouvelle Build Configuration a notre projet. Pour éviter d’avoir à refaire certaines configurations, nous allons utiliser les paramètres de la précédente Build Configuration, pour notre nouvelle Build Configuration. Pour le faire :
- Depuis la page d’administration de votre Build dans TeamCity ;
- Cliquez sur le bouton Actions puis sur « Copy Configuration » ;
- Dans la fenêtre qui s’affiche, entrez le nom de la « Build Configuration ;
- Cliquez sur Ok, pour enregistrer les modifications.
Nous allons apporter quelques changements à cette nouvelle « Build Configuration » que nous avons créée.
La première chose à faire sera l’ajout d’une dépendance avec la Build Configuration précédente. L’objectif est de permettre de lancer la tâche de déploiement uniquement après que l’étape de Build se soit effectuée correctement. Pour le faire :
- Cliquez sur « Dependencies » ;
- Puis sur « Add new snapshot dependency » ;
- Dans la fenêtre qui s’affiche, sélectionnez votre build ;
- Et cliquez enfin sur Save.
Pour garder une certaine cohérence dans la numérotation des Builds, vous allez modifier les paramètres généraux de votre Build et éditer la zone « Build number format » pour saisir « %dep.NomdeVotreProjet_NomDeVotreBuild.build.counter% ».
Exemple : %dep.Teamcity_Build.build.counter%.
En procédant ainsi, vous serez en mesure d’identifier quelle Build a été déployée, et de ce fait le commit en rapport avec cette dernière.
Vous allez ensuite supprimer le trigger qui a été repris de la configuration précédente. S’il reste actif, à chaque modification de votre repository, le déploiement se fera automatiquement après la Build. En fonction de votre stratégie de déploiement continue, vous pouvez bien évidement décider de maintenir ce trigger.
Passons maintenant à la création de la Build Step qui permettra le déploiement de votre application dans Azure. Revenez sur la page de votre Build Configuration, cliquez sur « Build Steps » dans le menu à gauche. Cliquez ensuite sur « Add build step ». Dans la fenêtre qui va s’afficher :
- Sélectionnez « Command Line » dans la zone « Runner type » ;
- Renseignez le champ « Step name » ;
- Saisissez les informations suivantes dans la zone de saisie « Custom script ».
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:package='artifacts\WebDeploy\Integration\TeamCityTest.zip' -dest:auto,computerName="https://teamcitytest.scm.azurewebsites.net:443/msdeploy.axd?site=teamcitytest",userName="userName",password="pwd",authtype="Basic",includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension
Pour récupérer les informations nécessaires à la création de votre profil de publication, vous pouvez :
- vous connecter au portail Microsoft Azure ;
- accéder à la liste des « App Services » ;
- sélectionner votre application Web ;
- cliquer sur Obtenir le profil de publication dans la boite d’outils pour télécharger les informations sur votre profil de publication.
Ceci fait, pour lancer le déploiement de votre application, vous pouvez simplement vous positionner sur la dernière Build qui s’est effectuée avec succès, puis cliquer sur Actions, ensuite sur Promote.
Puisque nous avons mentionné que notre Build Configuration de déploiement dépend de cette Build, TeamCity affichera dans une fenêtre le nom de la build de déploiement. Vous n’aurez plus qu’à cliquer sur Run pour lancer le déploiement.
En fonction de vos environnements (par exemple : Dev, Préprod, Prod) vous pouvez créer plusieurs Build Configuration de déploiement. Par exemple, si vous disposez d’un Serveur Azure pour les développeurs, vous devez créer une Build configuration pour les déploiements qui dépendra de la Build Configuration de l’intégration continue. Le déploiement pourrait se faire automatiquement sur le serveur de développement. Ensuite, pour les testeurs, vous allez créer une Build configuration qui dépendra de la build configuration Dev.
Lorsque votre application sera prête pour la préproduction, vous allez simplement promouvoir la build correspondante dans la build configuration Dev.
