[{"data":1,"prerenderedAt":712},["ShallowReactive",2],{"/fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/":3,"navigation-fr-fr":40,"banner-fr-fr":459,"footer-fr-fr":472,"Olivier Dupré":683,"next-steps-fr-fr":697},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":16,"config":30,"_id":33,"_type":34,"title":35,"_source":36,"_file":37,"_stem":38,"_extension":39},"/fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments","blog",false,"",{"ogTitle":9,"schema":10,"ogImage":11,"ogDescription":12,"ogSiteName":13,"noIndex":6,"ogType":14,"ogUrl":15,"title":9,"canonicalUrls":15,"description":12},"Déployer en continu dans de multiples environnements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Déployer en continu dans de multiples environnements avec les pipelines enfants\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Olivier Dupré\"}],\n        \"datePublished\": \"2024-09-26\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097012/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750097011626.jpg","Découvrez comment créer un workflow rationalisé dans GitLab pour gérer le déploiement continu dans de multiples environnements.","https://about.gitlab.com","article","https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"heroImage":11,"body":17,"authors":18,"updatedDate":20,"date":21,"title":22,"tags":23,"description":12,"category":29},"Les équipes DevSecOps doivent parfois coordonner le déploiement continu dans\ndes environnements différents, tout en préservant leurs workflows. La\n[plateforme DevSecOps de GitLab](https://about.gitlab.com/fr-fr) répond à ce\nbesoin, de manière simple et efficace, y compris avec des environnements\nsandbox temporaires créés à la demande. Découvrez dans cet article un\nexemple de mise en œuvre de ce processus en déployant une architecture avec\nTerraform sur plusieurs environnements cibles.\n\n\nCette stratégie s'adapte facilement qu'il s'agisse d'un projet d'Infrastructure as Code (IaC) utilisant une autre technologie comme [Pulumi](https://www.pulumi.com/) ou [Ansible](https://www.ansible.com/), d'un projet de code source ou d'un projet de dépôt monolithique combinant plusieurs langages.\n\n\nÀ la fin de ce tutoriel, le pipeline que vous aurez créé permettra de déployer :\n\n\n* Un environnement temporaire de **développement** pour chaque branche de fonctionnalité.\n\n* Un environnement d'**intégration**, qu'il est facile de supprimer et redéployer à partir de la branche principale.\n\n* Un environnement d'**assurance qualité (QA)**, également déployé à partir de la branche principale, pour exécuter les étapes de QA.\n\n* Un environnement de **préproduction** pour chaque tag, dernière étape avant la phase de production.\n\n* Un environnement de **production** qui dans cet exemple sera déployé manuellement, mais qui peut également être déployé en continu.\n\n\n> Légende des schémas figurant dans cet article :\n\n>\n\n> * Les encarts aux angles arrondis représentent les branches de GitLab.\n\n> * Les encarts rectangulaires représentent les environnements.\n\n> * Le texte sur les flèches représente les actions requises pour passer d'un encart à l'autre.\n\n> * Les encarts carrés représentent une prise de décision.\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\n    D -->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\n    D -->|tag| G(X.Y.Z)\n    F -->|validate| G\n\n    G -->|auto deploy| H[staging]\n    H -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n\nNous allons vous expliquer les [raisons](#why) des [actions](#what) présentées dans le flowchart ci-dessus, ainsi que [les étapes à suivre](#how) pour chacune d'elles. Ce tutoriel sera ainsi plus facile à suivre et vous pourrez le reproduire sans difficulté.\n\n\n## Raisons\n\n\n* [L'intégration continue (CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/) constitue quasiment une norme établie. La plupart des entreprises implémentent des pipelines CI ou cherchent à standardiser leurs pratiques.\n\n* La [livraison continue (CD)](https://about.gitlab.com/fr-fr/topics/ci-cd/), qui consiste à effectuer la publication des artefacts vers un dépôt ou un registre à la fin du pipeline CI, est également courante.\n\n* L'étape suivante, le [déploiement continu](https://about.gitlab.com/fr-fr/topics/ci-cd/#what-is-continuous-deployment \"Qu'est-ce que le déploiement continu ? \"), qui automatise le déploiement de ces artefacts, est en revanche moins répandu. Il est essentiellement implémenté dans le domaine des applications. Le déploiement continu d'une infrastructure est plus compliqué et implique la gestion de plusieurs environnements. Tester, sécuriser et vérifier le code de l'infrastructure constitue un défi supplémentaire et c'est un domaine où le processus [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps ?\") n'a pas encore atteint sa pleine maturité. L'intégration de la sécurité en amont, qui nécessite l'implication des équipes de sécurité, représente également une difficulté. Et il est très important de prendre en compte les problèmes de sécurité dès les premières étapes du développement, afin de passer d'une approche DevOps à un processus **[DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\")**.\n\n\nCe tutoriel vous invite à tester une méthode simple et efficace pour adopter une approche DevSecOps pour votre infrastructure. Nous prendrons l'exemple du déploiement de ressources dans cinq environnements, du développement à la production.\n\n\n**Remarque :** même si je préconise l'adoption d'une [approche FinOps](https://about.gitlab.com/fr-fr/the-source/platform/finops-balancing-financial-responsibility-and-innovation/ \"Qu'est-ce que l'approche FinOps ? \") et la réduction du nombre d'environnements, il existe parfois d'excellentes raisons de ne pas se limiter aux simples étapes de développement, préproduction et production. N'hésitez pas à adapter les exemples en fonction de vos besoins.\n\n\n## Actions\n\n\nL’avènement du cloud a boosté l'utilisation de l'IaC. Ansible et Terraform ont ouvert la voie, suivis par OpenTofu, Pulumi, AWS CDK, Google Deploy Manager et bien d'autres.\n\n\nUne Infrastructure as Code est la solution parfaite pour déployer une infrastructure de manière sécurisée. Vous pouvez la tester, la déployer et la réappliquer autant de fois que nécessaire pour atteindre votre objectif.\n\n\nMalheureusement, les entreprises maintiennent souvent plusieurs branches, voire de multiples dépôts, pour chacun de leurs environnements cibles, ce qui crée des problèmes. Elles ne respectent plus un processus rigoureux. Elles ne s'assurent plus que chaque modification du code en production a été soigneusement testée dans les environnements précédents. Par conséquent, des décalages apparaissent peu à peu d'un environnement à l'autre.\n\n\nJ'ai réalisé que ce tutoriel était nécessaire lors d'une conférence à laquelle j'ai assisté : tous les participants ont déclaré que leur workflow n'imposait des tests rigoureux de l'infrastructure qu'avant le déploiement en production. Et ils ont tous convenu qu'ils appliquaient parfois des correctifs directement en production. Bien sûr, cette démarche permet d'aller vite, mais est-elle sûre ? Comment reporter les correctifs sur les environnements précédents ? Comment vérifier qu'il n'y a pas d'effets de bord ? Comment limiter les risques auxquels votre entreprise est exposée lorsque vous déployez votre code trop rapidement en production ?\n\n\nLa question essentielle est de savoir *pourquoi* les [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"Créer une structure d'équipe DevOps idéale\") déploient directement en production. Le pipeline devrait-il être plus efficace ou plus rapide ? N'est-il pas possible d'automatiser le processus ? Ou, pire encore, n'y a-t-il *aucun moyen de tester le code en dehors de l'environnement de production* ?\n\n\nDans la section suivante, vous apprendrez à automatiser votre infrastructure et à garantir que votre équipe DevOps mène des tests efficaces avant d'effectuer un push vers un environnement qui affectera le reste du processus. Vous verrez comment sécuriser votre code et contrôler son déploiement de bout en bout.\n\n\n## Les étapes à suivre\n\n\nComme mentionné précédemment, de nombreux langages permettent actuellement de gérer l'IaC et nous ne pouvons pas *tous* les aborder ici. Je vais m'appuyer sur un code Terraform version 1.4. Ne prêtez pas attention au langage utilisé pour gérer l'IaC, mais plutôt au processus transposable à votre écosystème.\n\n\n### Le code Terraform\n\n\nCommençons par un code Terraform de base.\n\n\nNous allons déployer sur AWS, un cloud privé virtuel (VPC), qui est un réseau virtuel. Dans ce VPC, nous déploierons un sous-réseau public et un sous-réseau privé. Comme leur nom l'indique, il s'agit de sous-réseaux du VPC principal. Enfin, nous ajouterons une instance Elastic Cloud Compute (EC2) (une machine virtuelle) dans le sous-réseau public.\n\n\nNous allons ainsi déployer quatre ressources de manière relativement simple. L'idée est de se concentrer sur le pipeline, et non sur le code.\n\n\nVoici la cible que nous voulons atteindre pour votre dépôt.\n\n\n![cible du dépôt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097033415.png)\n\n\nDécomposons le processus.\n\n\nTout d'abord, nous déclarons toutes les ressources dans un fichier `terraform/main.tf` :\n\n\n```terraform\n\nprovider \"aws\" {\n  region = var.aws_default_region\n}\n\n\nresource \"aws_vpc\" \"main\" {\n  cidr_block = var.aws_vpc_cidr\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n\n\nresource \"aws_subnet\" \"public_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_public_subnet_cidr\n\n  tags = {\n    Name = \"Public Subnet\"\n  }\n}\n\nresource \"aws_subnet\" \"private_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_private_subnet_cidr\n\n  tags = {\n    Name = \"Private Subnet\"\n  }\n}\n\n\nresource \"aws_instance\" \"sandbox\" {\n  ami           = var.aws_ami_id\n  instance_type = var.aws_instance_type\n\n  subnet_id = aws_subnet.public_subnet.id\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n\n```\n\n\nComme vous pouvez le constater, ce code nécessite plusieurs variables. Nous les déclarons dans un fichier `terraform/variables.tf` :\n\n\n```terraform\n\nvariable \"aws_ami_id\" {\n  description = \"The AMI ID of the image being deployed.\"\n  type        = string\n}\n\n\nvariable \"aws_instance_type\" {\n  description = \"The instance type of the VM being deployed.\"\n  type        = string\n  default     = \"t2.micro\"\n}\n\n\nvariable \"aws_vpc_cidr\" {\n  description = \"The CIDR of the VPC.\"\n  type        = string\n  default     = \"10.0.0.0/16\"\n}\n\n\nvariable \"aws_public_subnet_cidr\" {\n  description = \"The CIDR of the public subnet.\"\n  type        = string\n  default     = \"10.0.1.0/24\"\n}\n\n\nvariable \"aws_private_subnet_cidr\" {\n  description = \"The CIDR of the private subnet.\"\n  type        = string\n  default     = \"10.0.2.0/24\"\n}\n\n\nvariable \"aws_default_region\" {\n  description = \"Default region where resources are deployed.\"\n  type        = string\n  default     = \"eu-west-3\"\n}\n\n\nvariable \"aws_resources_name\" {\n  description = \"Default name for the resources.\"\n  type        = string\n  default     = \"demo\"\n}\n\n```\n\n\nÀ ce stade, nous avons presque terminé la partie IaC. Il nous manque simplement une méthode pour partager les états Terraform. Si vous l'ignorez, Terraform fonctionne schématiquement comme suit :\n\n\n* La commande `plan` vérifie les différences entre l'infrastructure actuelle et celle définie dans le code. Elle génère ensuite un rapport des différences.\n\n* La commande `apply` exécute les modifications en fonction du rapport `plan` et met à jour l'état.\n\n\nLors du premier passage, l'état est vide. Il comporte ensuite les détails (ID, etc.) des ressources appliquées par Terraform.\n\n\nLe problème est le suivant : où cet état est-il stocké ? Comment le partager pour permettre à plusieurs développeurs et développeuses de collaborer sur le code ?\n\n\nLa solution est assez simple : stockez et partagez l'état dans GitLab via un [backend HTTP Terraform](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html).\n\n\nLorsque vous utilisez ce backend, la première étape consiste à créer le fichier `terraform/backend.tf` le plus simple qui soit. La deuxième étape est prise en charge dans le pipeline.\n\n\n```terraform\n\nterraform {\n  backend \"http\" {\n  }\n}\n\n```\n\n\nEt voilà ! Nous disposons maintenant d'un code Terraform minimaliste pour déployer ces quatre ressources. Nous renseignerons les valeurs des variables lors de l'exécution à une étape ultérieure.\n\n\n### Le workflow\n\n\nMettons en œuvre le workflow suivant :\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\n    D -->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\n    D -->|tag| G(X.Y.Z)\n    F -->|validate| G\n\n    G -->|auto deploy| H[staging]\n    H -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n\n1. Créez une branche de **fonctionnalité**. Elle exécute tous les scanners en continu sur le code pour s'assurer qu'il est toujours conforme et sécurisé. Ce code est déployé en continu dans un environnement temporaire `review/feature_branch` portant le nom de la branche actuelle. Il s'agit d'un environnement sûr où les équipes de développement et d'opérations peuvent tester leur code sans impact sur le reste du Système d’Information (SI). Le processus, comme les revues de code et l'exécution de scanners, est imposé à cette étape pour assurer que la qualité et la sécurité du code sont suffisantes et ne mettent pas votre SI en danger. L'infrastructure déployée par cette branche est automatiquement détruite lorsque la branche est fermée. Vous pouvez ainsi contrôler votre budget.\n\n2. Une fois approuvée, la branche de fonctionnalité est **fusionnée** dans la branche principale. Il s'agit d'une [branche protégée](https://docs.gitlab.com/ee/user/project/protected_branches.html) où aucun push ne peut être effectué directement. Elle est nécessaire pour veiller à ce que chaque demande de modification de l'environnement de production soit minutieusement testée. Cette branche est également déployée en continu. La cible ici est l'environnement `integration`. La suppression de cet environnement n'est pas automatisée pour des questions de stabilité, mais elle peut être déclenchée manuellement.\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    D(main) -->|auto deploy| E[integration]\n\u003C/pre>\n\n\n3. Une approbation manuelle est ensuite nécessaire pour déclencher le déploiement suivant. La branche principale sera déployée dans l'environnement `qa`. J'ai défini une règle ici pour empêcher la suppression depuis le pipeline. Cet environnement devrait être assez stable (après tout, c'est déjà le troisième) et je souhaite éviter une suppression accidentelle. N'hésitez pas à adapter les règles à vos processus.\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    D(main)-->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\u003C/pre>\n\n\n4. Pour continuer, nous devons **ajouter un tag** au code. Nous utilisons les [tags protégés](https://docs.gitlab.com/ee/user/project/protected_tags.html) pour que seul un ensemble spécifique d'utilisateurs ait l'autorisation de déployer dans ces deux derniers environnements. Ce tag va immédiatement déclencher un déploiement dans l'environnement `staging`.\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    D(main) -->|tag| G(X.Y.Z)\n    F[qa] -->|validate| G\n\n    G -->|auto deploy| H[staging]\n\u003C/pre>\n\n\n5. Nous arrivons enfin à l'environnement `production`. Il est souvent difficile de déployer l'infrastructure progressivement (10 %, 25 %, etc.). Nous la déployons donc dans son intégralité. Nous contrôlons toutefois ce déploiement à l'aide d'un déclencheur manuel intégré dans cette dernière étape. Afin de garder un contrôle maximal sur cet environnement hautement critique, nous le contrôlons en tant qu'[environnement protégé](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n\n\u003Cpre class=\"mermaid\">\n\nflowchart LR\n    H[staging] -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n\n### Le pipeline\n\n\nPour mettre en œuvre le [workflow](#the-workflow) ci-dessus, nous allons maintenant implémenter un pipeline comportant deux [pipelines enfants](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html).\n\n\n#### Le pipeline principal\n\n\nCommençons par le pipeline principal. Il est déclenché automatiquement par un **push effectué vers une branche de fonctionnalité**, une **fusion vers la branche par défaut** ou un **tag**. *Il* effectue un vrai **déploiement continu** dans les environnements suivants : `dev`, `integration` et `staging`. Il est déclaré dans le fichier `.gitlab-ci.yml` à la racine de votre projet.\n\n\n![la cible du dépôt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097033417.png)\n\n\n```yml\n\nstages:\n  - test\n  - environments\n\n.environment:\n  stage: environments\n  variables:\n    TF_ROOT: terraform\n    TF_CLI_ARGS_plan: \"-var-file=../vars/$variables_file.tfvars\"\n  trigger:\n    include: .gitlab-ci/.first-layer.gitlab-ci.yml\n    strategy: depend            # Wait for the triggered pipeline to successfully complete\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nreview:\n  extends: .environment\n  variables:\n    environment: review/$CI_COMMIT_REF_SLUG\n    TF_STATE_NAME: $CI_COMMIT_REF_SLUG\n    variables_file: review\n    TF_VAR_aws_resources_name: $CI_COMMIT_REF_SLUG  # Used in the tag Name of the resources deployed, to easily differenciate them\n  rules:\n    - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n\nintegration:\n  extends: .environment\n  variables:\n    environment: integration\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nstaging:\n  extends: .environment\n  variables:\n    environment: staging\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_TAG\n\n#### TWEAK\n\n# This tweak is needed to display vulnerability results in the merge widgets.\n\n# As soon as this issue https://gitlab.com/gitlab-org/gitlab/-/issues/439700 is resolved, the `include` instruction below can be removed.\n\n# Until then, the SAST IaC scanners will run in the downstream pipelines, but their results will not be available directly in the merge request widget, making it harder to track them.\n\n# Note: This workaround is perfectly safe and will not slow down your pipeline.\n\ninclude:\n  - template: Security/SAST-IaC.gitlab-ci.yml\n#### END TWEAK\n\n```\n\n\nCe pipeline n'exécute que deux étapes : `test` et  `environments`. La première est nécessaire pour que le *TWEAK* exécute les scanners. La seconde déclenche un pipeline enfant contenant un ensemble de variables différent pour chaque cas défini ci-dessus (push vers la branche, fusion dans la branche par défaut ou tag).\n\n\nNous ajoutons ici une dépendance avec le mot-clé [strategy:depend](https://docs.gitlab.com/ee/ci/yaml/index.html#triggerstrategy) sur notre pipeline enfant afin que la vue du pipeline dans GitLab ne soit mise à jour qu'une fois le déploiement terminé.\n\n\nComme vous le voyez, nous définissons un job de base [masqué](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs), puis nous ajoutons des variables et des règles spécifiques afin de déclencher un seul déploiement pour chaque environnement cible.\n\n\nOutre les [variables prédéfinies](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html), nous utilisons deux nouveaux éléments que nous devons définir :\n\n\n1. [Les variables spécifiques](#the-variable-definitions) à chaque environnement : `../vars/$variables_file.tfvars`\n\n2. [Le pipeline enfant](#the-child-pipeline), défini dans `.gitlab-ci/.first-layer.gitlab-ci.yml`\n\n\nCommençons par le plus rapide, les définitions des variables.\n\n\n### Les définitions des variables\n\n\nNous allons ici mélanger deux solutions pour fournir des variables à Terraform :\n\n\n* La première utilise des [fichiers .tfvars](https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files) pour tous les intrants ne contenant pas de données sensibles, qui doivent être stockées dans GitLab.\n\n\n![solution 1 pour fournir des variables à Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097033419.png)\n\n\n* La seconde utilise des [variables d'environnement](https://developer.hashicorp.com/terraform/language/values/variables#environment-variables) avec le préfixe `TF_VAR`. Combinée à la capacité de GitLab à [masquer les variables](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable), à [les protéger](https://docs.gitlab.com/ee/ci/variables/#protect-a-cicd-variable) et à les rendre [accessibles uniquement pour certains environnements](https://docs.gitlab.com/ee/ci/environments/index.html#limit-the-environment-scope-of-a-cicd-variable), cette deuxième façon d'injecter des variables est une solution puissante pour **empêcher les fuites d'informations contenant des données sensibles**. Par exemple, si vous considérez que le routage CIDR privé de votre environnement de production est une donnée sensible, vous pouvez le protéger de cette manière. Veillez à ce qu'il ne soit disponible que pour l'environnement `production`, pour les pipelines fonctionnant avec des branches et des tags protégés, et que sa valeur soit masquée dans les journaux du job.\n\n\n![solution 2 pour fournir des variables à Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097033422.png)\n\n\nDe plus, chaque fichier de variables doit être contrôlé via un [fichier `CODEOWNERS`](https://docs.gitlab.com/ee/user/project/codeowners/) où sont définies les personnes ayant l'autorisation d'apporter des modifications.\n\n\n```\n\n[Production owners] \n\nvars/production.tfvars @operations-group\n\n\n[Staging owners]\n\nvars/staging.tfvars @odupre @operations-group\n\n\n[CodeOwners owners]\n\nCODEOWNERS @odupre\n\n```\n\n\nCet article n'a pas pour but d'expliquer Terraform, nous allons donc simplement montrer le fichier `vars/review.tfvars`. Les fichiers d'environnement suivants sont, bien sûr, très similaires. Il suffit de définir les variables ne contenant pas de données sensibles et leurs valeurs ici.\n\n\n```shell\n\naws_vpc_cidr = \"10.1.0.0/16\"\n\naws_public_subnet_cidr = \"10.1.1.0/24\"\n\naws_private_subnet_cidr = \"10.1.2.0/24\"\n\n```\n\n\n#### Le pipeline enfant\n\n\nC'est dans ce pipeline que le travail concret est effectué. Il est donc un peu plus complexe que le premier. Mais rien qu'on ne puisse surmonter ensemble !\n\n\nComme nous l'avons vu dans la définition du pipeline principal, ce pipeline enfant est déclaré dans le fichier `.gitlab-ci/.first-layer.gitlab-ci.yml`.\n\n\n![Pipeline downstream déclaré dans le fichier](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097033424.png)\n\n\nDécomposons-le en petites étapes avant de revenir à une vue d'ensemble.\n\n\n##### Exécution des commandes Terraform et sécurisation du code\n\n\nNous allons d'abord mettre en place un pipeline pour Terraform. GitLab est une plateforme open source tout comme notre template de pipeline pour Terraform. Il vous suffit de l'inclure, en utilisant l'extrait de code suivant :\n\n\n```yml\n\ninclude:\n  - template: Terraform.gitlab-ci.yml\n```\n\n\nCe template exécute les vérifications Terraform sur le formatage et valide votre code, avant de le planifier et de l'appliquer. Il vous permet également de détruire ce que vous avez déployé.\n\n\nEn tant que plateforme DevSecOps unifiée, GitLab intègre deux scanners de sécurité directement dans ce template afin de détecter les menaces potentielles dans votre code et de vous avertir avant tout déploiement dans les environnements suivants.\n\n\nMaintenant que nous avons vérifié, sécurisé, compilé et déployé notre code, explorons quelques astuces supplémentaires.\n\n\n##### Partage du cache entre les jobs\n\n\nPour réutiliser les résultats des jobs dans les étapes suivantes du pipeline, nous allons activer la mise en cache. Il suffit d'ajouter le code suivant :\n\n\n```yml\n\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n```\n\n\nNous définissons ici un cache différent pour chaque commit, en revenant au nom de la branche principale si nécessaire.\n\n\nEn regardant de près les templates utilisés, on observe qu’ils contiennent des règles contrôlant l’exécution des jobs. Nous voulons exécuter tous les contrôles (assurance qualité et sécurité) sur toutes les branches. Nous allons donc personnaliser ces paramètres.\n\n\n##### Exécution des contrôles sur toutes les branches\n\n\nLes templates GitLab offrent une fonctionnalité puissante permettant de modifier uniquement certaines parties d’un template. Nous souhaitons seulement remplacer les règles de certains jobs afin de toujours exécuter des contrôles d'assurance qualité et de sécurité. Les autres paramètres de ces jobs resteront conformes au template.\n\n\n```yml\n\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - when: always\n\niac-sast:\n  rules:\n    - when: always\n```\n\n\nMaintenant que nous avons appliqué les contrôles d'assurance qualité et de sécurité, nous voulons différencier le comportement des environnements principaux (intégration et préproduction) dans le [workflow](#the-workflow) par rapport aux environnements de revue. Commençons par définir le comportement des environnements principaux. Nous modifierons ensuite cette configuration pour les environnements de revue.\n\n\n##### Pipeline CD pour l'intégration et la préproduction\n\n\nComme indiqué, nous voulons déployer la branche principale et les tags dans ces deux environnements. Nous ajoutons des règles pour contrôler ce déploiement sur les jobs `build` et `deploy`. Ensuite, nous activons la fonction `destroy` uniquement pour `integration`, car l'environnement `staging` est trop critique pour être supprimé en un seul clic. Les erreurs sont possibles et nous souhaitons les éviter.\n\n\nEnfin, nous relions le job `deploy` au job `destroy`, afin de pouvoir déclencher un `stop` sur l'environnement directement à partir de l'interface utilisateur graphique de GitLab.\n\n\n`GIT_STRATEGY` positionné à `none` empêche la récupération du code de la branche source dans le runner lors de la destruction. L'opération échouerait si la branche avait été supprimée manuellement. Nous comptons donc sur le cache pour obtenir tout ce dont nous avons besoin pour exécuter les instructions Terraform.\n\n\n```yml\n\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env (integration or staging) when merging to default branch or tagging. Second layer environments (qa and production) will be controlled manually\n  environment: \n    name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n```\n\n\nComme indiqué, cela nous permet de déployer sur les environnements `integration` et `staging`. Mais il manque toujours un environnement temporaire où les développeurs et développeuses peuvent expérimenter et valider leur code sans affecter le travail des autres. C'est tout l'intérêt du déploiement dans l'environnement `review`.\n\n\n##### Pipeline CD pour les environnements de revue\n\n\nLe déploiement dans l'environnement de revue n'est pas très différent du déploiement dans les environnements `integration` et `staging`. Nous allons une fois de plus tirer parti de la capacité de GitLab à remplacer uniquement des éléments de définition de job.\n\n\nTout d'abord, nous définissons des règles pour exécuter ces jobs uniquement sur les branches de fonctionnalités.\n\n\nEnsuite, nous relions le job `deploy_review` à `destroy_review`. Nous pouvons ainsi arrêter l'environnement **manuellement** à partir de l'interface utilisateur de GitLab. Plus important encore, ce job **déclenche automatiquement la destruction de l'environnement** lorsque la branche de fonctionnalité est fermée. Cette bonne pratique FinOps vous aide à contrôler vos dépenses opérationnelles.\n\n\nPuisque Terraform a besoin d'un fichier de plan pour la destruction d'une infrastructure, comme pour la compilation, nous ajoutons une dépendance de `destroy_review` à `build_review` afin de récupérer ses artefacts.\n\n\nEnfin, nous voyons ici que le nom de l'environnement est `$environment`. Il a été défini sur `review/$CI_COMMIT_REF_SLUG` dans le [pipeline principal](#the-main-pipeline) et transmis à ce pipeline enfant avec l'instruction `trigger:forward:yaml_variables:true`.\n\n\n```yml\n\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n```\n\n\nPour récapituler, nous avons maintenant un pipeline qui peut :\n\n\n* Déployer des environnements de revue temporaires, qui sont automatiquement détruits lorsque la branche de fonctionnalité est fermée\n\n* Déployer en continu la **branche par défaut** sur `integration`\n\n* Déployer en continu les **tags** sur l'environnement `staging`\n\n\nAjoutons maintenant un niveau supplémentaire, où nous allons déployer sur les environnements `qa` et `production` avec un déclencheur manuel.\n\n\n##### Pipeline CD pour l'assurance qualité et la production\n\n\nComme tout le monde n'est pas prêt à effectuer des déploiements continus en production, nous ajoutons une validation manuelle pour les deux prochains déploiements. À strictement parler, nous ne devrions pas ajouter ce déclencheur dans un processus **CD**, mais profitons de cette occasion pour vous apprendre à exécuter des jobs à partir d'autres déclencheurs.\n\n\nJusqu'à présent, nous avons lancé un [pipeline enfant](#the-child-pipeline) à partir du [pipeline principal](#the-main-pipeline) pour exécuter tous les déploiements.\n\n\nComme nous voulons exécuter d'autres déploiements à partir de la branche par défaut et des tags, nous ajoutons un nouveau niveau pour ces étapes supplémentaires. Rien de bien nouveau. Nous allons répéter le processus utilisé pour le [pipeline principal](#the-main-pipeline). En procédant de cette façon, vous pouvez manipuler autant de niveaux que vous le souhaitez. J'ai déjà vu jusqu'à neuf environnements.\n\n\nSans revenir sur les avantages d'un nombre limité d'environnements, le processus que nous utilisons ici permet d'implémenter très facilement le même pipeline, de la phase initiale jusqu’à la livraison finale, tout en gardant la définition de votre pipeline simple et divisée en petits segments que vous pouvez maintenir facilement.\n\n\nPour éviter les conflits de variables, nous utilisons simplement de nouveaux noms pour identifier l'état Terraform et le fichier d'intrant.\n\n\n```yml\n\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Otherwise, all pipelines will fail when reaching the pipeline timeout before deployment to 2nd layer.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n```\n\n\n**Un point important ici est la stratégie utilisée pour le nouveau pipeline enfant.** Nous maintenons la valeur par défaut du déclencheur `trigger:strategy`. Dans le cas contraire, le [pipeline principal](#the-main-pipeline) attend la fin de votre [pipeline de niveau « petit-enfant »](#the-grand-child-pipeline). Si vous utilisez un déclencheur manuel, cette opération peut prendre beaucoup de temps et rendre votre tableau de bord de pipeline plus difficile à lire et à comprendre.\n\n\nVous vous demandez probablement ce que contient le fichier `.gitlab-ci/.second-layer.gitlab-ci.yml` qui est inclus ici. Nous aborderons cette question dans la section suivante.\n\n\n##### Le premier niveau complet de définition de pipeline\n\n\nSi vous recherchez une vue complète de ce premier niveau (stocké dans `.gitlab-ci/.first-layer.gitlab-ci.yml`), consultez la section suivante.\n\n\n```yml\n\nvariables:\n  TF_VAR_aws_ami_id: $AWS_AMI_ID\n  TF_VAR_aws_instance_type: $AWS_INSTANCE_TYPE\n  TF_VAR_aws_default_region: $AWS_DEFAULT_REGION\n\ninclude:\n  - template: Terraform.gitlab-ci.yml\n\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n  - cleanup\n  - 2nd_layer       # Use to deploy a 2nd environment on both the main branch and on the tags\n\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\niac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\n###########################################################################################################\n\n## Integration env. and Staging. env\n\n##  * Auto-deploy to Integration on merge to main.\n\n##  * Auto-deploy to Staging on tag.\n\n##  * Integration can be manually destroyed if TF_DESTROY is set to true.\n\n##  * Destroy of next env. is not automated to prevent errors.\n\n###########################################################################################################\n\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env (integration or staging) when merging to default branch or tagging. Second layer environments (qa and production) will be controlled manually\n  environment: \n    name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n###########################################################################################################\n\n\n###########################################################################################################\n\n## Dev env.\n\n##  * Temporary environment. Lives and dies with the Merge Request.\n\n##  * Auto-deploy on push to feature branch.\n\n##  * Auto-destroy on when Merge Request is closed.\n\n###########################################################################################################\n\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n###########################################################################################################\n\n\n###########################################################################################################\n\n## Second layer\n\n##  * Deploys from main branch to qa env.\n\n##  * Deploys from tag to production.\n\n###########################################################################################################\n\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Otherwise, all pipelines will fail when reaching the pipeline timeout before deployment to 2nd layer.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n###########################################################################################################\n\n```\n\n\nÀ cette étape, nous avons déjà effectué des déploiements vers trois environnements en toute sécurité. Je trouve personnellement que cette démarche est idéale. Cependant, si vous avez besoin d'autres environnements, ajoutez-les à votre pipeline CD.\n\n\nVous avez sûrement remarqué que nous incluons un pipeline enfant avec le mot-clé `trigger:include`. Il inclut le fichier `.gitlab-ci/.second-layer.gitlab-ci.yml`. Nous souhaitons exécuter un pipeline très similaire, son contenu ressemble donc évidemment beaucoup à celui présenté ci-dessus. Le principal avantage de ce [pipeline de niveau « petit-enfant »](#the-grand-child-pipeline) est qu'il existe par lui-même, ce qui facilite la définition des variables et des règles.\n\n\n### Le pipeline de niveau « petit-enfant »\n\n\nCe pipeline de deuxième couche est tout nouveau. Par conséquent, il doit imiter la définition de la première couche, à savoir :\n\n\n* [Il doit inclure le template Terraform](#run-terraform-commands-and-secure-the-code).\n\n* [Il doit exécuter des contrôles de sécurité](#run-controls-on-all-branches). La validation Terraform dupliquerait le premier niveau, mais les scanners de sécurité peuvent identifier des menaces qui n'existaient pas encore lors des précédents scans (par exemple, si vous déployez en production quelques jours après votre déploiement en préproduction).\n\n* [Il doit remplacer les jobs de compilation et de déploiement pour définir des règles spécifiques](#cd-to-review-environments). Notez que l'étape `destroy` n'est plus automatisée pour éviter des suppressions accidentelles.\n\n\nComme expliqué ci-dessus, les variables `TF_STATE_NAME` et `TF_CLI_ARGS_plan` sont copiées du pipeline principal au pipeline enfant. Nous avions besoin d'un nom de variable différent pour transférer ces valeurs du pipeline enfant au pipeline « petit-enfant ». C'est pourquoi, dans le pipeline enfant, les noms de ces variables incluent le suffixe `_2`. La valeur est ensuite copiée dans la variable correspondante appropriée lors de l'exécution de la section `before_script`.\n\n\nComme nous avons déjà décomposé chaque étape, nous pouvons passer directement à la vue d'ensemble du deuxième niveau (codé dans `.gitlab-ci/.second-layer.gitlab-ci.yml`).\n\n\n```yml\n\n# Use to deploy a second environment on both the default branch and the tags.\n\n\ninclude:\n  template: Terraform.gitlab-ci.yml\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n\nfmt:\n  rules:\n    - when: never\n\nvalidate:\n  rules:\n    - when: never\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: always\n\n###########################################################################################################\n\n## QA env. and Prod. env\n\n##  * Manually trigger build and auto-deploy in QA\n\n##  * Manually trigger both build and deploy in Production\n\n##  * Destroy of these env. is not automated to prevent errors.\n\n###########################################################################################################\n\nbuild:  # terraform plan\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment:\n    name: $TF_STATE_NAME_2\n    action: prepare\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - when: manual\n\ndeploy: # terraform apply\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment: \n    name: $TF_STATE_NAME_2\n    action: start\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG && $TF_AUTO_DEPLOY == \"true\"\n    - if: $CI_COMMIT_TAG\n      when: manual\n###########################################################################################################\n\n```\n\n\nVoilà qui est fait. **Tout est prêt.** N'hésitez pas à changer la façon dont vous contrôlez l'exécution de vos jobs, en tirant parti, par exemple, de la capacité de GitLab à [retarder un job](https://docs.gitlab.com/ee/ci/jobs/job_control.html#run-a-job-after-a-delay) avant de le déployer en production.\n\n\n## Essayez par vous-même\n\n\nCe tutoriel est maintenant terminé. Nous savons désormais comment contrôler les **déploiements vers cinq environnements différents** en utilisant uniquement les **branches de fonctionnalités**, la **branche principale** et les **tags**.\n\n\n* Nous réutilisons intensivement les templates open source GitLab pour assurer la productivité et la sécurité de nos pipelines.\n\n* Nous tirons parti des capacités du template GitLab pour remplacer uniquement les blocs nécessitant un contrôle personnalisé.\n\n* Nous avons divisé le pipeline en petits segments et contrôlons les pipelines enfants afin qu'ils correspondent exactement à nos besoins.\n\n\nÀ vous de jouer maintenant. Vous pouvez, par exemple, facilement mettre à jour le pipeline principal afin de déclencher des pipelines enfants, pour votre code source logiciel, avec le mot-clé [trigger:rules:changes](https://docs.gitlab.com/ee/ci/yaml/#ruleschanges). Vous pouvez utiliser un autre [template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/) en fonction des changements qui se sont produits. Mais c'est une autre histoire.\n",[19],"Olivier Dupré","2025-01-09","2024-09-26","Déployer en continu dans de multiples environnements avec les pipelines enfants",[24,25,26,27,28],"CI/CD","CI","CD","DevSecOps platform","tutorial","engineering",{"slug":31,"featured":6,"template":32},"using-child-pipelines-to-continuously-deploy-to-five-environments","BlogPost","content:fr-fr:blog:using-child-pipelines-to-continuously-deploy-to-five-environments.yml","yaml","Using Child Pipelines To Continuously Deploy To Five Environments","content","fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments.yml","fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments","yml",{"_path":41,"_dir":42,"_draft":6,"_partial":6,"_locale":7,"data":43,"_id":455,"_type":34,"title":456,"_source":36,"_file":457,"_stem":458,"_extension":39},"/shared/fr-fr/main-navigation","fr-fr",{"logo":44,"freeTrial":49,"sales":54,"login":59,"items":64,"search":396,"minimal":432,"duo":446},{"config":45},{"href":46,"dataGaName":47,"dataGaLocation":48},"/fr-fr/","gitlab logo","header",{"text":50,"config":51},"Commencer un essai gratuit",{"href":52,"dataGaName":53,"dataGaLocation":48},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":55,"config":56},"Contacter l'équipe commerciale",{"href":57,"dataGaName":58,"dataGaLocation":48},"/fr-fr/sales/","sales",{"text":60,"config":61},"Connexion",{"href":62,"dataGaName":63,"dataGaLocation":48},"https://gitlab.com/users/sign_in/","sign in",[65,109,207,212,317,377],{"text":66,"config":67,"cards":69,"footer":92},"Plateforme",{"dataNavLevelOne":68},"platform",[70,76,84],{"title":66,"description":71,"link":72},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":73,"config":74},"Découvrir notre plateforme",{"href":75,"dataGaName":68,"dataGaLocation":48},"/fr-fr/platform/",{"title":77,"description":78,"link":79},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":80,"config":81},"Découvrez GitLab Duo",{"href":82,"dataGaName":83,"dataGaLocation":48},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":85,"description":86,"link":87},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":88,"config":89},"En savoir plus",{"href":90,"dataGaName":91,"dataGaLocation":48},"/fr-fr/why-gitlab/","why gitlab",{"title":93,"items":94},"Démarrer avec",[95,100,105],{"text":96,"config":97},"Ingénierie de plateforme",{"href":98,"dataGaName":99,"dataGaLocation":48},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":101,"config":102},"Expérience développeur",{"href":103,"dataGaName":104,"dataGaLocation":48},"/fr-fr/developer-experience/","Developer experience",{"text":106,"config":107},"MLOps",{"href":108,"dataGaName":106,"dataGaLocation":48},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":110,"left":111,"config":112,"link":114,"lists":118,"footer":189},"Produit",true,{"dataNavLevelOne":113},"solutions",{"text":115,"config":116},"Voir toutes les solutions",{"href":117,"dataGaName":113,"dataGaLocation":48},"/fr-fr/solutions/",[119,144,167],{"title":120,"description":121,"link":122,"items":127},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":123},{"icon":124,"href":125,"dataGaName":126,"dataGaLocation":48},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[128,131,135,140],{"text":24,"config":129},{"href":130,"dataGaLocation":48,"dataGaName":24},"/fr-fr/solutions/continuous-integration/",{"text":132,"config":133},"Développement assisté par l'IA",{"href":82,"dataGaLocation":48,"dataGaName":134},"AI assisted development",{"text":136,"config":137},"Gestion du code source",{"href":138,"dataGaLocation":48,"dataGaName":139},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":141,"config":142},"Livraison de logiciels automatisée",{"href":125,"dataGaLocation":48,"dataGaName":143},"Automated software delivery",{"title":145,"description":146,"link":147,"items":152},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":148},{"href":149,"dataGaName":150,"dataGaLocation":48,"icon":151},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[153,158,163],{"text":154,"config":155},"Application Security Testing",{"href":156,"dataGaName":157,"dataGaLocation":48},"/solutions/application-security-testing/","Application security testing",{"text":159,"config":160},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":161,"dataGaLocation":48,"dataGaName":162},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":164,"config":165},"Software Compliance",{"href":166,"dataGaName":164,"dataGaLocation":48},"/solutions/software-compliance/",{"title":168,"link":169,"items":174},"Mesures",{"config":170},{"icon":171,"href":172,"dataGaName":173,"dataGaLocation":48},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[175,179,184],{"text":176,"config":177},"Visibilité et mesures",{"href":172,"dataGaLocation":48,"dataGaName":178},"Visibility and Measurement",{"text":180,"config":181},"Gestion de la chaîne de valeur",{"href":182,"dataGaLocation":48,"dataGaName":183},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":185,"config":186},"Données d'analyse et informations clés",{"href":187,"dataGaLocation":48,"dataGaName":188},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":190,"items":191},"GitLab pour",[192,197,202],{"text":193,"config":194},"Entreprises",{"href":195,"dataGaLocation":48,"dataGaName":196},"/fr-fr/enterprise/","enterprise",{"text":198,"config":199},"PME",{"href":200,"dataGaLocation":48,"dataGaName":201},"/fr-fr/small-business/","small business",{"text":203,"config":204},"Secteur public",{"href":205,"dataGaLocation":48,"dataGaName":206},"/fr-fr/solutions/public-sector/","public sector",{"text":208,"config":209},"Tarifs",{"href":210,"dataGaName":211,"dataGaLocation":48,"dataNavLevelOne":211},"/fr-fr/pricing/","pricing",{"text":213,"config":214,"link":216,"lists":220,"feature":304},"Ressources",{"dataNavLevelOne":215},"resources",{"text":217,"config":218},"Afficher toutes les ressources",{"href":219,"dataGaName":215,"dataGaLocation":48},"/fr-fr/resources/",[221,254,276],{"title":222,"items":223},"Premiers pas",[224,229,234,239,244,249],{"text":225,"config":226},"Installation",{"href":227,"dataGaName":228,"dataGaLocation":48},"/fr-fr/install/","install",{"text":230,"config":231},"Guides de démarrage rapide",{"href":232,"dataGaName":233,"dataGaLocation":48},"/fr-fr/get-started/","quick setup checklists",{"text":235,"config":236},"Apprentissage",{"href":237,"dataGaLocation":48,"dataGaName":238},"https://university.gitlab.com/","learn",{"text":240,"config":241},"Documentation sur le produit",{"href":242,"dataGaName":243,"dataGaLocation":48},"https://docs.gitlab.com/","product documentation",{"text":245,"config":246},"Vidéos sur les bonnes pratiques",{"href":247,"dataGaName":248,"dataGaLocation":48},"/fr-fr/getting-started-videos/","best practice videos",{"text":250,"config":251},"Intégrations",{"href":252,"dataGaName":253,"dataGaLocation":48},"/fr-fr/integrations/","integrations",{"title":255,"items":256},"Découvrir",[257,262,266,271],{"text":258,"config":259},"Histoires de succès client",{"href":260,"dataGaName":261,"dataGaLocation":48},"/fr-fr/customers/","customer success stories",{"text":263,"config":264},"Blog",{"href":265,"dataGaName":5,"dataGaLocation":48},"/fr-fr/blog/",{"text":267,"config":268},"Travail à distance",{"href":269,"dataGaName":270,"dataGaLocation":48},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":272,"config":273},"TeamOps",{"href":274,"dataGaName":275,"dataGaLocation":48},"/fr-fr/teamops/","teamops",{"title":277,"items":278},"Connecter",[279,284,289,294,299],{"text":280,"config":281},"Services GitLab",{"href":282,"dataGaName":283,"dataGaLocation":48},"/fr-fr/services/","services",{"text":285,"config":286},"Communauté",{"href":287,"dataGaName":288,"dataGaLocation":48},"/community/","community",{"text":290,"config":291},"Forum",{"href":292,"dataGaName":293,"dataGaLocation":48},"https://forum.gitlab.com/","forum",{"text":295,"config":296},"Événements",{"href":297,"dataGaName":298,"dataGaLocation":48},"/events/","events",{"text":300,"config":301},"Partenaires",{"href":302,"dataGaName":303,"dataGaLocation":48},"/partners/","partners",{"backgroundColor":305,"textColor":306,"text":307,"image":308,"link":312},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":309,"config":310},"carte promo The Source",{"src":311},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":313,"config":314},"Lire les articles les plus récents",{"href":315,"dataGaName":316,"dataGaLocation":48},"/fr-fr/the-source/","the source",{"text":318,"config":319,"lists":321},"Société",{"dataNavLevelOne":320},"company",[322],{"items":323},[324,329,335,337,342,347,352,357,362,367,372],{"text":325,"config":326},"À propos",{"href":327,"dataGaName":328,"dataGaLocation":48},"/fr-fr/company/","about",{"text":330,"config":331,"footerGa":334},"Emplois",{"href":332,"dataGaName":333,"dataGaLocation":48},"/jobs/","jobs",{"dataGaName":333},{"text":295,"config":336},{"href":297,"dataGaName":298,"dataGaLocation":48},{"text":338,"config":339},"Leadership",{"href":340,"dataGaName":341,"dataGaLocation":48},"/company/team/e-group/","leadership",{"text":343,"config":344},"Équipe",{"href":345,"dataGaName":346,"dataGaLocation":48},"/company/team/","team",{"text":348,"config":349},"Manuel",{"href":350,"dataGaName":351,"dataGaLocation":48},"https://handbook.gitlab.com/","handbook",{"text":353,"config":354},"Relations avec les investisseurs",{"href":355,"dataGaName":356,"dataGaLocation":48},"https://ir.gitlab.com/","investor relations",{"text":358,"config":359},"Centre de confiance",{"href":360,"dataGaName":361,"dataGaLocation":48},"/fr-fr/security/","trust center",{"text":363,"config":364},"Centre pour la transparence de l'IA",{"href":365,"dataGaName":366,"dataGaLocation":48},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":368,"config":369},"Newsletter",{"href":370,"dataGaName":371,"dataGaLocation":48},"/company/contact/","newsletter",{"text":373,"config":374},"Presse",{"href":375,"dataGaName":376,"dataGaLocation":48},"/press/","press",{"text":378,"config":379,"lists":380},"Nous contacter",{"dataNavLevelOne":320},[381],{"items":382},[383,386,391],{"text":55,"config":384},{"href":57,"dataGaName":385,"dataGaLocation":48},"talk to sales",{"text":387,"config":388},"Aide",{"href":389,"dataGaName":390,"dataGaLocation":48},"/support/","get help",{"text":392,"config":393},"Portail clients GitLab",{"href":394,"dataGaName":395,"dataGaLocation":48},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":397,"login":398,"suggestions":405},"Fermer",{"text":399,"link":400},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":401,"config":402},"gitlab.com",{"href":62,"dataGaName":403,"dataGaLocation":404},"search login","search",{"text":406,"default":407},"Suggestions",[408,411,416,418,423,428],{"text":77,"config":409},{"href":82,"dataGaName":410,"dataGaLocation":404},"GitLab Duo (AI)",{"text":412,"config":413},"Suggestions de code (IA)",{"href":414,"dataGaName":415,"dataGaLocation":404},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":24,"config":417},{"href":130,"dataGaName":24,"dataGaLocation":404},{"text":419,"config":420},"GitLab sur AWS",{"href":421,"dataGaName":422,"dataGaLocation":404},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":424,"config":425},"GitLab sur Google Cloud ",{"href":426,"dataGaName":427,"dataGaLocation":404},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":429,"config":430},"Pourquoi utiliser GitLab ?",{"href":90,"dataGaName":431,"dataGaLocation":404},"Why GitLab?",{"freeTrial":433,"mobileIcon":438,"desktopIcon":443},{"text":434,"config":435},"Commencer votre essai gratuit",{"href":436,"dataGaName":53,"dataGaLocation":437},"https://gitlab.com/-/trials/new/","nav",{"altText":439,"config":440},"Icône GitLab",{"src":441,"dataGaName":442,"dataGaLocation":437},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":439,"config":444},{"src":445,"dataGaName":442,"dataGaLocation":437},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":447,"mobileIcon":451,"desktopIcon":453},{"text":448,"config":449},"En savoir plus sur GitLab Duo",{"href":82,"dataGaName":450,"dataGaLocation":437},"gitlab duo",{"altText":439,"config":452},{"src":441,"dataGaName":442,"dataGaLocation":437},{"altText":439,"config":454},{"src":445,"dataGaName":442,"dataGaLocation":437},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":460,"_dir":42,"_draft":6,"_partial":6,"_locale":7,"title":461,"titleMobile":461,"button":462,"config":467,"_id":469,"_type":34,"_source":36,"_file":470,"_stem":471,"_extension":39},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant disponible en version bêta publique !",{"text":463,"config":464},"Essayer la version bêta",{"href":465,"dataGaName":466,"dataGaLocation":48},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":468},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":473,"_dir":42,"_draft":6,"_partial":6,"_locale":7,"data":474,"_id":679,"_type":34,"title":680,"_source":36,"_file":681,"_stem":682,"_extension":39},"/shared/fr-fr/main-footer",{"text":475,"source":476,"edit":482,"contribute":487,"config":492,"items":497,"minimal":670},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":477,"config":478},"Afficher le code source de la page",{"href":479,"dataGaName":480,"dataGaLocation":481},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":483,"config":484},"Modifier cette page",{"href":485,"dataGaName":486,"dataGaLocation":481},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":488,"config":489},"Veuillez contribuer",{"href":490,"dataGaName":491,"dataGaLocation":481},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":493,"facebook":494,"youtube":495,"linkedin":496},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[498,521,575,607,641],{"title":66,"links":499,"subMenu":504},[500],{"text":501,"config":502},"Plateforme DevSecOps",{"href":75,"dataGaName":503,"dataGaLocation":481},"devsecops platform",[505],{"title":208,"links":506},[507,511,516],{"text":508,"config":509},"Voir les forfaits",{"href":210,"dataGaName":510,"dataGaLocation":481},"view plans",{"text":512,"config":513},"Pourquoi choisir GitLab Premium ?",{"href":514,"dataGaName":515,"dataGaLocation":481},"/fr-fr/pricing/premium/","why premium",{"text":517,"config":518},"Pourquoi choisir GitLab Ultimate ?",{"href":519,"dataGaName":520,"dataGaLocation":481},"/fr-fr/pricing/ultimate/","why ultimate",{"title":522,"links":523},"Solutions",[524,529,532,534,539,544,548,551,554,559,561,563,565,570],{"text":525,"config":526},"Transformation digitale",{"href":527,"dataGaName":528,"dataGaLocation":481},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":530,"config":531},"Sécurité et conformité",{"href":156,"dataGaName":157,"dataGaLocation":481},{"text":141,"config":533},{"href":125,"dataGaName":126,"dataGaLocation":481},{"text":535,"config":536},"Développement agile",{"href":537,"dataGaName":538,"dataGaLocation":481},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":540,"config":541},"Transformation cloud",{"href":542,"dataGaName":543,"dataGaLocation":481},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":545,"config":546},"SCM",{"href":138,"dataGaName":547,"dataGaLocation":481},"source code management",{"text":24,"config":549},{"href":130,"dataGaName":550,"dataGaLocation":481},"continuous integration & delivery",{"text":180,"config":552},{"href":182,"dataGaName":553,"dataGaLocation":481},"value stream management",{"text":555,"config":556},"GitOps",{"href":557,"dataGaName":558,"dataGaLocation":481},"/fr-fr/solutions/gitops/","gitops",{"text":193,"config":560},{"href":195,"dataGaName":196,"dataGaLocation":481},{"text":198,"config":562},{"href":200,"dataGaName":201,"dataGaLocation":481},{"text":203,"config":564},{"href":205,"dataGaName":206,"dataGaLocation":481},{"text":566,"config":567},"Formation",{"href":568,"dataGaName":569,"dataGaLocation":481},"/fr-fr/solutions/education/","education",{"text":571,"config":572},"Services financiers",{"href":573,"dataGaName":574,"dataGaLocation":481},"/fr-fr/solutions/finance/","financial services",{"title":213,"links":576},[577,579,581,583,586,588,591,593,595,597,599,601,603,605],{"text":225,"config":578},{"href":227,"dataGaName":228,"dataGaLocation":481},{"text":230,"config":580},{"href":232,"dataGaName":233,"dataGaLocation":481},{"text":235,"config":582},{"href":237,"dataGaName":238,"dataGaLocation":481},{"text":240,"config":584},{"href":242,"dataGaName":585,"dataGaLocation":481},"docs",{"text":263,"config":587},{"href":265,"dataGaName":5},{"text":589,"config":590},"Histoires de réussite client",{"href":260,"dataGaLocation":481},{"text":258,"config":592},{"href":260,"dataGaName":261,"dataGaLocation":481},{"text":267,"config":594},{"href":269,"dataGaName":270,"dataGaLocation":481},{"text":280,"config":596},{"href":282,"dataGaName":283,"dataGaLocation":481},{"text":272,"config":598},{"href":274,"dataGaName":275,"dataGaLocation":481},{"text":285,"config":600},{"href":287,"dataGaName":288,"dataGaLocation":481},{"text":290,"config":602},{"href":292,"dataGaName":293,"dataGaLocation":481},{"text":295,"config":604},{"href":297,"dataGaName":298,"dataGaLocation":481},{"text":300,"config":606},{"href":302,"dataGaName":303,"dataGaLocation":481},{"title":318,"links":608},[609,611,613,615,617,619,621,625,630,632,634,636],{"text":325,"config":610},{"href":327,"dataGaName":320,"dataGaLocation":481},{"text":330,"config":612},{"href":332,"dataGaName":333,"dataGaLocation":481},{"text":338,"config":614},{"href":340,"dataGaName":341,"dataGaLocation":481},{"text":343,"config":616},{"href":345,"dataGaName":346,"dataGaLocation":481},{"text":348,"config":618},{"href":350,"dataGaName":351,"dataGaLocation":481},{"text":353,"config":620},{"href":355,"dataGaName":356,"dataGaLocation":481},{"text":622,"config":623},"Sustainability",{"href":624,"dataGaName":622,"dataGaLocation":481},"/sustainability/",{"text":626,"config":627},"Diversité, inclusion et appartenance (DIB)",{"href":628,"dataGaName":629,"dataGaLocation":481},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":358,"config":631},{"href":360,"dataGaName":361,"dataGaLocation":481},{"text":368,"config":633},{"href":370,"dataGaName":371,"dataGaLocation":481},{"text":373,"config":635},{"href":375,"dataGaName":376,"dataGaLocation":481},{"text":637,"config":638},"Déclaration de transparence sur l'esclavage moderne",{"href":639,"dataGaName":640,"dataGaLocation":481},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":378,"links":642},[643,646,648,650,655,660,665],{"text":644,"config":645},"Échanger avec un expert",{"href":57,"dataGaName":58,"dataGaLocation":481},{"text":387,"config":647},{"href":389,"dataGaName":390,"dataGaLocation":481},{"text":392,"config":649},{"href":394,"dataGaName":395,"dataGaLocation":481},{"text":651,"config":652},"Statut",{"href":653,"dataGaName":654,"dataGaLocation":481},"https://status.gitlab.com/","status",{"text":656,"config":657},"Conditions d'utilisation",{"href":658,"dataGaName":659},"/terms/","terms of use",{"text":661,"config":662},"Déclaration de confidentialité",{"href":663,"dataGaName":664,"dataGaLocation":481},"/fr-fr/privacy/","privacy statement",{"text":666,"config":667},"Préférences en matière de cookies",{"dataGaName":668,"dataGaLocation":481,"id":669,"isOneTrustButton":111},"cookie preferences","ot-sdk-btn",{"items":671},[672,674,677],{"text":656,"config":673},{"href":658,"dataGaName":659,"dataGaLocation":481},{"text":675,"config":676},"Politique de confidentialité",{"href":663,"dataGaName":664,"dataGaLocation":481},{"text":666,"config":678},{"dataGaName":668,"dataGaLocation":481,"id":669,"isOneTrustButton":111},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",[684],{"_path":685,"_dir":686,"_draft":6,"_partial":6,"_locale":7,"content":687,"config":691,"_id":693,"_type":34,"title":694,"_source":36,"_file":695,"_stem":696,"_extension":39},"/en-us/blog/authors/olivier-dupr","authors",{"name":19,"config":688},{"headshot":689,"ctfId":690},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750713474/cj6odchlpoqxbibenvye.png","4VIckvQsyfNxEtz4pM42aP",{"template":692},"BlogAuthor","content:en-us:blog:authors:olivier-dupr.yml","Olivier Dupr","en-us/blog/authors/olivier-dupr.yml","en-us/blog/authors/olivier-dupr",{"_path":698,"_dir":42,"_draft":6,"_partial":6,"_locale":7,"header":699,"eyebrow":700,"blurb":701,"button":702,"secondaryButton":706,"_id":708,"_type":34,"title":709,"_source":36,"_file":710,"_stem":711,"_extension":39},"/shared/fr-fr/next-steps","Commencez à livrer des logiciels de meilleurs qualité plus rapidement","Plus de 50 % des entreprises du classement Fortune 100 font confiance à GitLab","Découvrez comment la plateforme DevSecOps intelligente\n\n\npeut aider votre équipe.\n",{"text":50,"config":703},{"href":704,"dataGaName":53,"dataGaLocation":705},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":55,"config":707},{"href":57,"dataGaName":58,"dataGaLocation":705},"content:shared:fr-fr:next-steps.yml","Next Steps","shared/fr-fr/next-steps.yml","shared/fr-fr/next-steps",1759347879310]