CI/CD on The Cloud Optimist

Le jour où j'ai accidentellement supprimé une API, et ce que cela m'a appris sur le DevOps

Tue, 17 Feb 2026 07:30:00 +0100

La journée du 4 avril 2024 avait bien commencé. Un petit café en main, un VS Code en plein ébullition, et de la douce musique électro dans les oreilles, tant de facteurs positifs qui ne pouvaient présager de la catastrophe à venir.

Aujourd’hui, j’aimerai vous raconter comment une journée en apparence tranquille est devenue un moment marquant de ma carrière de DevOps !

Incident

Le contexte

Je travaillais alors dans une équipe avec pour but de mettre à disposition une API Gateway globale sur AWS, avec plusieurs endpoints managés par différentes équipes. Concrètement, la mise en place de cette API Gateway était l’étape initiale du projet. Cela comprenait un record DNS qui pointait vers cette API, l’API Gateway elle-même, ainsi qu’un Cognito Authorizer configuré avec plusieurs clients.

Une fois cette API prête, des équipes externes pouvaient alors déployer leurs propres endpoints sur cette API. Pour cela, une pipeline CI/CD était mise en place, et via CloudFormation, les endpoints se rattachaient directement à l’API déjà créée.

Je simplifie au maximum, si des détails techniques vous intéressent, n’hésitez pas à me contacter !

De mon côté, en plus d’être responsable de l’infrastrcture globale de l’API, il m’arrivait de travailler ou de troubleshooter certains services.

Le début du drame

Si vous avez déjà travaillé avec CloudFormation, vous êtes peut-être familier avec le terme UPDATE_ROLLBACK_FAILED. C’est ce qui arrive lorsque vous essayez de mettre à jour une stack CloudFormation, mais que celle-ci a rencontré un problème. Elle essaiera donc de faire un rollback. Mais si ce rollback n’aboutit pas, votre stack sera alors en UPDATE_ROLLBACK_FAILED.

Et ce UPDATE_ROLLBACK_FAILED est bien embêtant, car vous ne pouvez plus relancer de déploiements tant que vous n’avez pas résolu le problème.

C’est exactement ce qui s’est passé ce fameux 4 avril 2024. Un de nos services s’est retrouvé dans cet état, et j’ai commencé à investiguer le pourquoi du comment.

Après quelques minutes, j’ai constaté que le problème venait de la ressource API elle-même. Sans trop réfléchir, et dans une optique de débloquer le problème rapidement, je me suis rendu directement sur la console AWS, sur le service API Gateway. J’ai cherché la ressource en question, et me suis empressé de la supprimer.

À ce moment précis, quelque chose de très étrange s’est produit. Un comportement inattendu qui m’a glacé le sang. Au lieu de me retrouver sur la même page, AWS m’a renvoyé sur la page principale du service API Gateway. Cette même page qui liste vos APIs disponibles, et qui affichait maintenant le nombre 0.

J’ai ainsi réalisé que je n’avais pas supprimé la ressource API, mais bien l’API Gateway dans sa totalité.

Les détails d’un échec

Jamais je n’aurais pensé commettre une telle bêtise. Et j’imagine que vous lisant ces lignes, vous vous dites la même chose.

Car pour se tromper, il fallait le faire !

Laissez-moi vous faire une reconstitution de la scène du crime. Voici ce que j’ai vu au moment où j’ai pris la décision de supprimer une ressource de l’API Gateway.

Toute ressemblance avec une situation réelle est totalement fortuite

Dans ma situation, sur quel bouton auriez-vous cliqué ? Facile ! Le bouton Delete juste à droite de la ressource !

Pour ma part (et je ne sais toujours pas ce qui m’a poussé à faire cela), j’ai préféré cliquer sur le bouton API actions. Après tout, je voulais en effet faire une action !

Et que se passe-t-il quand on clique sur ce bouton ?

Oula ! De suite, on voit que ce n’est pas du tout ce qu’on veut faire. Mais pensez-vous que cela m’a découragé ? Absolument pas ! J’étais venu pour supprimer une ressource, et quand j’ai vu le mot Delete, je n’ai pas réfléchi plus longtemps ! J’aurais dû, car ainsi, j’aurais sûrement vu le mot API juste à côté.

Heureusement, nos amis de chez AWS ont pensé à tout ! Lorsque vous cliquez sur Delete API, on va tout de même vous demander si vous êtes bel et bien certain de vouloir supprimer cette API. Un beau message s’affiche, vous indiquant le nom de l’API en question, et vous demandant de taper le mot confirm pour valider cette opération.

Tout ça, c’est bien beau, mais les ingénieurs d’AWS ont sous-estimé mon impatience. À ce moment-là, cette demande de confirmation n’était pas une mise en garde, mais un obstacle à mon but de supprimer ma ressource. Ni une ni deux, j’ai entré le mot confirm, et validé l’opération.

Voici donc la dernière chose que j’ai vue avant de finalement réaliser l’erreur que j’avais commise.

Une vision d’horreur

Je voulais absolument vous retracer ce petit parcours pour vous faire comprendre une chose : vous aurez beau mettre en place toutes les sécurités possibles, vous ne pourrez jamais rien faire contre un individu impatient, car ce dernier ne saura pas lire vos avertissements.

Alors, la prochaine fois que vous devrez faire une action somme toute inoffensive, prenez bien le temps de lire et de vous assurer que vous êtes bel et bien sur le bon chemin.

Cela étant dit, passons maintenant à une étape cruciale : la résolution de cet incident !

Résolution

Le déclic

Revenons donc sur le moment du drame. Après avoir réalisé ce qui était arrivé, j’ai eu comme un électrochoc, un éclair de génie (aucune poudre blanche n’ayant pourtant été consommée). Je savais maintenant ce que je devais faire : résoudre l’incident, mais surtout, documenter les actions que j’allais entreprendre.

Car quelques semaines plus tôt, je m’étais intéressé à l’incident GitLab de 2017, celui ayant interrompu le service pendant plusieurs heures, et résultant d’une perte de données pour certains utilisateurs. J’ai ainsi découvert le terme de Post-Morten, et leur intérêt dans ce genre de situation. Mais je garde ça pour la prochaine section de cet article.

En attendant, si vous êtes intéressés par ces sujets-là, je vous conseille la très bonne chaîne Youtube de Kevin Fang qui je le cite : “lit des postmortems et en fait des vidéos de piètre qualité”.

Rollback, impact, et communication

La première chose que je me suis dite, c’est qu’il était peut-être possible de faire une sorte de rollback directement depuis AWS, et d’ainsi réduire au maximum l’impact sur les utilisateurs. Si j’avais correctement lu le message d’avertissement plus haut, j’aurais tout de suite compris que cela était impossible (mais si je l’avais lu, je n’aurais de toute façon pas été dans cette situation).

N’ayant aucun moyen rapide et simple de revenir en arrière, j’étais maintenant confiant que j’étais face à un véritable incident ayant un impact global. J’ai donc dans un premier temps pris soin de comprendre tous les impacts que cette suppression d’API allait avoir. Dans mon cas, non seulement l’API n’était plus disponible (merci Captain Obvious), mais en plus de cela, aucun nouveau déploiement n’était possible jusqu’à ce que l’API soit de nouveau opérationnelle.

Finalement, j’ai fait en sorte d’avertir toute notre équipe interne de la situation. Ainsi, ils étaient au courant de l’incident en cours, et que j’étais en train de travailler à sa résolution.

Analyse et découverte de problèmes

Il était maintenant temps de se retrousser les manches et de trouver un moyen de redéployer cette API Gateway.

En premier lieu, je me suis rendu dans le service CloudFormation, car j’avais souvenir que cette API avait été initialement déployée via ce service. J’ai d’abord essayé de mettre à jour la stack, en pensant que cela pourrait faire revenir ma chère API comme par magie.

Évidemment, cela n’allait pas être aussi simple. La mise à jour de cette stack était maintenant impossible, car la suppression manuelle de l’API avait fait rentrer la stack dans un état “hybride” dont elle n’arrivait pas à se sortir.

La mise à jour de cette stack étant impossible, la suite logique était de la supprimer afin de la déployer à nouveau proprement. Et c’est là que les ennuis ont commencé. Cette fameuse stack CloudFormation produisait plusieurs Outputs. Deux de ces outputs étaient nécessaires à toutes les stacks “enfants” qui avaient jusqu’alors déployé leurs endpoints sur cette API. Ainsi, CloudFormation m’interdisait de supprimer ma stack, car elle pourrait impacter toutes les autres.

Après plusieurs minutes de réflexion pour essayer de trouver d’autres alternatives, cette forte interdépendance m’amena à prendre une décision difficile : supprimer toutes les stacks “enfants” de CloudFormation, pour un total de 81 stacks.

Pour couronner le tout, ces stacks “enfants” n’avaient pas de tags identifiables qui auraient pu nous permettre d’automatiser cette suppression. Heureusement, la plupart d’entre elles avaient un nom avec un préfixe reconnaissable, ce qui m’a permis de faire un bon coup de ménage sur la plupart d’entre elles.

Je vous ai parlé d’interdépendances ? Parce que ce n’est pas fini ! Certaines stacks avaient déployé des buckets S3. Et devinez quoi ? CloudFormation ne voudra pas supprimer votre stack, si votre bucket S3 n’est pas vide ! Et bien sûr, 14 stacks se sont retrouvées dans l’état DELETE_FAILED à cause de cela. Heureusement, le problème se résout assez facilement : après avoir fait un backup de chaque bucket, il suffit de les vider et de relancer la suppression de la stack.

Déploiement de l’API : Le bout du tunnel ?

Étant venu à bout de toutes ces interdépendances, il était maintenant temps de supprimer la stack CloudFormation de l’API Gateway, et de la déployer à nouveau.

La suppression se passa sans plus de problème (Dieu merci), mais évidemment, cela ne fût pas le cas pour sa création.

Déjà, parlons de la stack elle-même. Un fichier YML existait dans un repo GitHub, mais celui-ci n’avait pas été mis à jour depuis des lustres, et je savais que je ferais mieux d’utiliser la définition de la stack présente dans CloudFormation (et oui, je l’ai quand même gardée, pas fou le gars).

Cette stack ne déployait pas uniquement l’API Gateway, mais plusieurs ressources AWS (je ne rentrerai pas dans les détails du pourquoi nous avions besoin de ces ressources dans cet article), dont des Lambdas. Ces dernières se basaient encore sur Python 3.7, version avec laquelle il était impossible de se servir pour créer de nouvelles Lambdas. Heureusement, un petit upgrade en Python 3.12 sera suffisant pour qu’AWS nous laisse tranquille.

Et, à ma grande surprise, la stack se déployait maintenant sans souci !

Mais je vous la fait courte, il restait encore du pain sur la planche ! En effet, il manquait à la stack CloudFormation plusieurs ressources critiques à la bonne exécution de notre API. Des ressources qui avaient été créées à la main dans AWS directement, faisant fi de toute bonne pratique d’Infrastructure as Code (pleure en Terraform). Dans un souci de rétablissement du service le plus rapidement possible (on est DevOps, ou on ne l’est pas !), ces ressources seront donc créées une nouvelle fois à la main.

Pour finir, plusieurs composants clés faisaient référence à l’ARN de l’ancienne API en dur. Il fallait ainsi faire tout un travail d’archéologie pour trouver tous les endroits où une mise à jour vers la nouvelle API s’imposait.

Finalement, après plusieurs heures de troubleshooting, l’API était de nouveau opérationnelle, et les développeurs pouvaient à nouveau déployer leurs projets.

Cet incident aura démarré le 4 avril 2024 à 15h24 et se sera conclu le 5 avril 2024 à 08h46.

Post-Mortem et Lessons Learned

Pendant cet incident, j’ai réalisé une prise de note intensive sur les actions menées. J’avais déjà entendu parler du principe de Post-Mortem, et je pensais que cet incident serait le parfait candidat.

Si vous ignorez le principe d’un Post-Mortem, il agit comme un document retraçant les étapes de résolution d’un incident, couvrant les impacts, et la root cause, mais surtout — et à mon sens le plus intéressant — comporte une section appellée Lessons Learned. Cette section, si vous la prenez au sérieux, sera votre meilleure alliée pour construire une architecture plus robuste et plus durable.

Concrètement, vous allez noter dans cette section trois points clés : ce qui s’est bien passé, ce qui s’est mal passé, et là où vous avez eu de la chance. Et surtout, soyez honnêtes ! Même si certains points vous paraissent bêtes, ou vous font passer pour un incompétent (et je vous dis ça alors que j’ai manuellement supprimé une API, donc prenez-le avec légèreté), le but n’est pas de pointer du doigt (ce qu’on appelle aussi la blameless culture), mais de comprendre les failles dans notre système, afin de les améliorer.

« The cost of failure is education. » — Devin Carraway (Source)

Cela vous paraît peut-être encore un peu flou, alors laissez-moi vous montrer mes lessons learned de cet incident.

What went well

Pendant cet incident, deux choses se sont bien passées.

D’abord, la résolution s’est faite par un membre de l’équipe qui connaissait en profondeur cette architecture, ce qui a permis de comprendre rapidement ce qui devait être remis en place pour restaurer le service.

Enfin, il y a eu une bonne communication tout au long de cet incident. Lorsque le problème s’est présenté, il n’a pas essayé d’être dissimulé, et des mises à jour fréquentes ont été annoncées pour avertir de l’avancement de sa résolution. C’est un point très important, car non seulement vous donnez de la visibilité sur vos actions, mais par la communication, vous pouvez aussi acquérir des informations utiles à la résolution de votre incident (un collègue pourra par exemple vous pointer vers une documentation dont vous n’avez pas connaissance, ou vous donner un coup de main si nécessaire).

What went wrong

Ici, c’est la partie qui fait mal. Comme je vous l’ai dit, il faut ravaler sa fierté, et mettre en lumière tout ce qui aurait pu être mieux exécuté.

Pour cet incident, quatre choses ne se sont pas bien passées.

Pour commencer, l’infrastrucutre de cette API n’était non seulement pas consolidée dans un seul et même fichier (ou dossier), mais était en plus disséminée dans plusieurs repos GitHub. Il était ainsi très compliqué d’avoir une vue d’ensemble de ce qui était nécessaire au bon fonctionnement de cette API.

Ensuite, un gros problème résidait dans ce qu’on appelle le drift. Ce sont toutes les différences que vous avez entre votre infrastructure réelle, et votre infrastructure telle qu’elle est définie dans votre code. Idéalement, aucune modification manuelle ne doit avoit lieu, et tout doit passer par votre fichier d’Infrastructure as Code. Si cela avait était le cas, un simple redéploiement aurait permi une remise en service instantanée.

Un autre problème résidait dans la forte interdépendance de toutes les ressources. Beaucoup par exemple se basaient sur un output de la stack CloudFormation. Si vous enlevez cette stack, vous enlevez ainsi la possibilité de déployer la suite de votre infrastructure.

Enfin, l’identification des ressources liées à notre infrastructure était difficile. Notre stack déployait les ressources sans aucun tag associé, ce qui rendait compliqué la recherche de toutes les ressources nécessaires à notre API.

Where we got lucky

Cette partie peut ressembler à du positif, mais il n’en est rien ! Car vous allez ici parler des élément qui se sont bien passés, mais UNIQUEMENT car vous avez eu de la chance. Comprenez qu’à tout moment, cela aurait pû être un autre point à mettre dans la catégorie “What went wrong”. Donc soyez heureux pour cette fois, mais ne baissez pas votre garde pour autant !

Pour cet incident, trois choses se sont bien passées par chance.

Tout d’abord, l’incident a été immédiatement identifié (c’est au moins l’avantage quand on fait une boulette pareille). Mais cela aurait pû être bien pire ! Car si cette API avait été supprimée par tout autre moyen (un script d’automatisation par exemple), nous n’avions aucun monitoring en place capable de nous prévenir d’une telle chose.

Ensuite, il se trouve que la personne qui a supprimé cette API avait une excellente connaissance du projet et de l’infrastructure (je parle de moi oui, il faut bien s’envoyer quelques fleurs). Cela a permis de très vite enchaîner sur la résolution de l’incident, mais cela aurait pu se passer autrement.

Enfin, cette API était en fait notre API de dev. L’API de prod, elle, allait très bien (détail que j’ai volontairement gardé pour la fin, il paraît que c’est du storytelling). Alors certes, l’impact fût minime, mais l’incident aurait tout de même pû arriver en production, avec les mêmes problématiques de remise en service. Et cela aurait pû coûter bien plus cher.

Préparer le futur

Maintenant que vous avez pu lister les problèmes rencontrés lors de la résolution de cet incident, en tant que bon DevOps, vous vous devez d’en tirer les leçons. Notez bien tout ce qui pourrait être amélioré, mais surtout, fixez-vous un plan ! Sinon, ce ne seront que de vastes phrases sans utilité.

« Tout objectif sans plan n’est qu’un souhait. » — Antoine de Saint-Exupéry

Dans mon cas, les trois leçons clés ont été les suivantes :

Consolidation de l’Infrastructure as Code : tout doit pouvoir être déployé en un clin d’oeil. C’est un chantier que je serai amené à compléter dans les mois qui suivirent (mais cette histoire, c’est pour une prochaine fois).
Amélioration du monitoring et de l’alerting : si cet incident devait de nouveau arriver, il nous faut être averti rapidement afin de réagir en vitesse.
Documentation plus claire et cohérente : n’importe quel membre de l’équipe doit pouvoir faire face à un tel incident, et cela commence par une documentation fiable et compréhensible.

Toutes ces leçons seront ensuite trackées en tant qu’issues GitHub, et je m’appliquerai à les compléter dans les mois qui suivirent (mais cette histoire, c’est pour une prochaine fois).

Conclusion

Vous l’aurez compris, un accident ça arrive. L’essentiel est qu’il soit bénéfique pour vous, et l’ensemble de votre organisation. Servez-vous en comme d’une opportunité d’apprendre et de consolider des failles qui n’était jusqu’alors pas détectées (certaines entreprises s’amusent d’ailleurs même à volontairement créer ce chaos).

Merci de m’avoir lu jusqu’au bout ! Je vous laisse ici, car j’ai d’autres infrastructures à supprimer !

Comment j'ai automatisé la création de mon blog dans le Cloud

Tue, 04 Mar 2025 07:30:00 +0100

Le commencement et la fin

Quand j’ai envisagé de créer un blog pour la première fois, j’étais encore étudiant dans mon école d’ingénieurs. Et le monde des sites internets et des blogs était encore quelque chose de nouveau pour moi. Et lorsque je me suis finalement lancé dans l’aventure du blogging, c’est tout naturellement que je me suis tourné vers ce qui semblait être la meilleure solution à l’époque : WordPress.

Quoi que l’on en dise, WordPress est une solution relativement simple d’usage pour les débutants qui souhaitent créer leur premier site internet. Et ça tombe bien, car j’en faisais parti !

Alors, armé d’un tout nouveau compte chez OVH, j’ai pû mettre en ligne mon blog personnel en quelques cliques !

Et puis, quelques années plus tard, quand me vint l’idée de publier un blog dédié à des sujets professionels, là encore, j’ai fait appel à mon bon vieil ami WordPress.

Les mois passèrent, et l’idyle que je vivais avec WordPress commençait petit à petit à se ternir. Certes, rajouter des articles à travers l’UI de WordPress était pratique, mais pour ce qui était de gérer les backups, c’était une autre paire de manches. En plus, WordPress requiert une base de données pour fonctionner, ce qui rendait le tout très volumineux pour quelques articles, sans compter la facture qui venait avec.

Je me rendais alors compte que, pour un blog aussi simple, et avec si peu de visites, il y avait certainement un moyen d’améliorer les choses.

Le début d’un nouveau plan

Je vais vous raconter ici le cheminement qui m’a amené au renouveau de mon blog sur lequel vous vous trouvez aujourd’hui. Si vous êtes seulement intéressé par les détails techniques, vous pouvez avancer à la prochain section. Sinon, bonne lecture !

La découverte d’Hugo

Avant de me mettre en quête d’un nouvel outil pour mon blog, j’ai d’abord réfléchi à ce dont j’avais réelement besoin.

Mon blog était en fait assez rudimentaire : une page d’accueil qui listait les différents articles, pas de JavaScript tarabiscoté dans les parages, et aucun besoin d’un backend pour gérer une API. Au final, l’utilisation d’une base de données était-elle nécessaire ?

Il y avait aussi une chose importante à garder en mémoire. Je suis un ingénieur, ce qui fait de moi par définition, un bien piètre designer. Je voulais à tout prix éviter d’avoir à gérer le CSS de mon blog : je voualais me concenter sur le contenu, plutôt que sur le style.

J’ai donc commencé mes recherches, dans l’espoir de trouver un outil qui répondrait à ces critères. Et il ne m’a pas fallu bien longtemps avant de tomber sur la perle rare : Hugo.

À peine eus-je atterri sur le site d’Hugo que je fus accueilli par cet intriguant message : Le framework le plus rapide du monde pour générer des sites web. On peut dire que cela a piqué ma curiosité, et je me pressa d’aller fouiller dans la documentation. Et je n’allais pas être déçu.

Hugo se charge de convertir des articles au format markdown (comme l’on trouve sur les README de GitHub par exemple) vers le format HTML. Qui plus est, il existe une miriade de thèmes mis à disposition, ce qui me laissait l’embarras du choix, sans avoir besoin de designer quoi que ce soit !

Sans perdre une seconde, je m’empressai de convertir mon blog WordPress vers un site Hugo (j’ai utilisé pour ça un super petit script intitulé wordpress-to-hugo-exporter qui convertit une base de données WordPress en fichiers markdown avec l’arborescence requise pour Hugo).

Mon site Hugo était désormais prêt ! Il fallait maintenant trouver un moyen de l’héberger quelque part.

Un hébergeur à la hauteur : AWS

En même temps que je me creusais la tête pour trouver une alternative pour mon blog, j’ai eu une opportunité professionnelle qui m’a amené à travailler dans une entreprise spécialisée dans le Cloud, et plus particulièrement AWS.

À l’époque, le Cloud était tout nouveau pour moi. Mais j’en entendais tellement parler, que je voulais connaître la raison de cet engouement. Était-ce vraiment un “game-changer”, comme certains le disaient, ou était-ce encore un de ces mots-clés techniques qui faisait le buzz ?

Pour vous la faire courte, AWS était (et est toujours) absolument incroyable ! Ce n’était pas seulement la découverte d’un nouvel outil, il s’agissait là d’un changement de paradigme qui ne me ferait plus jamais aborder un problème de la même manière (si vous ne connaissez pas AWS et pensez que j’en fais trop, attendez de vous y mettre…).

Plus j’en apprenais sur AWS et la multitude de services qui le composait, plus je me disais : n’y a-t-il pas un moyen pour moi d’utiliser le Cloud pour mon blog ?

Avec cette idée en tête, je commençais à me renseigner sur toutes les options qu’offrait AWS. Et compte tenu de ma récente découverte d’Hugo, mon site n’avait ni besoin de PHP, ni d’une base de données pour fonctionner. Il s’agissait maintenant d’un site statique qui, à première vue, pouvait très bien être déployé dans un bucket S3.

Et non seulement AWS offre une documentation sur l’hébergement d’un site statique dans un bucket S3, mais le coût de stockage d’un site si léger ne représentait que quelques centimes.

J’avais trouvé là une manière simple et peu coûteuse d’héberger mon site.

Le dernier point qui me chiffonait, est que pour mettre en place tout cela, je devais créer un bucket AWS S3, le configurer convenablement, rajouter le CDN AWS CloudFront, prendre en compte les certificats via AWS ACM, et finalement créer une entrée DNS dans AWS Route53. Tant d’actions qui, si réalisées manuellement, pouvaient être difficiles à reproduire si jamais je venais à accidentellement supprimer mon compte AWS.

Il me fallait donc maintenant un moyen simple et robuste de configurer cette infrastructure.

Terraform à la rescousse

Quand vous commencez à apprendre le Cloud, vous allez généralement entendre parler d’Infrastructure as Code.

Le principe est simple : décrire son infrastructure Cloud avec… du code ! (oui, comme son nom l’indique).

L’avantage d’utiliser un outil d’IaC, c’est que vous allez pouvoir garder en mémoire les changements effectués sur votre infrastructure, et pouvoir ainsi avoir un historique de toutes les modifications effectuées (un peu comme vous pouvez le faire avec du code classique sur GitHub).

Imaginons par exemple que quelqu’un décide de changer la configuration d’un service AWS. Cette personne se connecte sur la console AWS et effectue ces modifications. Mais après plusieurs essais infructueux, cette personne décide de laisser tomber pour le moment, et de revenir en arrière. Mais voilà, elle n’est plus vraiment sûr de la manière dont le service était configuré au départ ! Et à moins d’avoir pris note de l’état initial, cette personne n’a plus qu’à deviner à coups de plusieurs essais l’état dans lequel remettre ce service.

Tout cela aurait pû être évité si le service avait initialement été configuré avec un outil d’Infrastructure as Code. Si tel avait été le cas, un petit coup de déploiement automatique aurait fait l’affaire !

Des outils d’IaC, il en existe un paquet. Mais comment ne pas parler du plus populaire, de celui qui a rendu cette pratique commune dans le milieu du Cloud : Terraform.

Terraform est donc un outil d’Infrastructure as Code avec une approche déclarative, ce qui signifie que c’est à vous de déclarer l’état dans lequel vous souhaitez déployer votre infrastructure. Pour cela, il faut utiliser un langage bien particulier : le hcl (pour HashiCorp Configuration Language). Voici par exemple la création d’un bucket S3 via Terraform.

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"

  tags = {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

Revenons maintenant à mon blog ! Terraform me semblait l’outil parfait pour configurer mon infrastructure qui accueillerait mon blog. Je n’avais plus qu’à passer par une étape d’architecture pour savoir de quels services AWS j’aurais besoin et comment les connecter entre eux, avant de mettre la main dans le code pour définir tout cela en langage Terraform.

Voici d’ailleurs le diagramme d’architecture que j’ai initialement crée pour l’occasion.

Tout cela était parfait, mais je me rendis vite compte d’une chose. À chaque fois que j’allais rajouter un article, ou que je devais modifier mon infrastructure, il me fallait cloner le projet sur mon ordinateur, et effectuer tout un tas d’opérations manuelles.

Autant vous dire que cela ne me plaisait pas du tout, et je comptais bien y remédier !

Oubliez les copier-coller avec GitHub Actions

Comme je le disais juste au-dessus, mon site était fin prêt. La dernière étape qui me manquait concernait le déploiement.

Pour l’instant, quand je voulais créer un nouvel article, il me fallait build le site Hugo à la main, et déplacer les fichiers générés dans mon bucket S3. Quel terrible gâchis de temps et d’énergie !

J’ai donc creusé le sujet des pipelines CI/CD afin de me rendre la vie plus simple (si le sujet vous intéresse, je vous conseille mon article sur la mise en place d’une stratégie CI/CD). Et bien que Jenkins essayait à tout prix de se distinguer, je suis parti sur ce qui semblait être le plus logique : GitHub Actions.

Les GitHub Actions sont en fait des pipelines CI/CD qui sont définies directement dans votre repository GitHub. Le gros avantage, est que vous n’avez pas besoin de créer un compte supplémentaire ou d’installer quoi que ce soit, tout est inclus ! En plus de ça, GitHub Actions utilise une syntaxe YAML très facile à comprendre (contrairement à Jenkins et son groovy des enfers !).

C’est donc assez facilement que j’ai pû créer une pipeline qui me reconfigure Terraform si mon infrastructure a été modifiée, et qui me build et deploy automatiquement mon blog sur mon bucket S3 en cas de modifications ou ajout d’un article.

Toutes les steps de la pipeline sont au vert, mission accomplie !

Côté technique : L’état actuel des choses

Mon blog est désormais automatisé et se déploie sur AWS automatiquement !

Si vous voulez plonger directement dedans, tout est publique sur mon repository GitHub : https://github.com/antoinedelia/cloud-optimist

Mais laissez-moi détailler un peu tout ça.

Structure du projet

La structure de mon projet est comme suit :

cloud-optimist/
├── .github/
│   └── workflows/
│       └── main.yml  # GitHub Actions
├── cloud/
│   └── ...  # Mon blog Hugo
├── terraform/
│   └── ...  # La configuration Terraform
└── README.md

Comme vous le voyez, je sépare ce projet en trois dossiers clés :

.github : contient le fichier main.yml qui définit les étapes CI/CD de la GitHub Actions
cloud : contient mon blog Hugo
terraform : contient toute l’infrastructure Terraform

La GitHub Actions

Ma GitHub Actions est assez simple, et se décompose en plusieurs étapes.

Les étapes de préparation

Regardons d’abord le haut du fichier.

name: 'Build and Deploy'

on:
  push:
    branches:
    - master
  pull_request:

jobs:
  build-and-deploy:
    name: 'Build & Deploy'
    runs-on: ubuntu-latest
    environment: production

    defaults:
      run:
        shell: bash
        working-directory: cloud

Ici, je dis à GitHub de lancer la pipeline uniquement sur la branch master, ou s’il s’agit d’une Pull Request. Je vous rassure, je ne déplois rien en production via une Pull Request. Vous verrez un peu plus bas, que cela me permet uniquement de build mon blog afin de tester que tout va bien, mais le déploiement ne sera effectué qu’une fois les changements mergés sur la branch master.

J’indique également à GitHub d’utiliser bash, et de se baser par défaut dans le dossier cloud.

Voyons maintenant la suite :

    steps:
    - uses: actions/checkout@v3
    - uses: dorny/paths-filter@v2
      id: filter
      with:
        filters: |
          web:
            - 'cloud/**'
          terraform:
            - 'terraform/**'

Cette première étape est cruciale si vous voulez accélérer vos temps de CI/CD ainsi qu’économiser de l’argent.

Je me sers de l’actions dorny/paths-filter qui me permet de détecter quels fichiers ont été modifiés lors du dernier commit. Dans mon cas, je regarde en particulier les dossiers cloud et terraform. Ainsi, si je ne détecte pas de changements côté Terraform, aucun besoin de lancer l’étape qui va reconfigurer mon infrastructure. Idem, si le dossier cloud est intact, inutile de build et deploy le blog. Cela vous sauvera quelques centimes liés au coût de transfert de fichiers vers AWS (pas la peine de me remercier !).

La section suivante parle d’elle-même.

    # Checkout the repository to the GitHub Actions runner
    - name: Checkout
      uses: actions/checkout@v2
      
    - name: Update Git Submodules
      working-directory: ./
      run: git submodule update --init --recursive

Je viens récupérer le contenu de mon repository et m’assure de mettre à jour les submodules. Cette dernière étape me servait du temps où j’utilisais les submodules pour mes thèmes Hugo. J’utilise désormais les Hugo Modules, et je pourrais donc zapper cette étape.

Les étapes Terraform

Passons à la partie Terraform :

    # Install the latest version of Terraform CLI and configure the Terraform CLI configuration file with a Terraform Cloud user API token
    - name: Setup Terraform
      if: steps.filter.outputs.terraform == 'true'
      uses: hashicorp/setup-terraform@v1
      with:
        cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}

    # Initialize a new or existing Terraform working directory by creating initial files, loading any remote state, downloading modules, etc.
    - name: Terraform Init
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform init

    # Checks that all Terraform configuration files adhere to a canonical format
    - name: Terraform Format
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform fmt -check

    # Generates an execution plan for Terraform
    - name: Terraform Plan
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform plan

      # On push to master, build or change infrastructure according to Terraform configuration files
    - name: Terraform Apply
      working-directory: ./terraform
      if: steps.filter.outputs.terraform == 'true' && github.ref == 'refs/heads/master' && github.event_name == 'push'
      run: terraform apply -auto-approve

C’est déjà bien plus long ! Analysons ça étape par étape.

La première chose qui devrait attirer votre attention, c’est cette ligne :

`1`	`if: steps.filter.outputs.terraform == 'true'`

Vous vous rappelez, c’est ce qui permet de dire si des fichiers ont été modifiés dans le dossier terraform. Je vérifie donc ici si j’ai besoin de lancer ces étapes ou non.

Ensuite, je lance quelques commandes basiques de Terraform : un terraform init pour initialiser mon projet, un terraform fmt -check pour m’assurer que mon code est tout joli, et enfin un terraform plan pour voir les changements à effectuer.

Reste une dernière étape, et pas des moindres : le terraform apply -auto-approve, qui permettra de déployer les changements. Mais si vous êtes attentifs, vous remarquerez que j’ai rajouté deux conditions :

`1`	`github.ref == 'refs/heads/master' && github.event_name == 'push'`

Cela me garantit que cette étape ne sera uniquement lancée si l’action est un push sur la branch master. Ainsi, aucun risque de déploiement inopportun si je décide de travailler sur une autre branch ou sur une Pull Request. Ouf !

Les étapes Hugo et AWS

Maintenant que mon infrastructure est au point, il est temps de publier mon blog !

    - name: Build
      uses: actions/setup-node@v2
      if: steps.filter.outputs.web == 'true'
    - run: sudo wget https://github.com/gohugoio/hugo/releases/download/v0.142.0/hugo_extended_0.142.0_linux-amd64.deb -O hugo.deb
    - run: sudo dpkg --install ./hugo.deb
    - run: hugo

    - name: Deploy to AWS
      uses: jakejarvis/s3-sync-action@master
      if: steps.filter.outputs.web == 'true' && github.ref == 'refs/heads/master' && github.event_name == 'push'
      with:
        args: --acl public-read --follow-symlinks --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'eu-west-1'
        SOURCE_DIR: 'cloud/public/'

Comme pour Terraform, nous vérifions si des modifications ont été effectuées au niveau du blog.

`1`	`if: steps.filter.outputs.web == 'true'`

Ensuite, je récupère une version extended d’Hugo directement depuis la release GitHub, ici la version v0.142.0. Je l’installe et build mon site en lançant la commande hugo.

Cette étape pourrait être simplifiée avec l’utilisation de l’actions peaceiris/actions-hugo

Enfin, j’utilise l’actions jakejarvis/s3-sync-action (je me rends compte en écrivant cet article que cette actions a été archivée quelques jours plus tôt, aïe ! – je rajouterai un edit plus tard pour parler d’une alternative) pour déplacer mon blog vers mon bucket S3.

Bien sûr, il vous faudra stocker vos credentials au niveau de votre repository GitHub pour autoriser cette opération vers AWS, mais rien de bien sorcier !

La partie Terraform

Concernant la partie Terraform, je vais essayer d’être bref, car il n’y a rien de bien compliqué.

Une particularité dans mon cas, c’est que j’aime séparer mes fichiers .tf en fonction des services AWS utilisés, plutôt que d’avoir un unique fichier main.tf qui peut vite devenir difficile à lire. J’ai donc un fichier s3.tf pour les ressources liées au service S3, un cloudfront.tf pour tout ce qui est lié au service CloudFront, etc.

Un détail important, c’est qu’il est nécessaire de définir à minima la region us-east-1, car c’est dans cette region que vous devez créer vos certificats ACM. Pour le reste, toutes mes ressources sont créées dans la region eu-west-1. J’utilise pour cela les alias Terraform. Voici un exemple :

# La configuration par défaut : les ressources qui commencent par `aws_` utiliseront ce provider
provider "aws" {
  region = "eu-west-1"
}

provider "aws" {
  region = "us-east-1"
  alias  = "us_east_1"
}

resource "aws_s3_bucket" "site" {
  bucket        = var.bucket_name
  force_destroy = true
}

resource "aws_acm_certificate" "cert" {
  provider                  = aws.us_east_1  # Utilise le provider AWS dans us-east-1 via son alias
  domain_name               = var.domain_name
  subject_alternative_names = ["*.${var.domain_name}"]
  validation_method         = "DNS"
}

La partie Hugo

Mon blog Hugo se base sur le theme Stack. Il existe d’ailleurs un template GitHub qui vous permet en un clic de récupérer le squelette du blog, et de l’adapter selon vos envies, ou de tout simplement vous concentrer directement sur vos articles.

Pas grande chose de plus à dire sur cette partie, si ce n’est que je vous encourage à voir le fonctionnement des Hugo Modules, ce qui vous évitera de gérer vos thèmes via un submodule (et qui vous simplifiera la vie lors de la mise à jour du thème).

Pistes d’améliorations

Bien que je sois très satisfait du résultat final, j’ai noté quelques points qui pourraient être améliorés dans le futur.

D’abord, j’ai vu qu’Hugo dispose d’une commande deploy qui est capable de déployer directement un blog sur un bucket S3. Parfait ! Je dois donc creuser le sujet de Hugo Deploy.

Enfin, même si l’hébergement dans AWS est peu coûteux (moins de 2$ par mois), il n’en est pas moins gratuit. Or, il serait tout à fait possible d’utiliser les GitHub Pages pour rendre ce blog accessible, et profiter de GitHub comme hébergement (là-dessus, je suis un peu moins emballé, car je ne pourrais plus me la péter avec mes jolis diagrammes AWS…).

Conclusion

Et voilà, vous savez tout !

De mes débuts avec WordPress, qui, bien que pratique, présentait des faiblesses du point de vue backup, maintenance et déploiement.

De mes recherches pour trouver une stack technique parfaite : AWS, Terraform, Hugo et GitHub Actions, tout ça pour permettre un déploiement rapide et à moindre coût !

Quand je compare avec ce que j’avais à l’époque, je ne suis que trop heureux d’avoir sauté le pas !

Et vous aussi, vous avez maintenant toutes les informations pour créer un blog à vous, et déployer tout ça en un clin d’oeil !

Happy blogging !

Comment mettre en place une stratégie CI/CD pour onboarder plus de 100 projets Python en moins d'une minute

Sun, 19 Jan 2025 16:45:00 +0200

Nous savons tous que les pipelines CI/CD sont importantes. Il semble même impossible d’imaginer un monde où l’on déploie un projet en production sans vérifier la qualité de son code et sans s’assurer que des tests ont été effectués. De plus, pour permettre aux développeurs de se concentrer sur le développement, tout cela devrait être automatisé.

Eh bien, les choses ne sont pas toujours aussi simples.

Aujourd’hui, je vais vous partager comment nous sommes passés de l’absence de stratégie CI/CD à l’intégration de plus de 100 projets Python en moins d’une minute.

La réalité

Lorsque j’ai rejoint mon entreprise actuelle, j’ai constaté que nous gérions un grand nombre de projets Python. Mais quand j’ai essayé de vérifier la CI/CD de ces projets, c’était un peu le bazar. Certains projets avaient une configuration CI/CD, mais pas beaucoup. Et ceux qui en avaient une n’utilisaient pas les mêmes règles pour vérifier la conformité du code. Il était clair que la mise en place d’une CI/CD pour chaque projet était traitée comme un effort de dernier recours. Et, pour être honnête, cela se comprend.

En effet, bien que les pipelines CI/CD soient largement reconnues pour leur efficacité, leur mise en place s’avère souvent difficile.

Mais je savais que nous pouvions changer cela d’une manière ou d’une autre. Avant de sauter dans une stratégie à mettre en place, je voulais comprendre ce qui avait empêché cette mise en place en premier lieu.

Manque de permissions

La première chose que j’ai réalisée, c’est que tous les développeurs n’avaient pas le même niveau d’accès à notre instance Jenkins. Tandis que certains pouvaient créer de nouvelles pipelines pour leurs projets, d’autres ne le pouvaient pas. Dans les grandes entreprises, ce genre de scénario n’est pas rare.

Leçon apprise : un manque de permissions ne devrait pas être un obstacle pour utiliser une pipeline CI/CD.

Manque de connaissances

Lorsque les développeurs avaient la possibilité de créer un pipeline, certains ne le faisaient pas, simplement parce qu’ils n’avaient pas les connaissances nécessaires. Il faut préciser que notre entreprise utilise une instance Jenkins comme outil officiel de CI/CD. Cet outil, bien qu’ayant fait ses preuves, reste pour le moins difficile d’usage, notamment pour les jeunes développeurs qui sont souvent familiers avec d’autres outils CI/CD (comme GitHub Actions ou CircleCI). De plus, nous n’avions pas de documentation claire sur le processus à suivre pour créer une nouvelle pipeline. Ainsi certains développeurs, de peur de casser quelque chose, préféraient ne pas prendre de risques en évitant de toucher à Jenkins.

Leçon apprise : nous devons nous assurer que les personnes sans connaissances sur Jenkins puissent utiliser un pipeline CI/CD.

Manque de temps

Mettre en place une pipeline CI/CD au début d’un projet demande du temps, chose qui peut être négligée par les chefs de projets qui veulent expédier un produit aussi rapidement que possible. De plus, il est parfois difficile de quantifier le retour sur investissement d’une pipeline CI/CD. Et si cela est difficile à prouver comme étant bénéfique pour l’entreprise, cela finit dans la boîte “on s’en occupera plus tard”. Et nous savons tous que les tâches qui finissent dans cette boîte ne verront plus jamais la lumière du jour.

Leçon apprise : la mise en place d’une pipeline CI/CD doit être rapide et simple.

Manque de guidelines claires

Enfin, j’ai jeté un œil aux projets qui eux avaient une pipeline CI/CD. Ils fonctionnaient bien, mais je pouvais clairement voir qu’ils manquaient d’une vision commune. Certains utilisaient le même formateur de code (black), mais pas toujours avec la même longueur de ligne. Certains incluaient une étape de test, d’autres non. Nous avions donc des projets n’ayant pas la même qualité et conformité de code. Et cela pouvait potentiellement créer de la confusion pour un nouveau développeur, ne sachant pas quel standard suivre.

Leçon apprise : des guidelines claires de CI/CD doivent être mises en place.

La vision globale

Après avoir analysé ce qui pouvait poser problème, il est maintenant important de penser à une solution qui puisse résoudre tous ces points, tout en respectant les meilleures pratiques de l’entreprise et en utilisant les outils à notre disposition.

Formatting

La première étape serait d’utiliser un formateur pour s’assurer que chaque ligne de code dans notre base de code soit uniforme. Cela permet d’éviter que nous ayons des standards de code différents à travers nos projets.

Auparavant, nous utilisions black comme formateur. Mais après avoir entendu beaucoup de bien sur le nouvel outil à la mode, nous avons décidé de passer à ruff, offrant les mêmes avantages que black, mais avec une exécution plus rapide (entre autres).

Linting

L’étape suivante serait d’utiliser un linter pour détecter les problèmes potentiels dans notre code. Cela nous permet d’éviter la complexité dans notre code, ainsi que de repérer les mauvaises pratiques ou les problèmes de sécurité.

Dans le passé, j’utilisais beaucoup flake8. Mais étant donné que nous utilisions déjà ruff, et que celui-ci peut également agir comme un linter, la question ne se posait plus.

Il existe de nombreuses règles que ruff peut appliquer. Nous avons décidé d’en utiliser certaines par défaut, tout en laissant une certaine liberté aux développeurs selon les projets.

Tests unitaires

Les tests sont une partie critique du développement de tout projet. Ils assurent que nous livrons un code de qualité en production, tout en nous permettant de nous assurer que notre code fonctionnera correctement.

Nous avons décidé d’utiliser pytest pour exécuter ces tests. Le répertoire de code par défaut devrait s’appeler src, et tous les tests devraient être dans un dossier tests, avec des fichiers préfixés par test_.

Code Coverage

Étroitement liée aux tests unitaires, le code coverage nous permet de savoir jusqu’où notre code a été testé. Cela peut nous indiquer rapidement si nous avons suffisamment testé notre code, ainsi que nous indiquer les lignes restantes à couvrir.

Comme nous utilisions pytest, nous avons décidé d’utiliser pytest-cov pour générer un coverage report, car il s’intègre parfaitement avec pytest.

Nous avons fixé le seuil de couverture minimale à 50 %. En dessous, cela risquerait de négliger des portions importantes du code, tandis qu’au-dessus, cela pourrait décourager les développeurs d’écrire les tests nécessaires.

Jenkins Organization Folders

Les étapes de notre futur pipeline étaient prêtes. Il nous restait à trouver un moyen d’appliquer globalement cette pipeline à nos repositories Python. J’ai alors cherché un moyen de le faire facilement via Jenkins.

C’est là que je suis tombé sur les Organization Folders.

Les Organization Folders sont conçus pour des scénarios comme le nôtre : scanner automatiquement une organisation (comme une organisation GitHub), filtrer les repositories que vous voulez et appliquer une pipeline Jenkins à ces derniers.

Dans notre exemple, nous pouvons rechercher tous les repositories avec le topic “python” et les identifier comme projets Python. Ils seront alors automatiquement build par Jenkins. Si un nouveau repository est créé avec ce topic, il sera également pris en charge par Jenkins.

Ainsi, en moins de 5 secondes, votre projet peut être intégré, sans avoir à le créer dans Jenkins. Tout est fait automatiquement pour que vous puissiez vous concentrer sur votre code.

Exemples et documentation

Tout cela était génial, mais je redoutais un dernier obstacle. Que se passerait-il si les développeurs essayaient cette pipeline CI/CD, tout ça pour se rendre compte que leur projet ne passaient pas ces étapes ? Sans documentation claire pour résoudre ces problèmes, ils abandonneraient ou essaieraient de corriger ces erreurs plus tard, ce qui détruirait notre objectif initial.

Je savais donc que pour embarquer les gens dans ce processus, il fallait fournir une documentation claire avec des exemples concrets, pour qu’ils puissent avoir les clés pour résoudre ces erreurs.

En particulier pour l’étape des tests unitaires, car je ne sais que trop bien que cela représente une tâche décourageante à démarrer. J’ai donc préparé un projet à l’avance avec des tests unitaires déjà prêts. N’importe qui pouvait ainsi s’en inspirer, ou direcement recopier certaines parties complexes (par exemple, le mock des appels API boto3).

La dernière étape serait de faire une présentation sur tout ce que je viens d’évoquer. Cela était essentiel pour expliquer et donner du sens à ce projet, pour que les développeurs comprennent réellement l’intérêt de tout cela, tout en s’assurant qu’ils aient toutes les clés pour être autonomes. Enfin, cela serait également l’occasion de répondre à de nombreuses questions, et assurer que tout le monde comprenne le fonctionnement de cette nouvelle pipeline.

Ce que nous avons aujourd’hui

Du point de vue d’un développeur, tout ce qu’il doit faire pour ajouter une pipeline CI/CD à son projet Python est d’ajouter le topic python à son repository et de s’assurer qu’un fichier pyproject.toml est bien créé à la racine du projet.

Ces deux exigences permettent à Jenkins de savoir quels projets il doit prendre en compte. Le fichier pyproject.toml est en effet indispensable pour les étapes de ruff dans la pipeline.

Une fois cela fait, le projet Python vérifiera maintenant les problèmes de formatage, les erreurs de linting, la validation des tests unitaires et la couverture du code.

Au final, nous pouvons maintenant mettre en place des pipelines CI/CD en moins d’une minute, que ce soit pour un nouveau projet ou un projet existant !

Quelques défauts

Bien que cela simplifie beaucoup de choses, il reste encore des améliorations possibles.

La pipeline ne peut pas être imposée

Actuellement, cette pipeline CI/CD ne peut pas être imposée, car les développeurs peuvent simplement retirer le topic python. Et bien que cela soit acceptable au début (car nous ne voulons pas bloquer les développeurs dans leur travail), l’objectif reste de s’assurer que nous appliquons les mêmes bonnes pratiques à tous les projets Python.

Cela pourrait être résolu à l’avenir par l’utilisation des GitHub Rulesets.

Ces règles fonctionnent à peu près de la même manière que les règles de protection des branches, sauf que vous définissez ces règles au niveau de votre organisation GitHub.

De cette manière, nous pourrions protéger nos branches principales pour tous nos repositories qui matchent à des “custom properties” et ainsi exiger qu’ils valident leur pipeline CI/CD avant de pouvoir merger.

Les étapes de la pipeline peuvent être ignorées

Le fichier pyproject.toml est utilisé pour dire à ruff quel format il doit appliquer ou quelles règles suivre.

Et comme nous utilisons actuellement le pyproject.toml dans chaque repository, un développeur pourrait simplement enlever ces règles, contournant ainsi toutes les directives que nous essayions d’appliquer au départ.

Encore une fois, bien que nous permettions cela pour l’instant afin de prendre en compte les nombreuses corrections à apporter, à terme, nous aimerions vouloir empêcher cela.

Nous pourrions soit utiliser un fichier pyproject.toml commun et fixe, soit l’ajouter dans le fichier CODEOWNERS de GitHub pour nous assurer qu’il ne puisse être modifié sans une approbation stricte.

Et après ?

Avec tout cela en place, nous pouvons maintenant penser à l’évolution de cette pipeline.

Par exemple, notre entreprise dispose d’une instance SonarQube. Nous serions intéressés d’ajouter une étape qui pourrait analyser chaque projet à la recherche de mauvaises pratiques.

Nous explorons aussi l’utilisation de mkdocs, pour que les projets puissent partager un style commun pour la documentation.

Et une de mes évolutions préférées, nous pourrions explorer l’utilisation de uv pour installer les dépendances, car il est beaucoup plus rapide que ce bon vieux pip !

Vous avez également peut-être remarqué que, bien que j’aie parlé de CI/CD tout au long de cet article, à aucun moment nous avons parlé d’une étape qui, eh bien, déploie quelque chose (ce qui nous laisse avec une pipeline CI). Nous réfléchissons déjà à un moyen de build/deploy des packages Python vers notre gestionnaire de dépôt Artifactory, ce qui en ferait enfin une vraie pipeline CI/CD !

Enfin, nous n’avons abordé que Python dans cet article, mais la même logique pourrait s’appliquer à d’autres types de projets. Par exemple, nous travaillons également sur une pipeline CI/CD pour Terraform.

Conclusion

En abordant les problèmes de permissions, les lacunes en matière de connaissances Jenkins et l’absence de guidelignes, nous avons construit une stratégie CI/CD unifiée qui prend désormais en charge plus de 100 projets Python. Cela prouve qu’avec la bonne approche, l’automatisation est réalisable pour toute organisation.

Cela a été un long mais enrichissant parcours !

J’espère que cet article a montré la valeur des pipelines CI/CD, vous a aidé à comprendre ce qui pourrait empêcher son application et vous a donné quelques idées sur la manière de mettre en place une stratégie similaire dans votre organisation !