GitLab CI/CD

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 1 sur 14. De nombreuses équipes d'ingénierie s'appuient sur des processus de release brouillons et non documentés, que seule une personne comprend vraiment. Le vrai chemin vers la production reste invisible jusqu'à ce que quelque chose casse. Le paradigme point gitlab tiret c i point yml change ça en traduisant tout ton cycle de vie de build et de release en un graphe transparent et séquentiel. GitLab CI/CD est le système d'intégration continue et de déploiement continu intégré à GitLab. Il est entièrement contrôlé par un seul fichier de configuration appelé point gitlab tiret c i point yml. Tu places ce fichier à la racine du repository de ton projet. Comme il est committé avec le code de ton application, ton processus de déploiement est versionné, auditable et accessible à n'importe quel développeur qui regarde le repository. Quand tu push un commit qui contient ce fichier, GitLab le détecte immédiatement et déclenche un pipeline. Un pipeline, c'est l'architecture de plus haut niveau de ton processus CI/CD. Il est composé de deux éléments principaux : les jobs et les stages. Les jobs dictent ce qui se passe réellement. Un job contient les commandes shell ou les scripts spécifiques nécessaires pour exécuter une tâche, comme compiler du code source, formater du texte ou déplacer des fichiers vers un serveur. Les stages dictent quand ces jobs s'exécutent. Tu organises les jobs en stages pour contrôler le flux d'exécution chronologique. Prends l'exemple d'un pipeline standard avec trois stages. En haut de ton fichier de configuration YAML, tu déclares tes stages dans l'ordre exact où tu veux qu'ils s'exécutent : build, test et deploy. En dessous de cette liste, tu définis tes jobs individuels et tu les associes à ces stages définis. Tu commences par écrire un job appelé build tiret job et tu l'assignes au stage build. Son script dit au système de compiler ton application. Ensuite, tu écris un job appelé test tiret job, tu l'assignes au stage test, et tu fournis la commande pour lancer ta suite de tests. Enfin, tu écris un job deploy tiret prod, tu le lies au stage deploy, et tu lui donnes les instructions pour push l'application compilée vers ton environnement de production. Voici le point essentiel. GitLab traite ces stages strictement en séquence. Le pipeline commence par le stage build. Le système exécute ton job de build. Si ce job se termine avec succès, le pipeline avance automatiquement au stage test et exécute le job de test. Si les tests passent, il passe au stage deploy. Cet ordre strict agit comme une quality gate définitive. Si un job échoue à n'importe quel moment, par exemple, si un test unitaire échoue pendant le stage test, le pipeline entier s'arrête. Le stage deploy ne s'exécutera jamais, ce qui veut dire que du code cassé ne peut pas atteindre la production. Comme cette logique est déclarée clairement dans le fichier YAML, l'interface utilisateur de GitLab la traduit en un graphe de pipeline visuel. N'importe qui dans ton équipe peut voir un commit, regarder le graphe, et comprendre instantanément où se trouve exactement le code dans le pipeline, quel stage a réussi, et précisément où une erreur s'est produite. La force principale de ce paradigme, c'est la centralisation. En définissant les stages et les jobs dans un seul fichier à la racine, ta séquence de déploiement arrête d'être un mystère et devient un processus lisible et répétable qui vit exactement au même endroit que ton code. Si tu veux aider à soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 2 sur 14. Tu passes des heures à écrire un fichier de configuration de pipeline parfait, tu fais un commit, et tu attends. Mais rien ne se passe. Ton pipeline est complètement inutile sans un moteur de calcul prêt à récupérer ces instructions. C'est là qu'interviennent les Runners et les Executors de GitLab. On croit souvent à tort que l'application GitLab exécute elle-même tes scripts de build. Ce n'est pas le cas. GitLab gère le repository et suit le statut de tes pipelines, mais il délègue strictement l'exécution en elle-même. Un GitLab Runner est une application séparée qui fonctionne comme un agent. Il interroge en permanence l'instance GitLab pour savoir s'il y a des jobs en attente qu'il est autorisé à traiter. Quand il en trouve un, il pull le payload du job, exécute les commandes, et renvoie les logs et les résultats à GitLab. Tu as deux options principales pour obtenir ces agents. La voie la plus simple est d'utiliser les runners hébergés par GitLab. Ils sont gérés pour toi sur GitLab SaaS et couvrent les environnements classiques comme Linux, macOS et Windows. Mais souvent, tu as besoin d'un setup custom. Peut-être que ton build nécessite du hardware spécialisé, comme un GPU spécifique, ou a besoin d'accéder à un réseau interne privé. Dans ce cas, tu utilises des runners self-managed. Tu installes l'application runner sur ta propre infrastructure. Tu peux scoper ces runners self-managed de façon globale sur toute une instance GitLab, les partager entre un groupe de projets liés, ou les verrouiller sur un seul projet spécifique. Une fois qu'un runner récupère un job, il doit savoir exactement comment et où exécuter les commandes. C'est défini par l'executor. L'executor dicte l'environnement d'exécution spécifique pour le job. Deux des types les plus courants sont le shell executor et le Docker executor. Le shell executor est très simple. Il exécute le job directement sur le système d'exploitation de la machine host en utilisant un shell de terminal standard, comme Bash ou PowerShell. À cause de ça, toutes les dépendances doivent être préinstallées sur cette machine host. Le Docker executor fonctionne différemment. Il lance un container isolé et tout neuf pour chaque job, exécute les scripts à l'intérieur, et le détruit juste après. Ça garantit un environnement complètement clean à chaque fois. Prenons un scénario concret en enregistrant un runner de projet self-managed en local, en utilisant un shell executor. D'abord, tu vas dans les paramètres de ton projet spécifique dans GitLab et tu crées un nouveau runner. GitLab va générer un token d'authentification unique. Ensuite, tu installes l'application GitLab Runner sur ta machine locale. Depuis ton terminal local, tu lances la commande register. Le prompt te demandera deux informations principales. Il a besoin de l'URL de ton instance GitLab et du token d'authentification que tu viens de générer. Cette étape lie de manière sécurisée ta machine locale à ce projet spécifique. Enfin, le setup te demandera de choisir un executor. Tu tapes shell. À partir de ce moment-là, à chaque fois qu'un job se déclenche dans ce projet GitLab, ta machine locale va le pull et exécuter les commandes directement dans son environnement de terminal local. Voici l'idée clé. GitLab est l'orchestrateur, mais le Runner et son Executor constituent le véritable atelier de production. En découplant la gestion des jobs de l'exécution des jobs, tu gagnes la flexibilité de faire tourner des pipelines sur n'importe quoi, d'un container cloud partagé à un serveur bare-metal dans un sous-sol verrouillé. Merci de m'avoir écouté, et happy coding à tous !

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 3 sur 14. Tu as un pipeline avec vingt jobs, et chacun d'eux commence par lancer exactement la même commande de setup. Quand ce processus de setup change, tu as maintenant vingt endroits différents à mettre à jour, et en oublier un seul va casser ton build. Résoudre cette répétition commence par comprendre l'anatomie d'un job CI/CD. Un job est l'unité d'exécution fondamentale dans GitLab CI/CD. Il est défini par un nom et doit contenir au moins une commande à exécuter. Ce bloc d'exécution principal est défini avec le mot-clé script. Le script représente un tableau de commandes exécutées en séquence par le runner. Si une commande échoue, le job s'arrête immédiatement et est marqué comme failed. Les jobs tournent rarement dans le vide. Ils ont souvent besoin que l'environnement soit préparé avant de tourner, et parfois d'un nettoyage après. C'est là qu'interviennent les mots-clés before script et after script. Prends l'exemple d'un projet Ruby. Avant de lancer tes tests ou d'exécuter un linter, tu dois installer tes dépendances. Tu places ta commande bundle install dans le bloc before script. Le runner exécute ce before script en premier. S'il réussit, le script principal se lance. Une fois le script principal terminé, le after script s'exécute. Voici le point clé. Le after script tourne même si le script principal échoue. C'est donc le bon endroit pour fermer les connexions réseau, supprimer les credentials temporaires, ou nettoyer les bases de données de test. Écrire cette même commande bundle install dans chaque job de test devient vite répétitif. Pour régler ça, tu utilises le mot-clé default à la racine de ton fichier de configuration. Toute configuration définie sous default est automatiquement héritée par tous les jobs du pipeline. Tu déclares ton before script bundle install une seule fois dans le bloc default. Maintenant, chaque job le lance automatiquement. Si un job spécifique n'en a pas besoin, tu définis un before script vide dans ce job spécifique. Cette définition locale écrase le default global. Parfois, tu as besoin d'une définition de job dans ton fichier, mais tu ne veux pas qu'il tourne vraiment. Tu es peut-être en train d'écrire un template de base dont d'autres jobs vont hériter, ou tu veux peut-être désactiver temporairement un test flaky sans supprimer complètement le code. Tu fais ça en masquant le job. Ajoute simplement un point tout au début du nom du job. Quand GitLab parse la configuration du pipeline, il ignore complètement tout nom de job qui commence par un point. Le job n'apparaîtra pas dans l'interface utilisateur, et il ne s'exécutera pas. À mesure que ton pipeline grandit, l'interface web peut vite être encombrée par des dizaines de jobs individuels. Si tu as plusieurs jobs très liés, tu peux les regrouper visuellement dans le graphe du pipeline. Tu fais ça en nommant les jobs avec un préfixe commun, suivi d'un slash ou de deux points. Par exemple, si tu nommes trois jobs distincts build slash ruby one, build slash ruby two, et build slash ruby three, l'interface va les regrouper dans un seul groupe déroulant simplement appelé build. Cliquer sur le groupe le déploie pour afficher les jobs individuels à l'intérieur. Ça ne change rien à la façon dont les jobs s'exécutent sur les runners, mais ça rend un pipeline massif beaucoup plus facile à lire d'un coup d'œil. Un pipeline bien structuré sépare le setup de l'exécution, utilise des defaults pour éliminer le code dupliqué, et s'appuie sur des conventions de nommage pour garder l'interface visuelle strictement concentrée sur l'essentiel. C'est tout pour cet épisode. Merci de ton écoute, et continue à builder !

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 4 sur 14. Hardcoder une clé API directement dans la configuration de ton pipeline est le moyen le plus rapide de compromettre tout ton environnement de production. Tu as besoin d'un moyen de passer dynamiquement la configuration et les credentials à tes jobs, sans les exposer à tous ceux qui peuvent lire ton repository. Les variables CI/CD et les secrets sont les mécanismes qui gèrent ça. Chaque fois qu'un runner GitLab récupère un job, il ne démarre pas de zéro. GitLab injecte automatiquement des variables prédéfinies dans l'environnement. Elles donnent un contexte immédiat à ton script. Tu as accès à des variables comme CI commit branch, le pipeline ID, et le nom du projet. Tu ne les définis pas. Elles sont juste là, prêtes à être utilisées dans tes scripts pour router la logique ou tagger les build artifacts. Au-delà du contexte prédéfini, tu devras fournir tes propres variables custom. Tu peux les définir à deux endroits : dans ton fichier de configuration yaml, ou dans l'UI de GitLab. La règle pour choisir où les mettre est simple. Si la valeur peut être lue sans risque, comme un flag de compilation ou l'URL d'un serveur de dev, mets-la dans le fichier yaml. La configuration reste avec le code. Si la valeur est sensible, comme un mot de passe de base de données, définis-la dans l'UI du projet GitLab. Quand tu places un secret dans l'UI, tu dois configurer ses limites de sécurité. On confond souvent le fait de masquer une variable et de protéger une variable. Ce sont des concepts complètement différents. Masquer une variable empêche sa valeur d'apparaître dans les logs du job. Si tu masques un mot de passe de base de données, et qu'un script mal écrit essaie de l'afficher dans la console, GitLab intercepte l'output stream. Il remplace le texte du mot de passe par une string d'astérisques avant même que le log ne soit sauvegardé. Le masquage contrôle la visibilité dans les logs. Voici le point essentiel. Masquer ne fait rien pour empêcher un développeur d'écrire un script qui envoie le mot de passe à un serveur externe. C'est là que la protection entre en jeu. Protéger une variable limite sa disponibilité. Une variable protégée est uniquement injectée dans les pipelines qui tournent sur des branches protégées ou des tags protégés. Si quelqu'un ouvre une merge request depuis une feature branch standard, le pipeline qu'il déclenche ne contiendra tout simplement pas cette variable. Ça empêche le code non fiable d'accéder aux secrets de production. En plus, tu peux utiliser des paramètres masqués dans l'UI pour une sensibilité extrême. Une fois qu'une variable est sauvegardée, sa valeur est masquée dans l'interface. Même les mainteneurs du projet ne peuvent pas facilement récupérer le texte brut plus tard, ce qui veut dire que quelqu'un qui a accès ne peut pas juste scraper la page des paramètres pour voler tous tes tokens. Maintenant, regarde comment la variable arrive jusqu'à ton application. La plupart des variables sont injectées comme des variables d'environnement standard. Mais certains outils refusent de lire les variables d'environnement et exigent de lire depuis un fichier physique. La CLI AWS, par exemple, attend souvent un fichier de credentials formaté qui se trouve sur le disque. Au lieu d'écrire un script de pipeline qui crée un fichier, y dumpe le texte de la variable, puis essaie de le supprimer de manière sécurisée plus tard, tu peux utiliser une variable de type File. Quand tu configures une variable avec le type File dans l'UI, le runner gère la logistique automatiquement. Quand le job démarre, le runner prend la valeur texte, l'écrit de manière sécurisée dans un fichier temporaire sur le disque du runner, et configure la variable d'environnement pour qu'elle contienne le chemin du fichier, et non son contenu. Tu as juste à pointer ton outil AWS vers le chemin fourni par la variable. Quand le job se termine, le runner détruit le fichier automatiquement. Sécuriser ton pipeline, c'est minimiser l'exposition à chaque étape. Ne te repose pas sur le masquage des logs pour te protéger contre le code malveillant, et n'écris pas toi-même des fichiers de credentials temporaires quand le runner peut gérer le cycle de vie en toute sécurité. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de builder !

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 5 sur 14. Ton job de build se termine parfaitement, mais ton job de deploy échoue mystérieusement avec une erreur file not found. Tu vérifies le runner, et les fichiers ont bien été générés il y a quelques minutes. Le problème se résume généralement à une incompréhension fondamentale entre deux mots-clés : artifacts et cache. Ces deux concepts sont souvent confondus parce qu'ils impliquent tous les deux de sauvegarder des fichiers sur un runner, mais ils existent pour des raisons totalement différentes. Le mot-clé cache définit une liste de fichiers et de dossiers prévus pour accélérer ton pipeline. Il stocke les dépendances téléchargées entre les différents runs de ton pipeline. Prends l'exemple d'un projet Node standard. Ton job de build a besoin de milliers de packages dans le dossier node modules. Au lieu de les télécharger depuis le registry public à chaque fois qu'un développeur push du code, tu configures un cache. Tu lui donnes une clé basée sur ton package lock file et tu le fais pointer vers le dossier node modules. Lors des runs suivants, GitLab restaure ces fichiers localement. Voici le point essentiel. Le caching est strictement une optimisation. Si le cache est purgé, expire ou n'arrive pas à s'extraire, ton job doit quand même pouvoir tourner et réussir en téléchargeant les packages depuis zéro. Un cache manquant signifie juste un pipeline plus lent, pas un pipeline cassé. La logique de ton job ne devrait jamais dépendre de la présence d'un cache. Les artifacts servent un but architectural complètement différent. Le mot-clé artifacts spécifie les fichiers et dossiers générés par un job qui doivent être passés aux jobs suivants au sein du même run de pipeline. Ce n'est pas une optimisation. C'est un prérequis structurel pour ton flow CI. Pour en revenir au projet Node, ton job de build compile ton code source dans un dossier de sortie final appelé dist. Ton job de deploy tourne dans un stage ultérieur et a besoin de ce dossier dist exact pour faire un push vers ton serveur de production. Parce que les jobs tournent dans des environnements isolés, le job de deploy ne peut pas simplement aller piocher dans le workspace du job de build. Tu combles ce vide en utilisant les artifacts. Tu définis le dossier dist sous le mot-clé artifacts dans ton job de build. En cas de succès du job, GitLab prend ces fichiers, les package et les attache au pipeline. Quand le job de deploy en aval démarre, GitLab télécharge automatiquement ce package d'artifacts et l'extrait dans le working directory. Si un artifact est manquant, le job en aval va échouer parce que les fichiers requis n'existent littéralement pas dans le workspace. Contrairement à un cache, tu ne peux pas simplement télécharger un artifact depuis internet s'il est manquant. Il contient l'état intermédiaire unique de ton run de pipeline actuel. Dans un fichier YAML correctement configuré, tu utilises souvent les deux dans le même job de build. Tu configures le cache pour cibler ton dossier de dépendances afin de gagner du temps. Tu configures les artifacts pour cibler ton dossier de sortie compilé afin de faire passer les données à la suite. Le job de deploy plus loin dans le pipeline n'a pas du tout besoin du cache. Il a seulement besoin du code buildé, qu'il reçoit de façon transparente parce que les artifacts sont téléchargés par défaut dans tous les stages suivants. Quand tu configureras ton prochain pipeline, rappelle-toi de cette règle. Utilise le cache pour les dépendances externes que tu pull pour gagner du temps, et utilise les artifacts pour les résultats de build internes que tu dois faire passer à la suite pour terminer le deploy. C'est tout pour aujourd'hui. Merci d'avoir écouté — va build un truc cool.

Salut, ici Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 6 sur 14. Tu viens de faire un commit pour corriger une typo dans un fichier markdown, et soudain ton pipeline lance une suite de tests end-to-end de vingt minutes. C'est un énorme gaspillage de minutes de compute et de ta patience. Pour arrêter de lancer des jobs lourds quand ils ne sont pas nécessaires, tu contrôles l'exécution avec le mot-clé rules. Le mot-clé rules détermine exactement quand un job est ajouté à un pipeline. Si tu utilises GitLab depuis un moment, tu te souviens peut-être avoir utilisé only et except pour filtrer les jobs. Ce sont des mots-clés legacy. Rules est le remplaçant moderne et plus puissant. Sous le capot, rules prend une liste de conditions. GitLab évalue cette liste de haut en bas. Dès qu'il trouve un match, il arrête de chercher et ajoute le job ou le skip, selon comment tu as configuré cette règle spécifique. Il y a trois conditions principales que tu peux évaluer. La première, c'est if. La condition if évalue les variables de pipeline avec une simple expression logique. Tu peux dire à un job de deploy de tourner uniquement si la branche du commit correspond à la branche par défaut. Si l'évaluation de la variable retourne true, la règle matche. Ensuite, la deuxième condition vérifie les modifications de fichiers avec le mot-clé changes. Ça évalue si le push actuel a modifié des fichiers qui correspondent à un chemin spécifique ou à un wildcard. C'est là que tu fais de vraies économies. Prends l'exemple d'un gros job de linter JavaScript. Tu ne veux pas que ce linter bouffe des cycles CPU si un développeur backend a juste touché aux fichiers de configuration de la base de données. Tu ajoutes une règle avec changes, et tu spécifies le wildcard pour les fichiers point js. Si le commit inclut des changements sur un fichier javascript, la règle matche et le linter tourne. Si aucun fichier javascript n'a été touché, le job est complètement exclu du pipeline. La troisième condition, c'est exists. Au lieu de vérifier des variables ou des modifications récentes, exists vérifie simplement si un fichier spécifique est présent dans le repository à ce moment-là. Tu as peut-être un template de pipeline générique utilisé par plusieurs projets. Tu peux définir un job de build de conteneur avec une règle exists qui pointe vers un Dockerfile. Si le projet a un Dockerfile dans son répertoire racine, le job tourne. Sinon, le job est complètement skippé. Voici le point essentiel. Trouver un match ne veut pas automatiquement dire que le job tourne. Quand une règle est évaluée à true, elle applique une instruction secondaire avec l'attribut when. Par défaut, une règle qui matche part du principe que le job doit être ajouté au pipeline. Mais tu peux définir explicitement une règle avec when défini sur never. C'est super efficace pour faire du blocklisting. Tu peux mettre une règle tout en haut de ta liste qui dit que si le message de commit contient le mot draft, on met when sur never. Comme les rules sont évaluées de haut en bas, ce job est instantanément killé avant même que d'autres conditions soient vérifiées. Si tu ne dois retenir qu'une chose sur le contrôle de l'exécution, c'est que l'ordre dicte le résultat. Place tes règles d'exclusion tout en haut de ta liste, parce qu'au moment où GitLab trouve une condition true, il arrête de lire et verrouille la décision. Je voudrais prendre un moment pour te remercier de ton écoute, ça nous aide beaucoup. Passe une bonne journée !

Salut, ici Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 7 sur 14. Ton pipeline n'est pas vraiment lent. Il est juste artificiellement bridé. Tu as probablement des jobs rapides qui attendent des jobs lents qui n'ont absolument rien à voir avec eux, simplement parce qu'ils sont dans la même colonne sur ton écran. Pour corriger ça, tu laisses tomber les colonnes rigides et tu construis des Directed Acyclic Graphs avec needs. Par défaut, les pipelines standards s'exécutent séquentiellement par stage. Tu définis des stages comme build, test et deploy. Chaque job du stage test doit être complètement terminé avant qu'un job du stage deploy puisse démarrer. Si ton stage test a cinq jobs, et que quatre d'entre eux se terminent en deux minutes alors qu'un seul prend dix minutes, tout le stage deploy est bloqué jusqu'à la dixième minute. La barrière d'exécution entre les stages est absolue. Le mot-clé needs brise cette barrière. Il te permet de définir des relations explicites entre les jobs, faisant passer ton pipeline d'une séquence stricte à un Directed Acyclic Graph. Quand tu utilises le mot-clé needs dans la définition d'un job, tu dis exactement au système quels jobs précédents doivent se terminer avant que celui-ci ne démarre. Au moment où ces dépendances spécifiques réussissent, ton job se déclenche. Il arrête d'attendre que le reste du stage se termine. Imagine un monorepo contenant à la fois un frontend et un backend. Tes jobs de build et de test backend sont rapides, ils prennent environ deux minutes. Ton build frontend est lourd, il prend dix minutes. Dans un pipeline traditionnel, le stage deploy ne peut pas se déclencher tant que les tests frontend et backend ne sont pas terminés. Ton deploy backend est littéralement pris en otage par le build frontend. Voici l'idée clé. Tu peux ajouter le mot-clé needs à ton job de deploy backend et lister uniquement le job de test backend comme dépendance. Maintenant, la logique d'exécution change. Le job de test backend se termine à la minute deux. Le job de deploy backend voit que sa dépendance explicite est remplie et démarre immédiatement. Il ignore complètement le fait que le build frontend tourne encore pendant huit minutes. Les stages existent toujours pour l'organisation visuelle dans l'interface utilisateur, mais l'ordre d'exécution réel est maintenant dicté par le graphe que tu as construit. Pour configurer ça, tu ajoutes le mot-clé needs à un job et tu fournis un array avec les noms exacts des jobs. Il y a un avantage secondaire ici concernant le transfert de données. Normalement, un job télécharge les artifacts de tous les jobs réussis des stages précédents. Quand tu utilises needs, le téléchargement des artifacts devient ciblé. Ton job téléchargera uniquement les artifacts des jobs spécifiques listés dans l'array needs. Ça évite à ton job de deploy backend de télécharger des assets frontend massifs et inutiles, ce qui fait gagner encore plus de temps pendant l'initialisation du job. Si tu as besoin qu'un job démarre immédiatement à la création du pipeline, en contournant tous les délais de stage, tu peux passer un array vide au mot-clé needs. Ça indique au système que le job a zéro dépendance, le poussant à s'exécuter à la seconde zéro. La vraie valeur d'un Directed Acyclic Graph, c'est de découpler des workflows indépendants au sein d'un seul pipeline. Tu arrêtes d'organiser les jobs selon le moment où ils doivent tourner, et tu commences à les organiser purement selon les inputs dont ils ont besoin pour s'exécuter. Merci de m'avoir écouté. Prenez soin de vous tous.

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 8 sur 14. Tu maintiens un projet open-source. Un inconnu le fork, y cache un script qui exporte des variables d'environnement dans un unit test, et ouvre une contribution. Si ton système run automatiquement ce code sur tes serveurs privés, tes secrets sont compromis. Pour éviter ça, tu as besoin d'une frontière stricte entre le simple fait de push du code et son exécution dans un environnement privilégié. Cette frontière est gérée par les Merge Request Pipelines. Normalement, GitLab trigger un pipeline à chaque fois que tu push un commit sur n'importe quelle branch. Un Merge Request Pipeline se comporte différemment. C'est un type spécifique de pipeline configuré pour run sur le contenu de la source branch, mais uniquement dans le contexte d'une Merge Request ouverte. Ce contexte te donne accès à des variables d'environnement spécifiques liées au merge lui-même, comme le nom de la target branch ou l'identifiant de la Merge Request. Tu indiques à un job de run en tant que Merge Request Pipeline en utilisant la section rules dans ton fichier de configuration. Tu écris une rule qui évalue la variable pipeline source. Tu vérifies si la CI pipeline source est égale au texte exact merge request event, écrit avec des underscores entre les mots. Quand tu appliques cette rule, le job va run uniquement quand une Merge Request est créée ou mise à jour. C'est très courant de combiner ça avec des rules qui empêchent le job de run sur des push de branch standards. Si tu ne les sépares pas, push un commit sur une Merge Request ouverte va trigger deux pipelines exactement en même temps, qui feront exactement le même travail. Ça nous amène aux implications de sécurité des contributions externes. Quand quelqu'un fork ton repository, il crée une copie complètement isolée. S'il ouvre une Merge Request depuis son fork vers ton projet parent, tout pipeline qui run automatiquement s'exécute dans son fork. Il utilise ses runners et ses variables. C'est fait exprès. Les secrets de ton projet parent sont en sécurité parce que le code du contributeur n'a pas accès à ton infrastructure. Mais au final, tu dois vérifier que son code passe ta test suite officielle en utilisant tes propres credentials de base de données et tes targets de déploiement. GitLab te permet de run des pipelines pour ces Merge Requests de fork au sein du projet parent, mais ça demande une action humaine délibérée. Un développeur ou un maintainer du projet parent doit trigger manuellement l'exécution. Dans un bon workflow, le maintainer lit d'abord le code soumis depuis le fork. Il doit chercher tout ce qui pourrait être malveillant, destructeur ou mal codé. C'est seulement quand le maintainer est absolument certain que le code est sûr qu'il clique sur le bouton pour trigger le pipeline. Une fois trigger, ce code externe s'exécute sur les runners du projet parent et a accès aux secrets du projet parent. Le trigger manuel agit comme une barrière de sécurité physique. C'est ça qui est important. Les Merge Request Pipelines ne sont pas juste un moyen de grouper des jobs dans l'interface utilisateur, ce sont un mécanisme de contrôle fondamental qui te permet d'évaluer du code externe sans exposer aveuglément ton infrastructure interne. Si tu veux nous aider à faire tourner la boutique, tu peux soutenir l'émission en cherchant DevStoriesEU sur Patreon. C'est tout pour aujourd'hui. Merci d'avoir écouté, et continue de coder !

Salut, ici Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 9 sur 14. Tu as un seul fichier YAML avec cinq cents jobs. Modifier une seule ligne, c'est comme désamorcer une bombe, et l'exécution prend une heure car tout s'exécute d'un seul bloc. Les downstream pipelines résolvent ce problème en divisant ce monolithe en workflows modulaires et indépendants. Un downstream pipeline est tout simplement un pipeline GitLab CI/CD déclenché par un autre pipeline. Le pipeline qui le déclenche est appelé l'upstream pipeline. Au lieu d'exécuter tous les jobs séquentiellement, l'upstream pipeline agit comme un coordinateur, en déléguant le travail à des pipelines plus petits et spécialisés. GitLab divise les downstream pipelines en deux types spécifiques selon l'endroit où ils s'exécutent. Le premier type est le parent-child pipeline. Ça se passe entièrement au sein du même projet. Si tu as un monorepo, une configuration parent-child est exactement ce qu'il te faut. Le pipeline parent détecte ce qui a changé et déclenche uniquement la configuration child correspondante. Le deuxième type est le multi-project pipeline. Ça se produit quand un pipeline dans un repository déclenche un pipeline dans un projet GitLab complètement différent. Tu utilises ça pour les architectures réparties sur plusieurs repositories, comme déclencher un projet de tests d'intégration uniquement après le succès du pipeline d'un projet API autonome. Tu configures les deux types en utilisant un mot-clé de job spécifique appelé trigger. Un trigger job est fondamentalement différent d'un job standard. Il ne contient jamais de section script. Il n'exécute pas de commandes sur un runner. Son seul but est de démarrer le downstream pipeline. Pour un multi-project pipeline, tu passes au mot-clé trigger le chemin vers le projet cible. Pour un parent-child pipeline, tu utilises le mot-clé trigger combiné au mot-clé include, en pointant vers un fichier YAML différent situé dans le même repository. Imagine un pipeline parent de routage qui gère trois microservices distincts stockés dans un monorepo. Le pipeline parent évalue le commit et déclenche trois child pipelines en parallèle. L'un gère le service utilisateur, l'autre le service de paiement et le dernier le service d'inventaire. Chaque child pipeline possède ses propres stages, jobs et rules. Ils s'exécutent indépendamment. Par défaut, un trigger job se lance en mode fire and forget. L'upstream job démarre le downstream pipeline et réussit immédiatement. Si tu as besoin que l'upstream pipeline attende et reflète le statut du downstream pipeline, tu ajoutes le paramètre strategy depend au trigger job. Ça force le pipeline parent à attendre, ce qui veut dire qu'une erreur dans le child pipeline va remonter et marquer le parent job comme failed. Voici le point clé. Les ingénieurs configurent souvent des parent-child pipelines et supposent immédiatement qu'ils sont cassés parce que les child pipelines n'apparaissent pas sur la page d'index principale des pipelines. C'est un choix de design intentionnel. L'index principal ne montre que les pipelines parents pour éviter de surcharger l'affichage. Pour voir les child pipelines, tu dois cliquer sur la vue détaillée du pipeline parent. Ils sont imbriqués sous le job spécifique qui les a déclenchés. Les multi-project pipelines, en revanche, apparaissent bien dans l'index des pipelines de leurs projets cibles respectifs, car ce sont des top-level pipelines dans ces repositories. Passer aux downstream pipelines t'oblige à traiter ta configuration CI/CD comme une véritable architecture logicielle, en remplaçant un script fragile par des composants distincts qui ont des domaines de défaillance isolés. C'est tout pour cette fois. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 10 sur 14. Si ton équipe a besoin de demander sur Slack pour savoir qui vient de faire un push sur le serveur de staging, tu as un manque de visibilité dans ton workflow. Tu as besoin d'un moyen définitif et automatisé pour tracker exactement quel code tourne à quel endroit à la seconde près, et c'est exactement le problème que résolvent les environnements et les déploiements de GitLab. Dans GitLab, un environnement est une entité logique de tracking. GitLab ne provisionne pas automatiquement tes serveurs et ne monte pas ton infrastructure cloud juste parce que tu as créé un environnement. L'environnement est simplement un label. Il indique à GitLab qu'un job spécifique de ton pipeline est responsable de push le code vers une destination précise, comme le staging ou la production. Tu configures ça en ajoutant le mot-clé environment directement dans ton job de déploiement. Tu fournis un nom statique pour la destination. Par exemple, tu pourrais créer un job appelé deploy to staging, et à l'intérieur de ce job, tu définis le nom de l'environnement sur staging. La section script de ton job s'occupe toujours du vrai travail. Elle lance les commandes qui copient les fichiers, appliquent les configurations ou redémarrent les services distants. Prends le scénario où tu déploies une nouvelle release candidate. Tu merges ton code et le pipeline démarre. Il build l'application, lance ta suite de tests, et arrive au job de déploiement en staging. Parce que tu as attaché le mot-clé environment à ce job, GitLab change la façon dont il traite l'exécution. Il surveille de près l'output du job. Quand ton script de déploiement se termine et que le job réussit, GitLab enregistre un événement de déploiement formel pour l'environnement de staging. Et voici le point clé. Utiliser ce simple mot-clé active toute une suite de fonctionnalités de tracking de déploiement dans l'interface de GitLab. Si tu vas dans le menu Operate sur la barre latérale et que tu sélectionnes Environments, tu te retrouves face à un dashboard qui montre le statut en temps réel de tes cibles de déploiement. Pour ton environnement de staging, tu n'as plus besoin de deviner ce qui tourne. Le dashboard affiche le hash exact du commit actuellement actif, la branche d'où vient ce commit, l'auteur du code, et depuis combien de temps le déploiement est terminé. Ça crée un historique immuable et partagé de l'état du serveur. Tout le monde sur le projet a exactement la même visibilité sans avoir besoin de vérifier les logs du serveur ou de demander aux collègues. Cliquer sur l'environnement de staging révèle l'historique complet des déploiements. C'est cet historique qui permet de faire des rollbacks manuels directement depuis l'interface utilisateur. Si une nouvelle release candidate casse complètement le serveur de staging, le réparer ne nécessite pas d'écrire un revert commit ou de reconstruire manuellement un ancien pipeline. Tu ouvres la liste de l'historique, tu identifies le dernier déploiement réussi connu, et tu cliques sur le bouton rollback juste à côté. GitLab relance immédiatement le job de déploiement à partir de cet ancien commit stable. Il remplace le code cassé et restaure ton environnement de staging dans un état fonctionnel rapidement. En utilisant le mot-clé environment, tu fais le pont entre l'exécution des scripts et le tracking des vrais déploiements. Ça transforme un job de pipeline isolé en un historique clair et visible de la version logicielle qui tourne actuellement sur ton infrastructure. J'aimerais prendre un instant pour te remercier de ton écoute, ça nous aide beaucoup. Passe une super journée !

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 11 sur 14. Donner à ton product manager une URL live et cliquable pour chaque feature branch élimine complètement l'excuse du ça marche sur ma machine. Ce workflow repose entièrement sur les environnements dynamiques et les Review Apps. Les environnements standards, comme le staging ou la production, sont statiques. Tu les définis une fois et ils persistent. Les environnements dynamiques sont créés à la volée. Tu les lances pour tester une branche spécifique, tu les utilises, puis tu les jettes. Quand tu utilises un environnement dynamique spécifiquement pour prévisualiser des changements de code dans une merge request, GitLab appelle ça une Review App. Pour créer un environnement dynamique, tu ne peux pas hardcoder son nom dans ton fichier de configuration. À la place, tu utilises des variables de pipeline. La variable la plus critique pour ça, c'est le CI commit ref slug. Cette variable prend le nom de ta branche, le convertit en minuscules, supprime les caractères spéciaux et le raccourcit. Ça te garantit d'avoir une string DNS-safe à utiliser pour nommer à la fois ton environnement dans GitLab et tes ressources d'infrastructure réelles. En définissant le nom de ton environnement avec le mot review suivi d'un slash et de cette variable slug, GitLab génère automatiquement un environnement séparé et tracké pour chaque branche que tu push. Voici le point clé. Créer l'enregistrement de l'environnement dans GitLab n'est que la moitié du travail. Tu dois aussi rediriger les reviewers vers le code réellement déployé. Disons que tu lances une instance AWS Lambda temporaire pour ta feature branch. Quand ton script de déploiement tourne, AWS génère une URL aléatoire pour cette nouvelle fonction Lambda. Tu ne connais pas cette URL à l'avance. Tu as besoin d'un moyen de renvoyer cette adresse générée dynamiquement vers l'interface utilisateur de GitLab pour que les reviewers puissent cliquer dessus. Tu résous ça en utilisant un type d'artifact spécifique appelé un dotenv report. Dans ton job de déploiement, après qu'AWS a provisionné la fonction Lambda et renvoyé l'endpoint, ton script écrit cette URL dans un simple fichier texte formaté en paire key-value. Tu configures ton job pour output ce fichier comme un artifact dotenv report. GitLab lit ce fichier à la fin du job et expose la variable. Tu configures ensuite le paramètre environment URL dans la définition de ton pipeline pour lire cette variable exacte. Grâce à cette connexion, ta merge request affichera maintenant un bouton View App qui redirige les utilisateurs directement vers cet endpoint AWS Lambda spécifique. L'infrastructure temporaire coûte de l'argent. Laisser tourner des centaines de fonctions Lambda stale va vider ton budget rapidement. Tu as besoin d'un moyen automatisé pour faire le clean up. Tu gères ça en utilisant le mot-clé on stop. Dans ton job de déploiement, tu ajoutes la propriété on stop et tu lui donnes le nom exact d'un autre job dans ton pipeline. Ce deuxième job contient ton script de teardown d'infrastructure. En les liant de cette façon, GitLab prend le relais sur la gestion du cycle de vie. Quand un développeur merge la feature branch, ou supprime la branche, GitLab exécute automatiquement ce job de teardown. L'infrastructure est détruite immédiatement. La vraie valeur des Review Apps n'est pas juste de prévisualiser le code, mais d'automatiser tout le cycle de vie de l'infrastructure. Tu provisionnes dynamiquement, tu lies de façon transparente et tu détruis de manière fiable des environnements temporaires sans qu'un seul développeur n'ait jamais à toucher une console d'hébergement. C'est tout pour cet épisode. Merci d'avoir écouté, et continue à développer !

Salut, ici Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 12 sur 14. Copier-coller le même script de déploiement dans cinquante repositories différents garantit une seule chose : quand ce script devra inévitablement changer, tu oublieras de mettre à jour au moins un repository. La solution, c'est d'écrire des configurations DRY en utilisant le mot-clé include. Dans GitLab CI, le mot-clé include te permet de diviser la configuration de ton pipeline en plusieurs fichiers plus petits et réutilisables. Au lieu de maintenir un seul énorme fichier YAML, tu construis un système modulaire. Quand un pipeline se déclenche, GitLab fait une pause, fetch tous les fichiers inclus, les merge ensemble, puis évalue la configuration combinée dans son ensemble. Il y a trois subkeys principales que tu utilises pour pull ces fichiers externes. La plus simple est local. Tu utilises include local pour pull un fichier qui se trouve exactement dans le même repository que ton fichier de pipeline principal. C'est strictement pour organiser un seul gros projet. Tu peux extraire toute ta logique de test dans un fichier appelé test pipeline point yml, mettre ta logique de déploiement dans deploy pipeline point yml, et garder ton fichier de configuration root propre en référençant simplement ces chemins locaux. La deuxième subkey est project, et c'est là que la modularité des pipelines scale dans toute l'organisation. Include project pull un fichier YAML depuis un repository complètement différent, hébergé sur la même instance GitLab. Tu spécifies le chemin du projet externe, ainsi que le chemin du fichier et, en option, la branche spécifique ou la référence de commit que tu veux pull. Prends l'exemple d'une équipe plateforme qui maintient un pipeline central de scan de sécurité. Au lieu que cinquante équipes de microservices différentes écrivent et maintiennent leurs propres jobs de sécurité, l'équipe plateforme maintient un seul template YAML qui fait autorité dans un projet plateforme dédié. Les cinquante projets de microservices ajoutent simplement un bloc include project qui pointe vers ce repository central. Quand l'équipe plateforme met à jour la version du scanner ou ajuste les règles de sécurité dans son template, les cinquante microservices exécutent automatiquement les vérifications mises à jour lors de leur prochaine exécution de pipeline. Aucun copier-coller répétitif n'est requis. La troisième subkey est remote. Include remote prend une URL HTTPS complète et fetch un fichier de configuration depuis n'importe quel serveur web public. Tu pourrais utiliser ça pour pull des définitions de pipeline fournies par un vendor ou des standards open source de la communauté. Le seul prérequis strict, c'est que l'URL doit être accessible publiquement via une requête web standard sans authentification. Maintenant, fais bien attention à cette partie. Tu vas souvent rencontrer une situation où un fichier inclus définit un job, mais le projet local a besoin de le modifier légèrement. GitLab gère ça grâce à son comportement de merge. Quand des fichiers sont inclus, GitLab fait un deep merge des configurations. Si un fichier inclus définit un job appelé run security scan, et que ton fichier principal définit aussi un job appelé run security scan, c'est la configuration de ton fichier principal qui prend le dessus. Ça veut dire que tu n'as pas besoin de jeter un template centralisé juste parce que ton projet spécifique a besoin d'un petit ajustement. Tu peux inclure le template de l'équipe plateforme, et ensuite définir localement juste le job run security scan avec une variable mise à jour ou l'ajout d'un script custom. Tes overrides locaux s'appliquent, pendant que le reste de la définition du job reste exactement comme l'équipe plateforme l'a écrit. La véritable puissance de la modularité des pipelines, ce n'est pas juste de centraliser le code, mais de concevoir des templates comme des valeurs par défaut sensées que les projets en aval peuvent override localement sans casser la chaîne d'héritage. C'est tout pour cet épisode. Merci de ton écoute, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 13 sur 14. Ton pipeline vient de planter parce que quelqu'un a mis à jour un snippet YAML partagé, trois repositories plus loin. Tu n'as eu aucun avertissement, et maintenant tu passes une heure à réparer un job que tu n'as même pas écrit. Fini de dépendre de snippets YAML fragiles et non versionnés. Les Components CI/CD et le CI/CD Catalog règlent ça en apportant la fiabilité d'un package manager directement dans tes pipelines. Les Components sont des configurations de pipeline réutilisables, avec un seul but précis. Ils agissent comme l'évolution moderne de l'ancienne méthode des include templates. Avec les templates legacy, tu importais basiquement du YAML brut via le réseau. Si le fichier upstream changeait, ton pipeline changeait instantanément, souvent avec des résultats désastreux. Les Components résolvent ça en imposant un versioning strict. Le CI/CD Catalog sert de registry centralisé où ton organisation peut publier, découvrir et partager ces Components versionnés. Pour builder un Component, tu as besoin d'un repository avec une structure de fichiers très spécifique. La logique principale doit se trouver dans un dossier explicitement nommé templates. Tu peux placer plusieurs fichiers YAML dans ce dossier, chaque fichier représentant un Component distinct. À la racine du repository, tu dois aussi fournir un fichier readme point md. Ce fichier markdown n'est pas juste une suggestion polie. Il sert de documentation officielle affichée dans le Catalog, détaillant ce que fait le Component et quels paramètres il requiert. Voici le point clé. Les Components sont trop rigides pour être utiles sans inputs. Les inputs agissent exactement comme des arguments de fonction pour la configuration de ton pipeline. Quand tu écris le YAML du Component, tu déclares un bloc tout en haut qui définit les inputs acceptés. Tu spécifies leurs noms, leurs valeurs par défaut, et s'ils sont requis. Prends l'exemple d'une équipe de platform engineering qui déploie des scans de sécurité obligatoires. Ils créent un projet de Component appelé corporate-security. À l'intérieur du dossier templates, ils écrivent un fichier spécifiquement pour la détection de secrets. Pour garder ça flexible, ils définissent un seul input requis appelé stage. Les développeurs d'applications de toute l'entreprise n'ont plus besoin d'écrire ou de maintenir les jobs de détection de secrets eux-mêmes. Pour consommer ce Component de détection de secrets précis, un développeur utilise la syntaxe include component dans la configuration de son pipeline. Il spécifie le chemin vers le Component sur le serveur. Ensuite, il ajoute un arobase suivi d'une version sémantique, comme un point zéro point zéro. C'est l'étape cruciale. Pinner la version sémantique garantit que le pipeline ne cassera jamais de façon inattendue, même si l'équipe plateforme release une version deux point zéro point zéro fortement modifiée plus tard dans la semaine. Si un développeur veut intentionnellement la version bleeding edge, il peut ajouter le tag spécial tilde latest au lieu d'un numéro de version, mais le semantic versioning est le choix par défaut le plus sûr. Juste en dessous de la déclaration include, le développeur passe ses variables, en mappant l'input stage à n'importe quel stage du pipeline qui correspond à son projet spécifique, comme test ou pre-build. Traiter la logique du pipeline comme un logiciel versionné change la façon dont les équipes scalent leur infrastructure. La vraie puissance des Components n'est pas juste la réutilisation de code, c'est la garantie absolue qu'un pipeline qui tourne avec succès aujourd'hui tournera exactement de la même manière dans six mois. Merci d'avoir écouté. Prenez soin de vous, tout le monde.

Salut, c'est Alex de DEV STORIES DOT EU. GitLab CI/CD, épisode 14 sur 14. Tu essaies de définir le nom du stage d'un job avec une variable CI standard, tu fais un push de ton code, et tu te prends direct une erreur de syntaxe. Le pipeline refuse de s'exécuter. Le problème, c'est le timing. Le runner ne peut pas définir la structure du pipeline avec des variables qu'il reçoit seulement après que le pipeline a déjà démarré. C'est exactement là qu'interviennent les Compile-Time CI Expressions. Voici l'idée clé. Les variables au runtime standards, écrites avec un seul signe dollar, sont évaluées par le shell quand le job s'exécute réellement. Au moment où le runner les voit, toute l'architecture du pipeline est déjà verrouillée. Tu ne peux pas changer dynamiquement un nom de stage, un service ou une version d'image pendant l'exécution, parce que GitLab a besoin de ces infos en amont pour construire le graphe du pipeline. Les expressions au compile-time résolvent ça en évaluant la logique au moment exact où GitLab parse ta configuration YAML, bien avant qu'un runner ne soit assigné. La syntaxe utilise un signe dollar suivi de doubles crochets. À l'intérieur de ces crochets, tu écris une expression qui est évaluée pour donner une valeur avant que le pipeline ne soit créé. Ces expressions tirent leurs données de contextes spécifiques. Un contexte, c'est en gros un ensemble restreint de données disponibles pendant le parsing du YAML. Le contexte le plus important est le contexte inputs, qui est énormément utilisé quand tu crées des composants CI/CD. Prends le scénario d'un composant de déploiement dynamique. Tu veux que le projet qui consomme ce composant passe un nom d'environnement comme input. Ensuite, tu veux utiliser cet input pour définir le nom du stage du job et dicter la version spécifique de l'image Docker qu'il va pull. Dans la configuration de ton composant, tu écris le champ stage et tu lui assignes une expression au compile-time qui contient inputs point environment. Quand un projet inclut ton composant, GitLab lit l'input environment fourni. Il évalue l'expression immédiatement. Le graphe du pipeline qui en résulte voit un nom de stage statique et hardcodé, et un tag d'image hardcodé. Le runner ne rencontre jamais les doubles crochets. Il reçoit simplement une configuration standard. Au-delà des inputs, les expressions au compile-time supportent aussi un contexte matrix, qui est actuellement en bêta. Quand tu génères des jobs parallèles en utilisant un mot-clé comme parallel matrix, tu peux utiliser des expressions au compile-time pour ajuster dynamiquement les propriétés du job en fonction des variables spécifiques assignées à chaque instance parallèle. Ça t'évite de devoir dupliquer les définitions de jobs juste pour changer un ou deux champs par exécution de la matrix. Ces expressions sont plus puissantes qu'un simple remplacement de texte. Tu peux écrire de la logique directement à l'intérieur des crochets en utilisant des opérateurs d'égalité, ainsi que des opérateurs logiques AND et OR. Tu peux évaluer si un input correspond à une string spécifique, et changer conditionnellement une valeur en fonction du résultat. Tu as aussi accès à des fonctions intégrées. La fonction expand vars, par exemple, te permet d'injecter en toute sécurité des valeurs au compile-time dans une string tout en préservant explicitement la syntaxe standard des variables au runtime. Ça garantit que le runner reçoit toujours les variables au runtime qu'il attend sans causer de conflits de parsing au tout début. Ce qu'il faut retenir, c'est que les expressions au compile-time te donnent un mécanisme natif pour templater le graphe de ton pipeline, en séparant proprement la logique de génération structurelle de l'exécution réelle du script. Prends le temps de lire la documentation officielle de GitLab, de passer en revue les fonctions supportées, et d'essayer de deploy un composant par toi-même. Si tu as des sujets que tu aimerais voir abordés dans une future série, visite devstories dot eu et fais-le-nous savoir. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.