[{"data":1,"prerenderedAt":854},["ShallowReactive",2],{"/en-us/blog/tags/cd/":3,"navigation-fr-fr":20,"banner-fr-fr":441,"footer-fr-fr":454,"CD-tag-page-fr-fr":666},{"_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/cd","tags",false,"",{"tag":9,"tagSlug":10},"CD","cd",{"template":12},"BlogTag","content:en-us:blog:tags:cd.yml","yaml","Cd","content","en-us/blog/tags/cd.yml","en-us/blog/tags/cd","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","/fr-fr/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},"/fr-fr/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":662,"_type":14,"title":663,"_source":16,"_file":664,"_stem":665,"_extension":19},"/shared/fr-fr/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":653},"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,590,624],{"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,574,576,578,580,582,584,586,588],{"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":573,"dataGaLocation":463},"/customers/",{"text":239,"config":575},{"href":241,"dataGaName":242,"dataGaLocation":463},{"text":249,"config":577},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":262,"config":579},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":254,"config":581},{"href":256,"dataGaName":257,"dataGaLocation":463},{"text":267,"config":583},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":585},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":587},{"href":279,"dataGaName":280,"dataGaLocation":463},{"text":282,"config":589},{"href":284,"dataGaName":285,"dataGaLocation":463},{"title":300,"links":591},[592,594,596,598,600,602,604,608,613,615,617,619],{"text":307,"config":593},{"href":309,"dataGaName":302,"dataGaLocation":463},{"text":312,"config":595},{"href":314,"dataGaName":315,"dataGaLocation":463},{"text":320,"config":597},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":599},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":601},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":335,"config":603},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":605,"config":606},"Sustainability",{"href":607,"dataGaName":605,"dataGaLocation":463},"/sustainability/",{"text":609,"config":610},"Diversité, inclusion et appartenance (DIB)",{"href":611,"dataGaName":612,"dataGaLocation":463},"/fr-fr/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":614},{"href":342,"dataGaName":343,"dataGaLocation":463},{"text":350,"config":616},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":355,"config":618},{"href":357,"dataGaName":358,"dataGaLocation":463},{"text":620,"config":621},"Déclaration de transparence sur l'esclavage moderne",{"href":622,"dataGaName":623,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":360,"links":625},[626,629,631,633,638,643,648],{"text":627,"config":628},"Échanger avec un expert",{"href":37,"dataGaName":38,"dataGaLocation":463},{"text":369,"config":630},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":374,"config":632},{"href":376,"dataGaName":377,"dataGaLocation":463},{"text":634,"config":635},"Statut",{"href":636,"dataGaName":637,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":639,"config":640},"Conditions d'utilisation",{"href":641,"dataGaName":642},"/terms/","terms of use",{"text":644,"config":645},"Déclaration de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":463},"/fr-fr/privacy/","privacy statement",{"text":649,"config":650},"Préférences en matière de cookies",{"dataGaName":651,"dataGaLocation":463,"id":652,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,660],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":463},{"text":658,"config":659},"Politique de confidentialité",{"href":646,"dataGaName":647,"dataGaLocation":463},{"text":649,"config":661},{"dataGaName":651,"dataGaLocation":463,"id":652,"isOneTrustButton":91},"content:shared:fr-fr:main-footer.yml","Main Footer","shared/fr-fr/main-footer.yml","shared/fr-fr/main-footer",{"allPosts":667,"featuredPost":830,"totalPagesCount":852,"initialPosts":853},[668,697,721,743,765,785,808],{"_path":669,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":670,"content":678,"config":690,"_id":693,"_type":14,"title":694,"_source":16,"_file":695,"_stem":696,"_extension":19},"/fr-fr/blog/demystifying-ci-cd-variables",{"title":671,"description":672,"ogTitle":671,"ogDescription":672,"noIndex":6,"ogImage":673,"ogUrl":674,"ogSiteName":675,"ogType":676,"canonicalUrls":674,"schema":677},"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","https://about.gitlab.com","article","\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":671,"description":672,"authors":679,"heroImage":673,"date":681,"body":682,"category":683,"tags":684,"updatedDate":689},[680],"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","engineering",[9,685,686,687,109,688],"features","inside GitLab","CI","tutorial","2025-01-28",{"slug":691,"featured":6,"template":692},"demystifying-ci-cd-variables","BlogPost","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":698,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":699,"content":705,"config":715,"_id":717,"_type":14,"title":718,"_source":16,"_file":719,"_stem":720,"_extension":19},"/fr-fr/blog/ensuring-compliance",{"ogTitle":700,"schema":701,"ogImage":702,"ogDescription":703,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":704,"title":700,"canonicalUrls":704,"description":703},"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":702,"body":706,"authors":707,"updatedDate":710,"date":711,"title":712,"tags":713,"description":703,"category":714},"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",[708,709],"Beatriz Barbosa","Fernando Diaz","2025-07-21","2022-04-04","Séparation des tâches et conformité avec GitLab : le guide",[687,9],"security",{"slug":716,"featured":6,"template":692},"ensuring-compliance","content:fr-fr:blog:ensuring-compliance.yml","Ensuring Compliance","fr-fr/blog/ensuring-compliance.yml","fr-fr/blog/ensuring-compliance",{"_path":722,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":723,"content":729,"config":737,"_id":739,"_type":14,"title":740,"_source":16,"_file":741,"_stem":742,"_extension":19},"/fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"title":724,"description":725,"ogTitle":724,"ogDescription":725,"noIndex":6,"ogImage":726,"ogUrl":727,"ogSiteName":675,"ogType":676,"canonicalUrls":727,"schema":728},"Du code à la production : guide du déploiement continu avec GitLab","Découvrez comment créer un pipeline de déploiement continu robuste dans GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Du code à la production : guide du déploiement continu avec GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Benjamin Skierlak\"},{\"@type\":\"Person\",\"name\":\"James Wormwell\"}],\n        \"datePublished\": \"2025-01-28\",\n      }\n                  ",{"title":724,"description":725,"authors":730,"heroImage":726,"date":689,"body":733,"category":734,"tags":735,"updatedDate":736},[731,732],"Benjamin Skierlak","James Wormwell","Le déploiement continu est une pratique qui change la donne et qui permet aux équipes d'offrir de la valeur plus rapidement, avec une confiance accrue. Cependant, adopter des workflows de déploiement avancés, tels que [GitOps](https://about.gitlab.com/fr-fr/topics/gitops/ \"Qu'est-ce que GitOps ? \"), l'orchestration de conteneurs avec [Kubernetes](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes, la solution d’orchestration des conteneurs\") ou les environnements dynamiques, peut être intimidant pour les équipes non expérimentées.\n\nChez GitLab, nous nous engageons à ce que la livraison de logiciels soit sans accroc et évolutive. En permettant aux équipes de se concentrer sur les fondamentaux, nous leur donnons les moyens d'établir une base solide qui soutient la croissance et de mettre en place des stratégies plus complexes au fil du temps. \n\nDans ce guide, découvrez les étapes clés pour mettre en œuvre le déploiement continu avec GitLab et poser les bases d'une réussite à long terme.\n\n## Commencez par planifier votre workflow\n\nAvant de passer à la mise en œuvre technique, prenez le temps de planifier votre workflow de déploiement. Une planification minutieuse et une approche méthodique sont les clés du succès.\n\n### Stratégie de gestion des artefacts\n\nDans le contexte du déploiement continu, les artefacts désignent les fichiers empaquetés suite au processus de compilation, destinés à être stockés, déployés et dont vous devez gérer les versions. \n\nEn voici quelques exemples :\n\n- images de conteneurs pour vos applications\n- paquets\n- exécutables ou fichiers binaires compilés\n- bibliothèques\n- fichiers de configuration\n- packages de documentation\n- autres artefacts\n\nChaque type d'artefact joue un rôle spécifique dans votre processus de déploiement. Par exemple, une application web typique peut générer les artefacts suivants :\n\n- une image de conteneur pour le service backend\n- une archive ZIP des ressources frontend compilées\n- des fichiers SQL pour les modifications de base de données\n- des fichiers de configuration propres à l'environnement\n\nLa gestion efficace de ces artefacts est cruciale pour la réussite des déploiements. Voici comment aborder la gestion des artefacts.\n\n#### Artefacts et stratégies de contrôle des versions\n\nUne bonne pratique permettant de démarrer avec une structure bien organisée consiste à établir une stratégie de gestion des versions claire pour vos artefacts. \n\nLors de la création de nouvelles versions :\n\n- Utilisez la gestion sémantique de version (major.minor.patch) pour les tags de version\n  - Exemple : `myapp:1.2.3` pour une version stable\n  - Modifications de la version majeure (2.0.0) pour les changements cassants\n  - Modifications de la version mineure (1.3.0) pour les nouvelles fonctionnalités\n  - Modifications de la version des correctifs (1.2.4) pour les corrections de bugs\n- Conservez un tag 'latest' pour la version stable la plus récente\n  - Exemple : `myapp:latest` pour les déploiements automatisés\n- Incluez un SHA de validation pour un suivi précis des versions\n  - Exemple : `myapp:1.2.3-abc123f` pour le débogage\n- Utilisez des tags basés sur les branches pour les environnements de développement\n  - Exemple : `myapp:feature-user-auth` pour les tests de fonctionnalités\n\n#### Rétention des artefacts de compilation\n\nMettez en œuvre des règles de durée de rétention définies :\n\n- Définissez des délais d'expiration explicites pour les artefacts temporaires\n- Définissez les artefacts nécessitant une durée de rétention permanente\n- Configurez des stratégies de nettoyage pour gérer le stockage\n\n#### Accès au registre et authentification\n\nSécurisez vos artefacts avec des contrôles d'accès appropriés :\n\n- Implémentez des jetons d'accès personnels (Personal Access Tokens) pour l'accès des développeurs\n- Configurez des variables CI/CD pour l'authentification du pipeline\n- Mettez en place des portées d'accès appropriées\n\n### Stratégie d’environnement de déploiement \n\nRéfléchissez dès le départ à la configuration de vos environnements, car ils façonnent l'ensemble de votre pipeline de déploiement :\n\n- Configurations de l'environnement de développement, de préproduction et de production\n- Variables et secrets propres à l'environnement\n- Contrôles d'accès et règles de protection\n- Approche de suivi et de surveillance du déploiement\n\n### Cibles de déploiement\n\nIl est important de réfléchir à la cible de déploiement et à l'approche choisie, tout en prenant en compte les avantages et les inconvénients de ces décisions :\n\n- Besoins en infrastructure (machines virtuelles, conteneurs, services cloud)\n- Configurations de la sécurité et de l'accès au réseau\n- Mécanismes d'authentification (clés SSH, jetons d'accès)\n- Éléments à prendre en compte pour l'allocation des ressources et la mise à l'échelle\n\nLorsque vous avez défini votre stratégie et pris les décisions fondamentales, vous pouvez transformer cette planification en un pipeline fonctionnel. Nous allons créer un exemple concret qui démontre ces concepts, en commençant par une application simple à laquelle nous ajouterons progressivement des fonctionnalités de déploiement.\n\n## Mettez en œuvre votre pipeline CD\n\n### Exemple pas à pas\n\nExaminons comment mettre en œuvre un pipeline de déploiement continu de base pour une application web. Nous utiliserons une application HTML simple à titre d'exemple, mais ces principes s'appliquent à tout type d'application. Nous allons également déployer notre application sous la forme d'une image Docker sur une simple machine virtuelle. Cela nous permettra de nous appuyer sur une image organisée avec un minimum de dépendances et de nous assurer qu'aucun prérequis propre à l'environnement n'est introduit involontairement. En travaillant sur une machine virtuelle, nous ne ferons pas appel aux intégrations natives de GitLab, ce qui nous permettra de travailler sur une configuration plus simple, quoique moins évolutive.\n\n#### Prérequis\n\nDans cet exemple, nous allons conteneuriser une application qui s'exécutera sur une machine virtuelle hébergée sur la plateforme d'un fournisseur de services cloud. Nous testerons également cette application localement sur notre machine. Cette liste de prérequis n'est nécessaire que pour notre scénario.\n\n##### Configuration de la machine virtuelle\n\n- Provisionnez une machine virtuelle sur la plateforme de votre fournisseur de services cloud préféré (par exemple, GCP, AWS, Azure).\n- Configurez les règles du réseau pour autoriser l'accès sur les ports 22, 80 et 443.\n- Enregistrez l'adresse IP publique de la machine pour le déploiement.\n\n##### Configuration de l'authentification SSH :\n\n- Générez une paire de clés publique/privée pour la machine.\n- Dans GitLab, accédez à **Paramètres > CI/CD > Variables**.\n- Créez une variable nommée `GITLAB_KEY`.\n- Définissez le type sur « Fichier » (requis pour l'authentification SSH).\n- Collez la clé privée dans le champ Valeur.\n- Définissez une variable USER (utilisateur qui se connecte et exécute les scripts sur votre machine virtuelle).\n\n##### Configuration des variables de déploiement\n\n- Créez des variables pour vos cibles de déploiement :\n  - `STAGING_TARGET` : l'adresse IP/le domaine de votre serveur de préproduction\n  - `PRODUCTION_TARGET` : l'adresse IP/le domaine de votre serveur de production\n\n##### Configuration du développement local\n\n- Installez Docker sur votre machine locale pour tester les déploiements.\n\n##### Accès au registre de conteneurs GitLab\n\n- Localisez votre chemin d'accès au registre :\n  - Accédez à **Déploiement > Registre de conteneurs**.\n- Copiez le chemin d'accès au registre (par exemple, registry.gitlab.com/group/project).\n- Configurez l'authentification :\n  - Accédez au menu **Paramètres > Jetons d'accès**.\n  - Créez un jeton avec un accès au registre.\n  - Expiration du jeton : maximum 1 an.\n  - Enregistrez le jeton de façon sécurisée.\n- Configurez l'accès au registre local :\n\n```\ndocker login registry.gitlab.com\n# The username if you are using a PAT is gitlab-ci-token\n# Password: your-access-token\n```\n\n#### 1. Création de votre application\n\nCommencez avec une application web de base. Dans notre exemple, nous utilisons une page HTML simple :\n\n```\n\u003C!|||UNTRANSLATED_CONTENT_START|||-- index.html -->\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!|||UNTRANSLATED_CONTENT_END|||-- Your content here -->\n  \u003C/body>\n\u003C/html>\n```\n\n#### 2. Conteneurisation de votre application\n\nCréez un Dockerfile pour empaqueter votre application :\n\n```\nFROM nginx:1.26.2\nCOPY index.html /usr/share/nginx/html/index.html\n```\n\nCe Dockerfile :\n\n- Utilise nginx comme image de base pour diffuser du contenu web\n- Copie votre fichier HTML au bon endroit dans la structure du répertoire nginx\n\n#### 3. Configuration de votre pipeline CI/CD\n\nCréez un fichier `.gitlab-ci.yml` pour définir les étapes de votre [pipeline CI/CD](https://about.gitlab.com/fr-fr/topics/ci-cd/cicd-pipeline/ \"Qu'est-ce qu'un pipeline CI/CD ?\") :\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\nDécomposons ce code :\n\n`TAG_LATEST` est composé de trois parties :\n\n- `$CI_REGISTRY_IMAGE` est le chemin d'accès au registre des conteneurs de votre projet dans GitLab.\n\nPar exemple : `registry.gitlab.com/your-group/your-project`\n\n- `$CI_COMMIT_REF_NAME` est le nom de votre branche ou tag.\n\nPar exemple, si vous travaillez sur la branche principale : `/main`, et si vous travaillez sur une branche de fonctionnalité : `/feature-login`\n\n- `:latest` est un suffixe fixe.\n\nAinsi, si vous êtes sur la branche principale, `TAG_LATEST` devient `registry.gitlab.com/your-group/your-project/main:latest`.\n\n`TAG_COMMIT` est presque identique, mais au lieu de `:latest`, il utilise : `$CI_COMMIT_SHA`, qui est l'identifiant de commit, par exemple `:abc123def456`.\n\nAinsi, pour ce même commit sur la branche principale, `TAG_COMMIT` devient :` registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\nLa présence de ces deux variables s'explique par le fait que `TAG_LATEST` vous permet facilement de toujours obtenir la version la plus récente. `TAG_COMMIT` vous fournit une version spécifique à laquelle vous pouvez revenir si nécessaire.\n\n#### 4. Publication dans le registre de conteneurs\n\nAjoutez le job de publication à votre pipeline :\n\n```\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\nCe job :\n\n- Utilise Docker-in-Docker pour compiler des images\n- Crée deux versions avec tag de votre image\n- S'authentifie auprès du registre GitLab\n- Effectue un push des deux versions vers le registre \n\nMaintenant que vos images sont stockées de façon sécurisée dans le registre, vous pouvez vous concentrer sur leur déploiement dans vos environnements cibles. Commençons par des tests locaux pour valider notre configuration avant de passer aux déploiements dans l'environnement de production.\n\n#### 5. Déploiement dans votre environnement\n\nAvant le déploiement en production, vous pouvez effectuer un test localement. Nous venons de publier notre image dans le dépôt GitLab, pour lequel nous allons effectuer un pull localement. Si vous ne connaissez pas le chemin d'accès exact, accédez à **Déploiement > Registre de conteneurs**. Vous devriez voir une icône permettant de copier le chemin d'accès de votre image à la fin de la ligne pour l'image de conteneur que vous souhaitez tester.\n\n```\ndocker login registry.gitlab.com \ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n```\n\nCe faisant, vous devriez être en mesure d'accéder à votre application localement sur votre adresse localhost via votre navigateur web.\n\nVous pouvez maintenant ajouter un job de déploiement à votre pipeline :\n\n```\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER \n      docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\nCe job :\n\n- Configure l'accès SSH à votre cible de déploiement\n- Effectue un pull de l'image la plus récente\n- Supprime tout conteneur existant\n- Déploie la nouvelle version\n\n#### 6. Suivi des déploiements\n\nActivez le suivi des déploiements en ajoutant la configuration de l'environnement :\n\n```\ndeploy:\n  environment:\n    name: production\n    url: https://your-application-url.com \n```\n\nCela crée un objet environnement dans la section **Exploitation > Environnements** de GitLab et fournit :\n\n- L'historique de déploiement\n- Le statut de déploiement actuel\n- Un accès rapide à votre application\n\nBien qu'un pipeline d'environnement unique soit un bon point de départ, la plupart des équipes doivent gérer plusieurs environnements, dont des environnements de test et de préproduction. Étoffons notre pipeline pour gérer ce scénario plus réaliste.\n\n#### 7. Configuration de plusieurs environnements\n\nPour obtenir un pipeline plus robuste, configurez les déploiements de préproduction et de production :\n\n```\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # deployment script here\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # deployment script here\n```\n\nCette configuration :\n\n- Effectue un déploiement vers l'environnement de préproduction à partir de votre branche principale\n- Utilise les tags GitLab pour déclencher les déploiements de production\n- Fournit un suivi distinct pour chaque environnement\n\nQue ce soit à cette étape ou à l'étape suivante, nous tirons parti des tags, qui sont une fonctionnalité très utile de GitLab. En créant manuellement un tag dans la section **Code > Tags**, `$CI_COMMIT_TAG` est créé, ce qui nous permet de déclencher des jobs en conséquence.\n\n#### 8. Création de notes de version automatisées\n\nNous utiliserons les fonctionnalités de gestion des versions de GitLab depuis notre pipeline CI/CD. Commencez par mettre à jour les étapes de votre pipeline CI/CD dans `.gitlab-ci.yml` :\n\n```\nstages:\n\n- publish\n- staging\n- release # New stage for releases\n- version\n- production\n```\n\nEnsuite, ajoutez le job de release :\n\n```\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # Only run when a tag is created\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # Release configuration\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # The tag to create\n    ref: '$CI_COMMIT_TAG'                # The tag to base release on\n```\n\nVous pouvez l'améliorer en ajoutant des liens vers vos images de conteneurs :\n\n```\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\nPour générer des notes de version automatisées pertinentes :\n\n- Utilisez des commits conventionnels (feat:, fix:, et autres commandes.).\n- Incluez les numéros de ticket (#123).\n- Séparez le sujet du corps par un saut de ligne.\n\nSi vous souhaitez des notes de version personnalisées avec des informations de déploiement :\n\n```\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\nUne fois configurées, les versions sont créées automatiquement lorsque vous ajoutez un tag [Git](https://about.gitlab.com/fr-fr/blog/what-is-git/ \"Qu'est-ce que Git ? \"). Vous pouvez les afficher dans GitLab sous **Déploiement > Releases**.\n\n#### 9. Assemblage\n\nVoici à quoi ressemble notre fichier YAML final :\n\n```\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# Build and publish to registry\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# Deploy to staging\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# Create release\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'Container Image'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# Version the image with release tag\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# Deploy to production\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\nCe pipeline complet :\n\n- Publie des images dans le registre (branche principale)\n- Déploie vers l'environnement de préproduction (branche principale)\n- Crée des versions (lorsqu'un tag est ajouté)\n- Crée des versions d'images avec des tags de version \n- Déploie dans l'environnement de production (lorsqu'un tag est créé)\n\nPrincipaux avantages :\n\n- Environnement de développement et de test local propre et reproductible\n- Chemin d'accès clair vers les environnements de production avec une structure qui renforce la confiance dans ce qui est déployé\n- Modèle pour se remettre de défaillances inattendues, entre autres\n- Possibilité de développement sur cette base et d'adoption de stratégies de déploiement plus complexes\n\n### Bonnes pratiques\n\nTout au long de la mise en œuvre, respectez les principes suivants :\n\n- Documentez tout, de l'utilisation des variables aux procédures de déploiement.\n- Utilisez les fonctionnalités intégrées de GitLab (environnements, releases, registre).\n- Mettez en œuvre des contrôles d'accès et des mesures de sécurité adaptés.\n- Pensez aux éventuelles défaillances en mettant en place des procédures de restauration robustes.\n- Évitez les redondances dans vos configurations de pipeline en suivant le principe DRY (Don't Repeat Yourself).\n\n## Mise à l'échelle de votre stratégie de déploiement\n\nPour terminer, voici quelques aspects à prendre en compte à mesure que votre stratégie de déploiement continu évolue.\n\n### Mesures de sécurité avancées\n\nAméliorez la sécurité grâce aux fonctionnalités suivantes :\n\n- Environnements protégés avec accès restreint\n- Approbations requises pour les déploiements en production\n- Scanning de sécurité intégré\n- Évaluations automatisées des vulnérabilités\n- Règles de protection des branches pour les modifications liées au déploiement\n\n### Stratégies de livraison progressive\n\nMettez en œuvre des stratégies de déploiement avancées :\n\n- Feature flags pour les déploiements contrôlés\n- Déploiements canari pour l'atténuation des risques\n- Stratégies de déploiement bleu-vert\n- Capacités de test A/B\n- Gestion dynamique de l'environnement\n\n### Surveillance et optimisation\n\nMettez en place des pratiques de surveillance robustes :\n\n- Suivi des mesures de déploiement\n- Mise en place d'un suivi des performances\n- Configuration d'alertes de déploiement\n- Établissement d'objectifs de niveau de service (SLO) en matière de déploiement\n- Optimisation régulière du pipeline\n\n## Pourquoi utiliser GitLab ?\n\nLa plateforme GitLab est idéale pour les workflows de déploiement modernes grâce à ses fonctionnalités de déploiement continu. Elle permet de simplifier les étapes menant du code à la production, en offrant un registre de conteneurs intégré, une gestion de l'environnement et le suivi des déploiements au sein d'une seule interface. Les variables propres à l'environnement, les portes d'approbation de déploiement et les fonctionnalités de restauration de GitLab fournissent la sécurité et le contrôle nécessaires aux déploiements en production, tandis que les fonctionnalités telles que les versions temporaires d'applications et les feature flags offrent des approches de livraison progressive. Ces fonctionnalités de déploiement continu font partie intégrante de la plateforme [DevSecOps](https://about.gitlab.com/fr-fr/topics/devsecops/ \"Qu'est-ce que DevSecOps ?\") complète de GitLab et s'intègrent parfaitement à l'ensemble du cycle de vie de vos logiciels.\n\n## Lancez-vous dès aujourd'hui\n\nOpter pour un déploiement continu est une évolution, pas une révolution. Commencez par les fondamentaux, établissez une base solide et intégrez progressivement des fonctionnalités avancées lorsque les besoins de votre équipe augmentent. GitLab fournit les outils et la flexibilité nécessaires pour vous accompagner à chaque étape de ce parcours, de votre premier déploiement automatisé aux pipelines de livraison complexes et multi-environnements.\n\n> [Essayez GitLab Ultimate gratuitement](https://about.gitlab.com/fr-fr/free-trial/devsecops/) et commencez votre déploiement continu dès aujourd'hui.","product",[9,109,685,734,688],"2025-03-24",{"slug":738,"featured":6,"template":692},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","content:fr-fr:blog:from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab","fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","fr-fr/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"_path":744,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":745,"content":751,"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":746,"description":747,"ogTitle":746,"ogDescription":747,"noIndex":6,"ogImage":748,"ogUrl":749,"ogSiteName":675,"ogType":676,"canonicalUrls":749,"schema":750},"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":746,"description":747,"authors":752,"heroImage":748,"date":754,"body":755,"category":734,"tags":756,"updatedDate":758},[753],"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",[109,687,9,757,734,688],"DevSecOps platform","2025-05-26",{"slug":760,"featured":91,"template":692},"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":748,"ogDescription":770,"ogSiteName":675,"noIndex":6,"ogType":676,"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":748,"body":773,"authors":774,"date":776,"title":768,"tags":777,"description":770,"category":734,"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",[734,688,687,9,109,685],"2025-06-10",{"slug":780,"featured":91,"template":692},"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":675,"ogType":676,"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",[687,9,800],"DevOps","2024-10-17",{"slug":803,"featured":6,"template":692},"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":824,"_id":826,"_type":14,"title":827,"_source":16,"_file":828,"_stem":829,"_extension":19},"/fr-fr/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"ogTitle":811,"schema":812,"ogImage":813,"ogDescription":814,"ogSiteName":675,"noIndex":6,"ogType":676,"ogUrl":815,"title":811,"canonicalUrls":815,"description":814},"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":813,"body":817,"authors":818,"updatedDate":820,"date":821,"title":822,"tags":823,"description":814,"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",[819],"Olivier Dupré","2025-01-09","2024-09-26","Déployer en continu dans de multiples environnements avec les pipelines enfants",[109,687,9,757,688],{"slug":825,"featured":6,"template":692},"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":831,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":832,"content":838,"config":846,"_id":848,"_type":14,"title":849,"_source":16,"_file":850,"_stem":851,"_extension":19},"/fr-fr/blog/ci-deployment-and-environments",{"title":833,"description":834,"ogTitle":833,"ogDescription":834,"noIndex":6,"ogImage":835,"ogUrl":836,"ogSiteName":675,"ogType":676,"canonicalUrls":836,"schema":837},"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","\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":833,"description":834,"authors":839,"heroImage":835,"date":842,"body":843,"category":683,"tags":844,"updatedDate":845},[840,841],"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",[687,9,688],"2024-11-21",{"slug":847,"featured":6,"template":692},"ci-deployment-and-environments","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",1,[668,697,721,743,765,785,808],1758326276301]