Partie 4 : Les détails de notre configuration sur Azure Devops
Vous l’avez fait, vous avez un environnement de travail, des ressources sur le portail Azure, du code hébergé sur Azure Devops, une build automatique qui se fait et même un déploiement… Mais peut-être souhaiteriez vous en savoir plus sur tout ces processus qui se sont fait automatiquement « par magie ».
Il est important de comprendre comment ça fonctionne car vous serez peut-être amené à changer une pipeline ou à les faire vous même de A à Z.
Sommaire de la quatrième et dernière partie
- Azure Devops : les pipelines
- Azure Devops : les release
- FAQ
Azure Devops : les pipelines
Rendez-vous sur Azure Devops et cliquez sur « Pipelines », dans le menu à gauche.
Vous retrouverez ici toutes vos pipelines. Azure Pipelines, c’est un service que l’on utilise pour builder et tester automatiquement notre code et le mettre à la disposition d’autres utilisateurs (source).
C’est à dire ? Pour avoir un exemple plus concret, cliquez sur le pipeline qui a automatiquement été créé. Dans mon cas il s’appelle « gwf-test-dev-wa – CI ». Cliquez ensuite en haut à droite sur « Edit ».
Nous somme dans l’onglet « Tasks » qui décrit les étapes de notre pipeline. Premièrement, le pipeline se base sur les sources de notre repos « MaPremiereWebApp », comme nous pouvons le voir en cliquant sur « Get Sources ». Nous retrouvons la configuration que nous avons renseigné sur le portail Azure à l’étape de liaison des sources, vous vous souvenez ?
S’en suit plusieurs étapes, tel que l’installation et la mise en cache de node, via la tâche « Use Node Version », l’installation des dépendances de notre code… jusqu’à la publication de l’artefact. L’artefact, c’est un « package » qui contient notre code et ses dépendances. Il sera ensuite utilisé pour le déploiement sur notre serveur. Ici notre artefact s’appelle « Drop ».
Azure Devops : les release
Dans le menu à gauche, dans la catégorie « Pipelines », cliquez sur « Releases ».
Cliquez ensuite sur « View all releases pipeline » qui est représenté par un dossier, puis cliquez sur le nom du pipeline.
Vous retrouverez sur la droite les différentes releases publiées. L’heure, la branche utilisée, l’environnement (ici « dev »).
Cliquez sur « Edit » pour en savoir plus. Sur la gauche nous retrouvons notre artefact « Drop », le fameux package qui contient notre code !
Pour avoir plus de détails sur le déploiement de « dev », cliquez sur « 1 job, 1 task ».
Nous retrouvons dans « Azure Subscription » le nom de la connection qui a automatiquement été créé par Azure.
Dans App Service name, nous retrouvons le nom que nous avons donné à notre web app.
Imaginons que je souhaite créer un nouveau stage qui correpond à « int », pour l’integration. Je n’aurais qu’à dupliquer le stage « dev » et changer l’App Service name.
Pour vous montrer mes dires, j’ai créé une nouvelle web app que j’ai nommé « gwf-test-int ».
Je clone le stage comme ci-dessous et le nomme int :
Je sélectionne ma subscription gratuite, ce qui me permettra de lister mes web app. Puis je sélectionne « gwf-test-int ».
Je sauvegarde, et c’est tout ! Ah si, je change la façon dont va se déclencher la release. Je veux qu’elle se déclenche uniquement quand je le souhaite. Pour changer le « trigger », il faut cliquer sur l’éclair, comme ci-dessous. Je n’oublie pas de sauvegarder mes modifications.
Je reviens sur l’écran des release et clique sur « Create release » pour créer une release manuellement. On notera que la release de « dev » est en trigger automatique, puisqu’elle est surlignée en bleu. On aperçoit également le nouveau stage « int » qui est apparu.
Je clique sur le stage « int » et clique sur « Deploy » pour lancer le déploiement en intégration. Et.. oh… magie ! Mon build est déployé avec succès !
Voilà, je pense qu’il était important d’expliquer comment se faisait réellement le déploiement. C’est bien quand tout se fait automatiquement, mais il est important de bien comprendre comme ça fonctionne derrière. Car le jour où ça ne fonctionne plus… good luck !
Vous pouvez désormais stopper votre web app, ou même la supprimer via Visual Studio Code dans l’onglet « Azure ».
F.A.Q
Dans votre pipeline, dans l’onglet « trigger », décocher « enable continuous integration » 
Comment on désactive les release automatique ?
Il faut éditer la release et changer le trigger comme sur la capture d’écran. Il faut désactiver « Continuous deployment trigger »
J’ai une erreur 404 sur ma web app, il ne trouve rien ça ne fonctionne pas !
Je vais revenir sur le point de mon article précédent… Vous savez quand je disais qu’il était important de nommer son fichier « server.js » lors de l’installation de NodeJS / ExpressJS, sinon on allait avoir des problèmes…
Lors de la création automatique du pipeline, dans le stage « dev », il y a l’option suivante qui permet de déterminer le fichier à lancer. Et dans notre cas devinez comment il s’appelle ? Eh oui, « server.js ». Si on avait laissé la valeur par défaut, jamais l’application ne se serait lancée.
En fait lors du déploiement d’une application, un fichier « web.config » est nécessaire pour pouvoir démarrer l’application. Et dans ce fichier on va retrouver une ligne qui dit « démarre sur server.js », en gros.
J’ai une erreur HTTP 5XX avec ma web app Node JS sur Azure !
Avez-vous pensé à débrancher et votre box ? Heu, votre web app ? Essayez de redémarrer et/ou vérifiez qu’aucun déploiement n’est en cours.
J’ai toujours une erreur HTTP 5xx avec ma web app Node JS sur Azure !
Vérifiez déjà que votre application node JS / ExpressJS fonctionne en local. Si tout est ok en local, peut-être que votre application n’arrive pas à démarrer sur Azure. Peut-être un problème de port. Il est nécessaire d’utiliser le port attribué par Azure de la manière suivante :
const port = process.env.PORT || 5000
Comme ça, vous utiliserez le port fourni en paramètre, et si il n’y en a pas (c’est que vous débuguez en local), vous utiliserez le port 5000.
Si vous avez d’autres questions, si vous souhaitez de l’aide sur un point, ou vous avez repéré une erreur, n’hésitez pas à utiliser l’espace commentaire.
Si cet article vous a plu, n’hésitez pas à le partager et me laisser un petit message sur LinkedIn ! A bientôt !