Hello !
Un sujet d’actualité aujourd’hui, suite au récent rachat de GitHub par Microsoft, avec la configuration d’un pipe DevOps à partir d’un projet GitHub et en bonus la présentation des slots de déploiement Azure.
Nous allons donc brancher VSTS sur un projet de mon dépôt GitHub.
On commence par créer un nouveau projet :
Initialisation du dépôt :
![Azure Web App Deployment Slots 2 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/2-1.png)
Sélectionner Build and Release > Build > New pipeline et choisir GitHub 🙂
![Azure Web App Deployment Slots 3 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/3-1.png)
Il s’agit toujours d’un projet ASP.NET Core :
![Azure Web App Deployment Slots 4 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/4-1.png)
On pense à décocher “Publish Web Projects” qui ne concerne pas le type de projet WebAPI :
![Azure Web App Deployment Slots 5 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/5-1.png)
Et on lance une build !
![Azure Web App Deployment Slots 6 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/6-1.png)
Nous pouvons maintenant configurer notre Release. Build and Release > Release > New definition. Nous allons choisir un template un peu différent de ce que nous avons déjà testé jusqu’a présent !
![Azure Web App Deployment Slots 7 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/7-1.png)
Je relie ma release à ma build :
![Azure Web App Deployment Slots 8 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/8-1.png)
Je met en place le déploiement continu :
![Azure Web App Deployment Slots 9 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/9-1.png)
Petite pause dans la configuration VSTS, nous devons également paramétrer notre Web App Azure !
Je choisis de créer une Web App et je remplis les informations habituelles :
![Azure Web App Deployment Slots 10 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/10-1.png)
Une fois ma Web App créée je vais paramétrer un emplacement de déploiement. Ceux-ci sont bien utiles quand il s’agit d’avoir à disposition un environnement de test iso à la production. Ces emplacements de déploiements sont des “sous applications” appartenant au même service plan que votre Web App.
![Azure Web App Deployment Slots 11 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/11-1.png)
J’ajoute un environnement “preprod” identique à la production :
![Azure Web App Deployment Slots 12 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/12-1.png)
J’ai désormais deux environnements à ma disposition, donc deux URL. La deuxième étant taggé avec le suffixe “preprod” qui correspond au nom de mon slot :
![Azure Web App Deployment Slots 13 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/13-1.png)
Et ma Web App de production :
![Azure Web App Deployment Slots 14 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/14-1.png)
Je peux vérifier que mes deux Web Apps sont fonctionnelles :
Passons à la configuration de ma release !
Je remplis comme d’habitude Azure Subscription, le nom de ma Web App et du groupe de ressource associé mais je dois en plus choisir sur quel slot déployer mon application !
![Azure Web App Deployment Slots 16 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/16-1.png)
Je choisis dans un premier temps de déployer sur preprod :
![Azure Web App Deployment Slots 17 2 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/17-2.png)
Je pense à modifier le package à déployer :
![Azure Web App Deployment Slots 19 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/19-1.png)
Et je vais désactiver la deuxième étape du déploiement. Cette étape effectue un échange entre ces deux environnements, mais ici je ne veux pas que ce swap soit fait automatiquement …
![Azure Web App Deployment Slots 21 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/21-1.png)
Ma release est prête !
J’effectue une demande de déploiement :
![Azure Web App Deployment Slots 23 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/23-1.png)
Release en cours !
![Azure Web App Deployment Slots 24 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/24-1.png)
J’ai des informations détaillée sur le déploiement via l’onglet Logs :
![Azure Web App Deployment Slots 25 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/25-1.png)
Une fois le déploiement terminé, j’obtiens sur mon environnement “preprod” :
![Azure Web App Deployment Slots 26 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/26-1.png)
Mon application est donc opérationnelle sur cet environnement !
Sur l’URL “prod” en revanche :
Rien n’a changé ! C’est ce que nous voulons. Nous avons donc une version N-1 en production et une version N en preprod.
Je peux donc valider tranquillement le fonctionnement de mon API REST. En cas d’erreur, ma production n’est pas impactée et je peux apporter mes modifications. Une fois que tout est testé / vérifié / validé nous pouvons échanger nos environnements.
je retourne sur ma Web API :
![Azure Web App Deployment Slots 27 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/27-1.png)
Et je clique sur le bouton Échanger à droite du bouton Arrêter. Je n’ai plus qu’un clic à faire pour swapper entre mes deux environnements !
![Azure Web App Deployment Slots 28 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/28-1.png)
Ma preprod est maintenant devenu la prod et inversement. Mon environnement de preprod contient maintenant la version N-1 de mon application tendis que la prod est en version N.
![Azure Web App Deployment Slots 30 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/30-1.png)
En cas d’anomalie détectée un peu tard, je n’ai qu’a reproduire l’opération pour que mes utilisateurs récupèrent immédiatement la version N-1 de l’API !
Dernier sujet aujourd’hui, la fonctionnalité “Test en production”. Reprenons notre déploiement de tout à l’heure avec :
- En preprod : version N
- En prod : version N-1
Je peux grâce à cette fonctionnalité orienter un certain volume du trafic utilisateur vers la version de preprod à la place de la production. Ainsi un certain pourcentage des utilisateurs vont pouvoir tester en condition réelle la nouvelle version de l’API. Une fois que le test me semble concluant, je peux procéder au swap !
![Azure Web App Deployment Slots 29 1 - Azure Web App Deployment Slots](http://thomasrannou.azurewebsites.net/wp-content/uploads/2018/08/29-1.png)
Récapitulons les avantages de ces emplacements de déploiements :
- Pas d’intéruption de service pendant un déploiement. Tout est transparent pour l’utilisateur.
- Possibilité de tester sur un emplacement dans les mêmes conditions que la production. Quand les tests sont validés, on opère le swap des environnements.
- Possibilité de rediriger progressivement le flux des utilisateurs pour tester la nouvelle version et vérifier qu’elle répond correctement à l’augmentation du trafic réseaux.
- Suite au swap, l’emplacement “preprod” contient la version qui était en production. Ainsi, en cas d’anomalie un rollback est facile à opérer.
Cette notion de deployment slot est une mise en oeuvre concrète des patterns “Blue/Green Deployment” et “Canary Release“. Je vous laisse suivre les liens pour une approche plus théorique du sujet 🙂