Nos 4 conseils pour déployer sereinement
Avec les mesures de confinement qui se sont imposées dans notre quotidien, les équipes de développement informatique se sont vues confronter à une augmentation massive de la décentralisation de leurs effectifs.
Il est ainsi devenu parfois difficile de prévoir le déploiement de nouveaux projets car même si le télétravail a déjà fait preuve de nombreuses qualités, il faut tout de même reconnaître que certaines actions, telles que les mises en production, sont nettement moins difficiles et risquées lorsque tous les acteurs peuvent être présents et interagissent.
Enfin… Ça c’était avant…
Aujourd’hui, avec l’arrivée des outils de travail collaboratif tels que Teams ou encore la plateforme Azure DevOps, il n’a jamais été aussi facile de travailler à distance.
Et c’est d’ailleurs sur l’une des fonctionnalités de ce dernier outil que s’attarde notre article du jour : Les pipelines de déploiement Azure DevOps.
Alors, que vous soyez habitués aux concepts sous-jacents du DevOps ou totalement néophytes, nous vous proposons aujourd’hui de découvrir les techniques et astuces que nous utilisons au quotidien au sein des équipes Eliade pour être productifs tout en étant éparpillés aux quatre coins du nord de la France.
De l’automatisation dans les tuyaux
Azure DevOps est une plateforme proposée par Microsoft afin de faciliter l’intégration de ce que l’on appelle la culture DevOps.
Cet outil permet non seulement de gérer son projet au travers de tableaux de suivi (souvent utilisés par les équipes pour visualiser les taches à faire, en cours et terminées), de disposer de contrôleurs de codes sources (Git et TFVC) mais également de faciliter l’automatisation de certaines tâches, parfois sources d’erreurs et de stress. La plus connue étant la fameuse mise en production, responsable de beaucoup de crises de nerfs pour les équipes qui en ont la charge.
Automatiser pour mieux créer
L’un des concepts les plus en vue de la culture DevOps concerne l’automatisation des déploiements. Il promet des déploiements plus faciles, plus rapides et moins risqués. Les équipes, pouvant compter sur l’efficacité et la fiabilité de leurs outils de livraison peuvent ainsi se concentrer sur l’essentiel, à savoir la création de nouvelles fonctionnalités.
Pour répondre à ce besoin d’automatisation, Microsoft propose les pipelines via sa plateforme Azure DevOps.
UN PIPELINE DE DÉPLOIEMENT AZURE DEVOPS
Nos 4 règles d’or
Afin d’assurer notre niveau de production, nous tachons d’appliquer 4 règles d’or concernant l’automatisation de nos tâches.
1. Assurer la qualité de notre code
Pouvoir développer plus c’est bien… Mais plus proprement, c’est mieux !
UN EXEMPLE DE BUILDS
C’est pourquoi, nous recommandons de créer pour chaque projet, un pipeline de compilation (appelé Build) permettant d’assurer la conformité de toutes les modifications effectuées au sein d’un projet.
Cette étape permet, entre-autres, de vérifier qu’aucune erreur de syntaxe pouvant altérer le bon fonctionnement d’une application n’ait été introduite, que le nouveau code respecte bien les normes de développement ou encore que l’ensemble des tests unitaires soient réussis.
Astuce : Azure DevOps permet également d’intégrer des outils extérieurs à ses propres fonctions. Il est ainsi possible par exemple de publier les résultats de l’analyse du code et des tests unitaires au sein d’un outil tier (par exemple SonarQube) pour pouvoir en analyser finement chaque mesure.
La dernière étape de cette build permet ensuite de construire un « artefact » (un package en quelque sorte) pouvant ensuite être exploité par un autre type de pipeline : les Releases.
2. Standardiser les déploiements
Lorsqu’on dispose d’un package prêt à être déployé, il ne reste plus qu’à s’en servir. C’est là qu’entrent en jeu les pipelines de Release.
Leur objectif est simple : Se charger d’envoyer sur nos environnements les nouvelles fonctionnalités tant attendues par les utilisateurs.
En utilisant ce type de pipeline, il est tout d’abord possible de définir les environnements cibles (Dev/Test/Prod) afin d’y déployer la nouvelle version de notre programme au moment voulu. Il existe ici plusieurs écoles :
-
Certains souhaitent garder la main mise sur certaines étapes et choisissent d’effectuer un déploiement successif sur chaque environnement (d’abord Dev, puis test et enfin production)
-
D’autres préfèrent déployer la totalité des modifications sur un maximum d’environnements et disposent d’un mécanisme interne permettant d’activer ou de désactiver les nouvelles fonctionnalités
-
Il est également possible d’effectuer un mix des deux méthodes ci-dessus en exploitant certaines fonctionnalités. Comme par exemple les « slots » de déploiement propres aux Web App Azure
Ainsi, en standardisant les actions nécessaires au déploiement de notre package et en créant un pipeline de Release dans Azure DevOps, il devient possible d’automatiser l’ensemble de la chaine permettant d’aller de la modification du code par un développeur jusqu’à la mise à disposition pour les utilisateurs.
Finies donc les erreurs humaines provoquant une interruption de la production et bonjour sérénité !
DANS CE PIPELINE, LE PACKAGE EST TOUT D'ABORD DEPLOYÉ SUR UN ENVIRNNEMENT DE TESTS UTILISATEURS, PUIS, SI LES TESTS UTILISATEURS SE SONT CORRECTEMENT DÉROULÉS, LE PACKAGE PEUT-ÊTRE DÉPLOYÉ EN PRODUCTION.
Astuce : Afin de standardiser au maximum chaque étape du pipeline de Release, nous utilisons chez Eliade la fonctionnalité des variables de déploiement. Cela nous permet de garder un processus de déploiement identique pour chacun de nos environnements et de pouvoir modifier certaines données moins structurantes tels qu’un mot de passe d’accès à une base de données ou encore l’URL d’un service tiers.
3. Ne pas hésiter à faire des demandes d’approbation avant un déploiement
Le “tout automatisé” est certes prometteur mais il ne faut pas être dupe. Si pour certains le jeu en vaut la chandelle, il s’avère parfois nécessaire de garder le contrôle sur certaines étapes d’un déploiement.
Je pense notamment au passage en production, qui peut encore nécessiter quelques validations de la part des équipes techniques et/ou métiers.
C’est pourquoi, il est possible de configurer au sein des pipelines de Release des demandes d’approbation avant et après chaque étape du déploiement.
Nous utilisons d’ailleurs cette technique en interne lorsque nous avons en charge le développement d’un projet nécessitant des validations auprès des équipes fonctionnelles et techniques de nos clients.
Ces étapes s’appellent :
- Post-Deployment approval
- Pre-Deployment approval
La première permet d’envoyer un mail de confirmation à un groupe de personne. Par exemple, pour valider le bon fonctionnement d’une nouvelle version sur un environnement.
Quant à la seconde, elle permet d’envoyer un mail pour demander la validation avant le déploiement d’une nouvelle version sur un environnement donné.
Par exemple, nous l’utilisons généralement comme ceci :
-
Le package est déployé sur l’environnement de développement
-
Une notification est envoyée aux métiers et/ou aux développeurs pour validation
-
Si 2 est validé, une notification est envoyée aux opérationnels pour valider le déploiement en production
-
Si l’étape précédente est validée, le package se déploie en production