Azure Pipelines

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 1 sur 10. Tu cliques un peu partout dans une interface web, tu glisses-déposes quelques boîtes, et ton build marche parfaitement. Puis quelqu'un modifie un paramètre, le build plante, et tu n'as absolument aucun historique de qui a fait quoi ou pourquoi. C'est le piège des éditeurs visuels, et c'est exactement pourquoi le passage de la Classic UI aux pipelines YAML est la fondation du CI/CD moderne. Azure Pipelines t'offre deux manières distinctes d'automatiser ton software delivery. La méthode la plus ancienne, c'est l'interface Classic. Elle repose sur un portail web graphique où tu configures des tâches avec des formulaires et des menus déroulants. Ça paraît accessible quand tu débutes. Mais à mesure que ton système grossit, l'approche Classic devient un handicap majeur. La configuration vit dans la base de données d'Azure DevOps, totalement déconnectée de ton code source. Les pipelines YAML remplacent ça par le concept de Pipeline-as-Code. Au lieu de configurer des paramètres dans un portail web, tu définis tout ton processus de build et de release dans un simple fichier texte. Tu commites ce fichier YAML directement dans ton repository, pour le garder juste à côté du code de l'application qu'il est censé builder. Certains développeurs hésitent à franchir le pas, par peur qu'une configuration au format texte limite les features par rapport à l'éditeur visuel. Ce n'est pas le cas. Les pipelines YAML offrent une parité de features complète pour la Continuous Integration et le Continuous Delivery. Microsoft considère la Classic UI comme legacy et concentre ses nouveaux développements sur YAML. C'est le standard d'entreprise pour la répétabilité et l'audit. Imagine une équipe qui migre une définition de build complexe en drag-and-drop vers un fichier dans le repository. Dans l'ancien système, tester une nouvelle étape de build impliquait de modifier la configuration partagée du pipeline, avec le risque de casser le build pour le reste de l'équipe. Avec YAML, le pipeline est versionné exactement comme ton application. Si tu crées une feature branch pour mettre à jour une dépendance principale, tu peux modifier le fichier YAML dans cette même branche. La logique de build mise à jour s'applique uniquement à ta branche isolée. Le reste de l'équipe continue d'utiliser le pipeline de la main branch sans interruption. Voici le point clé. Puisque ton pipeline est désormais un simple fichier texte dans Git, il est soumis à ton processus standard de code review. Quand tu t'éloignes de l'UI, personne ne peut modifier discrètement une cible de deploy ou sauter une étape de test. Chaque modification du pipeline nécessite un commit. Ça nécessite une pull request. Ça nécessite l'approbation d'un collègue. Tu gagnes une trace d'audit permanente et incontestable de chaque modification. De plus, l'état de ton pipeline est verrouillé pour toujours sur l'état de ton application. Si tu as besoin de faire un roll back vers une release d'il y a six mois, le fichier YAML de ce moment précis est préservé dans ton historique Git. Tu as la garantie d'avoir les bonnes instructions de build pour cette ancienne version spécifique du code. La transition vers YAML, c'est traiter ton mécanisme de delivery avec exactement la même rigueur d'ingénierie que le software qu'il livre. Si tu trouves ces épisodes utiles et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour celui-ci. Merci d'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 2 sur 10. La différence entre un stage et un job détermine exactement où ton pipeline va planter si tu comprends mal l'allocation des agents. Si tu te trompes, tu risques de voir tes artifacts de build disparaître soudainement juste au moment de lancer tes tests. L'anatomie d'un pipeline, et plus précisément les stages, les jobs et les steps, c'est la structure qui résout ce problème. Un pipeline est un système hiérarchique. Cette structure impose strictement comment le travail est divisé, où il s'exécute et dans quel ordre. La hiérarchie comporte trois niveaux. Les stages contiennent des jobs, et les jobs contiennent des steps. Un stage sert de frontière logique. Il regroupe le travail associé. Dans une application d'entreprise, tu utilises les stages pour séparer les grandes phases de ton cycle de livraison logicielle. Tu peux définir un stage de build, suivi d'un stage de test distinct. Par défaut, les stages s'exécutent séquentiellement. Un stage doit être complètement terminé avant que le suivant ne commence. Ils agissent comme des barrières organisationnelles pour l'ensemble de ton processus. Voici le point clé. Les ingénieurs confondent souvent les stages et les jobs, et les utilisent de manière interchangeable. Ils ne servent pas à la même chose. Un stage est un conteneur purement logique. Un job est une limite d'exécution physique. Un job définit l'environnement réel où ton code s'exécute. Chaque job est assigné à un agent, qui est la machine ou le conteneur qui exécute tes tasks. Toutes les opérations à l'intérieur d'un même job s'exécutent sur cet agent spécifique. Comme les jobs sont l'unité d'exécution, ils se comportent différemment des stages. Si tu places trois jobs dans un seul stage, Azure Pipelines va essayer de lancer ces trois jobs en parallèle sur trois agents différents, en supposant que tu aies la capacité disponible. Ça veut dire que les jobs ne partagent ni le système de fichiers local, ni la mémoire. Si le job A compile le code de ton application, le job B ne peut pas simplement accéder aux binaries compilés sur le disque local. Le job B tourne sur une machine complètement différente. Si tu as besoin que deux processus partagent le même espace disque local de manière séquentielle, ils doivent être placés dans le même job. À l'intérieur d'un job, tu définis des steps. Un step est la plus petite brique de base d'un pipeline. C'est une instruction concrète, généralement une task ou un script. Comme les steps vivent à l'intérieur d'un job spécifique, ils s'exécutent tous séquentiellement sur exactement le même agent. Le step un pourrait être une task pour télécharger ton code source. Le step deux pourrait être un bash script qui lance ton compiler. Puisqu'ils partagent le même environnement d'exécution, le step deux a un accès direct et immédiat aux fichiers que le step un vient de télécharger. Applique ça à la structuration d'un pipeline d'entreprise qui build une application, lance des unit tests et package le résultat. Tu crées un seul stage nommé Continuous Integration. À l'intérieur de ce stage, tu définis deux jobs séparés pour accélérer l'exécution. Le job un gère le build principal. Ses steps font un checkout du code, lancent le compiler et packagent le binary. Le job deux gère l'analyse statique du code et les unit tests autonomes. Comme ce sont des jobs séparés au sein du même stage, ils s'exécutent en parallèle sur des agents distincts. Ils ne se bloquent pas l'un l'autre, mais ils ne partagent pas non plus de système de fichiers. Si le job deux a besoin du binary créé par le job un, tu dois explicitement dire au job un de publier l'artifact dans le stockage du pipeline, et dire au job deux de le télécharger. La structure dicte les capacités de ton architecture de Continuous Integration. Utilise les stages pour organiser ton workflow logiquement, mais repose-toi sur les jobs pour contrôler exactement où et comment ton exécution scale sur les machines. Merci d'avoir écouté. J'espère que tu as appris quelque chose de nouveau.

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 3 sur 10. Chaque pipeline a besoin de puissance de calcul, mais choisir le mauvais Execution Context peut doubler tes temps de build en douce. Tu as beau écrire un code de pipeline parfait, si ton build doit télécharger des gigaoctets de dépendances de zéro à chaque run, ton équipe va perdre des heures à attendre. Ce goulot d'étranglement, c'est exactement pour ça que tu dois comprendre l'Execution Context, et plus particulièrement les Agents et les Demands. Pour builder du code ou faire un deploy de logiciel dans Azure DevOps, tu as besoin d'un agent. Un agent, c'est tout simplement un logiciel installable qui se connecte à ton organisation Azure DevOps, qui écoute s'il y a du travail, et qui exécute les jobs un par un. Chaque agent tourne sur une machine hôte, et en général, tu as le choix entre deux types d'hôtes. Tu peux utiliser des agents Microsoft-hosted, ou tu peux utiliser des agents self-hosted. Les agents Microsoft-hosted sont le choix par défaut pour des raisons de simplicité. Tu demandes une machine, et Microsoft t'en fournit une depuis son pool cloud. Tu n'as jamais besoin de patcher le système d'exploitation ou de mettre à jour le logiciel de l'agent. Mais cette commodité cache un piège dans lequel tombent beaucoup d'équipes. Voici le truc à retenir. Un agent Microsoft-hosted te donne une machine virtuelle flambant neuve, complètement vierge, pour chaque run de ton pipeline. Il ne garde aucun souvenir de ton dernier build. Quand ton job est terminé, cette machine est définitivement détruite. Si ton build a besoin d'un cache de packages de plusieurs gigaoctets, il va le télécharger sur le réseau en partant de zéro à chaque run, à moins que tu n'ajoutes des étapes de caching explicites dans ton pipeline pour sauvegarder et restaurer ces données. Si tu veux éviter de télécharger tout Internet à chaque fois, ou si ton build doit passer derrière un pare-feu d'entreprise strict, tu utilises des agents self-hosted. Tu installes le logiciel de l'agent sur ta propre infrastructure. Ça peut être un serveur dans ton data center local ou une machine virtuelle persistante dans ton propre tenant cloud. Comme la machine survit entre les runs, tes caches de packages, tes SDK téléchargés et tes fichiers de build incrémentiel restent exactement là où tu les as laissés. Ça accélère considérablement les temps d'exécution. Si tu cherches un juste milieu moderne, tu peux jeter un œil aux Managed DevOps Pools. Ils agissent comme une alternative aux scale-sets, où tu définis des images de base et des tailles personnalisées, et Azure gère le provisioning et le scaling automatiques. Voilà pour ce que sont les agents. Maintenant, comment Azure DevOps sait-il quel agent utiliser pour un job spécifique ? Ça repose sur un système de Capabilities et de Demands. Chaque agent self-hosted renvoie une liste de Capabilities au serveur. Beaucoup d'entre elles sont découvertes automatiquement par le logiciel de l'agent, comme le type de système d'exploitation ou le path vers des outils installés comme Node ou Python. Tu peux aussi définir des user capabilities personnalisées, par exemple pour indiquer qu'une machine spécifique possède une carte graphique particulière. Dans la définition de ton pipeline, tu écris des Demands pour correspondre à ces Capabilities. Un Demand garantit que ton job sera uniquement routé vers un agent qui possède la Capability exacte que tu demandes. Imagine un scénario où tu buildes une application iOS. Builder pour iOS nécessite Xcode, qui requiert impérativement du matériel Apple. Supposons que tu aies un seul pool de vingt agents self-hosted, mais que seulement deux d'entre eux soient des Mac Minis. Il te suffit d'ajouter un Demand pour la Capability macOS à ton job de pipeline. Quand Azure DevOps évalue le run, il filtre toutes les machines Windows et Linux du pool, et route ton build iOS directement vers l'un des Mac Minis disponibles. Ton choix d'agent dicte l'architecture complète de ton pipeline. Le Microsoft-hosted te libère de la maintenance des serveurs au prix de devoir gérer le state toi-même, tandis que le self-hosted échange l'entretien de l'infrastructure contre de la vitesse brute et des caches persistants. C'est tout pour cette fois. Merci de ton écoute, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 4 sur 10. Tu penses peut-être que ton pipeline ne s'exécute que quand quelqu'un push un commit. Mais dans un système mature, les pipelines sont bien plus proactifs, en lançant différents types de validation à des moments complètement différents. On va parler de l'automatisation du workflow avec les triggers. Les triggers définissent exactement quels événements déclenchent l'exécution de ton pipeline. Le type le plus courant, c'est le trigger d'intégration continue, ou CI. Un trigger CI se déclenche automatiquement dès que du code est push sur une branche spécifique. Dans ton fichier de pipeline, tu définis ça avec un simple bloc trigger. Tu peux lui dire d'écouter la branche main, mais d'ignorer certains chemins de fichiers, comme les dossiers de documentation. Ça évite à ton pipeline de perdre du temps à build l'application quand quelqu'un a juste corrigé une faute de frappe dans un fichier texte. Ça, c'est pour le code qui est déjà en train d'arriver sur une branche. Mais en général, tu veux attraper les erreurs avant que le merge se fasse. C'est le rôle des triggers de Pull Request, ou PR. Un trigger PR se déclenche quand une Pull Request est ouverte ou quand de nouveaux commits sont push sur cette PR existante. Son but principal, c'est de protéger la branche cible en validant le code entrant. Et voici le point essentiel. Il y a un piège classique dans lequel les développeurs tombent avec les triggers de PR. Quand une Pull Request déclenche un pipeline, Azure Pipelines évalue la configuration en utilisant le fichier YAML situé dans la branche source, et non dans la branche cible. La logique qui gère la validation vient de la feature branch elle-même. Si tu fais des modifications dans la configuration du pipeline sur ta feature branch, ces changements s'appliquent au run de la PR. Les triggers de PR doivent être rapides. Si tu configures un trigger de PR, tu dois l'utiliser pour lancer des opérations rapides, comme des tests unitaires et du linting de code. Tu veux que les développeurs aient un feedback en quelques minutes. Mais certaines opérations, comme une analyse statique approfondie ou des scans de sécurité lourds, prennent beaucoup plus de temps. Un scan de sécurité de deux heures va paralyser ton équipe si tu l'attaches à un trigger de PR. Ça nous amène au troisième type : les triggers planifiés. Au lieu de réagir aux mouvements de code, les triggers planifiés exécutent les pipelines en fonction d'une horloge. Ils utilisent la syntaxe cron standard pour définir des jours et des heures spécifiques pour faire tourner le pipeline. Tu définis un bloc schedules dans ton fichier YAML, tu spécifies l'expression cron, et tu listes les branches que tu veux build. Tu peux combiner ces triggers pour construire un workflow efficace. Pendant la journée, tes triggers de PR lancent des tests unitaires rapides sur les feature branches pour que le développement continue d'avancer. Pendant ce temps, tu configures un trigger planifié pour lancer ce fameux scan de sécurité de deux heures tous les soirs à minuit sur la branche main. Tu peux même configurer le trigger planifié pour qu'il s'exécute uniquement si de nouveaux commits ont été merge depuis la nuit précédente. Ça permet de skip complètement le run pendant un week-end calme, et d'économiser des coûts de compute. Utiliser ces triggers ensemble te permet de séparer le feedback rapide pour les développeurs de la validation système approfondie. Les triggers ne sont pas juste des boutons de démarrage ; ce sont les contrôles architecturaux qui décident comment et quand tes ressources de compute sont dépensées. Merci de ton écoute — à la prochaine.

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 5 sur 10. Hardcoder les noms d'environnement directement dans tes fichiers YAML, c'est de la dette technique qui n'attend que d'exploser lors de ta prochaine migration d'infrastructure. Quand ces noms changent, tu n'as pas envie de fouiller dans des dizaines de repositories pour les mettre à jour. Le State Management avec les Variables et les Variable Groups résout ça en centralisant ta configuration. Le pipeline connaît déjà pas mal de choses sur son contexte d'exécution de base. Azure fournit des variables système prédéfinies pour donner à ton pipeline une conscience de son environnement sans aucun setup manuel. Par exemple, si tu as besoin de savoir quelle branche a déclenché le run, tu utilises Build point SourceBranch. Si tu as besoin de l'ID unique du run en cours, tu utilises Build point BuildId. Elles sont automatiquement remplies et prêtes à être lues. Quand tu as besoin d'une configuration custom, tu définis des variables inline. Tu les places directement dans ton fichier YAML sous le bloc variables. C'est parfait pour des valeurs spécifiques à un seul pipeline, comme un flag de configuration de build ou un chemin de fichier local. Ça permet de garder la logique self-contained. Par contre, les variables inline posent problème quand tu scales. Prends un scénario où tu as trois pipelines de microservices séparés. Ils ont tous besoin de connaître le nom de l'environnement de déploiement cible et un ensemble d'URL d'endpoints d'API partagées. Si tu les définis inline, tu te répètes à travers trois repositories. Si un endpoint change, tu as trois pull requests à faire. La solution, c'est un Library Variable Group. C'est un store clé-valeur centralisé, gardé dans la Library Azure DevOps. Tu crées le groupe une seule fois dans l'UI, tu le remplis avec tes noms d'environnement et tes endpoints d'API, puis tu références ce groupe par son nom dans le bloc variables de tes trois pipelines de microservices. Quand le jour de la migration arrive, tu mets à jour le Variable Group dans le portail DevOps, et chaque pipeline utilise instantanément les nouvelles valeurs lors de son prochain run. Tu appliques le principe Don't Repeat Yourself, en gardant ta configuration partagée à un seul et même endroit. Voici le point clé. La façon dont tu appelles une variable change le moment où Azure l'évalue. Il y a deux syntaxes principales, et les mélanger va casser ton pipeline. La première, c'est la syntaxe macro, qui s'écrit avec un signe dollar suivi de parenthèses qui entourent le nom de la variable. La syntaxe macro est évaluée au runtime. Azure remplace la variable juste avant que la task spécifique qui l'utilise ne s'exécute. La deuxième, c'est la syntaxe template expression, qui s'écrit avec un signe dollar suivi de doubles accolades contenant le mot variables point et le nom de ta variable. Les template expressions sont évaluées au compile time, avant même que le pipeline ne commence à tourner. Si tu essaies d'utiliser une variable pour décider si un stage doit s'exécuter, ou pour définir une boucle sur une liste de jobs, tu dois utiliser la syntaxe template expression. Le pipeline a besoin de cette valeur en amont pour construire le graphe d'exécution. Si une valeur est générée dynamiquement pendant le run du pipeline par un script, tu dois utiliser la syntaxe macro, parce que la valeur n'existe tout simplement pas au compile time. Maîtrise la différence entre les template expressions au compile time et les macros au runtime, et tu élimineras les erreurs de parsing de variables les plus frustrantes dans le développement de ton pipeline. C'est tout pour cette fois. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 6 sur 10. Masquer un secret dans les logs de ton pipeline ne veut pas dire qu'il est sécurisé si tu l'as tapé directement dans ta configuration CI/CD. Quand un administrateur de base de données fait une rotation de ce mot de passe, tes déploiements plantent instantanément jusqu'à ce que quelqu'un mette à jour le pipeline manuellement. Pour corriger ça, tu récupères les credentials dynamiquement en utilisant Azure Key Vault. On définit souvent les variables secrètes directement dans l'UI d'Azure DevOps. Tu cliques sur l'icône du cadenas, le texte disparaît, et tu penses être en sécurité. Stocker des secrets dans l'UI du pipeline crée une posture de sécurité fragmentée. Si une politique d'entreprise impose la rotation des credentials tous les trente jours, trouver et mettre à jour chaque variable de pipeline à travers des dizaines de projets est un cauchemar opérationnel. En plus, tu perds l'audit centralisé sur qui ou quoi a accédé à ces données. L'approche secure-by-design consiste à récupérer les secrets dynamiquement au runtime depuis un Key Vault d'entreprise. Le pipeline ne possède jamais le secret. Il l'emprunte juste au moment précis où il en a besoin. Pour réussir ça, tu utilises la task de pipeline Azure Key Vault. D'abord, le pipeline a besoin de la permission de regarder dans ton vault. Tu configures une service connection Azure Resource Manager dans ton projet DevOps. Cette connexion repose soit sur un Service Principal, soit sur une Managed Identity. Tu accordes ensuite à cette identité un accès en lecture explicite aux secrets de ton Key Vault en utilisant le role-based access control d'Azure ou les access policies du vault. Voici le point clé. Le pipeline tourne sous cette identité, prouvant qui il est à Azure avant de récupérer la moindre donnée sensible. Ça correspond à un modèle zero-trust. Aucun credential permanent n'existe dans ton repository de code ou dans les définitions de ton pipeline. Prends l'exemple d'un pipeline qui récupère une connection string de base de données très sensible juste avant de déployer un service backend. Dans la définition de ton pipeline, juste avant l'étape de déploiement, tu ajoutes la task Azure Key Vault version deux. Tu fournis trois inputs principaux à cette task. Premièrement, tu spécifies le nom de la service connection de ta souscription Azure. Deuxièmement, tu fournis le nom de ton Key Vault. Troisièmement, tu définis une liste des noms de secrets spécifiques que tu veux télécharger. Tu peux passer un astérisque en wildcard pour tout télécharger, mais le principe de moindre privilège veut que tu ne demandes que ce dont tu as exactement besoin. Tu demandes spécifiquement un secret nommé production-database-connection. Quand le pipeline atteint cette étape, il fait un appel au vault. Si l'identité a la permission, le vault renvoie le secret. La task prend cette valeur sécurisée et la transforme automatiquement en une variable de pipeline standard. Le nom de la nouvelle variable de pipeline correspond exactement au nom du secret dans le vault. Ta prochaine étape de déploiement peut maintenant référencer cette variable pour configurer la base de données, exactement comme n'importe quel input de texte standard. Azure Pipelines enregistre aussi cette valeur téléchargée comme une variable secrète en arrière-plan. Si un script affiche accidentellement la connection string dans la console, le système l'intercepte et remplace le texte réel par des astérisques dans les logs. Le fetching dynamique garantit que quand l'équipe base de données met à jour le mot de passe principal dans le vault, ton pipeline utilise automatiquement la nouvelle string lors de son tout prochain run, avec zéro intervention manuelle. Ton système de continuous delivery devrait agir comme un coursier sécurisé, qui récupère la mallette verrouillée juste avant la livraison, plutôt que de stocker une copie permanente au dépôt. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de développer !

Bonjour, ici Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 7 sur 10. Les pipelines d'entreprise les plus fiables ne s'exécutent pas juste à l'aveugle de haut en bas. Ils réagissent dynamiquement quand ça tourne mal, en détruisant l'infrastructure après un crash ou en ignorant les lourdes suites de tests pendant un petit hotfix. Pour construire ce genre de résilience, tu as besoin du contrôle dynamique : les conditions et les expressions. Chaque job et chaque step dans Azure Pipelines a une condition qui lui est attachée, que tu l'écrives explicitement ou non. Par défaut, le système applique une condition intégrée appelée succeeded. Ça veut dire qu'un step ne s'exécute que si toutes ses dépendances précédentes se sont terminées sans lancer d'erreur. Si le step un échoue, le step deux est automatiquement ignoré. On comprend souvent mal à quel moment ces vérifications se font. Une condition évalue si un step doit s'exécuter, et elle le fait complètement avant que le step ou le job ne commence. Un step ne peut jamais utiliser une condition pour évaluer son propre output interne. La condition est le gardien qui se tient à l'entrée. Elle regarde l'état du pipeline jusqu'à ce moment précis et décide si le step est autorisé à démarrer. Parfois, tu as explicitement besoin qu'un job s'exécute quand un step précédent plante. Prends l'exemple d'un job de déploiement qui monte une infrastructure de test temporaire. Si le déploiement crashe à mi-chemin, le comportement par défaut ignore le reste du pipeline. Tes serveurs temporaires restent en ligne, brûlant silencieusement ton budget cloud. Tu corriges ça en ajoutant un job de nettoyage dédié à la fin du pipeline, mais tu changes sa condition de succeeded à failed. Maintenant, ce job de nettoyage ignore complètement les runs réussis. Il ne se réveille pour détruire l'infrastructure temporaire que si les jobs de déploiement principaux crashent. Tu n'es pas limité aux vérifications de statut de base comme succeeded, failed, ou always. Tu peux écrire des expressions personnalisées pour évaluer l'état des variables et prendre des décisions de routage granulaires. Azure Pipelines utilise une syntaxe fonctionnelle pour ces expressions. Au lieu d'écrire des symboles mathématiques, tu utilises des fonctions nommées. Si tu veux vérifier si une variable est égale à une valeur spécifique, tu utilises une fonction appelée eq. Tu ouvres les parenthèses, tu passes la variable de pipeline que tu vérifies, tu ajoutes une virgule, et tu fournis la valeur que tu attends. Tu peux combiner plusieurs vérifications en imbriquant ces fonctions. Supposons que tu aies un job de release qui ne doit s'exécuter que si le pipeline a le statut succeeded et que la branche courante est main. Tu commences avec une fonction and. À l'intérieur de ses parenthèses, tu passes deux arguments. Le premier argument est la fonction succeeded. Le deuxième argument est ta fonction eq, qui compare la variable de la branche source avec la string de la branche main. Le job de release ne se déclenchera que si les deux instructions s'évaluent à true. Utiliser des expressions te permet de construire des pipelines qui s'adaptent au contexte du run. Avant de terminer, si tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon, ce qui est toujours apprécié. Voici la partie qui compte. La vraie résilience d'un pipeline ne vient pas du fait d'empêcher chaque erreur possible, mais d'utiliser des conditions pour s'assurer que ton système sait exactement comment gérer l'échec quand il se produit inévitablement. Merci d'avoir écouté. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 8 sur 10. Tu as cinquante microservices, et tu viens de mettre à jour la définition de build pour l'un d'entre eux. Maintenant, tu dois copier-coller manuellement ce bloc YAML quarante-neuf fois de plus. Si tu copies-colles du code entre tes pipelines, tu accumules une dette technique énorme et tu rends les mises à jour de sécurité globales impossibles. La solution, c'est la réutilisabilité d'entreprise : les templates YAML. Les templates te permettent de définir la logique de ton pipeline une seule fois et de la réutiliser partout. Dans Azure Pipelines, les templates fonctionnent de deux manières complètement différentes : les Includes et les Extends. Un template Include agit exactement comme un copier-coller effectué par le compilateur du pipeline. Tu prends une séquence courante, comme l'installation d'une série de dépendances ou la publication d'un artifact, tu la sauvegardes dans un fichier YAML indépendant, et ensuite tu la références depuis ton pipeline principal. Quand le pipeline s'exécute, il tire le contenu de ce template externe directement dans ton job ou ton stage actif. C'est super utile pour éviter de te répéter, mais ça laisse quand même au développeur le contrôle total sur la structure du pipeline. C'est lui qui décide si, quand et où inclure ton template. Voici le point clé. Quand une équipe plateforme centrale a besoin d'imposer des règles, elle n'utilise pas les Includes. Elle utilise les Extends. Un template Extends inverse complètement la structure de contrôle. Au lieu que le pipeline du développeur tire des morceaux de logique, le pipeline du développeur déclare qu'il étend un template central. Ce template central dicte exactement les stages, les jobs et le squelette global de tout le pipeline. Le développeur a seulement le droit de passer ses instructions spécifiques dans les emplacements que le template laisse explicitement ouverts. Prends l'exemple d'une règle imposée par l'équipe de sécurité. Elle exige que chaque microservice exécute un scanner de code SAST, pour Static Application Security Testing, avant que le moindre code ne compile. Pour imposer ça, elle écrit un template Extends qui définit un job avec deux steps. Le premier step, c'est le scanner SAST obligatoire. Le deuxième step, c'est un espace réservé pour les actions du développeur. Le fichier de pipeline de l'équipe de développement ne fait rien d'autre que pointer vers ce template central et fournir ses commandes de build spécifiques à cet espace réservé. L'équipe plateforme garantit que le scanner s'exécute en premier, à chaque fois, sans jamais avoir besoin d'auditer cinquante fichiers YAML individuels. Pour passer ces commandes ou d'autres informations dans les templates, tu utilises les paramètres de template. On confond souvent les paramètres avec les variables, mais leur comportement est fondamentalement différent. Les variables sont évaluées au runtime et sont généralement juste du texte peu structuré. Les paramètres sont évalués au compile time. Avant même que le pipeline ne commence à s'exécuter, Azure DevOps parse les templates et résout tous les paramètres. Parce que ça se passe au compile time, les paramètres offrent des contrôles de sécurité stricts. Tu peux définir des types de paramètres précis, comme boolean, number, ou une liste de steps. Tu peux imposer des valeurs par défaut ou restreindre les inputs à une liste prédéfinie de strings autorisées. Si un développeur essaie de passer une string de texte dans un paramètre boolean, le pipeline refuse de compiler. Ce typage fort empêche les erreurs au runtime et garantit que le template se comporte exactement comme l'équipe centrale l'avait prévu. En forçant la structure du pipeline à être évaluée et type-checkée avant que l'exécution ne commence, un template Extends agit comme une frontière architecturale. Il sépare complètement ce que les développeurs buildent de la façon dont l'organisation le sécurise. C'est tout pour cet épisode. Merci de m'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 9 sur 10. Tu peux facilement écrire un job de pipeline standard qui lance un shell script pour push du code sur un serveur. Mais quand un bug critique te tombe dessus et qu'on te demande ce qui est passé en production mardi dernier exactement, ce job standard ne te donne rien d'autre que des console logs. Pour avoir une vraie trace d'audit de ce qui a été déployé et où, tu dois cibler tes déploiements avec des Environments. Dans Azure DevOps, un Environment est une collection logique de ressources que tu cibles avec un déploiement. Tu l'appelles par exemple production ou staging, et ça sert de point d'ancrage pour le tracking. Au lieu d'utiliser un job de pipeline standard pour push ton code, tu utilises un mot-clé spécial appelé deployment job. Quand tu lies un deployment job à un Environment, Azure DevOps tracke automatiquement les commits exacts et les work items qui sont déployés sur cette cible spécifique. Tu obtiens un historique de déploiement complet dans l'interface utilisateur sans écrire de logique de logging supplémentaire. Il y a une différence majeure dans le comportement des deployment jobs par rapport aux jobs standards. Un job standard télécharge automatiquement ton repository de code source. Un deployment job ne le fait pas. Par défaut, il skippe complètement l'étape de checkout. Ça piège pas mal de développeurs. La raison est simple. Au moment où tu arrives à la phase de déploiement, tu devrais déployer un artifact précompilé ou une container image créée dans une étape de build précédente. En général, tu n'as pas besoin du code source brut sur un runner de déploiement. Si tu as vraiment besoin du repository source, tu dois dire explicitement au deployment job de faire un checkout. Quand tu définis un deployment job, tu ne listes pas une simple séquence de tâches à plat. Tu englobes ces tâches dans une stratégie de déploiement. La stratégie la plus courante, c'est run once. Comme son nom l'indique, elle exécute simplement tes étapes de déploiement de façon séquentielle sur l'Environment. Si tu as besoin de quelque chose de plus complexe, tu peux utiliser la stratégie canary. Canary te permet de déployer sur un petit pourcentage de tes serveurs, de monitorer les erreurs, puis de déployer progressivement la nouvelle version sur le reste. Ça limite les dégâts d'une mauvaise release. À l'intérieur de ces stratégies, tes tâches sont organisées en lifecycle hooks. Ça impose une structure propre. D'abord, tu as le hook pre-deploy, où tu peux initialiser des ressources ou lancer des migrations de base de données. Ensuite vient le hook deploy, qui push la nouvelle version de ton application. Après ça, le hook route-traffic gère la bascule des requêtes réseau vers la version nouvellement déployée. Enfin, tu peux utiliser post-route-traffic pour lancer des health checks ou nettoyer les anciennes ressources. Si quelque chose se passe mal, il y a aussi les hooks on-failure et on-success pour gérer les rollbacks ou les notifications. Prends un scénario où tu utilises la stratégie run once pour push une container image vers un namespace Kubernetes. Dans ton pipeline, tu définis un deployment job qui cible ton Environment de production. À l'intérieur de la stratégie run once, tu utilises le hook deploy pour définir une tâche qui prend ton artifact de conteneur buildé et applique le manifest de déploiement au cluster. Tu n'as pas besoin de faire un checkout du repository parce que la container image est déjà buildée et stockée dans ton registry. Quand ce pipeline tourne, les tâches s'exécutent et Azure DevOps enregistre l'action. Comme il cible un Environment, tu peux ouvrir l'interface, cliquer sur production, et voir exactement quel commit a déclenché le build de l'image, quel développeur l'a écrit, et qu'il a bien atteint le cluster Kubernetes. Voici le point clé. Passer d'un job standard à un deployment job ne change pas seulement la façon dont ton pipeline est structuré. Ça transforme ton pipeline d'un script d'automatisation aveugle en un historique de déploiement entièrement traçable. Merci de ton écoute. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. Azure Pipelines, épisode 10 sur 10. Tu ne veux surtout pas qu'un pipeline automatisé fasse un push d'une migration de base de données massive et irréversible en production un vendredi soir. Un pipeline entièrement automatisé, c'est génial jusqu'à ce qu'il se déclenche au mauvais moment ou sans supervision humaine. C'est là que les Enterprise Gates, et plus particulièrement les Approvals et les Checks, résolvent ce problème. Avant d'examiner les checks spécifiques, on doit dissiper une idée reçue courante. Les Approvals et les Checks ne sont pas définis dans ton fichier YAML de pipeline. Ils sont configurés dans l'UI d'Azure DevOps, directement sur la ressource elle-même, comme un Environment ou une Service Connection. Cette distinction est super importante. Si ces règles étaient dans le fichier YAML, un développeur pourrait éditer le fichier sur une feature branch, supprimer les checks de production et contourner les contrôles. En plaçant la configuration sur la ressource, le propriétaire de la ressource fait respecter les règles. Ça rend ta conformité inviolable. Le code du pipeline demande simplement à utiliser la ressource, et la ressource décide si les conditions de deploy sont remplies. Appliquons ça à un scénario concret. Tu as un Environment nommé Production. Tu veux garantir la sécurité des releases et la conformité ITIL sans perdre ton automatisation. D'abord, tu veux empêcher les deploys pendant le week-end. Sur l'Environment Production dans l'UI, tu ajoutes un check Business Hours. Tu définis la fenêtre de temps autorisée, disons du lundi au jeudi, de neuf heures à dix-sept heures dans ta timezone locale. Si un pipeline essaie de deploy en dehors de cette fenêtre, il se met en pause. Il attend dans un état pending jusqu'à ce que les business hours commencent. Fini les migrations du vendredi soir. Ensuite, tu as besoin d'un sanity check humain. Tu ajoutes un check Manual Approval et tu l'assignes à un groupe spécifique, comme l'équipe QA. Quand le pipeline atteint le stage de deploy pour la Production, il s'arrête. Un e-mail part à l'équipe QA. Ils passent en revue les changements et approuvent ou rejettent explicitement le run dans le portail Azure DevOps. Le pipeline ne reprend qu'après l'approbation. Tu peux même forcer la séquence d'évaluation, en exigeant que le check Business Hours passe avant que la notification du manual approval soit envoyée. Maintenant, tu dois garantir que du code expérimental ne passe pas entre les mailles du filet. Tu implémentes le Branch Control. Tu ajoutes un check qui dit que seule la main branch est autorisée à cibler l'Environment de Production. Si quelqu'un déclenche le pipeline depuis une feature branch, le check échoue automatiquement. Le deploy est bloqué avant même d'essayer de run. Enfin, il y a le problème des deploys concurrents. Si deux développeurs font un merge de code à dix minutes d'intervalle, tu pourrais te retrouver avec deux pipelines qui essaient de mettre à jour la même infrastructure de production en même temps. Le check Exclusive Lock empêche cette race condition. Il garantit qu'un seul run de pipeline peut accéder à l'Environment à la fois. Le deuxième pipeline attend simplement dans une queue jusqu'à ce que le premier se termine, garantissant un historique de deploy propre et séquentiel. Voici l'idée clé. Les Approvals et les Checks retirent le pouvoir de deploy au code du pipeline pour le confier au propriétaire de l'infrastructure, créant une frontière sécurisée et inaltérable autour de tes systèmes critiques. Comme c'est le dernier épisode de notre série sur Azure Pipelines, je te recommande vivement de creuser la documentation officielle de Microsoft et de tester ces configurations hands-on. Si tu veux suggérer des sujets pour notre prochaine série, passe sur devstories dot eu. C'est tout pour cette fois. Merci de ton écoute, et continue à build !