[{"data":1,"prerenderedAt":876},["ShallowReactive",2],{"/en-us/blog/tags/ci/":3,"navigation-fr-fr":20,"banner-fr-fr":441,"footer-fr-fr":454,"CI-tag-page-fr-fr":665},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/ci","tags",false,"",{"tag":9,"tagSlug":10},"CI","ci",{"template":12},"BlogTag","content:en-us:blog:tags:ci.yml","yaml","Ci","content","en-us/blog/tags/ci.yml","en-us/blog/tags/ci","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":437,"_type":14,"title":438,"_source":16,"_file":439,"_stem":440,"_extension":19},"/shared/fr-fr/main-navigation","fr-fr",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":378,"minimal":414,"duo":428},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/fr-fr/","gitlab logo","header",{"text":30,"config":31},"Commencer un essai gratuit",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Contacter l'équipe commerciale",{"href":37,"dataGaName":38,"dataGaLocation":28},"/fr-fr/sales/","sales",{"text":40,"config":41},"Connexion",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,299,359],{"text":46,"config":47,"cards":49,"footer":72},"Plateforme",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"La plateforme DevSecOps alimentée par l'IA la plus complète",{"text":53,"config":54},"Découvrir notre plateforme",{"href":55,"dataGaName":48,"dataGaLocation":28},"/fr-fr/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (IA)","Créez des logiciels plus rapidement en tirant parti de l'IA à chaque étape du développement",{"text":60,"config":61},"Découvrez GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/fr-fr/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Choisir GitLab","10 raisons pour lesquelles les entreprises choisissent GitLab",{"text":68,"config":69},"En savoir plus",{"href":70,"dataGaName":71,"dataGaLocation":28},"/fr-fr/why-gitlab/","why gitlab",{"title":73,"items":74},"Démarrer avec",[75,80,85],{"text":76,"config":77},"Ingénierie de plateforme",{"href":78,"dataGaName":79,"dataGaLocation":28},"/fr-fr/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Expérience développeur",{"href":83,"dataGaName":84,"dataGaLocation":28},"/fr-fr/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/fr-fr/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produit",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Voir toutes les solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/fr-fr/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisation","CI/CD et automatisation pour accélérer le déploiement",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/fr-fr/solutions/continuous-integration/",{"text":113,"config":114},"Développement assisté par l'IA",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Gestion du code source",{"href":119,"dataGaLocation":28,"dataGaName":120},"/fr-fr/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Livraison de logiciels automatisée",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Securité","Livrez du code plus rapidement sans compromettre la sécurité",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/fr-fr/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Sécurité de la chaîne d'approvisionnement logicielle",{"href":142,"dataGaLocation":28,"dataGaName":143},"/fr-fr/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Mesures",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/fr-fr/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Visibilité et mesures",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Gestion de la chaîne de valeur",{"href":163,"dataGaLocation":28,"dataGaName":164},"/fr-fr/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Données d'analyse et informations clés",{"href":168,"dataGaLocation":28,"dataGaName":169},"/fr-fr/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab pour",[173,178,183],{"text":174,"config":175},"Entreprises",{"href":176,"dataGaLocation":28,"dataGaName":177},"/fr-fr/enterprise/","enterprise",{"text":179,"config":180},"PME",{"href":181,"dataGaLocation":28,"dataGaName":182},"/fr-fr/small-business/","small business",{"text":184,"config":185},"Secteur public",{"href":186,"dataGaLocation":28,"dataGaName":187},"/fr-fr/solutions/public-sector/","public sector",{"text":189,"config":190},"Tarifs",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/fr-fr/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"Ressources",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Afficher toutes les ressources",{"href":200,"dataGaName":196,"dataGaLocation":28},"/fr-fr/resources/",[202,235,258],{"title":203,"items":204},"Premiers pas",[205,210,215,220,225,230],{"text":206,"config":207},"Installation",{"href":208,"dataGaName":209,"dataGaLocation":28},"/fr-fr/install/","install",{"text":211,"config":212},"Guides de démarrage rapide",{"href":213,"dataGaName":214,"dataGaLocation":28},"/fr-fr/get-started/","quick setup checklists",{"text":216,"config":217},"Apprentissage",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Documentation sur le produit",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Vidéos sur les bonnes pratiques",{"href":228,"dataGaName":229,"dataGaLocation":28},"/fr-fr/getting-started-videos/","best practice videos",{"text":231,"config":232},"Intégrations",{"href":233,"dataGaName":234,"dataGaLocation":28},"/fr-fr/integrations/","integrations",{"title":236,"items":237},"Découvrir",[238,243,248,253],{"text":239,"config":240},"Histoires de succès client",{"href":241,"dataGaName":242,"dataGaLocation":28},"/fr-fr/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":28},"/fr-fr/blog/","blog",{"text":249,"config":250},"Travail à distance",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/fr-fr/teamops/","teamops",{"title":259,"items":260},"Connecter",[261,266,271,276,281],{"text":262,"config":263},"Services GitLab",{"href":264,"dataGaName":265,"dataGaLocation":28},"/fr-fr/services/","services",{"text":267,"config":268},"Communauté",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Événements",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"Partenaires",{"href":284,"dataGaName":285,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","L'avenir du développement logiciel. Tendances et perspectives.",{"altText":291,"config":292},"carte promo The Source",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"Lire les articles les plus récents",{"href":297,"dataGaName":298,"dataGaLocation":28},"/fr-fr/the-source/","the source",{"text":300,"config":301,"lists":303},"Société",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"À propos",{"href":309,"dataGaName":310,"dataGaLocation":28},"/fr-fr/company/","about",{"text":312,"config":313,"footerGa":316},"Emplois",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"Leadership",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"Équipe",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"Manuel",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Relations avec les investisseurs",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Centre de confiance",{"href":342,"dataGaName":343,"dataGaLocation":28},"/fr-fr/security/","trust center",{"text":345,"config":346},"Centre pour la transparence de l'IA",{"href":347,"dataGaName":348,"dataGaLocation":28},"/fr-fr/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":360,"config":361,"lists":362},"Nous contacter",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":35,"config":366},{"href":37,"dataGaName":367,"dataGaLocation":28},"talk to sales",{"text":369,"config":370},"Aide",{"href":371,"dataGaName":372,"dataGaLocation":28},"/support/","get help",{"text":374,"config":375},"Portail clients GitLab",{"href":376,"dataGaName":377,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":379,"login":380,"suggestions":387},"Fermer",{"text":381,"link":382},"Pour rechercher des dépôts et des projets, connectez-vous à",{"text":383,"config":384},"gitlab.com",{"href":42,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Suggestions",[390,393,398,400,405,410],{"text":57,"config":391},{"href":62,"dataGaName":392,"dataGaLocation":386},"GitLab Duo (AI)",{"text":394,"config":395},"Suggestions de code (IA)",{"href":396,"dataGaName":397,"dataGaLocation":386},"/fr-fr/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":399},{"href":111,"dataGaName":109,"dataGaLocation":386},{"text":401,"config":402},"GitLab sur AWS",{"href":403,"dataGaName":404,"dataGaLocation":386},"/fr-fr/partners/technology-partners/aws/","GitLab on AWS",{"text":406,"config":407},"GitLab sur Google Cloud ",{"href":408,"dataGaName":409,"dataGaLocation":386},"/fr-fr/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":411,"config":412},"Pourquoi utiliser GitLab ?",{"href":70,"dataGaName":413,"dataGaLocation":386},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425},{"text":416,"config":417},"Commencer votre essai gratuit",{"href":418,"dataGaName":33,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"Icône GitLab",{"src":423,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"En savoir plus sur GitLab Duo",{"href":62,"dataGaName":432,"dataGaLocation":419},"gitlab duo",{"altText":421,"config":434},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":436},{"src":427,"dataGaName":424,"dataGaLocation":419},"content:shared:fr-fr:main-navigation.yml","Main Navigation","shared/fr-fr/main-navigation.yml","shared/fr-fr/main-navigation",{"_path":442,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":443,"titleMobile":443,"button":444,"config":449,"_id":451,"_type":14,"_source":16,"_file":452,"_stem":453,"_extension":19},"/shared/fr-fr/banner","La plateforme GitLab Duo Agent est maintenant disponible en version bêta publique !",{"text":445,"config":446},"Essayer la version bêta",{"href":447,"dataGaName":448,"dataGaLocation":28},"/fr-fr/gitlab-duo/agent-platform/","duo banner",{"layout":450},"release","content:shared:fr-fr:banner.yml","shared/fr-fr/banner.yml","shared/fr-fr/banner",{"_path":455,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":661,"_type":14,"title":662,"_source":16,"_file":663,"_stem":664,"_extension":19},"/shared/fr-fr/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":652},"Git est une marque déposée de Software Freedom Conservancy et notre utilisation de « GitLab » est sous licence",{"text":459,"config":460},"Afficher le code source de la page",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Modifier cette page",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Veuillez contribuer",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,557,589,623],{"title":46,"links":481,"subMenu":486},[482],{"text":483,"config":484},"Plateforme DevSecOps",{"href":55,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":189,"links":488},[489,493,498],{"text":490,"config":491},"Voir les forfaits",{"href":191,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Pourquoi choisir GitLab Premium ?",{"href":496,"dataGaName":497,"dataGaLocation":463},"/fr-fr/pricing/premium/","why premium",{"text":499,"config":500},"Pourquoi choisir GitLab Ultimate ?",{"href":501,"dataGaName":502,"dataGaLocation":463},"/fr-fr/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Solutions",[506,511,514,516,521,526,530,533,536,541,543,545,547,552],{"text":507,"config":508},"Transformation digitale",{"href":509,"dataGaName":510,"dataGaLocation":463},"/fr-fr/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sécurité et conformité",{"href":137,"dataGaName":138,"dataGaLocation":463},{"text":122,"config":515},{"href":105,"dataGaName":106,"dataGaLocation":463},{"text":517,"config":518},"Développement agile",{"href":519,"dataGaName":520,"dataGaLocation":463},"/fr-fr/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Transformation cloud",{"href":524,"dataGaName":525,"dataGaLocation":463},"/fr-fr/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":119,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":109,"config":531},{"href":111,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":161,"config":534},{"href":163,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/fr-fr/solutions/gitops/","gitops",{"text":174,"config":542},{"href":176,"dataGaName":177,"dataGaLocation":463},{"text":179,"config":544},{"href":181,"dataGaName":182,"dataGaLocation":463},{"text":184,"config":546},{"href":186,"dataGaName":187,"dataGaLocation":463},{"text":548,"config":549},"Formation",{"href":550,"dataGaName":551,"dataGaLocation":463},"/fr-fr/solutions/education/","education",{"text":553,"config":554},"Services financiers",{"href":555,"dataGaName":556,"dataGaLocation":463},"/fr-fr/solutions/finance/","financial services",{"title":194,"links":558},[559,561,563,565,568,570,573,575,577,579,581,583,585,587],{"text":206,"config":560},{"href":208,"dataGaName":209,"dataGaLocation":463},{"text":211,"config":562},{"href":213,"dataGaName":214,"dataGaLocation":463},{"text":216,"config":564},{"href":218,"dataGaName":219,"dataGaLocation":463},{"text":221,"config":566},{"href":223,"dataGaName":567,"dataGaLocation":463},"docs",{"text":244,"config":569},{"href":246,"dataGaName":247},{"text":571,"config":572},"Histoires de réussite client",{"href":241,"dataGaLocation":463},{"text":239,"config":574},{"href":241,"dataGaName":242,"dataGaLocation":463},{"text":249,"config":576},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":262,"config":578},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":254,"config":580},{"href":256,"dataGaName":257,"dataGaLocation":463},{"text":267,"config":582},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":584},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":586},{"href":279,"dataGaName":280,"dataGaLocation":463},{"text":282,"config":588},{"href":284,"dataGaName":285,"dataGaLocation":463},{"title":300,"links":590},[591,593,595,597,599,601,603,607,612,614,616,618],{"text":307,"config":592},{"href":309,"dataGaName":302,"dataGaLocation":463},{"text":312,"config":594},{"href":314,"dataGaName":315,"dataGaLocation":463},{"text":320,"config":596},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":598},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":600},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":335,"config":602},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":604,"config":605},"Sustainability",{"href":606,"dataGaName":604,"dataGaLocation":463},"/sustainability/",{"text":608,"config":609},"Diversité, inclusion et appartenance (DIB)",{"href":610,"dataGaName":611,"dataGaLocation":463},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":613},{"href":342,"dataGaName":343,"dataGaLocation":463},{"text":350,"config":615},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":355,"config":617},{"href":357,"dataGaName":358,"dataGaLocation":463},{"text":619,"config":620},"Déclaration de transparence sur l'esclavage moderne",{"href":621,"dataGaName":622,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":360,"links":624},[625,628,630,632,637,642,647],{"text":626,"config":627},"Échanger avec un expert",{"href":37,"dataGaName":38,"dataGaLocation":463},{"text":369,"config":629},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":374,"config":631},{"href":376,"dataGaName":377,"dataGaLocation":463},{"text":633,"config":634},"Statut",{"href":635,"dataGaName":636,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":638,"config":639},"Conditions d'utilisation",{"href":640,"dataGaName":641},"/terms/","terms of use",{"text":643,"config":644},"Déclaration de confidentialité",{"href":645,"dataGaName":646,"dataGaLocation":463},"/fr-fr/privacy/","privacy statement",{"text":648,"config":649},"Préférences en matière de cookies",{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,659],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":463},{"text":657,"config":658},"Politique de confidentialité",{"href":645,"dataGaName":646,"dataGaLocation":463},{"text":648,"config":660},{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":91},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",{"allPosts":666,"featuredPost":853,"totalPagesCount":874,"initialPosts":875},[667,695,718,742,765,785,808,831],{"_path":668,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":669,"content":677,"config":688,"_id":691,"_type":14,"title":692,"_source":16,"_file":693,"_stem":694,"_extension":19},"/fr-fr/blog/ci-deployment-and-environments",{"title":670,"description":671,"ogTitle":670,"ogDescription":671,"noIndex":6,"ogImage":672,"ogUrl":673,"ogSiteName":674,"ogType":675,"canonicalUrls":673,"schema":676},"Comment déployer du code dans des environnements multiples avec GitLab CI","GitLab CI est à la fois puissant et polyvalent. Découvrez les capacités de cet outil à travers plusieurs scénarios d'utilisation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662033/Blog/Hero%20Images/intro.jpg","https://about.gitlab.com/blog/ci-deployment-and-environments","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Comment déployer du code dans des environnements multiples avec GitLab CI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ivan Nemytchenko\"},{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2021-02-05\",\n      }",{"title":670,"description":671,"authors":678,"heroImage":672,"date":681,"body":682,"category":683,"tags":684,"updatedDate":687},[679,680],"Ivan Nemytchenko","Cesar Saavedra","2021-02-05","Imaginez-vous gestionnaire d’un site d'information. Heureusement, le code de\nvotre projet est déjà hébergé sur GitLab.com et vous utilisez [GitLab\nCI/CD](https://docs.gitlab.com/ee/ci/testing/ \"Test avec GitLab CI/CD\") pour\nvos tests. Maintenant, vous souhaitez connaître toutes les possibilités de\n[déploiement](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/\n\"Meilleures pratiques CI/CD\").\n\n\nPar souci de pertinence, supposons que l'application se compose uniquement\nde fichiers HTML, sans code côté serveur ni compilation sophistiquée des\nactifs JS. La plateforme de destination sera également générique, nous\nutiliserons [Amazon S3](https://aws.amazon.com/fr/s3/ \"Amazon S3\").\n\n\nPlutôt que de fournir des extraits de code à copier-coller, nous allons vous\npartager les principes et les fonctionnalités de GitLab CI, afin que vous\npuissiez les appliquer dans votre propre pile technologique. \n\n\nDéroulons donc notre histoire depuis son commencement, où il n'est pas\nencore question d'intégration continue.\n\n\n## La ligne de départ\n\n\n__Déploiement__ : un ensemble de fichiers HTML devraient apparaître dans\nvotre bucket S3 (déjà configuré pour [héberger un site web\nstatique](https://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/HostingWebsiteOnS3Setup.html\n\"Héberger un site web statique avec Amazon S3\")). Il y a des millions de\nfaçons de procéder. Dans notre cas, nous utiliserons la bibliothèque [AWS\nCLI](https://aws.amazon.com/fr/cli/ \"AWS CLI\") fournie par Amazon. \n\n\nLa commande complète ressemble à ceci :\n\n\n```shell\n\naws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n\n```\n\n\nLe push du code vers le dépôt et le déploiement sont deux processus\ndistincts.\n\n\n![Déploiement\nmanuel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/19-updated.png){:\n.center}\n\n{: .note .text-center}\n\n\nDétail important : la commande nécessite de [fournir les variables\nd'environnement](https://docs.aws.amazon.com/fr_fr/cli/latest/userguide/cli-chap-getting-started.html)\n`AWS_ACCESS_KEY_ID` et `AWS_SECRET_ACCESS_KEY`. Il vous faudra peut-être\naussi spécifier `AWS_DEFAULT_REGION`. \n\n\nEssayons d'automatiser cette procédure avec [l'intégration continue de\nGitLab](https://about.gitlab.com/fr-fr/solutions/continuous-integration/\n\"Intégration continue de GitLab\").\n\n\n## Votre premier déploiement automatisé\n\n\nGitLab CI offre une grande flexibilité dans l'exécution des commandes. Sa\nconfiguration s'adapte à vos besoins, reproduisant l'environnement de votre\nterminal local. Ajoutez votre script dans le fichier .gitlab-ci.yml et\neffectuez un push de votre code : l’outil d'intégration continue de GitLab\ndéclenche un *job* et vos commandes sont exécutées.\n\n\nPrécisons maintenant le contexte d'utilisation de cet exemple : il s'agit\nd'un site de taille modeste, avec une trentaine de visiteurs journaliers, et\nune seule branche principale de dépôt de code. Commençons par spécifier un\n*job* avec la commande précédente dans le fichier `.gitlab-ci.yml` :\n\n\n```yaml\n\ndeploy:\n  script: aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\nOups, la commande a échoué :\n\n\n![Message d'erreur lors de l'exécution d'un job\nGitLab.](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/13.jpg){:\n.shadow}\n\n\nIl fallait d'abord vérifier l'existence d'un exécutable `aws`. Pour\ninstaller `awscli`, nous avons besoin de `pip`, qui est un outil\nd'installation de paquets Python. Spécifions une image Docker avec Python\npréinstallé, qui devrait également contenir `pip` : \n\n\n```yaml\n\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\n![Déploiement\nautomatisé](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/fail1.png){:\n.center}\n\n{: .note .text-center}\n\n\nVous effectuez un push de votre code sur GitLab, et il est automatiquement\ndéployé par l’outil CI. \n\n\nL'installation d'`awscli` rallonge le temps d'exécution du job, mais pour\nl'instant ce n'est pas un souci. Pour accélérer le processus, [cherchez une\nimage Docker](https://hub.docker.com/ \"Chercher une image Docker\") avec\n`awscli` préinstallé, ou créez une image vous-même. \n\n\nN’oublions pas les variables d'environnement récupérées depuis la [console\nAWS](https://console.aws.amazon.com/) :\n\n\n```yaml\n\nvariables:\n  AWS_ACCESS_KEY_ID: \"AKIAIOSFODNN7EXAMPLE\"\n  AWS_SECRET_ACCESS_KEY: \"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\"\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\nCela devrait fonctionner, mais attention : ce n'est jamais une bonne idée de\ndévoiler des clés secrètes de votre code, même dans un dépôt privé.\nRemédions donc à cette situation.\n\n\n### Des secrets bien gardés\n\n\nGitLab dispose d’un endroit spécialement dédié aux variables secrètes :\n__Paramètres > CI/CD > Variables__.\n\n\n![Ajouter une variable secrète dans\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/add-variable-updated.png)\n\n\nTout ce que vous y mettez se transforme en variables d'environnement. En\ncochant la case « Masquée », vous masquerez la variable dans les job logs.\nEn cochant la case « Protéger la variable », vous n’exporterez la variable\nuniquement vers les pipelines s'exécutant sur des branches et des étiquettes\nprotégées. \n\n\nSeuls les utilisateurs ayant le statut de propriétaire ou de chargé de\nmaintenance sur un projet auront accès à cette section. Nous pourrions\nsupprimer la section `variables` de notre configuration CI, mais nous allons\nl'utiliser à d'autres fins.\n\n\n### Savoir spécifier et utiliser des variables non-secrètes\n\n\nLorsque votre configuration s'agrandit, il devient pratique de conserver\ncertains paramètres sous formes de variables au début de votre\nconfiguration. Le cas présent ne le justifie pas, mais pour les besoins de\ncette démonstration, nous allons définir le nom du compartiment S3 comme\nvariable :\n\n\n```yaml\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\nJusqu'ici, tout va bien :\n\n\n![Compilation GitLab CI sans\nerreur](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/14.jpg){:\n.shadow.medium.center}\n\n\nDans notre scénario, la fréquentation du site est en hausse, et vous avez\nembauché un développeur pour vous aider. Voyons comment le workflow GitLab\nCI s'adapte au travail en équipe.\n\n\n## Comment utiliser GitLab CI en équipe\n\n\nAvec deux utilisateurs travaillant dans le même dépôt, il n'est plus\npratique d'utiliser la branche principale pour le développement. Vous\ndécidez d'utiliser des branches séparées pour les nouvelles fonctionnalités\net les nouveaux articles, et de les fusionner dans la branche principale\nlorsqu'elles sont prêtes.\n\n\nCependant, votre configuration CI actuelle ne prend pas en charge les\nbranches. Chaque push effectué vers GitLab sera déployé sur S3. La solution\nest simple : il suffit d'ajouter `only: main` au job `deploy`.\n\n\nEn plus de ne pas vouloir déployer chaque branche sur l’environnement de\nproduction, vous souhaiteriez pouvoir prévisualiser vos modifications depuis\nles branches de fonctionnalités. \n\n\n![Déploiement de la branche principale de GitLab vers AWS\nS3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/15-updated.png){:\n.center}\n\n{: .note .text-center}  \n\n\n### Comment configurer un environnement de test ?\n\n\nMatteo, votre nouveau développeur, vous propose d'utiliser la fonctionnalité\n[GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/ \"GitLab\nPages\"), idéale pour prévisualiser votre travail en cours. Afin d'[héberger\ndes sites web sur GitLab\nPages](https://docs.gitlab.com/ee/user/project/pages/getting_started/pages_ui.html\n\"Héberger des sites web sur GitLab Pages\"), votre fichier de configuration\nCI doit répondre à trois règles simples :\n\n\n- Le *job* doit être nommé `pages`\n\n- Il doit y avoir une section `artifacts` avec un dossier `public`\n\n- Tout ce que vous souhaitez héberger doit être placé dans le dossier\n`public`\n\n\nLe contenu du dossier public sera hébergé à l'adresse suivante :\n`http://\u003Cusername>.gitlab.io/\u003Cprojectname>/`\n\n\nVoici la configuration complète après avoir appliqué l’[exemple de\nconfiguration pour les sites web en\nHTML](https://gitlab.com/pages/plain-html/-/blob/main/.gitlab-ci.yml\n\"Exemple de configuration pour les sites web en HTML\") :\n\n\n```yaml\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n  only:\n  - main\n\npages:\n  image: alpine:latest\n  script:\n  - mkdir -p ./public\n  - cp ./*.html ./public/\n  artifacts:\n    paths:\n    - public\n  except:\n  - main\n```\n\n\nNous avons spécifié deux jobs. L'un d'eux déploie le site web pour vos\nclients sur S3 (`deploy`). L'autre (`pages`) déploie le site web sur GitLab\nPages. Nommons-les « Environnement de production » et « Environnement de\npréproduction ». Toutes les branches seront déployées sur GitLab Pages, à\nl'exception de la branche principale. \n\n\n![Déploiement différencié des branches dans GitLab Pages et\nS3.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/16-updated.png){:\n.center}\n\n{: .note .text-center}\n\n\n## Introduction aux environnements\n\n\nGitLab offre la prise en charge de [nombreux\nenvironnements](https://docs.gitlab.com/ee/ci/environments/ \"Environnements\nGitLab\") (dynamiques ou statiques) ; vous devez simplement spécifier\nl'environnement correspondant pour chaque *job* de déploiement :\n\n\n```yaml\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy to production:\n  environment: production\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n  only:\n  - main\n\npages:\n  image: alpine:latest\n  environment: staging\n  script:\n  - mkdir -p ./public\n  - cp ./*.html ./public/\n  artifacts:\n    paths:\n    - public\n  except:\n  - main\n```\n\n\nGitLab garde une trace de tous vos déploiements. Ainsi, vous savez toujours\nce qui est actuellement déployé sur vos serveurs :\n\n\n![Visualisation des environnements sur GitLab\nCI/CD.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/envs-updated.png){:\n.shadow.center}\n\n\nL'historique complet de vos déploiements sur chacun de vos environnements\nactuels vous est aussi fourni :\n\n\n![Historique des déploiements\nGitLab.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/staging-env-detail-updated.png){:\n.shadow.center}\n\n\nMaintenant que tout est automatisé et configuré, de nouveaux défis nous\nattendent.\n\n\n## Comment dépanner les déploiements ?\n\n\nOups ! La branche de fonctionnalités que vous avez poussé sur\nl'environnement de préproduction vient d'être remplacée par celle de Matteo,\nqui vient d'effectuer un push de sa propre branche. L'énervement vous gagne,\nc'est la troisième fois que cela arrive aujourd'hui ! \n\n\nEt si vous utilisiez Slack pour notifier vos déploiements, afin d'éviter ce\ngenre de désagrément ?\n\n\n> Recevez des notifications en utilisant l'[application GitLab pour\nSlack](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html).\n\n\n## Du travail d'équipe à grande échelle\n\n\nQuelque temps plus tard, et vous voilà à la tête d'un site web très\npopulaire, et d'une équipe de huit personnes. Mais, désormais, les membres\nde votre équipe perdent un temps précieux à attendre de pouvoir\nprévisualiser leur travail. Le déploiement de chaque branche en\npréproduction n'est plus optimal.\n\n\n![File d'attente de branches à examiner en\npréproduction](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/build.png){:\n.center}\n\n\nIl est temps de perfectionner le système. Vous convenez avec votre équipe de\nfusionner au préalable chaque changement sur la branche de préproduction. La\nmodification du fichier `.gitlab-ci.yml` est minime :\n\n\n```yaml\n\nexcept:\n\n- main\n\n```\n\n\nest remplacé par\n\n\n```yaml\n\nonly:\n\n- staging\n\n```\n\n\n![Dessin de développeurs qui fusionnent leurs changements dans une branche\nde préproduction avant de les déployer sur\nS3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/17-updated.png){:\n.center}\n\n{: .note .text-center}\n\n\nVos collaborateurs doivent fusionner leurs branches de fonctionnalités avant\nde prévisualiser leur travail en préproduction. Cela nécessite plus de temps\net d'efforts, mais tout le monde s'accorde à dire que c'est toujours mieux\nque d'attendre.\n\n\n## Comment gérer les urgences ?\n\n\nIl arrive parfois que les choses tournent mal. Quelqu'un a mal fusionné des\nbranches et a effectué un push du résultat directement en production, juste\nau moment où le hashtag de votre site devenait viral sur les réseaux\nsociaux. Des milliers de personnes voient des visuels cassés au lieu de\nvotre page d'accueil habituelle. Heureusement, la fonction __Restaurer\nl’environnement__ a permis de résoudre le problème en moins d'une minute.\n\n\n![Fonctionnalité de restauration sur la plateforme\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/18-updated.png){:\n.shadow.center}\n\n{: .note .text-center}\n\n\nLa fonction de restauration de l'environnement relance le job précédent avec\nla validation précédente. Vous avez décidé de désactiver le déploiement\nautomatique en production et de passer au déploiement manuel. Pour ce faire,\nvous devez ajouter  `when : manual` à votre *job*. Il n'y aura effectivement\nplus de déploiement automatique en production. Le déploiement manuel\ns'effectue en allant dans __Compilation > Pipelines__, et en cliquant sur\n__« Exécuter des jobs manuels ou différés »__ :\n\n\n![Déploiement manuel sur\nGitLab.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/prod-env-rollback-arrow-updated.png){:\n.shadow.center}\n\n\nEffectuons maintenant un bond en avant dans le temps. Votre entreprise est\ndevenue une société de plusieurs centaines d'employés travaillant sur le\nsite web, et les compromis précédents ne fonctionnent plus.\n\n\n### Faire ses premiers pas avec les Review Apps\n\n\nLogiquement, la nouvelle étape consiste à lancer une instance temporaire de\nl'application par branche de fonctionnalités pour la revue. Pour cela, nous\navons configuré un autre bucket S3. Sa seule particularité est que le\ncontenu du site est placé dans un dossier portant le nom de la branche de\ndéveloppement, de sorte que l’URL ressemble à :\n\n\n`http://\u003CREVIEW_S3_BUCKET_NAME>.s3-website-us-east-1.amazonaws.com/\u003Cbranchname>/`\n\n\nVoici le remplacement du *job* `pages` utilisé auparavant :\n\n\n```yaml\n\nreview apps:\n  variables:\n    S3_BUCKET_NAME: \"reviewbucket\"\n  image: python:latest\n  environment: review\n  script:\n  - pip install awscli\n  - mkdir -p ./$CI_BUILD_REF_NAME\n  - cp ./*.html ./$CI_BUILD_REF_NAME/\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n\nIci, il est bon de connaître l'origine de cette variable\n`$CI_BUILD_REF_NAME`. GitLab prédéfinit de [nombreuses variables\nd'environnement](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html\n\"Variables d'environnement dans GitLab\") à utiliser dans vos jobs. Notez que\nnous avons défini la variable `S3_BUCKET_NAME` à l'intérieur du *job*. Vous\npouvez ainsi réécrire les définitions de niveau supérieur. \n\n\nReprésentation visuelle de la configuration des Review Apps :\n\n\n![Dessin représentant la configuration Review Apps de\nGitLab.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/manual-pipeline-arrow-updated.png){:\n.illustration}\n\n\nLes détails de l'implémentation des Review Apps varient selon votre pile\ntechnologique et de votre processus de déploiement. Tout ne sera pas aussi\nsimple qu'avec un site HTML statique. Programmer des instances temporaires à\nla volée avec tous les logiciels et services requis n'est pas chose aisée.\nMais tout cela peut être accompli, notamment à l'aide des conteneurs Docker,\nChef ou Ansible.\n\n\nLe déploiement avec Docker mériterait d'ailleurs un article complet. Et si\nvous regrettez l'absence de scénarios plus complexes qu'un simple\ndéploiement en HTML statique, nous vous recommandons de lire [cet\narticle](https://about.gitlab.com/blog/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/\n\"Construire une version d'Elixir dans une image Docker en utilisant GitLab\nCI - Partie 1\"). Abordons maintenant un dernier sujet.\n\n\n### Déployer sur différentes plateformes\n\n\nDans la pratique, nous ne sommes pas limités à S3 et à GitLab Pages. Nous\nhébergeons et déployons nos applications sur différents services. De plus,\nsi vous décidez un jour de passer à une nouvelle plateforme, vous devrez\nalors réécrire tous vos scripts de déploiement. Vous pourrez alors utiliser\nune petite merveille appelée `dpl` pour vous faciliter la tâche.\n\n\nJusqu'ici, nous avons utilisé `awscli` pour livrer du code à un service\ncomme Amazon S3. Quel que soit le système utilisé, le principe reste le même\n: vous exécutez une commande avec certains paramètres et transmettez une clé\nsecrète d'authentification. L'outil de déploiement `dpl` utilise ce principe\net fournit une interface unique pour cette [liste de\nfournisseurs](https://github.com/travis-ci/dpl#supported-providers \"Liste de\nfournisseurs\"). Voici à quoi ressemblerait le déploiement d’un *job* en\nproduction avec `dpl`:\n\n\n```yaml\n\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy to production:\n  environment: production\n  image: ruby:latest\n  script:\n  - gem install dpl\n  - dpl --provider=s3 --bucket=$S3_BUCKET_NAME\n  only:\n  - main\n```\n\n\nEn cas de déploiement sur plusieurs systèmes ou de changements fréquents de\nplateforme de destination, `dpl` vous aide à uniformiser vos scripts de\ndéploiement.\n\n\n## Cinq points clés à retenir\n\n\n1. Un déploiement est une commande (ou un ensemble de commandes)\nrégulièrement exécutée. Il peut donc être exécuté dans GitLab CI.\n\n\n2. La plupart des commandes à exécuter nécessitent de fournir une ou\nplusieurs clés secrètes, que vous stockez dans __Paramètres >\n[CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD\n?\") > Variables__.\n\n\n3. Avec GitLab CI, vous pouvez spécifier de façon flexible les branches vers\nlesquelles vous déployez votre code.\n\n\n4. GitLab conserve l'historique des déploiements dans tous vos\nenvironnements, et vous permet de revenir à n'importe quelle version\nprécédente.\n\n\n5. Pour les éléments critiques de votre infrastructure, vous pouvez activer\nle déploiement manuel depuis l'interface de GitLab, au lieu du déploiement\nautomatisé.\n","engineering",[9,685,686],"CD","tutorial","2024-11-21",{"slug":689,"featured":6,"template":690},"ci-deployment-and-environments","BlogPost","content:fr-fr:blog:ci-deployment-and-environments.yml","Ci Deployment And Environments","fr-fr/blog/ci-deployment-and-environments.yml","fr-fr/blog/ci-deployment-and-environments",{"_path":696,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":697,"content":703,"config":712,"_id":714,"_type":14,"title":715,"_source":16,"_file":716,"_stem":717,"_extension":19},"/fr-fr/blog/demystifying-ci-cd-variables",{"title":698,"description":699,"ogTitle":698,"ogDescription":699,"noIndex":6,"ogImage":700,"ogUrl":701,"ogSiteName":674,"ogType":675,"canonicalUrls":701,"schema":702},"Variables d’environnement : tout savoir sur les variables CI/CD de GitLab","Les variables CI/CD permettent de contrôler les jobs et les pipelines. Découvrez tout ce que vous devez savoir sur les variables d'environnement de GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664679/Blog/Hero%20Images/blog-image-template-1800x945__24_.png","https://about.gitlab.com/blog/demystifying-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Variables d’environnement : tout savoir sur les variables CI/CD de GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2021-04-09\",\n      }",{"title":698,"description":699,"authors":704,"heroImage":700,"date":706,"body":707,"category":683,"tags":708,"updatedDate":711},[705],"Veethika Mishra","2021-04-09","Définir et utiliser des variables dans le cadre d'une approche [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/) s'avère une méthode très flexible. Ces variables sont d'une grande utilité pour contrôler les jobs et les pipelines, tout en vous permettant d'éviter de coder en dur des valeurs directement dans votre fichier de configuration `.gitlab-ci.yml`. \n\nDans [GitLab CI/CD](https://docs.gitlab.com/ee/ci/), les variables peuvent être utilisées pour personnaliser les jobs en définissant et en stockant des valeurs spécifiques. Pour définir vos variables CI/CD dans GitLab, accédez à **Paramètres >> CI/CD >> Variables** ou définissez-les simplement dans le fichier `.gitlab-ci.yml`. Sachez que les variables servent également d'alternative aux valeurs codées en dur.\n\nUtiliser des variables s’avère particulièrement utile pour configurer des services tiers dans différents environnements de déploiement, tels que l'environnement de test (`testing`), l'environnement de préproduction (`staging`), l'environnement de production (`production`), et plus encore. Pour modifier les services liés à ces environnements, il suffit de changer simplement la variable qui pointe vers le point de terminaison d'API associé aux services. Vous pouvez également utiliser des variables pour configurer les jobs et les rendre disponibles en tant que variables d'environnement dans les jobs lorsqu'ils s'exécutent.\n\nDécouvrez dans cet article tout ce que vous devez savoir sur les variables d’environnement afin de mieux comprendre leur fonctionnement et leur portée. \n\n![GitLab lit le fichier .gitlab-ci.yml pour analyser la variable référencée, puis envoie les informations à GitLab Runner. Les variables sont exposées et générées par le runner.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_processing.jpeg)\n\n## La relation entre les variables et les environnements\n\nLe processus de développement logiciel comprend plusieurs étapes destinées à tester un produit avant de le déployer et de le mettre à disposition des utilisateurs. Les [environnements](https://docs.gitlab.com/ee/ci/environments/) sont utilisés pour définir ces étapes, qui peuvent différer d'une équipe à l'autre, voire d'une entreprise à l'autre.\n\nLes variables, quant à elles, sont des valeurs de données susceptibles de changer à la suite d'une interaction entre un utilisateur et un produit. Par exemple, son âge, ses préférences ou toute autre information qui pourrait déterminer l'étape suivante qui lui sera présentée dans le flux de tâches du produit.\n\nLe terme [variable d'environnement](https://docs.gitlab.com/ee/administration/environment_variables.html) fait souvent référence à des variables définies dans un environnement donné, mais en dehors de l'application. Les variables dans GitLab CI/CD offrent aux équipes de développement la possibilité de configurer des valeurs dans le code. L'intérêt principal étant de garantir sa flexibilité. Ces variables permettent aux utilisateurs de modifier une application déployée dans un certain environnement sans toucher au code. Il est possible d'exécuter des tests en toute simplicité ou même d'intégrer des services tiers en modifiant une variable d'environnement de configuration en dehors de l'application.\n\n## La portée des variables dans l'approche CI/CD\n\n![Ordre de priorité des variables CI/CD : 1) Exécution manuelle du pipeline, variables de déclenchement et de planification du pipeline, 2) Variables protégées au niveau du projet, au niveau du groupe et au niveau de l'instance, 3) Variables CI/CD héritées, 4) Variables globales définies dans yml au niveau du job, 5) Variables de déploiement, 6) Variables CI/CD prédéfinies](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_precedence.jpeg)\n\n### Variables définies dans `.gitlab-ci.yml`\n\nLes variables qui doivent être disponibles dans l'environnement du job peuvent être ajoutées à GitLab. Ces variables CI/CD stockent la configuration du projet ne contenant pas de données sensibles, comme l'URL de la base de données dans le fichier `.gitlab-ci.yml`. Réutilisez cette variable dans plusieurs jobs ou scripts, là où la valeur est nécessaire. Si la valeur change, vous n'avez besoin de mettre à jour la variable qu'une seule fois. Le changement se reflète ensuite partout où la variable est utilisée.\n\n### Variables CI/CD au niveau du projet\n\nUn cran au-dessus des exigences spécifiques au dépôt, vous pouvez définir des variables CI/CD dans les [paramètres du projet](https://docs.gitlab.com/ee/ci/variables/#for-a-project), afin qu'elles soient disponibles dans les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"). Celles-ci sont stockées en dehors du dépôt (c'est-à-dire qu'elles ne figurent pas dans le fichier `.gitlab-ci.yml`), mais peuvent néanmoins être utilisées dans les scripts et la configuration CI/CD. Le stockage des variables en dehors du fichier `.gitlab-ci.yml` limite ces valeurs à la portée du projet uniquement, sans les enregistrer en texte brut dans le projet.\n\n### Variables CI/CD au niveau du groupe et de l'instance\n\nCertaines variables sont pertinentes à l'échelle du groupe ou de l'instance et peuvent être utiles à tous les projets associés à un groupe ou à une instance spécifique. Définissez les variables dans les [paramètres du groupe ou de l'instance](https://docs.gitlab.com/ee/ci/variables/#for-a-group) afin que tous les projets de ces portées puissent utiliser les variables sans avoir besoin d'en connaître la valeur ou de les recréer pour chaque projet de portée inférieure. Par exemple, une valeur commune à plusieurs projets se gère facilement si elle ne doit être mise à jour qu'à un seul endroit. Alternativement, plusieurs projets peuvent utiliser un mot de passe spécifique sans avoir besoin de connaître la valeur du mot de passe lui-même.\n\n## Jobs et pipelines en tant qu'environnements\n\nEn plus d'être utilisées comme des variables d'environnement, les variables dans GitLab CI/CD fonctionnent également dans la portée du fichier de configuration `.gitlab-ci.yml` pour définir le comportement du pipeline, indépendamment de son environnement. Les variables peuvent être stockées dans les paramètres du projet/groupe/instance et mises à la disposition des jobs dans les pipelines.\n\nPar exemple :\n\n```  \njob:  \n  rules:  \n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  \n  script:  \n  - echo \"This job ran on the $CI_COMMIT_BRANCH branch.\"  \n```\n\nLa variable `($CI_COMMIT_BRANCH)` dans la section du script s'exécute dans la portée du job dans lequel elle a été définie. Cette portée est l'« environnement du job », ce qui signifie que lorsque le job se lance, le GitLab Runner démarre un conteneur Docker et exécute le job dans cet environnement. Le runner met cette variable (et toutes les autres variables prédéfinies ou personnalisées) à la disposition du job et peut également afficher leur valeur dans les données de sortie du log si nécessaire.\n\nToutefois, la variable est aussi utilisée dans la section `if:` pour déterminer quand le job doit s'exécuter. Il ne s'agit pas en soi d'un environnement, c'est pourquoi nous les appelons variables CI/CD. Elles peuvent être utilisées pour configurer dynamiquement vos jobs CI/CD, ainsi que comme variables d'environnement lorsque le job est en cours d'exécution.\n\n## Variables prédéfinies\n\nUn certain nombre de variables sont [prédéfinies](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) lorsqu'un pipeline GitLab CI/CD démarre. Un utilisateur peut immédiatement accéder aux valeurs pour des éléments tels que les validations, le projet ou les détails du pipeline sans avoir à définir les variables elles-mêmes.\n\n## Variables CI/CD personnalisées\n\n![Les runners peuvent créer deux types de variables CI/CD personnalisées : Type et Fichier.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variable_types.jpeg)\n\nLors de la création d'une variable CI/CD dans les paramètres, GitLab offre à l'utilisateur plus d'options pour configurer la variable. Utilisez ces options de configuration supplémentaires pour exercer un contrôle plus strict sur les variables plus sensibles :\n\n**Portée de l'environnement :** si une variable ne doit être utilisée que dans un environnement spécifique, définissez-la pour qu'elle soit disponible uniquement dans cet environnement. Par exemple, vous pouvez définir un jeton de déploiement pour qu'il ne soit disponible que dans l'environnement `production`.\n\n**Variables protégées :** comme pour la portée de l'environnement, vous pouvez définir une variable pour qu'elle ne soit disponible que lorsque le pipeline s'exécute sur une branche protégée, comme votre branche par défaut.\n\n**Type de variable :** certaines applications nécessitent que la configuration leur soit transmise sous la forme d'un fichier. Si une application nécessite cette configuration, définissez simplement le type de variable comme « Fichier ». Cette configuration de la variable CI/CD signifie que lorsque le runner rend la variable disponible dans l'environnement, il l'écrit dans un fichier temporaire et stocke le chemin d'accès au fichier en tant que valeur. Un utilisateur peut ensuite transmettre le chemin d'accès au fichier à toutes les applications qui en ont besoin.\n\nEn plus des éléments énumérés pour définir et utiliser les variables, GitLab a introduit une fonctionnalité qui génère des variables préremplies lorsqu'un pipeline doit être exécuté manuellement. Les variables préremplies réduisent les risques d'erreur et facilitent l'exécution du pipeline.\n\n**Variables masquées :** les [variables masquées](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable) sont des variables CI qui ont été **cachées dans les job logs** pour empêcher l'affichage de leur valeur.\n\n**Variables masquées et cachées :** introduites dans [GitLab 17.4](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/#hide-cicd-variable-values-in-the-ui), les variables [masquées et cachées](https://docs.gitlab.com/ee/ci/variables/#hide-a-cicd-variable) offrent la même fonctionnalité de masquage des job logs et **gardent la valeur cachée** **dans l'interface utilisateur des paramètres**. Nous ne recommandons pas d'utiliser ces deux types de variables pour les informations sensibles (comme les secrets), car elles peuvent être exposées par inadvertance.\n\n## Secrets\n\nUn secret est un identifiant de connexion sensible qui doit rester confidentiel. Voici des exemples de secrets :\n\n* Mots de passe\n* Clés SSH\n* Jetons d'accès\n* Tout autre type d'identifiants de connexion dont la divulgation pourrait porter préjudice à l'entreprise\n\nGitLab permet actuellement à ses utilisateurs d'[utiliser des secrets externes](https://docs.gitlab.com/ee/ci/secrets/) dans l'[intégration continue (CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue (CI) ?\"), en tirant parti de HashiCorp Vault, Google Cloud Secret Manager et Azure Key Vault pour gérer de manière sécurisée les clés, les tokens et d'autres secrets au niveau du projet. Les utilisateurs peuvent ainsi séparer ces secrets des autres variables CI/CD pour des raisons de sécurité.\n\n### Gestionnaire de secrets de GitLab\n\nEn plus de fournir une assistance pour les secrets externes dans la CI, GitLab prévoit également de proposer une [solution native de gestion des secrets](https://gitlab.com/groups/gitlab-org/-/epics/10108) permettant de stocker les secrets de manière pratique et sécurisée au sein de sa plateforme. Cette solution aidera également les clients à utiliser les secrets stockés dans les composants et les environnements spécifiques à GitLab, ainsi qu'à gérer facilement les accès au niveau des groupes d'espaces de nommage et des projets.\n\nPour en savoir plus sur le gestionnaire de secrets de GitLab, consultez notre article « [Le gestionnaire de secrets natif de GitLab renforce la sécurité de la chaîne d'approvisionnement logicielle](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/) ». \n\n***Avertissement :** cet article de blog contient des informations relatives aux produits, fonctionnalités et caractéristiques à venir. Il est important de noter que les informations contenues dans cet article de blog ne sont fournies qu'à titre informatif. Veuillez ne pas vous fier à ces informations à des fins d'achat ou de planification. Comme pour tout projet, les éléments mentionnés dans cet article sont susceptibles de changer ou d’être retardés. Le développement, la sortie et le calendrier de tout produit ou fonctionnalité restent à la seule discrétion de GitLab.*\n",[685,709,710,9,109,686],"features","inside GitLab","2025-01-28",{"slug":713,"featured":6,"template":690},"demystifying-ci-cd-variables","content:fr-fr:blog:demystifying-ci-cd-variables.yml","Demystifying Ci Cd Variables","fr-fr/blog/demystifying-ci-cd-variables.yml","fr-fr/blog/demystifying-ci-cd-variables",{"_path":719,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":720,"content":726,"config":736,"_id":738,"_type":14,"title":739,"_source":16,"_file":740,"_stem":741,"_extension":19},"/fr-fr/blog/ensuring-compliance",{"ogTitle":721,"schema":722,"ogImage":723,"ogDescription":724,"ogSiteName":674,"noIndex":6,"ogType":675,"ogUrl":725,"title":721,"canonicalUrls":725,"description":724},"Séparation des tâches et conformité avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Séparation des tâches et conformité avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Beatriz Barbosa\"},{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-04-04\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098232/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098232241.jpg","Maintenez la conformité sans compromettre la rapidité de développement grâce à votre plateforme DevSecOps.","https://about.gitlab.com/blog/ensuring-compliance",{"heroImage":723,"body":727,"authors":728,"updatedDate":731,"date":732,"title":733,"tags":734,"description":724,"category":735},"Découvrez dans cet article les différentes façons de garantir la\n**séparation des tâches** ainsi que la **[sécurité et\nconformité](https://about.gitlab.com/fr-fr/solutions/security-compliance/)\nlogicielle continue** avec la plateforme DevSecOps de GitLab. Avant de\ncommencer, définissons tout d'abord ces deux concepts clés.\n\n\n## Qu’est-ce que la conformité ?\n\n\nLa **conformité** désigne le fait de respecter les directives et les spécifications définies par votre entreprise ou par un organisme réglementaire. Elle permet de préserver l'éthique de l'entreprise, d'appliquer des règles d'utilisation appropriées, de respecter les normes de sécurité et plus largement, de protéger les utilisateurs.\n\n\nIl s'agit d'un aspect fondamental, car les manquements peuvent entraîner des sanctions juridiques et financières importantes. En plus d'assurer la conformité, les équipes [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que le DevSecOps ?\") doivent également conjuguer vélocité de développement soutenue, simplicité, visibilité et contrôle.\n\n\n## Qu’est-ce que la séparation des tâches ?\n\n\nLa **séparation des tâches** vise à confier une tâche à plusieurs acteurs afin de limiter les risques d'erreurs et de prévenir les activités malveillantes. Cela signifie que chaque tâche ne peut être effectuée que par les rôles les plus adaptés. \n\n\nPrenons un exemple avec plusieurs rôles, chacun doté d'un objectif spécifique :\n\n\n* Un développeur est responsable de la création de nouvelles fonctionnalités.\n\n* Un responsable de la conformité est chargé de créer et d'imposer l'utilisation d'un [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\").\n\n* Un ingénieur en sécurité applicative a pour mission d'approuver les merge requests comportant des vulnérabilités.\n\n\nEn tenant compte de cette répartition des rôles, nous nous assurons qu'un développeur ne puisse pas modifier un pipeline CI/CD en cours d'exécution. Cette tâche est en effet réservée au responsable de la conformité, qui veille à ce que seul le code conforme puisse être fusionné sans nécessiter d'approbation supplémentaire.\n\n\nL'ingénieur en sécurité applicative, quant à lui, est chargé de vérifier et d'approuver le code comportant des vulnérabilités. Il met en place les mesures d'atténuation appropriées afin d'éviter toute mauvaise surprise lorsque le code atteint l'environnement de production. Dans ce scénario, les équipes de développement ne peuvent pas fusionner le code tant que les exigences de conformité et de sécurité ne sont pas satisfaites.\n\n\n## Règles de sécurité\n\n\nGitLab met à disposition de ses utilisateurs des **règles de sécurité** qui permettent aux équipes de sécurité d'exiger l'exécution de scans de sécurité conformément à une configuration spécifique, pour garantir que les scans n'ont pas été modifiés ou désactivés.\n\n\nLes règles de sécurité peuvent être associées à des **frameworks de conformité** spécifiques et, dans ce cas, votre projet intègre des exigences de conformité plus strictes et nécessite une supervision supplémentaire. Ce label de conformité peut être créé dans **Sécurisation > Centre de conformité > Frameworks** au niveau de votre groupe principal.\n\n\n![Label du framework de conformité](https://about.gitlab.com/images/blogimages/compliance-04-2022/cf-step-2.png)\n\n\n**Remarque :** les labels de conformité ne peuvent être attribués qu'à des projets du groupe principal dans lequel ils sont créés.\n\n\nIl existe trois types de règles : les [règles d'exécution des scans](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html), les [règles d'approbation des merge requests](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html) et les [règles d'exécution des pipelines](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html).\n\n\n* **Règles d'exécution des scans :** elles exigent l'exécution de scans de sécurité à une fréquence prédéfinie ou à chaque pipeline du projet.\n\n* **Règles d'approbation des merge requests :** elles permettent de définir les mesures à prendre en fonction des résultats des scans, par exemple d'exiger l'approbation de l'équipe de sécurité avant tout merge.\n\n* **Règles d'exécution des pipelines :** elles imposent l'exécution de certains jobs CI/CD pour les projets concernés.\n\n\nVous pouvez les configurer dans l'Éditeur de règle de GitLab en suivant quelques étapes simples.\n\n\n### Règle d'exécution des scans\n\n\n1. Accédez à **Sécurité et conformité > Politiques**.\n\n2. Créez une nouvelle règle en cliquant sur le bouton **Nouvelle règle**.\n\n3. Sélectionnez **Exécution des scans**.\n\n4. Créez une règle. Dans cet exemple, nous créons une règle qui exige qu'un [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) soit configuré pour qu'un pipeline puisse s'exécuter.\n\n\n```yaml\n\nname: force_sast\n\ndescription: 'require sast to run'\n\nenabled: true\n\nrules:\n\n- type: pipeline branches: - main actions:\n\n- scan: sast\n\n```\n\n\n5. Soumettez la règle en créant une merge request, puis fusionnez-la.\n\n\nL'ensemble des modifications apportées à la règle d'exécution des scans sont appliquées par le biais d'un job en arrière-plan qui s'exécute toutes les 10 minutes. Patientez le temps nécessaire pour que les modifications prennent effet après leur commit.\n\n\n6. Essayez ensuite d'exécuter votre pipeline. Celui-ci ne s'exécutera que si le SAST est correctement défini dans le fichier YAML.\n\n\n**Remarque** : vous pouvez également forcer l'exécution d'un SAST à intervalles réguliers. Consultez la [documentation](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) dédiée aux règles d'exécution des scans pour en savoir plus.\n\n\n### Règle d'approbation des merge requests\n\n\n1. Accédez à **Sécurisation > Politiques**.\n\n2. Créez une nouvelle règle en cliquant sur le bouton **Nouvelle règle**.\n\n3. Sélectionnez **Règle d'approbation des merge requests**.\n\n4. Définissez la portée de la règle.\n\n5. Créez une règle.\n\n\n![Création d'une règle d'approbation des merge requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098241214.png)\n\n\n6. Ajoutez l'action à effectuer.\n\n\n![Mise à jour de la séparation des tâches - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098241215.png)\n\n\n**Remarque :** la règle d'approbation des merge requests est appliquée en fonction des règles que vous avez définies. Si celles-ci ne sont pas valides ou inexploitables, GitLab exige alors une approbation manuelle. Pour éviter ce blocage automatique, vous pouvez modifier le champ « Comportement par défaut en cas d'erreur » et le régler sur `open`.\n\n\n![Mise à jour de la séparation des tâches - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098241217.png)\n\n\n1. Soumettez votre règle d'approbation en créant une merge request, puis en la fusionnant.\n\n2. Créez ensuite une merge request distincte contenant des vulnérabilités.\n\n3. Vérifiez que la règle d'approbation des merge requests s'applique en consultant votre merge request.\n\n\n### Règle d'exécution des pipelines\n\n\nPour configurer une règle d'exécution des pipelines, vous devez d'abord créer un projet contenant les fichiers CI que vous souhaitez exécuter. Assurez-vous de limiter l'accès à l'équipe de sécurité et/ou à l'administrateur pour garantir la séparation des tâches. \n\n\nNous avons créé un projet intitulé « Conformité et déploiement », qui contient le fichier YAML que nous souhaitons appliquer.\n\n\n1. Accédez à **Sécurisation > Politiques**.\n\n2. Cliquez sur le bouton **Nouvelle règle** pour créer une nouvelle règle.\n\n3. Sélectionnez **Règle d'exécution des pipelines**.\n\n4. Définissez la portée de la règle.\n\n5. Ajoutez l'action à effectuer.\n\n\n![Création d'une règle d'exécution des pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098241219.png)\n\n\n6. Ajoutez des conditions.\n\n7. Créez une merge request pour soumettre cette règle, puis fusionnez-la.\n\n8. Essayez ensuite d'exécuter votre pipeline. Les étapes et les jobs spécifiques à cette règle s'afficheront alors dans votre pipeline.\n\n\n## Tableau de bord de gestion des audits et de la conformité\n\n\nLa conformité implique également de s'assurer qu'elle est réellement appliquée dans vos groupes/projets. GitLab dispose d'une fonctionnalité d'événements d'audit et de rapports de conformité pour vous assister dans ce processus.\n\n\nLa **fonctionnalité d'événements d'audit** permet aux propriétaires et administrateurs de GitLab de suivre les événements importants, tels que des actions précises effectuées par certains membres de l'équipe et l'heure à laquelle elles se sont produites.\n\n\n![Fonctionnalité d'événements d'audit de GitLab ](https://about.gitlab.com/images/blogimages/compliance-04-2022/project-audit-events.png)\n\n\nElle enregistre différents types d'actions par groupe et par projet, comme indiqué dans la documentation dédiée à [la fonctionnalité d'événements d'audit](https://docs.gitlab.com/ee/administration/audit_events.html). Vous pouvez accéder à cette fonctionnalité dans **Sécurité et conformité > Événements d'audit**.\n\n\n\nVoici quelques exemples :\n\n\n* Un utilisateur a été ajouté à un projet ainsi qu’à ses autorisations.\n\n* Les autorisations d'un utilisateur affecté à un projet ont été modifiées.\n\n* Une variable CI/CD du projet a été ajoutée, supprimée, ou son statut de protection a été modifié.\n\n* Un utilisateur a été ajouté à un groupe ainsi qu’à ses autorisations.\n\n* Le nom ou le chemin d'accès d'un groupe a été modifié.\n\n\nLes événements d'audit peuvent également être envoyés à un point de terminaison HTTP à l'aide du streaming d'événements d'audit. Découvrez comment mettre en œuvre le streaming des événements d'audit dans cette [vidéo](https://youtu.be/zHwVF9-i7e4?t=52).\n\n\nLa fonctionnalité de **respect des normes** vous permet de suivre l'activité des merge requests d'un groupe. Elle fournit une vue d'ensemble de tous les projets du groupe.\n\n\n![Fonctionnalité de respect des normes dans GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098241222.png)\n\n\nGrâce à ce rapport, vous pouvez :\n\n\n* Obtenir un aperçu des dernières merge requests pour chaque projet.\n\n* Vérifier si les merge requests ont été approuvées, et par qui.\n\n* Identifier les auteurs des merge requests.\n\n* Afficher le dernier résultat du pipeline CI/CD pour chaque merge request.\n\n\nLe rapport de respect des normes est accessible dans le groupe principal en accédant à **Sécurisation > Centre de conformité**, puis en cliquant sur l'onglet **Respect des normes**.\n\n\n- - -\n\n\nMerci de votre intérêt pour cet article ! Découvrez plus d'informations sur la séparation des tâches au sein de GitLab [sur cette page](/solutions/compliance/).\n",[729,730],"Beatriz Barbosa","Fernando Diaz","2025-07-21","2022-04-04","Séparation des tâches et conformité avec GitLab : le guide",[9,685],"security",{"slug":737,"featured":6,"template":690},"ensuring-compliance","content:fr-fr:blog:ensuring-compliance.yml","Ensuring Compliance","fr-fr/blog/ensuring-compliance.yml","fr-fr/blog/ensuring-compliance",{"_path":743,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":744,"content":750,"config":759,"_id":761,"_type":14,"title":762,"_source":16,"_file":763,"_stem":764,"_extension":19},"/fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd",{"title":745,"description":746,"ogTitle":745,"ogDescription":746,"noIndex":6,"ogImage":747,"ogUrl":748,"ogSiteName":674,"ogType":675,"canonicalUrls":748,"schema":749},"Premiers pas avec GitLab : comprendre l'approche CI/CD ","Découvrez tout ce que vous devez savoir sur l’approche CI/CD grâce à ce guide dédié aux débutants.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659525/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25.png","https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Premiers pas avec GitLab : comprendre l'approche CI/CD \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-25\",\n      }\n                  ",{"title":745,"description":746,"authors":751,"heroImage":747,"date":753,"body":754,"category":755,"tags":756,"updatedDate":758},[752],"GitLab","2025-04-25","Imaginez un cycle de développement logiciel dans lequel chaque modification de code est automatiquement compilée, testée, puis déployée auprès de vos utilisateurs. C'est tout l'intérêt de l'[approche CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ? \") (intégration continue/livraison continue) qui vous aide à détecter les bogues à un stade précoce, garantit la qualité du code et vous permet de livrer des logiciels plus rapidement et plus fréquemment.\n\n## Qu'est-ce que l'approche CI/CD ?\n\n* **L'[intégration continue](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/ \"Qu'est-ce que l'intégration continue ? \")** est une pratique de développement qui consiste à fusionner régulièrement les modifications apportées au code dans un dépôt partagé, de préférence plusieurs fois par jour, afin qu'elles soient vérifiées via un processus automatisé de compilation et de tests. Les équipes de développement peuvent ainsi détecter rapidement les problèmes et conflits éventuels.  \n* **La [livraison continue](https://about.gitlab.com/fr-fr/topics/continuous-delivery/ \"Qu'est-ce que la livraison continue ? \")** complète l'intégration continue en automatisant le pipeline pour la sortie de nouvelles versions. *À tout moment*, l'application reste déployable vers un environnement donné (par exemple, préproduction, production), en un seul clic ou par le biais d'un déclenchement automatique.  \n* **Le déploiement continu** pousse encore plus loin la logique d’automatisation. *Chaque compilation réussie* est directement mise en production, sans validation manuelle. Ce niveau d'automatisation requiert une confiance totale dans vos tests automatisés et vos processus de déploiement.\n\n## Pourquoi choisir GitLab CI/CD ?\n\nEntièrement intégré à la plateforme GitLab, GitLab CI/CD est un système puissant, qui permet d'automatiser facilement chaque étape de votre cycle de développement logiciel. Avec GitLab CI/CD, vous pouvez notamment :\n\n* **Automatiser l'intégralité de votre cycle de développement :** compilation, tests, déploiement, tout peut être orchestré via le [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \").  \n* **Détecter les bogues en amont :** les problèmes sont identifiés et corrigés bien avant d’atteindre l'environnement de production. \n* **Obtenir des retours immédiats :** les équipes de développement obtiennent un retour rapide sur leurs modifications de code.  \n* **Renforcer la collaboration :** les workflows automatisés fluidifient le travail en équipe.  \n* **Accélérer la livraison :** les livraisons de nouvelles versions sont plus rapides et plus fréquentes.  \n* **Réduire les risques :** les erreurs de déploiement et les retours en arrière sont considérablement réduits.\n\n## Quels sont les principaux composants de GitLab CI/CD ?\n\n- **`.gitlab-ci.yml` :** ce [fichier YAML](https://docs.gitlab.com/ee/ci/yaml/), situé dans le répertoire racine de votre projet, définit l'ensemble du pipeline CI/CD, y compris les étapes, les jobs et les runners.  \n- **[GitLab Runner](https://docs.gitlab.com/runner/):** cet agent exécute les jobs CI/CD sur l'infrastructure de votre choix (par exemple, machines physiques, machines virtuelles, conteneurs Docker ou clusters [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Qu'est-ce que Kubernetes ? \")).  \n- **[Étapes](https://docs.gitlab.com/ee/ci/yaml/#stages):** elles définissent l'ordre d'exécution des jobs (par exemple, compilation, tests et déploiement).  \n- **[Jobs](https://docs.gitlab.com/ee/ci/yaml/#job-keywords):** chaque job représente une unité de travail spécifique exécutée lors de l'étape correspondante (par exemple, compiler du code, exécuter des tests ou déployer dans l'environnement de préproduction).\n\n## Comment configurer GitLab CI ?\n\nGitLab CI est très facile à prendre en main. Voici un exemple basique de fichier `.gitlab-ci.yml` :\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the application...\"\n\ntest_job:\n  stage: test\n  script:\n    - echo \"Running tests...\"\n\ndeploy_job:\n  stage: deploy\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n\n```\n\nCette configuration définit trois étapes : « compilation », « test » et « déploiement ». Chaque étape contient un job qui exécute un script simple.\n\n### Exemples de configuration CI/CD\n\nExplorons quelques exemples plus concrets.\n\n**Création, compilation et déploiement d'une application Node.js**\n\nPrenons l'exemple du pipeline ci-dessous qui compile et teste une application Node.js à l'aide de npm, puis la déploie sur Heroku via [dpl](https://docs.gitlab.com/ci/examples/deployment/). L'étape de déploiement du pipeline utilise des [variables GitLab CI/CD](https://docs.gitlab.com/ci/variables/), qui permettent de stocker des informations sensibles (par exemple, des identifiants de connexion) et de les utiliser en toute sécurité dans les processus CI/CD. \n\nDans cet exemple, une clé API pour déployer l'application sur Heroku est stockée sous le nom de variable `$HEROKU_API_KEY`, cette clé étant utilisée par l'outil dpl.\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild:\n  stage: build\n  image: node:latest\n  script:\n    - npm install\n    - npm run build\n\ntest:\n  stage: test\n  image: node:latest\n  script:\n    - npm run test\n\ndeploy:\n  stage: deploy\n  image: ruby:latest\n  script:\n    - gem install dpl\n    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY\n\n```\n\n**Déploiement vers différents environnements (préproduction et production)**\n\nGitLab propose également la gestion des [environnements](https://docs.gitlab.com/ci/environments/) au sein du pipeline CI/CD pour suivre les déploiements vers des cibles d'infrastructure. Dans l'exemple ci-dessous, le pipeline ajoute des étapes avec une propriété « environnement » pour les environnements de préproduction et de production. Alors que l'étape deploy_staging exécute son script automatiquement, l'étape deploy_production nécessite une approbation manuelle afin d'éviter tout déploiement accidentel en production.  \n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy_staging\n  - deploy_production\n\nbuild:\n  # ...\n\ntest:\n  # ...\n\ndeploy_staging:\n  stage: deploy_staging\n  script:\n    - echo \"Deploying to staging...\"\n  environment:\n    name: staging\n\ndeploy_production:\n  stage: deploy_production\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n  when: manual  # Requires manual approval\n\n```\n\n### GitLab Auto DevOps\n\n[GitLab Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) simplifie encore plus l'approche CI/CD en fournissant une configuration prédéfinie pour compiler, tester et déployer automatiquement vos applications. Cette suite de fonctionnalités tire parti des bonnes pratiques et des normes du secteur pour rationaliser votre workflow.\n\nPour activer Auto DevOps :\n\n1. Accédez à **Paramètres > CI/CD > Pipelines généraux**.  \n2. Activez l'option **Auto DevOps**.\n\nAuto DevOps détecte automatiquement le langage et le framework de votre projet et configure les étapes de compilation, de tests et de déploiement nécessaires. Il est donc inutile de créer un fichier `.gitlab-ci.yml`.\n\n### Catalogue CI/CD\n\nLe catalogue CI/CD est une liste de projets contenant des [composants CI/CD](https://docs.gitlab.com/ee/ci/components/) publiés par la communauté, que vous pouvez utiliser pour optimiser votre workflow CI/CD. Vous pouvez y contribuer en ajoutant vos propres composants ou en enrichissant ceux déjà existants. Les composants publiés dans le [catalogue CI/CD](https://gitlab.com/explore/catalog) sont disponibles sur GitLab.com.\n\n> [Tutoriel : Comment configurer votre premier composant GitLab CI/CD](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n\n### Templates CI\n\nVous pouvez également créer vos propres [templates CI](https://docs.gitlab.com/ee/ci/examples/) afin de standardiser et de réutiliser les configurations de vos pipelines CI/CD entre plusieurs projets. Cette pratique favorise la cohérence et réduit les doublons.\n\nPour créer un template CI :\n\n1. Créez un fichier `.gitlab-ci.yml` dans un projet ou un dépôt dédié.  \n2. Définissez la configuration CI/CD souhaitée dans ce template.  \n3. Dans le fichier `.gitlab-ci.yml`, utilisez le terme `include` pour inclure ce template.\n\n## Optimisez votre processus de développement\n\nGitLab CI/CD transforme en profondeur votre workflow de développement de logiciels. En maîtrisant ses concepts, en configurant efficacement vos pipelines CI/CD et en tirant parti de fonctionnalités tels qu'Auto DevOps, le catalogue CI/CD et les templates CI, vous pouvez automatiser l'ensemble de votre cycle de développement logiciel et livrer des logiciels de haute qualité plus rapidement et plus efficacement.\n\nVous souhaitez approfondir vos connaissances ? Inscrivez-vous aux [cours disponibles sur le portail GitLab University](https://university.gitlab.com/). \n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/).\n\n## Articles de la série « Premiers pas avec GitLab »\n\nDécouvrez les autres articles de notre série « Premiers pas avec GitLab » :\n\n- [Comment gérer les utilisateurs](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Comment importer vos projets dans GitLab](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Comment maîtriser la gestion de projet](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-mastering-project-management/)\n- [La gemme gitlab-triage : votre alliée pour des workflows Agile automatisés](https://about.gitlab.com/fr-fr/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n","product",[109,9,685,757,755,686],"DevSecOps platform","2025-05-26",{"slug":760,"featured":91,"template":690},"getting-started-with-gitlab-understanding-ci-cd","content:fr-fr:blog:getting-started-with-gitlab-understanding-ci-cd.yml","Getting Started With Gitlab Understanding Ci Cd","fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd.yml","fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd",{"_path":766,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":767,"content":772,"config":779,"_id":781,"_type":14,"title":782,"_source":16,"_file":783,"_stem":784,"_extension":19},"/fr-fr/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"ogTitle":768,"schema":769,"ogImage":747,"ogDescription":770,"ogSiteName":674,"noIndex":6,"ogType":675,"ogUrl":771,"title":768,"canonicalUrls":771,"description":770},"Premiers pas avec GitLab : comment tirer parti des variables CI/CD","{\n  \"@context\": \"https://schema.org\",\n  \"@type\": \"Article\",\n  \"headline\": \"Premiers pas avec GitLab : comment tirer parti des variables CI/CD\",\n  \"author\": [{\"@type\": \"Person\", \"name\": \"GitLab Team\"}],\n  \"datePublished\": \"2025-05-27\"\n}\n","Découvrez les variables CI/CD, leur rôle clé dans l'approche DevSecOps ainsi que les bonnes pratiques relatives à leur utilisation.","https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"heroImage":747,"body":773,"authors":774,"date":776,"title":768,"tags":777,"description":770,"category":755,"updatedDate":778},"*Bienvenue dans notre série « Premiers pas avec GitLab », conçue pour guider les nouveaux utilisateurs dans la prise en main de la plateforme DevSecOps de GitLab.* \n\nAprès avoir exploré les bases de [l'approche CI/CD de GitLab](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd/) dans notre précédent article, concentrons-nous à présent sur les **variables CI/CD** afin de tirer pleinement parti de leur potentiel.\n\n## Qu’est-ce qu’une variable CI/CD ?\n\nLes variables CI/CD sont des paires clé-valeur dynamiques que vous pouvez définir à différents niveaux (projet, groupe ou instance par exemple) au sein de votre environnement GitLab. Elles permettent de personnaliser les [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\"), de centraliser les configurations et de gérer en toute sécurité des données sensibles. Intégrées directement dans le fichier `.gitlab-ci.yml` comme des espaces réservés pour les valeurs correspondantes, elles facilitent la maintenance, renforcent la sécurité et améliorent la flexibilité des workflows CI/CD.\n\n## Quel est le rôle des variables CI/CD ?\n\nLes variables CI/CD offrent de nombreux avantages :\n\n* **Flexibilité** : adaptez facilement vos pipelines à différents environnements, configurations ou cibles de déploiement sans modifier votre script CI/CD principal.  \n* **Sécurité** : stockez en toute sécurité des informations sensibles telles que des clés API, des mots de passe et des tokens sans les exposer dans votre code.  \n* **Maintenabilité** : en centralisant les valeurs, elles simplifient la gestion et les mises à jour de votre configuration CI/CD pour qu'elle reste structurée correctement.  \n* **Réutilisation** : définies une seule fois, elles peuvent être réutilisées dans plusieurs projets, ce qui favorise la cohérence et réduit les doublons.\n\n## Portées des variables CI/CD : projet, groupe et instance\n\nGitLab permet de définir des variables CI/CD à différentes niveaux hiérarchiques du projet, avec un contrôle précis sur leur visibilité, leur portée et leur accessibilité :\n\n* **Variables au niveau du projet** : elles sont propres à un seul projet et idéales pour stocker des paramètres spécifiques, notamment :\n\n  * L'URL de déploiement : définissez des URL distinctes pour les environnements de préproduction et de production.  \n  * Les identifiants de connexion à la base de données : stockez les données de connexion à la base de données afin de pouvoir les utiliser lors d'un test ou d'un déploiement.  \n  * Les feature flags : activez ou désactivez les fonctionnalités à différentes étapes de votre pipeline.  \n  * Exemple : dans le cadre de votre projet `MyWebApp`, vous souhaitez stocker l'URL de déploiement de production. Vous pouvez définir une variable au niveau du projet, nommée `DPROD_DEPLOY_URL`, avec la valeur `https://mywebapp.com` d'URL de production.  \n* **Variables au niveau du groupe** : elles sont partagées par tous les projets d'un groupe GitLab. Elles sont utiles pour centraliser des paramètres communs à plusieurs projets, notamment :\n\n  * Les clés API de services partagés : stockez-les pour des services tels qu'AWS, Google Cloud ou Docker Hub qui sont utilisés par plusieurs projets au sein du groupe.  \n  * Les paramètres de configuration généraux : définissez des paramètres de configuration communs qui s'appliquent à tous les projets du groupe.  \n  * Exemple : dans votre groupe `Web Apps`, vous souhaitez stocker une clé API pour Docker Hub. Vous pouvez définir une variable au niveau du groupe, nommée `DOCKER_HUB_API_KEY`, avec la valeur de clé API correspondante.  \n* **Variables au niveau de l'instance** : elles sont disponibles pour tous les projets d'une instance GitLab et couramment utilisées pour les paramètres généraux qui s'appliquent à l'ensemble de l'entreprise, notamment :\n\n  * Le token d'enregistrement de runner par défaut : fournissez un token par défaut pour l'enregistrement de nouveaux [runners](https://docs.gitlab.com/runner/).  \n  * Les informations sur la licence : stockez les clés de licence des fonctionnalités GitLab ou des outils tiers.  \n  * Les paramètres d'environnement généraux : définissez des variables d'environnement qui doivent être disponibles pour tous les projets.  \n  * Exemple : vous souhaitez définir une image Docker par défaut pour tous les projets de votre instance GitLab. Vous pouvez définir une variable au niveau de l'instance, nommée `DEFAULT_DOCKER_IMAGE`, avec la valeur `ubuntu:latest`.\n\n## Comment définir des variables CI/CD ?\n\nPour définir une variable CI/CD, voici comment procéder :\n\n1. Cliquez sur les boutons **Paramètres > CI/CD** de votre projet, groupe ou instance.  \n2. Accédez à la section **Variables**.  \n3. Cliquez sur **Ajouter une variable**.  \n4. Saisissez la **clé** (par exemple, `API_KEY`) et la **valeur** correspondante.  \n5. Facultatif : cochez l'option **Protéger la variable** si elle contient des données sensibles afin de restreindre son utilisation aux pipelines qui s'exécutent sur des branches ou des tags protégés.  \n6. Facultatif : cochez la case **Masquer la variable** pour masquer sa valeur dans les job logs, afin d'éviter toute exposition accidentelle.  \n7. Cliquez sur **Enregistrer la variable**.\n\n## Comment utiliser des variables CI/CD ?\n\nPour utiliser une variable CI/CD dans votre fichier `.gitlab-ci.yml`, faites simplement précéder le nom de la variable du symbole `$` :\n\n```yaml\ndeploy_job:\n  script:\n    - echo \"Deploying to production...\"\n    - curl -H \"Authorization: Bearer $API_KEY\" https://api.example.com/deploy\n```\n\n## Comment utiliser les variables CI/CD prédéfinies dans GitLab ?\n\nGitLab met à disposition un ensemble de [variables CI/CD prédéfinies](https://docs.gitlab.com/ci/variables/predefined_variables/) que vous pouvez utiliser dans vos pipelines CI/CD. Celles-ci fournissent des informations contextuelles sur le pipeline, le job, le projet en cours, et bien plus encore.\n\nVoici les variables plus couramment utilisées :\n\n* `$CI_COMMIT_SHA` : SHA de validation qui déclenche le pipeline  \n* `$CI_PROJECT_DIR` : répertoire dans lequel le projet est cloné  \n* `$CI_PIPELINE_ID` : ID du pipeline en cours\n* `$CI_ENVIRONMENT_NAME` : nom de l'environnement de déploiement cible (le cas échéant)\n\n## Bonnes pratiques pour l'utilisation des variables CI/CD\n\n* Gérez en toute sécurité les variables sensibles : utilisez des variables protégées et masquées pour stocker les clés API, les mots de passe et tout autre secret.  \n* Évitez de coder en dur les valeurs : stockez les valeurs de configuration dans des variables afin de renforcer la flexibilité et la maintenance de vos pipelines.\n* Organisez vos variables : utilisez des noms explicites et regroupez les variables par usage pour faciliter leur gestion.  \n* Choisissez la portée appropriée : définissez vos variables au niveau du projet, groupe ou instance en fonction de leur utilisation prévue et de leur visibilité.\n\n## Tirez parti de la puissance des variables CI/CD\n\nLes variables CI/CD sont un outil puissant pour personnaliser et sécuriser vos pipelines GitLab. En maîtrisant leur fonctionnement et en comprenant leurs différentes portées, vous pouvez créer des workflows plus flexibles, plus faciles à maintenir et plus efficaces.\n\n> Prêt à passer à l’action ? Commencez à utiliser les variables CI/CD dès aujourd'hui et profitez d'un [essai gratuit de GitLab Ultimate avec Duo Enterprise](https://about.gitlab.com/fr-fr/free-trial/).\n\n## Articles de la série « Premiers pas avec GitLab »\n\nDécouvrez les autres articles de notre série « Premiers pas avec GitLab » :\n\n* [Comment gérer les utilisateurs](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-manage-users/)\n* [Comment importer vos projets dans GitLab](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n* [Comment maîtriser la gestion de projet](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-mastering-project-management/)\n* [La gemme gitlab-triage : votre alliée pour des workflows Agile automatisés](https://about.gitlab.com/fr-fr/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n* [Comprendre l'approche CI/CD](https://about.gitlab.com/fr-fr/blog/getting-started-with-gitlab-understanding-ci-cd/)",[775],"GitLab Team","2025-05-27",[755,686,9,685,109,709],"2025-06-10",{"slug":780,"featured":91,"template":690},"getting-started-with-gitlab-working-with-ci-cd-variables","content:fr-fr:blog:getting-started-with-gitlab-working-with-ci-cd-variables.yml","Getting Started With Gitlab Working With Ci Cd Variables","fr-fr/blog/getting-started-with-gitlab-working-with-ci-cd-variables.yml","fr-fr/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"_path":786,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":787,"content":793,"config":802,"_id":804,"_type":14,"title":805,"_source":16,"_file":806,"_stem":807,"_extension":19},"/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices",{"title":788,"description":789,"ogTitle":788,"ogDescription":789,"noIndex":6,"ogImage":790,"ogUrl":791,"ogSiteName":674,"ogType":675,"canonicalUrls":791,"schema":792},"Quelles sont les meilleures pratiques CI/CD à connaître ?","Dans cet article, nous vous partageons tous nos conseils pour mettre en oeuvre une approche CI/CD réussie.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661856/Blog/Hero%20Images/ci-cd-demo.jpg","https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Quelles sont les meilleures pratiques CI/CD à connaître ?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-02-03\",\n      }",{"title":788,"description":789,"authors":794,"heroImage":790,"date":796,"body":797,"category":798,"tags":799,"updatedDate":801},[795],"Valerie Silverthorne","2022-02-03","L'intégration continue et la livraison continue sont au cœur de toute pratique DevOps réussie. Pour livrer des logiciels modernes, les équipes doivent se tenir au courant des meilleures pratiques en matière de CI/CD. Que signifie le CI/CD ? Comment mettre en place cette approche au sein de votre entreprise ?  Découvrez tous nos conseils dans cet article. \n\n## Qu’est-ce que le CI/CD ?\n\nLe [CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/ \"Qu'est-ce que le CI/CD ?\") (Continuous Integration/Continuous Delivery) est à la fois un processus, une méthodologie et un état d'esprit. En termes simples, l'intégration continue (CI) permet aux [équipes DevOps](https://about.gitlab.com/fr-fr/topics/devops/build-a-devops-team/ \"Equipe DevOps\") de rationaliser le développement de code grâce à l'automatisation. Elle simplifie la création de logiciels et l'intégration du code source, permet le [contrôle de version](https://about.gitlab.com/fr-fr/topics/version-control/ \"Contrôle de version\") et favorise la collaboration entre les équipes. \n\nEnsuite, la livraison continue (CD) prend le relais avec la mise en place de tests et de déploiements automatisés, permettant de faire gagner un temps considérable aux équipes Ops en charge de la livraison et du déploiement, et de [réduire la chaîne d'outils](https://about.gitlab.com/resources/whitepaper-forrester-manage-your-toolchain/ \"Gestion de la chaîne d'outils\") nécessaire au cycle de développement logiciel. Son maître-mot est là encore l'automatisation.\n\n## 10 meilleures pratiques CI/CD à suivre\n\nPour réussir votre approche CI/CD, faites de la notion de continuité le mantra de vos pratiques de développement, de l'intégration jusqu'au déploiement de votre logiciel. Le but du CI/CD dans l’approche DevOps est de livrer des logiciels plus rapidement qu'en suivant les méthodes traditionnelles. \n\nVoici dix conseils éprouvés par les équipes DevOps que vous pouvez suivre :\n\n__1. Ne compilez qu'une seule fois.__ Créer une nouvelle version à chaque étape est source d'incohérences. Utilisez plutôt les mêmes artefacts tout au long du pipeline CI/CD, dont les compilations doivent être indépendantes de l'environnement de développement.\n\n__2. Rationalisez les tests.__ Trouvez un équilibre entre leur portée et leurs performances. Si ces derniers prennent trop de temps, les utilisateurs essaieront de contourner le processus.\n\n__3. Échouez rapidement (*fail fast*).__ Avec l'intégration continue, les équipes de développement cherchent à identifier les problèmes le plus tôt possible, pour corriger le code fraîchement écrit. Limiter les changements de contexte améliore leur confort et la qualité de leur travail.\n\n__4. Faites-le quotidiennement.__ Plus les validations sont régulières, plus les équipes DevOps en bénéficieront. \n\n__5. Corrigez les erreurs.__ L'intégration continue et la livraison continue facilitent la correction d’erreurs de compilation.\n\n__6. Nettoyez les environnements de pré-production.__ Avec le temps, il devient de plus en plus difficile de garder une trace de toutes les modifications de configuration et mises à jour effectuées. C’est pourquoi il est important de nettoyer les environnements de pré-production entre chaque déploiement.\n\n__7. Automatisez en permanence.__ Continuez à ajuster votre pipeline CI/CD pour garantir un état « d’automatisation continue ». \n\n__8. Documentez votre travail.__ Assurez-vous que vos plans de release et de restauration sont bien documentés et compris par toute votre équipe. \n\n__9. Sécurisez votre logiciel.__ L’approche CI/CD implique le contrôle en amont. L’occasion d'intégrer la sécurité plus tôt dans le processus.\n\n__10. Travaillez en boucle.__ Veillez à ce que tous les membres de votre équipe soient impliqués dans les boucles de rétroactions.\n\nPour aller plus loin, consultez notre documentation dédiée à [l’utilisation de l’approche CI/CD avec GitLab](https://docs.gitlab.com/ee/topics/build_your_application.html \"Approche CI/CD avec GitLab\"). \n\n## Quelles sont les meilleures pratiques en matière de livraison continue ?\n\nSi l'intégration continue focalise souvent l'attention des équipes, les meilleures pratiques de livraison continue (CD) méritent, elles aussi, un tour d'horizon. \n\nVoici un résumé des meilleures pratiques en matière de livraison continue (CD) :\n\n- __Démarrez maintenant.__ N’attendez pas l'arrivée d'une nouvelle plateforme. Il est toujours possible d'améliorer la vôtre pour la rendre plus rapide et plus efficace.\n\n- *__Less is more.__* La meilleure livraison continue se fait avec un minimum d'outils.\n\n- __Suivez ce qui se passe.__ La mise en place de jalons peut vous aider à garder le contrôle sur vos tickets et vos merge requests. Ils sont efficaces lors de la mise en place de sprints et de releases agiles.\n\n- __Déployez automatiquement les modifications.__ Rationalisez les tests d'acceptation utilisateur et le staging avec l’automatisation. \n\n- __Gérez le pipeline de release.__ La solution ? L'automatisation.\n\n- __Établissez une surveillance.__ Surveiller de près le processus de production permet d'économiser du temps et de d'argent. La surveillance fournit aussi des données analytiques à l'entreprise.\n\n- __Lancez le déploiement continu.__ Une fois le processus de livraison continue en place, il vous est possible d'automatiser le déploiement, afin de lancer automatiquement vos modifications en production.\n\nTirez parti de tous les avantages de [l'intégration et de la livraison continues](https://about.gitlab.com/fr-fr/solutions/continuous-integration/ \"Intégration et livraison continues\") avec la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"DevSecOps\") de GitLab.  \n\n## Comment améliorer son pipeline CI/CD ?\n\nUn pipeline se définit comme la série d'étapes impliquées dans le déploiement d'une nouvelle version d'un logiciel. La surveillance et l'automatisation sont des concepts introduits dans un [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ? \") pour améliorer le processus de développement d'applications, aussi bien pendant les phases d'intégration et de test que lors de la livraison et du déploiement du logiciel. \n\nLes étapes d'un pipeline CI/CD comprennent : la planification, l’analyse, la conception, la compilation, les tests, la release, le déploiement, la validation, la conformité et la maintenance. Elles peuvent être réalisées manuellement, mais c'est par leur automatisation qu'un pipeline CI/CD trouve sa valeur. \n\nPour améliorer votre pipeline CI/CD, envisagez les approches suivantes :\n\n- __Variez les stratégies de release.__ Vous pourriez envisager un déploiement Canary, qui permet de déployer de nouvelles fonctionnalités auprès d'un groupe restreint d'utilisateurs.\n\n- __Mettez en place un maximum de [tests automatisés](https://about.gitlab.com/blog/want-faster-releases-your-answer-lies-in-automated-software-testing/ \"Tests automatisés\"),__ car il n'y en a jamais assez.\n\n- __Réduisez le nombre d'outils.__ En minimisant leur nombre, vous limitez les étapes et les interactions nécessaires. L'approche [DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"DevOps\") requiert la centralisation des outils, y compris CI/CD.\n\n- __Intégrez à votre routine de travail l'analyse de la composition logicielle__ pour anticiper les problèmes critiques liés aux logiciels open source.\n\n## Comment mesurer le succès de votre approche CI/CD ?\n\nIl est impossible de savoir si vos pratiques CI/CD sont efficaces sans les mesurer. Les métriques jouent un rôle important dans l'amélioration des performances et dans l'identification des axes de progrès. Elles servent aussi de base pour mesurer l'impact des changements apportés. \n\nVoici des métriques importantes à utiliser :\n\n### Durée de cycle\n\nIl s'agit du temps nécessaire au déploiement d'une application, à partir du moment où le travail sur le code a commencé. La mesure des différentes phases de ce processus permet de déterminer la durée moyenne du cycle, le temps total de développement, et d'identifier d'éventuels goulots d'étranglement.\n\n### Time to value\n\nLe délai de création de valeur exprime le temps nécessaire à la publication du code. Cela comprend l'intégration, les tests, la livraison et le déploiement, et peut prendre de quelques minutes à quelques heures. Si une compilation nécessite plusieurs jours, alors le processus doit être revu.\n\n### Temps de disponibilité\n\nLe temps de disponibilité (ou *uptime*) est une mesure importante pour les équipes Ops, car il indique si tout fonctionne comme il se doit. Avec une stratégie CI/CD automatisée, les responsables opérationnels peuvent ainsi consacrer plus de temps à la résolution de problèmes liés à la stabilité et moins à ceux liés au workflow.\n\n### Taux d'erreur\n\nMesurer le taux d'erreur des applications fait naturellement partie du travail des équipes de développement. Cela permet de déceler des problèmes de qualité, de performance et de disponibilité. Parfois, un taux d'erreur élevé s'accompagne pourtant d'un uptime performant. Cela illustre la difficulté de fixer des objectifs opérationnels cohérents entre toutes les équipes, un des [challenges reconnus des pratiques CI/CD](https://about.gitlab.com/blog/modernize-your-ci-cd/ \"Challenges des pratiques CI/CD\"). \n\n### Coûts d'infrastructure\n\nDans le cadre d’un développement cloud-natif, les coûts d'infrastructure revêtent une importance stratégique. Le déploiement et la gestion d'une plateforme CI/CD peuvent entraîner des dépenses importantes s’ils ne sont pas contrôlés. Pour les maîtriser, il faut considérer tous les facteurs que représentent les coûts des fournisseurs de solutions cloud computing. Ils comprennent le matériel réseau, mais aussi la maintenance de l'infrastructure et la main-d'œuvre.\n\n### Fidélisation des collaborateurs\n\nCe n'est pas un mystère : un développeur valorisé et satisfait sera moins susceptible de quitter l'entreprise. La fidélisation des employés passe aussi par une collaboration efficace et de qualité. En étudiant le taux de rétention de vos effectifs, vous serez en mesure d’identifier des problèmes potentiels de gestion d'équipe.\n\n## Pourquoi faut-il suivre ces bonnes pratiques CI/CD ?\n\nLorsque les meilleures pratiques en intégration et livraison continues sont respectées, c'est toute l'entreprise qui en profite, des RH aux opérations. La mise en place de métriques de performance CI/CD apporte ainsi des données utiles au développement de nombreux aspects de l'entreprise.\n\nUn pipeline CI/CD efficace peut changer la donne pour vos équipes DevOps. Voici quelques-uns des principaux avantages :\n\n- __Les développeurs et développeuses écrivent du code au lieu de le corriger.__ Avec une chaîne d'outils réduite, le temps de maintenance diminue au profit de celui consacré à la production d'applications logicielles de qualité.\n\n- __Le code est en production.__ Les équipes de développement peuvent rapidement déployer leur code en production, ce qui contribue également à leur satisfaction au travail.\n\n- __Les équipes de développement se concentrent sur les tâches les plus importantes.__ Avec un processus CI/CD rationalisé, les équipes orientent leur travail sur des aspects plus cruciaux pour l’entreprise et ne perdent plus de temps à gérer des tâches à faible valeur ajoutée. \n\n- __L'innovation est facilitée.__ Dans un secteur toujours plus dynamique et concurrentiel, des processus CI/CD bien construits permettent aux entreprises de développer des logiciels plus facilement, plus rapidement et de manière plus sûre. Les équipes DevOps ont ainsi plus de temps et d'énergie pour créer et innover.\n\n- __Il est plus facile d'attirer et de retenir les talents.__ Les talents DevOps peuvent être très difficiles à séduire sur un marché du travail très compétitif. Une organisation faisant preuve d'excellence dans ses processus CI/CD pourra plus facilement démontrer l'importance qu'elle accorde à son équipe DevOps.\n\n- __Chacun fait ce qu’il sait faire de mieux.__ Une démarche CI/CD bien définie favorise une [collaboration optimale](https://about.gitlab.com/fr-fr/teamops/ \"TeamOps\") où chaque équipe peut se consacrer à sa fonction, qu'elle ait trait au développement, à la sécurité, aux tests ou aux opérations.\n\n## Stratégie de déploiement CI/CD\n\nL'objectif de l'approche CI/CD est simple : apporter au client une application logicielle à la fois plus performante et plus rapide. Les entreprises qui l'adoptent constatent une hausse considérable de leur productivité, l'astuce consistant à définir une stratégie de déploiement adaptée à leurs besoins. \n\nVoici quelques stratégies qui contribuent à la réussite d'un déploiement :\n\n- Engagez-vous à respecter la fréquence des livraisons continues.\n- Automatisez le processus de compilation.\n- Exécutez les tests en parallèle, et créez un pipeline de déploiement.\n- Corrigez votre logiciel en amont pour accélérer le rythme de développement sans conséquences néfastes.\n- Utilisez des outils d'intégration continue fournissant un retour d'information rapide.\n\n## Comment mettre en œuvre une approche CI/CD ?\n\nComme pour tout autre logiciel, définissez au préalable les moteurs économiques et stratégiques qui justifient l'adoption de l'approche CI/CD. Impliquez toutes les parties prenantes de l'entreprise dans le processus de décision et de mise en œuvre. Les équipes de développement doivent y participer activement, puisqu'elles seront les principaux utilisateurs du produit.\n\nEffectuez des recherches approfondies pour trouver quels logiciels faciliteront la mise en œuvre des meilleures pratiques CI/CD, et n'hésitez pas à recourir à des essais gratuits au besoin. \n\nEnsuite, démarrez le processus dans un esprit de constance. La patience ne semble pas de mise pour une approche visant à accélérer la livraison de logiciels, mais elle vous évitera de laisser des erreurs se glisser tout au long du cycle de développement de votre logiciel. Votre efficacité n'en sera que plus grande.\n\nEnfin, il est essentiel de conserver un processus d'intégration cohérent. Effectuez des tests unitaires, déclenchez manuellement des releases et consultez les métriques. Vous pourrez alors déterminer ce qui peut et doit être automatisé. \n\nEn suivant ces bonnes pratiques CI/CD, vous permettrez à votre entreprise et à votre équipe DevOps de gagner sur plusieurs tableaux. Non seulement vous profiterez de logiciels de meilleure qualité, développés plus rapidement, mais vous augmenterez par la même occasion la satisfaction et l’engagement de vos équipes de développement.\n","insights",[9,685,800],"DevOps","2024-10-17",{"slug":803,"featured":6,"template":690},"how-to-keep-up-with-ci-cd-best-practices","content:fr-fr:blog:how-to-keep-up-with-ci-cd-best-practices.yml","How To Keep Up With Ci Cd Best Practices","fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices.yml","fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices",{"_path":809,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":810,"content":816,"config":825,"_id":827,"_type":14,"title":828,"_source":16,"_file":829,"_stem":830,"_extension":19},"/fr-fr/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"ogTitle":811,"schema":812,"ogImage":813,"ogDescription":814,"ogSiteName":674,"noIndex":6,"ogType":675,"ogUrl":815,"title":811,"canonicalUrls":815,"description":814},"Automatisez vos sorties et notes de version avec GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutoriel : Automatisez vos sorties et notes de version avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","Découvrez comment automatiser vos livraisons de logiciels avec l'API Changelog de GitLab : créez des artefacts, changelogs complets et notes de version clairs.","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"heroImage":813,"body":817,"authors":818,"updatedDate":820,"date":821,"title":811,"tags":822,"description":814,"category":755},"**Mise à jour 2025** : l'API Changelog de GitLab continue d'évoluer et offre\ndésormais de nouvelles fonctionnalités avancées, telles que la génération de\nchangelogs personnalisés basés sur l'historique de vos commits. Ces\nnouveautés ne sont pas détaillées dans cet article, mais vous pouvez les\nconsulter dans notre[ documentation officielle dédiée aux\nchangelogs.](https://docs.gitlab.com/user/project/changelogs/)\n\n\nLorsque vous développez un logiciel dont les utilisateurs se servent au quotidien, il est essentiel de les informer des modifications apportées à chaque nouvelle version (nouvelles fonctionnalités, modifications ou suppressions). Ils peuvent ainsi tirer pleinement parti du logiciel et éviter les mauvaises surprises lors des mises à niveau.\n\n\nMais historiquement, rédiger les notes de version et maintenir un changelog ont toujours été des tâches laborieuses qui obligent les équipes et les Release Managers à passer au crible les modifications et l'historique des merge requests. Désormais, avec l'API Changelog de GitLab, vous pouvez tirer parti de l'historique détaillé des modifications enregistrées dans votre dépôt [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ?\") pour créer automatiquement des notes de version et tenir à jour votre changelog.\n\n\nDécouvrez dans ce tutoriel comment intégrer cette automatisation dans vos [pipelines CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\").\n\n\n## Sorties de nouvelles versions dans GitLab\n\n\nDans GitLab, une nouvelle version correspond à une version spécifique de votre code, identifiée par un tag git. Elle regroupe les modifications apportées depuis la dernière version, les notes de version associées, ainsi que tous les artefacts générés à partir de cette version du code, tels que les images Docker, les paquets d'installation et la documentation.\n\n\nVous pouvez créer et suivre les sorties de ces nouvelles versions dans GitLab à l'aide de l'interface utilisateur en appelant notre API Release ou en définissant un job de `release` dans un pipeline CI. Nous utiliserons ce dernier dans ce tutoriel afin de bénéficier de l'automatisation déjà en place pour les tests, les scans du code et les autres étapes de validation, et d'automatiser également les sorties de nouvelles versions.\n\n\nNous devons d'abord disposer d'un historique clair de toutes les modifications apportées. C'est ce que fournit précisément le dépôt Git via les messages de commit et le suivi des merge requests. Ce dernier garantit une génération automatisée et fiable des notes de version et du changelog. \n\n\n## Lignes terminales dans un commit\n\n\nLes [lignes terminales dans un commit Git](https://git-scm.com/docs/git-interpret-trailers/fr) sont des métadonnées structurées ajoutées en fin de vos messages de commit, sous la forme simple `\u003CHEADER>:\u003CBODY>`. L'interface de ligne de commande `git` peut ensuite les analyser et les extraire pour les utiliser dans d'autres systèmes, par exemple via la commande `git commit --sign-off` qui permet de confirmer un commit en y ajoutant une ligne terminale `Signed-off-by: \u003CVotre nom>`. Vous pouvez y ajouter n'importe quelle information structurée. Il s'agit donc d'un emplacement idéal pour stocker des métadonnées, et dans notre exemple, pour générer automatiquement notre changelog.\n\n\nEn ajoutant la ligne terminale `Changelog: \u003Cadded/changed/removed>` à la fin de nos messages de commit, l'API Changelog de GitLab l'analysera et créera automatiquement un changelog.\n\n\nNous allons illustrer ce mécanisme en apportant quelques modifications à un code source existant afin de sortir une nouvelle version et de générer automatiquement ses notes de version et les entrées du changelog correspondant.\n\n\n## Exemple concret avec une application Python\n\n\nPartons d'un dépôt contenant une application web simple écrite en Python. Supposons que la version 1.0.0 de cette application vient de sortir et représente l'état actuel du code, et qu'elle a été créée manuellement dans GitLab, sans pipeline de sortie de nouvelle version automatisé :\n\n\n![Capture d'écran de l'interface utilisateur de GitLab montrant la sortie de la nouvelle version 1.0.0](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n\n## Modifications en vue de la version 2.0.0\n\n\nComme nous sommes en mode de développement rapide, nous allons travailler sur la sortie de la version 2.0.0 de notre application dès aujourd'hui. Celle-ci introduira une fonctionnalité de chatbot et supprimera la fonctionnalité de blockchain quantique, qui servait uniquement à impressionner les investisseurs lors de notre premier cycle de financement par capital-risque. Nous allons également ajouter un job de sortie de nouvelle version automatisé à notre pipeline CI/CD.\n\n\nTout d'abord, nous devons supprimer les fonctionnalités obsolètes à l'aide d'une merge request qui contient les suppressions nécessaires en veillant à ce que le message de commit inclue la ligne terminale `Changelog: removed`. Pour cela, nous pouvons par exemple l'inclure directement dans un commit, ou effectuer un [rebasage interactif](https://about.gitlab.com/fr-fr/blog/keep-git-history-clean-with-interactive-rebase/ \"Qu'est-ce que le rebasage interactif ?\") et l'ajouter à l'aide de l'interface de ligne de commande (CLI). \n\n\nMais dans notre exemple, nous traiterons cette étape en dernier, et utiliserons plutôt le bouton `Modifier le message de commit` dans GitLab pour ajouter la ligne terminale au commit comme suit :\n\n\n![Capture d'écran de l'interface utilisateur de GitLab montrant une merge request supprimant les fonctionnalités inutilisées](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\n\nVous pouvez également modifier le titre du commit pour qu'il soit plus concis. Nous allons donc renommer notre commit « Supprimer les fonctionnalités inutilisées », pour que ce titre apparaisse dans le changelog.\n\n\nEnsuite, ajoutons de nouvelles fonctionnalités pour la version 2.0.0. Là encore, il suffit d'ouvrir une autre merge request qui inclut nos nouvelles fonctionnalités, de modifier le commit pour inclure la ligne terminale `Changelog: added`, puis de modifier son titre pour qu'il soit plus concis :\n\n\n![Capture d'écran de l'interface utilisateur de GitLab montrant une merge request servant à ajouter de nouvelles fonctionnalités](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png)\n\n\nNous sommes maintenant prêts à publier la version 2.0.0. Mais cette fois-ci, au lieu de la créer manuellement, nous allons ajouter les jobs nécessaires à notre fichier `.gitlab-ci.yml` : ils gèreront automatiquement la sortie de la nouvelle version à notre place et généreront les notes de version et les entrées du changelog lorsque nous ajouterons à notre code le tag `2.0.0` en référence à la nouvelle version.\n\n\n**Remarque :** pour ajouter facilement des lignes terminales de changelog, utilisez un outil comme [Danger, qui permet de vérifier automatiquement le respect des conventions dans les merge requests](https://docs.gitlab.com/ee/development/dangerbot.html).\n\n\n## Création d'un pipeline automatisé de sortie de nouvelle version\n\n\nLa première étape consiste à créer un token d'accès au projet qui nous permettra d'appeler l'API de GitLab afin de générer les entrées de notre changelog. [Créons un token d'accès au projet avec la portée de l'API](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token), puis [stockons-le dans les variables CI/CD](https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui) du projet sous le nom `CI_API_JETON`. Nous référencerons cette variable à des fins d'authentification auprès de l'API.\n\n\nEnsuite, ajoutons deux nouveaux jobs à notre fichier `gitlab-ci.yml` :\n\n\n```yaml\n\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRE_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\n\nDans notre configuration, le job `prepare_job` utilise `curl` et `jq` pour appeler le point de terminaison de l'API Changelog de GitLab, puis transmet le résultat à notre job `release_job` chargé de créer automatiquement la nouvelle version. \n\n\nVoici les principaux éléments à retenir :\n\n\n* Nous utilisons le token d'accès au projet créé précédemment pour appeler l'API Changelog de GitLab, qui génère les notes de version que nous stockons en tant qu'artefact.\n\n* Nous utilisons la variable `$CI_COMMIT_TAG` pour identifier la version. Pour que l'API Changelog fonctionne correctement, nous devons utiliser la gestion sémantique de version pour nos tags (par exemple, `2.0.0`). Nous avons également restreint le job de sortie de nouvelle version à l'aide d'une règle spécifique dans la section `rules`, qui vérifie la présence d'un tag de version sémantique.\n\n  * La gestion sémantique de version est nécessaire pour que l'API Changelog de GitLab déclenche le job. Elle utilise ce format pour trouver la version la plus récente à comparer à notre version actuelle.\n* Nous utilisons l'image `release-cli` officielle de GitLab, indispensable pour exploiter le terme `release` dans un job.\n\n* Nous utilisons le terme `release` pour créer une sortie de nouvelle version dans GitLab et pour le remplissage des champs obligatoires.\n\n* Nous pouvons transmettre un fichier en tant qu'argument pour la `description` de la nouvelle version. Dans notre exemple, il s'agit du fichier que nous avons généré lors du job `prepare_job`, puis transmis à ce job sous forme d'artefact.\n\n* Nous avons également inclus notre image de conteneur, qui a été compilée plus tôt dans le pipeline, en tant que ressource associée à la nouvelle version. Vous pouvez également y joindre les ressources de votre choix, générées lors de votre processus de compilation, telles que des binaires ou de la documentation, à condition de fournir l'URL redirigeant vers l'endroit où vous les avez chargés plus tôt dans le pipeline.\n\n\n## Automatisation d'une sortie de nouvelle version\n\n\nAvec cette configuration, il suffit d'effectuer le push d'un tag respectant notre schéma de gestion des versions vers notre dépôt à l'aide de la CLI ou comme dans notre exemple, directement depuis l'interface utilisateur de GitLab, sur la branche principale, en sélectionnant Code -> Tags -> Nouveau tag dans la barre latérale :\n\n![Capture d'écran de l'interface utilisateur de GitLab montrant comment créer un tag](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\n\nDès la création du tag, nos pipelines commenceront à s'exécuter automatiquement. L'API Changelog de GitLab génère alors des notes de version au format markdown contenant toutes les modifications apportées entre cette version et la version précédente. \n\n\nVoici un extrait du markdown généré dans notre exemple :\n\n\n```md\n\n## 2.0.0 (2023-08-25)\n\n\n### added (1 change)\n\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n\n### removed (1 change)\n\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n\n```\n\n\nComme vous pouvez le constater, GitLab a extrait automatiquement les entrées de nos notes de version à l'aide des lignes terminales que nous avons intégrées dans nos messages de commit Git. De plus, des notes incluent des liens vers la merge request associée pour accéder rapidement aux compléments d'information et discussions relatifs aux modifications.\n\n\nVoici notre nouvelle version 2.0.0 :\n\n![Interface utilisateur de la nouvelle version de GitLab montrant la nouvelle version 2.0.0](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n\n## Automatisation de la mise à jour du changelog\n\n\nPour maintenir à jour votre changelog (soit l'historique rassemblant toutes vos notes de version), vous pouvez effectuer une requête `POST` vers le point de terminaison de l'API Changelog utilisé précédemment.\n\n\nSi vous effectuez cette opération dans le cadre de votre pipeline de nouvelle version, intégrez cette étape en ajoutant ce qui suit à la section `script` de votre job de préparation :\n\n\n```sh\n\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n\n```\n\n\n**Notez que cette opération modifie le dépôt** en créant un commit qui ajoute les notes de la nouvelle version à un fichier `CHANGELOG.md` :\n\n![Capture d'écran du dépôt montrant une validation mettant à jour le fichier changelog](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\n\nEt voilà, nous avons terminé ! En utilisant l'historique détaillé fourni par `git` avec quelques lignes terminales de commit pratiques, nous pouvons tirer parti de la puissante de l'API et des pipelines CI/CD de GitLab pour automatiser notre processus de sortie de nouvelle version et de génération de notes de version.\n\n\n> Pour découvrir le projet utilisé dans ce tutoriel, [consultez ce lien](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo).\n",[819],"Ben Ridley","2025-07-09","2023-11-01",[9,109,800,823,824],"DevSecOps","git",{"slug":826,"featured":6,"template":690},"tutorial-automated-release-and-release-notes-with-gitlab","content:fr-fr:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","fr-fr/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","fr-fr/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"_path":832,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":833,"content":839,"config":847,"_id":849,"_type":14,"title":850,"_source":16,"_file":851,"_stem":852,"_extension":19},"/fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"ogTitle":834,"schema":835,"ogImage":836,"ogDescription":837,"ogSiteName":674,"noIndex":6,"ogType":675,"ogUrl":838,"title":834,"canonicalUrls":838,"description":837},"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/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"heroImage":836,"body":840,"authors":841,"updatedDate":843,"date":844,"title":845,"tags":846,"description":837,"category":683},"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",[842],"Olivier Dupré","2025-01-09","2024-09-26","Déployer en continu dans de multiples environnements avec les pipelines enfants",[109,9,685,757,686],{"slug":848,"featured":6,"template":690},"using-child-pipelines-to-continuously-deploy-to-five-environments","content:fr-fr:blog:using-child-pipelines-to-continuously-deploy-to-five-environments.yml","Using Child Pipelines To Continuously Deploy To Five Environments","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",{"_path":854,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":855,"content":861,"config":868,"_id":870,"_type":14,"title":871,"_source":16,"_file":872,"_stem":873,"_extension":19},"/fr-fr/blog/basics-of-gitlab-ci-updated",{"title":856,"description":857,"ogTitle":856,"ogDescription":857,"noIndex":6,"ogImage":858,"ogUrl":859,"ogSiteName":674,"ogType":675,"canonicalUrls":859,"schema":860},"Intégration continue : créez votre premier pipeline CI avec GitLab ","Vous débutez dans l'intégration continue ? Apprenez à créer votre premier pipeline CI avec GitLab. Lisez notre guide complet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662061/Blog/Hero%20Images/cicdcover.png","https://about.gitlab.com/blog/basics-of-gitlab-ci-updated","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Intégration continue : créez votre premier pipeline CI avec GitLab \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2020-12-10\",\n      }",{"title":856,"description":857,"authors":862,"heroImage":858,"date":864,"body":865,"category":683,"tags":866,"updatedDate":867},[863],"Itzik Gan Baruch","2020-12-10","Imaginons que vous ne connaissiez rien au concept d’[intégration continue\n(CI)](https://about.gitlab.com/fr-fr/topics/ci-cd/benefits-continuous-integration/\n\"Qu'est-ce que l'intégration continue (CI) ?\") ni à son rôle clé dans le\ncycle de vie du développement logiciel.\n\n\nÀ présent, supposons que vous travaillez sur un projet pour lequel\nl'intégralité du code est répartie dans seulement deux fichiers. Pour\ngarantir le bon fonctionnement de ce projet, il est impératif que la\nconcaténation de ces deux fichiers contienne la phrase « Hello world ».\n\n\nToute la réussite du projet repose sur cette simple phrase, car sans elle,\ntout serait compromis.\n\n\nConscient de cet enjeu, votre meilleur développeur logiciel a décidé de\ncréer un script qui s'exécute dès qu’un nouveau morceau de code est envoyé\naux clients.\n\n\nVoici à quoi cela ressemble  :\n\n\n```bash\n\ncat file1.txt file2.txt | grep -q \"Hello world\"\n\n```\n\n\nMême si, en l'état, ce script permet d'exécuter notre tâche, son\ndéclenchement reste manuel. Et, avec une équipe de développement composée de\n10 personnes, vous n'êtes pas à l'abri d'une erreur humaine qui pourrait\nvous coûter très cher. \n\n\nLa preuve en est, pas plus tard que la semaine dernière, un nouveau membre\nde votre équipe a oublié d'exécuter le script, provoquant des erreurs de\ncompilation pour trois de vos clients.\n\n\nVous prenez donc la décision de résoudre ce problème, une bonne fois pour\ntoutes, en utilisant le pipeline d'[intégration et de livraison\ncontinues](https://about.gitlab.com/fr-fr/solutions/continuous-integration/\n\"Intégration et livraison continues\") de GitLab. Par chance, votre code est\ndéjà sur la plateforme. Il ne vous reste plus qu'à vous lancer.  \n\n\n## Effectuer un premier test dans le pipeline CI de GitLab\n\n\nÀ la lecture de la documentation de GitLab, nous savons qu'il suffit de\nréunir deux lignes de code dans un fichier appelé `.gitlab-ci.yml`:\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n```\n\n\nNous le validons et constatons que la compilation s'est déroulée avec succès\n\n\n![Compilation réussie dans le pipeline d’intégration\ncontinue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_succeeded.png)\n\n\nMaintenant, remplaçons « world » par « Africa » dans le deuxième fichier et\nvoyons ce qui se passe :\n\n\n![Échec de compilation dans le pipeline CI\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_failed.png)\n\n\nComme nous pouvions le prévoir, la compilation a échoué.\n\n\nNous avons désormais mis en place l'automatisation des tests.  \n\n\nÀ partir de maintenant, [GitLab\nCI](https://about.gitlab.com/fr-fr/blog/ci-deployment-and-environments/\n\"Comment déployer du code dans des environnements multiples avec GitLab CI\")\nexécutera notre script de test dès que nous effectuerons un push du code\nvers le dépôt de code source dans l'environnement\n[DevOps](https://about.gitlab.com/fr-fr/topics/devops/ \"Que signifie DevOps\n?\"). \n\n\nRemarque : dans l'exemple ci-dessus, nous supposons que file1.txt et\nfile2.txt existent sur l'hôte du runner. Pour exécuter cet exemple dans\nGitLab, utilisez le code ci-dessous, qui crée d'abord les fichiers, puis\nexécute le script.\n\n\n```yaml\n\ntest:\n\nbefore_script:\n      - echo \"Hello \" > | tr -d \"\\n\" | > file1.txt\n      - echo \"world\" > file2.txt\nscript: cat file1.txt file2.txt | grep -q 'Hello world'\n\n```\n\n\nPour simplifier notre démonstration, nous partons du principe que ces\nfichiers existent déjà sur l'hôte. Nous n'allons donc pas les créer dans les\nétapes suivantes.\n\n\n## Rendre les résultats des compilations téléchargeables\n\n\nLa prochaine étape consiste à empaqueter le code avant de l'envoyer aux\nclients. Alors, pourquoi ne pas automatiser aussi cette partie du processus\nde développement logiciel ?\n\n\nPour cela, tout ce que nous devons faire est de définir un autre job pour\nl'intégration continue. \n\n\nCommençons par nommer notre job « package » :\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > package.gz\n```\n\n\nNous avons maintenant deux onglets : \n\n\n![Deux onglets - générés par deux\njobs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/two_tabs.png)\n\n\nCependant, nous avons oublié de spécifier que le nouveau fichier est un\nartefact de compilation, afin qu’il puisse être téléchargé. Nous pouvons\ncorriger cela en ajoutant une section `artefacts` :\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nVérifions que tout est en place :\n\n\n![Artefact de compilation téléchargeable dans le pipeline CI/CD de\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/artifacts.png)\n\n\nFélicitations ! Tout semble fonctionnel. En revanche, dans la configuration\nactuelle, les jobs s'exécutent en parallèle. Cela signifie que notre\napplication pourra être empaquetée, et ce, même si les tests échouent. Pour\néviter que cela ne se produise, nous allons devoir exécuter les jobs de\nmanière séquentielle.  \n\n\n## Exécuter des jobs de manière séquentielle\n\n\nPour éviter d'empaqueter une application contenant des erreurs, nous allons\nfaire en sorte d'exécuter le job « package » uniquement si les tests sont\npréalablement réussis. Pour commencer, définissons l'ordre d'exécution en\nétablissant des étapes spécifiques  :\n\n\n```yaml\n\nstages:\n  - test\n  - package\n\ntest:\n  stage: test\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nCela devrait maintenant fonctionner.\n\n\nNous souhaitons également garantir que la compilation (qui est représentée\npar la concaténation dans notre exemple) ne s'exécute qu'une seule fois. En\neffet, cette étape pouvant être chronophage, il serait dommage de l'exécuter\ninutilement.\n\n\nPour éviter cela, définissons une étape supplémentaire :\n\n\n```yaml\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nJetons un œil à nos artefacts :\n\n\n![Artefacts de compilation dans le pipeline CI de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/clean-artifacts.png)\n\n\nTout a l'air de fonctionner. En revanche, il faudrait éviter de rendre le\nfichier « compile » téléchargeable. Pour cela, nous allons rendre nos\nartefacts temporaires expirables en définissant `expire_in` à « 20 minutes\n».  \n\n\n```yaml\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n```\n\n\nMaintenant, notre configuration semble plutôt complète : \n\n- Nous avons trois étapes séquentielles pour compiler, tester et empaqueter\nnotre application. \n\n- Nous transmettons également l'application compilée aux étapes suivantes\npour ne pas exécuter la compilation à deux reprises (ce qui accélère le\nprocessus). \n\n- Et nous stockons une version empaquetée de notre application dans les\nartefacts de compilation pour une utilisation ultérieure.\n\n\n## Savoir quelle image Docker utiliser\n\n\nJusqu'ici, tout va bien. Cependant, en regardant de plus près, nos\ncompilations semblent toujours lentes. Prenons un moment pour regarder les\njournaux (logs) :\n\n\n![Image ruby\n3.1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/ruby-31.png)\n\n\nEn observant de plus près, nous remarquons la mention suivante : `ruby:3.1`.\nCela signifie que GitLab.com utilise des images Docker pour [exécuter nos\ncompilations](https://about.gitlab.com/blog/shared-runners/), et qu’il\nutilise [par\ndéfaut](https://docs.gitlab.com/ee/user/gitlab_com/#shared-runners), l'image\n[`ruby:3.1`](https://hub.docker.com/_/ruby/).\n\n\nCette image contient certainement de nombreux paquets dont nous n'avons pas\nbesoin. Dans un souci d'optimisation de notre pipeline CI, il serait donc\npréférable de changer d'image. Après une courte recherche sur Google, nous\ndécouvrons qu'il existe une image Linux presque vierge appelée\n[`alpine`](https://hub.docker.com/_/alpine/). Nous allons alors l'utiliser.\nPour cela, nous devrons ajouter `image: alpine` au fichier `.gitlab-ci.yml`.\n\n\nEt voilà !  Nous avons maintenant réduit le temps de compilation de presque\ntrois minutes :\n\n\n![Vitesse de compilation améliorée dans le pipeline de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/speed.png)\n\n\nVous pouvez également trouver des images libres de droits sur\n[mysql](https://hub.docker.com/_/mysql/),\n[Python](https://hub.docker.com/_/python/),\n[Java](https://hub.docker.com/_/java/) et\n[php](https://hub.docker.com/_/php/). Il est facile, alors, d'en choisir une\npour notre pile technologique. \n\n\nNote : il sera toujours préférable d'utiliser une image qui ne contient\naucun logiciel supplémentaire dont vous n'avez pas besoin, car cela minimise\ngrandement le temps de téléchargement.\n\n\n## Gérer des scénarios complexes \n\n\nImaginons maintenant un scénario un peu plus complexe. Par exemple, un\nnouveau client souhaite que nous empaquetions notre application au format\n`.iso` plutôt qu'en `.gz`. \n\n\nÉtant donné que le pipeline d'intégration continue gère tout le processus,\net que les images ISO peuvent être créées avec la commande `mkisofs`, il\nsuffit d'ajouter un job supplémentaire.\n\n\nVoici à quoi notre configuration devrait ressembler :\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\n# ... \"compile\" and \"test\" jobs are skipped here for the sake of compactness\n\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nNotez que les noms des jobs ne doivent pas être nécessairement identiques.\nS'ils l'étaient, il serait impossible de faire s'exécuter les jobs en\nparallèle dans la même étape du processus de développement logiciel. \n\n\nAinsi, dans l'exemple qui suit, ignorez le fait que les jobs et étapes\nportent le même nom.\n\n\nQuoi qu'il en soit, la compilation échoue :\n\n\n![Echec de compilation dans le pipeline de\nGitLab](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/mkisofs.png)\n\n\nLe problème vient de  `mkisofs` qui n'est pas inclus dans l'image `alpine`.\nNous devons donc d'abord l'installer.\n\n\n## Gérer des logiciels et des paquets manquants \n\n\nSelon le [site Web d’Alpine\nLinux](https://pkgs.alpinelinux.org/contents?file=mkisofs&path=&name=&branch=edge&repo=&arch=\n\"Site Web Alpine Linux\"), `mkisofs` fait partie des paquets `xorriso` et\n`cdrkit`. Voici les commandes que nous devons exécuter pour installer un\npaquet :\n\n\n```bash\n\necho \"ipv6\" >> /etc/modules  # enable networking\n\napk update                   # update packages list\n\napk add xorriso              # install package\n\n```\n\n\nCes commandes s'exécutent de la même manière que toute autre commande au\nsein du processus d'intégration continue. La liste complète des commandes\nque nous devons transmettre à la section `script` devrait ressembler à ceci\n:\n\n\n```yml\n\nscript:\n\n- echo \"ipv6\" >> /etc/modules\n\n- apk update\n\n- apk add xorriso\n\n- mkisofs -o ./packaged.iso ./compiled.txt\n\n```\n\n\nCependant, pour des raisons sémantiques, plaçons les commandes liées à\nl'installation du paquet dans `before_script`. \n\n\nNotez que si vous utilisez `before_script` au niveau supérieur d'une\nconfiguration, alors les commandes s'exécuteront avant tous les jobs. Dans\nnotre cas, nous voulons simplement qu'elles s'exécutent avant un job\nspécifique.\n\n\n## Graphes acycliques orientés pour des pipelines CI plus rapides et\nflexibles\n\n\nPlus haut, nous avons configuré des étapes pour que les jobs d'empaquetage\nne s'exécutent qu'à la condition que les tests réussissent. Mais, que se\npasserait-il si nous voulions bouleverser le séquencement des étapes en\nexécutant certains jobs plus tôt qu'initialement prévu ? \n\n\nDans certains cas, le séquencement traditionnel des étapes peut ralentir la\ndurée globale d'exécution du [pipeline\nCI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce\nqu'un pipeline CI/CD ?\"). Pour éviter cela, nous pouvons choisir de\npersonnaliser le séquencement de nos jobs. \n\n\nPar exemple : imaginons que notre étape de test comprenne des tests lourds,\nprenant beaucoup de temps à s'exécuter. Supposons aussi que ces tests ne\nsoient pas nécessairement liés aux jobs d’empaquetage. Dans ce cas, il\nserait préférable que les jobs d’empaquetage puissent démarrer sans attendre\nla fin de ces tests. C'est là qu'interviennent les [graphes acycliques\norientés](https://about.gitlab.com/blog/directed-acyclic-graph/ \"Graphes\nacycliques orientés\"). Ces derniers visent à rompre l'ordre normal\nd'exécution des jobs (ordre séquentiel) grâce à la création de dépendances\nentre certains jobs. Vous pouvez ainsi définir un ordre personnalisé pour\nexécuter les différents jobs de votre pipeline CI.\n\n\nGrâce au mot-clé `needs`, GitLab crée des dépendances entre les jobs et leur\npermet de s'exécuter plus tôt, dès que leurs jobs dépendants sont terminés.\n\n\nDans l'exemple ci-dessous, les jobs d’empaquetage commenceront à s'exécuter\ndès que le test sera terminé. Ainsi, à l'avenir, si quelqu'un ajoute\nd'autres tests à l'étape de test, les jobs d’empaquetage commenceront à\ns'exécuter avant la fin des nouveaux tests :\n\n\n```yaml\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nVoici notre version définitive de `.gitlab-ci.yml`:\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  before_script:\n      - echo \"Hello  \" | tr -d \"\\n\" > file1.txt\n      - echo \"world\" > file2.txt\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nNous venons de créer un pipeline ! Ainsi, nous avons trois étapes\nséquentielles avec les \n\njobs `pack-gz` et `pack-iso` qui s'exécutent en parallèle à l'intérieur de\nl'étape d'empaquetage :\n\n\n![Représentation d'un artefact de compilation d'un pipeline\nCI](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/pipeline.png)\n\n\n## Améliorer votre pipeline CI\n\n\nNous allons maintenant découvrir comment améliorer notre pipeline\nd'intégration continue.\n\n\n### Intégrer des tests automatisés dans vos pipelines CI\n\n\nL'objectif clé du développement logiciel avec une approche DevOps est de\nréussir à créer des applications offrant une excellente expérience\nutilisateur. \n\n\nAvec cet objectif en tête, pourquoi ne pas renforcer le cycle de\ndéveloppement logiciel en cherchant à détecter d'éventuels bogues dès le\ndébut du processus ? Pour ce faire, ajoutons des tests à notre pipeline CI.\nDe cette façon, nous pourrons résoudre les problèmes le plus tôt possible.\n\n\nPar chance, le pipeline CI de GitLab nous facilite la tâche en proposant des\ntemplates de tests prêts à l'emploi. Tout ce que nous avons à faire, c'est\nd'inclure ces templates dans la configuration de notre pipeline CI.\n\n\nDans cet exemple, nous allons réaliser des [tests\nd'accessibilité](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html\n\"Test d'accessibilité\") :\n\n\n```yaml\n\nstages:\n  - accessibility\n\nvariables:\n  a11y_urls: \"https://about.gitlab.com https://www.example.com\"\n\ninclude:\n  - template: \"Verify/Accessibility.gitlab-ci.yml\"\n```\n\n\nPersonnalisez la variable `a11y_urls` pour répertorier les URL des pages web\nà tester avec [Pa11y](https://pa11y.org/ \"Pa11y\") et GitLab [Code\nQuality](https://docs.gitlab.com/ee/ci/testing/code_quality.html \"Code\nQuality\"). \n\n\n```yaml\n   include:\n   - template: Jobs/Code-Quality.gitlab-ci.yml\n```\n\n\nGitLab facilite la consultation du rapport de test directement dans la zone\ndu widget de la [merge\nrequest](https://docs.gitlab.com/ee/user/project/merge_requests/ \"Merge\nrequest\"). Ce widget vous permet de voir la revue de code, l'état du\npipeline et les résultats des tests au même endroit. La capture d'écran\nci-dessous montre à quel point ce widget facilite le travail de vos\néquipes. \n\n\n![Exemple de rapport d'accessibilité dans le pipeline CI/CD de\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_10.56.41.png)\n\n\u003Ccenter>\u003Ci>Widget pour les merge requests en matière\nd'accessibilité\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n![Exemple de rapport de test sur la qualité du code suite à une merge\nrequest dans\nGitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.00.25.png)\n\n\u003Ccenter>\u003Ci>Widget de merge request pour GitLab Code Quality\u003C/i>\u003C/center>\n\n\n### Matrice des compilations\n\n\nDans certains cas, nous devons tester notre application dans différentes\nconfigurations, versions de systèmes d'exploitation et langages de\nprogrammation. Nous utilisons alors la compilation «\n[parallel:matrix](https://docs.gitlab.com/ee/ci/yaml/#parallelmatrix\n\"parallel:matrix\") ». Cela nous permet de tester notre application à travers\ndiverses combinaisons en parallèle dans un seul job. Maintenant, testons\nnotre code avec différentes versions de Python et avec le mot-clé « matrix\n».\n\n\n```yaml\n\npython-req:\n  image: python:$VERSION\n  stage: lint\n  script:\n    - pip install -r requirements_dev.txt\n    - chmod +x ./build_cpp.sh\n    - ./build_cpp.sh\n  parallel:\n    matrix:\n      - VERSION: ['3.8', '3.9', '3.10', '3.11']   # https://hub.docker.com/_/python\n```\n\n\nLors de l'exécution du pipeline, ce job s'exécute en parallèle quatre fois,\nchaque fois en utilisant une image Python différente comme indiqué\nci-dessous :\n\n\n![Exécution de jobs en parallèle dans le pipeline\nCI/CD](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.12.48.png)\n\n\n### Tests unitaires\n\n\n#### Que sont les tests unitaires ?\n\n\nLes tests unitaires sont des tests ciblés et de petite envergure qui\nvérifient des composants ou des fonctions d'un logiciel. Ces tests\npermettent d'assurer qu'il fonctionne comme prévu. Ils sont essentiels pour\nvérifier que chaque partie du code fonctionne correctement et permettent de\ndétecter les bogues le plus tôt possible dans le processus de développement\nlogiciel. \n\n\nExemple : imaginez que vous développiez une application de calculatrice. Un\ntest unitaire pour la fonction « addition » va vérifier si le résultat d'un\ncalcul comme 2 + 2 est bien égale à 4. Si ce test est concluant, nous avons\nconfirmation que la fonction « addition » fonctionne correctement.\n\n\n#### Tests unitaires : les bonnes pratiques\n\n\nMettre en place des tests unitaires, c'est bien, mais il est possible\nd'aller encore plus loin pour faciliter la vie de vos équipes de\ndéveloppement.\n\n\nPar exemple, lorsqu'un test échoue, vos équipes reçoivent une notification.\nS'engage alors un long processus de vérification des job logs afin de\ntrouver et de corriger les erreurs. Ce processus est long et pourrait être\noptimisé.\n\n\nIl est possible de configurer votre job pour qu'il utilise des [rapports de\ntests\nunitaires](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html\n\"Rapports de tests unitaires\") (rapports détaillés des erreurs permettant de\nles traiter plus efficacement). GitLab affiche ces rapports dans la merge\nrequest et sur la page de détails des pipelines CI. Cela facilite\nl'identification des échecs, car il n'y a alors plus besoin de consulter\nl'intégralité du journal.\n\n\n#### Rapport de test JUnit\n\n\nCi-dessous un exemple de rapport de test JUnit : \n\n\n![Rapport de test JUnit dans un pipeline d'intégration\ncontinue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674097/Blog/Content%20Images/pipelines_junit_test_report_v13_10.png){:\n.shadow.center}\n\n\n### Stratégies d'intégration et de tests de bout en bout\n\n\nAfin de s'assurer que toutes les parties de notre code fonctionnent en\nharmonie (y compris les\n[microservices](https://about.gitlab.com/fr-fr/topics/microservices/ \"Que\nsont les microservices ?\"), les tests d'interface utilisateur), il est\ncapital de configurer un pipeline dédié à l'intégration et aux tests de bout\nen bout.\n\n\nCes tests sont exécutés [chaque\nnuit](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) et il est\npossible de configurer le système pour que les [résultats soient\nautomatiquement envoyés vers un canal Slack\ndédié](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#notification-events).\nAinsi, lorsque les équipes de développement arrivent le matin, elles peuvent\nrapidement travailler sur les problèmes identifiés la veille. L'objectif\nétant de détecter et de corriger les problèmes le plus tôt possible dans le\nprocessus de développement logiciel.\n\n\n### Environnement de test\n\n\nDans certains cas, nous avons besoin d'un environnement dédié pour tester\ncorrectement nos applications. On parle alors d'environnement de test. Avec\nle pipeline CI/CD de GitLab, nous pouvons automatiser le déploiement des\nenvironnements de test, et ainsi gagner un temps considérable. \n\n\nComme cet article se concentre principalement sur les pipelines\nd'intégration continue, nous ne nous attarderons pas sur ce point ici. En\nrevanche, libre à vous de consulter la section dédiée à ce sujet dans la\n[documentation\nGitLab](https://docs.gitlab.com/ee/topics/release_your_application.html).\n\n\n## Implémenter des scans de sécurité dans un pipeline CI\n\n\nVoici comment mettre en œuvre des scans de sécurité dans un pipeline CI.\n\n\n### Intégration des SAST et des DAST\n\n\nAvant toute chose, nous souhaitons garder notre code en sécurité. S'il y a\nla moindre vulnérabilité dans nos dernières modifications, nous voulons en\nêtre informés dès que possible. C'est pourquoi il est judicieux d'ajouter\ndes scans de sécurité à votre pipeline CI. \n\nCes scans vérifient le code à chaque commit et vous alertent dès qu'une\nfaille est détectée. \n\n\nIl existe deux types de scan : \n\n- les tests statiques de sécurité des applications\n([SAST](https://docs.gitlab.com/ee/user/application_security/sast/ \"SAST\"))\n\n- les tests dynamiques de sécurité des applications\n([DAST](https://docs.gitlab.com/ee/user/application_security/dast/ \"DAST\"))\n\n\nCi-dessous, consultez notre guide interactif qui vous montre comment ajouter\ndes scans de sécurité à votre pipeline CI. \n\n\nCliquez sur l'image ci-dessous pour commencer. \n\n\n[![Scans product\ntour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.44.42.png)](https://gitlab.navattic.com/gitlab-scans)\n\n\nGrâce à l'IA et à ses capacités d'analyse, nous pouvons également obtenir\ndes suggestions sur la manière dont les vulnérabilités peuvent être\ncorrigées. Consultez cette démonstration pour plus d'informations.\n\n\nCliquez sur l'image ci-dessous pour commencer. \n\n\n[![product tour explain vulnerability\n](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.50.24.png)](https://tech-marketing.gitlab.io/static-demos/pt-explain-vulnerability.html)\n\n\n## Récapitulatif\n\n\nDans cet article, nous avons volontairement simplifié les exemples afin de\nfaciliter l'intégration des différents concepts de GitLab CI.\n\n\nRésumons rapidement ce que nous avons appris :\n\n1. Pour déléguer certaines tâches à GitLab CI, vous devez définir un ou\nplusieurs [jobs](https://docs.gitlab.com/ee/ci/jobs/) dans `.gitlab-ci.yml`.\n\n2. Les jobs doivent avoir des noms, de préférence facilement identifiables.\n\n3. Chaque job contient un ensemble de règles et d'instructions pour le\npipeline de GitLab. Ces derniers sont définis par des mots-clés spécifiques.\n\n4. Les jobs peuvent s'exécuter de manière séquentielle, en parallèle, ou\ndans l'ordre de votre choix grâce aux graphes acycliques orientés. \n\n5. Vous pouvez transférer des fichiers entre les jobs et les stocker dans\ndes artefacts de compilation afin de pouvoir les télécharger depuis\nl'interface de GitLab CI.\n\n6. Ajoutez [des tests et des scans de\nsécurité](https://docs.gitlab.com/ee/development/integrations/secure.html\n\"Tests et scans de sécurité\") au pipeline CI pour garantir la qualité et la\nsécurité de votre application.\n\n\nCi-dessous se trouvent des descriptions des termes et des mots-clés que nous\navons abordés dans cet article.\n\n\n### Mots-clés, descriptions et documentation\n\n\n{: #keywords}\n\n\n| Mots-clés/termes       | Description |\n\n|---------------|--------------------|\n\n| [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/) | Fichier contenant\ntoutes les explications sur la façon dont votre projet doit être construit |\n\n| [script](https://docs.gitlab.com/ee/ci/yaml/#script)        | Définit un\nscript shell à exécuter |\n\n| [before_script](https://docs.gitlab.com/ee/ci/yaml/#before_script) |\nUtilisé pour définir la commande qui doit être exécutée avant tous les jobs\n|\n\n|\n[image](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-image)\n| Définit l’image Docker à utiliser |\n\n| [stages](https://docs.gitlab.com/ee/ci/yaml/#stages)         | Définit une\nétape du pipeline CI (par défaut : `test`) |\n\n| [artifacts](https://docs.gitlab.com/ee/ci/yaml/#artifacts)     | Définit\nune liste d'artefacts de compilation |\n\n|\n[artifacts:expire_in](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in)\n| Utilisé pour supprimer les artefacts téléchargés après une durée spécifiée\n|\n\n| [needs](https://docs.gitlab.com/ee/ci/yaml/#needs) | Permet de définir les\ndépendances entre les jobs et permet d'exécuter des jobs dans l'ordre de\nvotre choix |\n\n| [pipelines](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/) |\nUn pipeline est un groupe de compilations exécutées par étapes (batch) |\n\n\n## En savoir plus sur les pipelines CI/CD\n\n\n- [Quelles sont les meilleures pratiques CI/CD à connaître\n?](https://about.gitlab.com/fr-fr/blog/how-to-keep-up-with-ci-cd-best-practices/\n\"Quelles sont les meilleures pratiques CI/CD à connaître ?\")\n\n- [Le guide CI/CD de GitLab pour les\ndébutants](https://about.gitlab.com/blog/beginner-guide-ci-cd/)\n\n- [Obtenez des pipelines plus rapides et plus flexibles avec un graphe\nacyclique orienté](https://about.gitlab.com/blog/directed-acyclic-graph/)\n\n- [Réduisez le temps de compilation avec une image Docker\npersonnalisée](http://beenje.github.io/blog/posts/gitlab-ci-and-conda/)\n\n- [Présentation de la version bêta du catalogue GitLab\nCI/CD](https://about.gitlab.com/blog/introducing-the-gitlab-ci-cd-catalog-beta/)\n\n\n## FAQ sur le pipeline d’intégration continue\n\n\n### Comment choisir entre l'exécution séquentielle et parallèle des jobs\ndans un pipeline CI ?\n\n\nIl y a plusieurs considérations à prendre en compte pour choisir entre\nl'exécution séquentielle et parallèle des jobs dans un pipeline CI. Ainsi,\nil faut considérer les dépendances entre les jobs, la disponibilité des\nressources, les temps d'exécution, les interférences potentielles, la\nstructure de la séquence de tests ou encore les coûts que cela implique. \n\n\nPar exemple, si vous avez un job de compilation qui doit se terminer avant\nqu'un job de déploiement puisse démarrer, vous exécuterez ces jobs de\nmanière séquentielle pour garantir le bon ordre d'exécution. En revanche,\nles tâches telles que les tests unitaires et les tests d'intégration peuvent\ngénéralement s'exécuter en parallèle, car elles ne dépendent pas de\nl'achèvement des autres.\n\n\n### Que sont les graphes acycliques orientés dans GitLab et comment\naméliorent-ils la flexibilité du pipeline CI ?\n\n\nUn graphe acyclique orienté dans un pipeline CI permet d'exécuter des jobs\nen fonction de leurs dépendances, plutôt que dans un ordre strictement\nséquentiel. Ce graphe vous permet ainsi de définir un ordre d'exécution des\njobs pour que ceux des étapes ultérieures commencent dès que les jobs des\nétapes précédentes se terminent. Cela réduit le temps d'exécution global du\npipeline, améliore l'efficacité et laisse même à certains jobs la\npossibilité de se terminer plus tôt que s'ils avaient été exécutés dans un\nordre purement séquentiel (du premier au dernier dans la liste).\n\n\n### Pourquoi est-il important de choisir la bonne image Docker pour les jobs\nd'un pipeline CI GitLab ?\n\n\nGitLab utilise des images Docker pour exécuter des jobs dont l'image par\ndéfaut est ruby 3.1. Pour optimiser votre pipeline CI, il sera cependant\ncrucial de choisir l'image la plus appropriée à vos besoins. Comprenez que\nles jobs téléchargent d'abord l'image Docker spécifiée. Si l'image contient\ndes paquets supplémentaires inutiles, cela augmentera les temps de\ntéléchargement et d'exécution. Il est donc important de s'assurer que\nl'image choisie contient uniquement les paquets essentiels afin d'éviter des\nretards inutiles dans l'exécution des jobs.\n\n\n### Prochaines étapes\n\n\nPour moderniser davantage vos pratiques de développement logiciel, consultez\nle [catalogue GitLab\nCI/CD](https://docs.gitlab.com/ee/architecture/blueprints/ci_pipeline_components/)\npour savoir comment standardiser et réutiliser les composants CI/CD.\n",[9,686],"2025-01-07",{"slug":869,"featured":6,"template":690},"basics-of-gitlab-ci-updated","content:fr-fr:blog:basics-of-gitlab-ci-updated.yml","Basics Of Gitlab Ci Updated","fr-fr/blog/basics-of-gitlab-ci-updated.yml","fr-fr/blog/basics-of-gitlab-ci-updated",1,[667,695,718,742,765,785,808,831],1758662386612]