Afin d’assurer notre niveau de production, nous tachons d’appliquer 4 règles d’or concernant l’automatisation de nos tâches.
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.
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.
Vous voulez automatiser vos déploiements mais vous ne savez pas par où commencer ?
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.
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.
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.
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é.
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
Ainsi, il reste possible de garder la main sur l’état des déploiements malgré la mise en place de l’automatisation des taches et les équipes opérationnelles peuvent prévoir un temps dans leur agenda pour s’assurer de la réussite du déploiement en production.
Note : Cette technique peut bien entendu faire frissonner les plus fervents défenseurs de la culture DevOps et du “tout automatisé” car elle ajoute une interaction humaine dans le flux de travail. Mais d’expérience, il est parfois nécessaire d’avoir recours à ces validations ne serait-ce que pour garder un climat de sécurité entre les développeurs, les opérationnels et les équipes métiers.
Le déploiement automatisé de nouvelles ressources logicielles peut sembler simple au premier abord, bien plus simple que les ressources matérielles tels que les serveurs et équipements réseaux.
Heureusement, avec l’arrivée du cloud, une nouvelle technologie facilitant la création de ces éléments essentiels au fonctionnement de tous les SI a vu le jour : L’Infrastructure as Code.
Cette technique permet de décrire une infrastructure entière à l’aide de fichiers qui pourront ensuite être exploités pour déployer dans vos prérequis matériels chez un fournisseur de services cloud tel que celui de Microsoft.
Chez Eliade, nous travaillons essentiellement avec deux formats de fichiers au sein d’Azure :
– Azure Resource Management (ARM)
– Terraform
Si le premier permet d’exploiter le maximum des possibilités offertes sur Azure, il est par définition spécifique à la plateforme de Microsoft.
Quant au second, il est compatible avec une multitude de fournisseurs et permet de mettre en place une technologie qui est moins contraignante vis-à-vis du fournisseur cible.
Bien entendu, ces deux technologies sont compatibles avec les pipelines Azure DevOps et peuvent donc être exploitées pour une large majorité des scénarios de déploiement dans le cloud.
Microsoft permet au travers d’Azure DevOps d’automatiser un large panel de scénarios de déploiements et ainsi de minimiser les interventions humaines nécessitant parfois une synchronisation difficile à obtenir lorsque vos équipes sont contraintes de travailler à distance.
La standardisation des déploiements permet de gagner en sérénité lors des mises en production et peut aller jusqu’à permettre le déploiement d’un projet plusieurs fois par jour.
La mise en place d’approbations permet de rassurer les moins enthousiastes au « tout automatisé » et de garder un climat de confiance entre tous les acteurs d’un projet.
L’arrivée de l’Infrastructure as Code permet aux équipes techniques d’exploiter l’une des forces majeures d’Azure et du cloud en général, à savoir la mise à disposition de ressources à la demande.
Bien sûr, ce billet de blog ne couvre qu’une infime partie des possibilités offertes par la plateforme Azure DevOps.
Alors si le sujet vous intéresse, que comme nous vous avez réussi à percevoir le potentiel de cet outil dans votre contexte ou que vous souhaitez en savoir plus. N’hésitez pas à nous contacter. Nous serons ravis de répondre à vos questions et de vous accompagner dans votre transition vers l’avenir.
Addendum
Pendant que nous écrivions cette publication, des mises à jour des pipelines de Build et de Release ont été mises en disponibilité générale :
https://devblogs.microsoft.com/devops/announcing-general-availability-of-azure-pipelines-yaml-cd/
Vous avez donc désormais le choix pour vos Releases.