[{"data":1,"prerenderedAt":1162},["ShallowReactive",2],{"/en-us/blog/tags/ci-cd/":3,"navigation-de-de":20,"banner-de-de":440,"footer-de-de":453,"CI/CD-tag-page-de-de":663},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/ci-cd","tags",false,"",{"tag":9,"tagSlug":10},"CI/CD","ci-cd",{"template":12},"BlogTag","content:en-us:blog:tags:ci-cd.yml","yaml","Ci Cd","content","en-us/blog/tags/ci-cd.yml","en-us/blog/tags/ci-cd","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":436,"_type":14,"title":437,"_source":16,"_file":438,"_stem":439,"_extension":19},"/shared/de-de/main-navigation","de-de",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":413,"duo":427},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/de-de/","gitlab logo","header",{"text":30,"config":31},"Kostenlose Testversion anfordern",{"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},"Vertrieb kontaktieren",{"href":37,"dataGaName":38,"dataGaLocation":28},"/de-de/sales/","sales",{"text":40,"config":41},"Anmelden",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,187,192,298,358],{"text":46,"config":47,"cards":49,"footer":72},"Plattform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":53,"config":54},"Erkunde unsere Plattform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/de-de/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":60,"config":61},"Lerne GitLab Duo kennen",{"href":62,"dataGaName":63,"dataGaLocation":28},"/de-de/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":68,"config":69},"Mehr erfahren",{"href":70,"dataGaName":71,"dataGaLocation":28},"/de-de/why-gitlab/","why gitlab",{"title":73,"items":74},"Erste Schritte mit",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/de-de/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Entwicklererfahrung",{"href":83,"dataGaName":84,"dataGaLocation":28},"/de-de/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":169},"Produkt",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Alle Lösungen anzeigen",{"href":97,"dataGaName":93,"dataGaLocation":28},"/de-de/solutions/",[99,124,147],{"title":100,"description":101,"link":102,"items":107},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/de-de/solutions/delivery-automation/","automated software delivery",[108,111,115,120],{"text":9,"config":109},{"href":110,"dataGaLocation":28,"dataGaName":9},"/de-de/solutions/continuous-integration/",{"text":112,"config":113},"KI-unterstützte Entwicklung",{"href":62,"dataGaLocation":28,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"Quellcodeverwaltung",{"href":118,"dataGaLocation":28,"dataGaName":119},"/de-de/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"Automatisierte Softwarebereitstellung",{"href":105,"dataGaLocation":28,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":28,"icon":131},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,138,143],{"text":134,"config":135},"Application Security Testing",{"href":136,"dataGaName":137,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":139,"config":140},"Schutz der Software-Lieferkette",{"href":141,"dataGaLocation":28,"dataGaName":142},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":144,"dataGaLocation":28},"/solutions/software-compliance/",{"title":148,"link":149,"items":154},"Bewertung",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":28},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"Sichtbarkeit und Bewertung",{"href":152,"dataGaLocation":28,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"Wertstrommanagement",{"href":162,"dataGaLocation":28,"dataGaName":163},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"Analysen und Einblicke",{"href":167,"dataGaLocation":28,"dataGaName":168},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab für",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":28,"dataGaName":176},"/de-de/enterprise/","enterprise",{"text":178,"config":179},"Kleinunternehmen",{"href":180,"dataGaLocation":28,"dataGaName":181},"/de-de/small-business/","small business",{"text":183,"config":184},"den öffentlichen Sektor",{"href":185,"dataGaLocation":28,"dataGaName":186},"/de-de/solutions/public-sector/","public sector",{"text":188,"config":189},"Preise",{"href":190,"dataGaName":191,"dataGaLocation":28,"dataNavLevelOne":191},"/de-de/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":285},"Ressourcen",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"Alle Ressourcen anzeigen",{"href":199,"dataGaName":195,"dataGaLocation":28},"/de-de/resources/",[201,234,257],{"title":202,"items":203},"Erste Schritte",[204,209,214,219,224,229],{"text":205,"config":206},"Installieren",{"href":207,"dataGaName":208,"dataGaLocation":28},"/de-de/install/","install",{"text":210,"config":211},"Kurzanleitungen",{"href":212,"dataGaName":213,"dataGaLocation":28},"/de-de/get-started/","quick setup checklists",{"text":215,"config":216},"Lernen",{"href":217,"dataGaLocation":28,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Produktdokumentation",{"href":222,"dataGaName":223,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Best-Practice-Videos",{"href":227,"dataGaName":228,"dataGaLocation":28},"/de-de/getting-started-videos/","best practice videos",{"text":230,"config":231},"Integrationen",{"href":232,"dataGaName":233,"dataGaLocation":28},"/de-de/integrations/","integrations",{"title":235,"items":236},"Entdecken",[237,242,247,252],{"text":238,"config":239},"Kundenerfolge",{"href":240,"dataGaName":241,"dataGaLocation":28},"/de-de/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":28},"/de-de/blog/","blog",{"text":248,"config":249},"Remote",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/de-de/teamops/","teamops",{"title":258,"items":259},"Vernetzen",[260,265,270,275,280],{"text":261,"config":262},"GitLab-Services",{"href":263,"dataGaName":264,"dataGaLocation":28},"/de-de/services/","services",{"text":266,"config":267},"Community",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"Forum",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"Veranstaltungen",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"Partner",{"href":283,"dataGaName":284,"dataGaLocation":28},"/de-de/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":290,"config":291},"the source promo card",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"Lies die News",{"href":296,"dataGaName":297,"dataGaLocation":28},"/de-de/the-source/","the source",{"text":299,"config":300,"lists":302},"Unternehmen",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"Über",{"href":308,"dataGaName":309,"dataGaLocation":28},"/de-de/company/","about",{"text":311,"config":312,"footerGa":315},"Karriere",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"Geschäftsführung",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"Team",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"Handbuch",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"Investor Relations",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"Trust Center",{"href":341,"dataGaName":342,"dataGaLocation":28},"/de-de/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":28},"/de-de/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"Newsletter",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"Presse",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":359,"config":360,"lists":361},"Kontakt",{"dataNavLevelOne":301},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"Support",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"Kundenportal",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"Schließen",{"text":380,"link":381},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":382,"config":383},"gitlab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"Vorschläge",[389,392,397,399,404,409],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"Code Suggestions (KI)",{"href":395,"dataGaName":396,"dataGaLocation":385},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":9,"config":398},{"href":110,"dataGaName":9,"dataGaLocation":385},{"text":400,"config":401},"GitLab auf AWS",{"href":402,"dataGaName":403,"dataGaLocation":385},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":405,"config":406},"GitLab auf Google Cloud",{"href":407,"dataGaName":408,"dataGaLocation":385},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":410,"config":411},"Warum GitLab?",{"href":70,"dataGaName":412,"dataGaLocation":385},"Why GitLab?",{"freeTrial":414,"mobileIcon":419,"desktopIcon":424},{"text":415,"config":416},"Kostenlos testen",{"href":417,"dataGaName":33,"dataGaLocation":418},"https://gitlab.com/-/trials/new/","nav",{"altText":420,"config":421},"GitLab-Symbol",{"src":422,"dataGaName":423,"dataGaLocation":418},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":420,"config":425},{"src":426,"dataGaName":423,"dataGaLocation":418},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"Erfahre mehr über GitLab Duo",{"href":62,"dataGaName":431,"dataGaLocation":418},"gitlab duo",{"altText":420,"config":433},{"src":422,"dataGaName":423,"dataGaLocation":418},{"altText":420,"config":435},{"src":426,"dataGaName":423,"dataGaLocation":418},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":441,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":442,"button":443,"config":448,"_id":450,"_type":14,"_source":16,"_file":451,"_stem":452,"_extension":19},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":444,"config":445},"Beta testen",{"href":446,"dataGaName":447,"dataGaLocation":28},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":449},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":454,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":455,"_id":659,"_type":14,"title":660,"_source":16,"_file":661,"_stem":662,"_extension":19},"/shared/de-de/main-footer",{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":651},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":458,"config":459},"Quelltext der Seite anzeigen",{"href":460,"dataGaName":461,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":464,"config":465},"Diese Seite bearbeiten",{"href":466,"dataGaName":467,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":469,"config":470},"Beteilige dich",{"href":471,"dataGaName":472,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":474,"facebook":475,"youtube":476,"linkedin":477},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[479,502,557,587,621],{"title":46,"links":480,"subMenu":485},[481],{"text":482,"config":483},"DevSecOps-Plattform",{"href":55,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":188,"links":487},[488,492,497],{"text":489,"config":490},"Tarife anzeigen",{"href":190,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Vorteile von Premium",{"href":495,"dataGaName":496,"dataGaLocation":462},"/de-de/pricing/premium/","why premium",{"text":498,"config":499},"Vorteile von Ultimate",{"href":500,"dataGaName":501,"dataGaLocation":462},"/de-de/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Lösungen",[505,510,513,515,520,525,529,532,535,540,542,544,547,552],{"text":506,"config":507},"Digitale Transformation",{"href":508,"dataGaName":509,"dataGaLocation":462},"/de-de/topics/digital-transformation/","digital transformation",{"text":511,"config":512},"Sicherheit und Compliance",{"href":136,"dataGaName":137,"dataGaLocation":462},{"text":121,"config":514},{"href":105,"dataGaName":106,"dataGaLocation":462},{"text":516,"config":517},"Agile Entwicklung",{"href":518,"dataGaName":519,"dataGaLocation":462},"/de-de/solutions/agile-delivery/","agile delivery",{"text":521,"config":522},"Cloud-Transformation",{"href":523,"dataGaName":524,"dataGaLocation":462},"/de-de/topics/cloud-native/","cloud transformation",{"text":526,"config":527},"SCM",{"href":118,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":9,"config":530},{"href":110,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":160,"config":533},{"href":162,"dataGaName":534,"dataGaLocation":462},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":462},"/de-de/solutions/gitops/","gitops",{"text":173,"config":541},{"href":175,"dataGaName":176,"dataGaLocation":462},{"text":178,"config":543},{"href":180,"dataGaName":181,"dataGaLocation":462},{"text":545,"config":546},"Öffentlicher Sektor",{"href":185,"dataGaName":186,"dataGaLocation":462},{"text":548,"config":549},"Bildungswesen",{"href":550,"dataGaName":551,"dataGaLocation":462},"/de-de/solutions/education/","education",{"text":553,"config":554},"Finanzdienstleistungen",{"href":555,"dataGaName":556,"dataGaLocation":462},"/de-de/solutions/finance/","financial services",{"title":193,"links":558},[559,561,563,565,568,570,573,575,577,579,581,583,585],{"text":205,"config":560},{"href":207,"dataGaName":208,"dataGaLocation":462},{"text":210,"config":562},{"href":212,"dataGaName":213,"dataGaLocation":462},{"text":215,"config":564},{"href":217,"dataGaName":218,"dataGaLocation":462},{"text":220,"config":566},{"href":222,"dataGaName":567,"dataGaLocation":462},"docs",{"text":243,"config":569},{"href":245,"dataGaName":246,"dataGaLocation":462},{"text":238,"config":571},{"href":572,"dataGaName":241,"dataGaLocation":462},"/customers/",{"text":248,"config":574},{"href":250,"dataGaName":251,"dataGaLocation":462},{"text":261,"config":576},{"href":263,"dataGaName":264,"dataGaLocation":462},{"text":253,"config":578},{"href":255,"dataGaName":256,"dataGaLocation":462},{"text":266,"config":580},{"href":268,"dataGaName":269,"dataGaLocation":462},{"text":271,"config":582},{"href":273,"dataGaName":274,"dataGaLocation":462},{"text":276,"config":584},{"href":278,"dataGaName":279,"dataGaLocation":462},{"text":281,"config":586},{"href":283,"dataGaName":284,"dataGaLocation":462},{"title":299,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":306,"config":590},{"href":308,"dataGaName":301,"dataGaLocation":462},{"text":311,"config":592},{"href":313,"dataGaName":314,"dataGaLocation":462},{"text":319,"config":594},{"href":321,"dataGaName":322,"dataGaLocation":462},{"text":324,"config":596},{"href":326,"dataGaName":327,"dataGaLocation":462},{"text":329,"config":598},{"href":331,"dataGaName":332,"dataGaLocation":462},{"text":334,"config":600},{"href":336,"dataGaName":337,"dataGaLocation":462},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":462},"/sustainability/",{"text":606,"config":607},"Vielfalt, Inklusion und Zugehörigkeit",{"href":608,"dataGaName":609,"dataGaLocation":462},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":611},{"href":341,"dataGaName":342,"dataGaLocation":462},{"text":349,"config":613},{"href":351,"dataGaName":352,"dataGaLocation":462},{"text":354,"config":615},{"href":356,"dataGaName":357,"dataGaLocation":462},{"text":617,"config":618},"Transparenzerklärung zu moderner Sklaverei",{"href":619,"dataGaName":620,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":622,"links":623},"Nimm Kontakt auf",[624,627,629,631,636,641,646],{"text":625,"config":626},"Sprich mit einem Experten/einer Expertin",{"href":37,"dataGaName":38,"dataGaLocation":462},{"text":368,"config":628},{"href":370,"dataGaName":371,"dataGaLocation":462},{"text":373,"config":630},{"href":375,"dataGaName":376,"dataGaLocation":462},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":637,"config":638},"Nutzungsbedingungen",{"href":639,"dataGaName":640,"dataGaLocation":462},"/terms/","terms of use",{"text":642,"config":643},"Datenschutzerklärung",{"href":644,"dataGaName":645,"dataGaLocation":462},"/de-de/privacy/","privacy statement",{"text":647,"config":648},"Cookie-Einstellungen",{"dataGaName":649,"dataGaLocation":462,"id":650,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":462},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":462},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":462,"id":650,"isOneTrustButton":91},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"allPosts":664,"featuredPost":1142,"totalPagesCount":1160,"initialPosts":1161},[665,695,716,738,763,785,806,826,850,870,894,916,941,962,983,1007,1032,1053,1077,1101,1122],{"_path":666,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":675,"config":688,"_id":691,"_type":14,"title":692,"_source":16,"_file":693,"_stem":694,"_extension":19},"/de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"title":668,"description":669,"ogTitle":668,"ogDescription":669,"noIndex":6,"ogImage":670,"ogUrl":671,"ogSiteName":672,"ogType":673,"canonicalUrls":671,"schema":674},"Automatisierung der Migration von Container-Images von Amazon ECR zu GitLab","Wenn Plattformteams ihre CI/CD zu GitLab verschieben, sollte die Migration von Container-Images kein Engpass sein. Befolge diese Schritt-für-Schritt-Anleitung, um den Pipeline-Migrationsprozess zu automatisieren.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","https://about.gitlab.com/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisierung der Migration von Container-Images von Amazon ECR zu GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-13\",\n      }\n                  ",{"title":668,"description":669,"authors":676,"heroImage":670,"date":678,"body":679,"category":680,"tags":681,"updatedDate":687},[677],"Tim Rizzi","2025-02-13","„Wir müssen Hunderte von Container-Images von Amazon Elastic Container Registry (ECR) zu GitLab migrieren. Könnt ihr uns helfen?“ Diese Frage taucht immer wieder in Gesprächen mit Platform Engineers auf. Sie modernisierten also ihre DevSecOps-Toolchain mit GitLab, kamen aber beim Verschieben ihrer Container-Images nicht weiter. Während ein einzelner Image-Transfer einfach ist, erscheint das schiere Volumen überwältigend.\n\nEin Platform Engineer brachte es auf den Punkt: „Ich weiß genau, was zu tun ist – pullen, neu kennzeichnen, pushen. Aber ich habe 200 Microservices mit jeweils mehreren Tags. Ich kann es nicht rechtfertigen, Wochen für diese Migration aufzuwenden, während wichtige Infrastrukturarbeiten anstehen.“\n\n## Die Herausforderung\n\nDieses Gespräch führte zu einer Idee. Was wäre, wenn wir den gesamten Prozess automatisieren könnten? Wenn Plattformteams ihre [CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/) zu GitLab verschieben, sollte die Migration von Container-Images kein Engpass sein. Der manuelle Prozess ist einfach, aber repetitiv: Jedes Image pullen, neu kennzeichnen und in die Container-Registry von GitLab pushen. Angesichts dutzender Repositories und mehrerer Tags pro Image, bedeutet dies Tage oder Wochen langwieriger Arbeit.\n\n## Die Lösung\n\nWir haben uns daran gemacht, eine GitLab-Pipeline zu erstellen, die all diese schwierigen Aufgaben automatisch erledigt. Das Ziel war einfach: Wir wollten Platform Engineers ein Tool zur Verfügung stellen, das sie in wenigen Minuten einrichten und über Nacht ausführen können, sodass am nächsten Morgen alle ihre Images erfolgreich migriert wurden.\n\n### Einrichten des Zugriffs\n\nDas Wichtigste zuerst: die Sicherheit. Teams sollen diese Migration mit minimalen AWS-Berechtigungen durchführen können. Hier ist die schreibgeschützte Identitäts- und Zugriffsmanagement (IAM)-Richtlinie dafür:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"ecr:GetAuthorizationToken\",\n                \"ecr:BatchCheckLayerAvailability\",\n                \"ecr:GetDownloadUrlForLayer\",\n                \"ecr:DescribeRepositories\",\n                \"ecr:ListImages\",\n                \"ecr:DescribeImages\",\n                \"ecr:BatchGetImage\"\n            ],\n            \"Resource\": \"*\"\n        }\n    ]\n}\n```\n\n### GitLab-Konfiguration\n\nNachdem die Sicherheit gewährleistet ist, ist der nächste Schritt die Einrichtung von GitLab. Wir haben uns auf das Wesentliche beschränkt. Du musst diese Variablen in deinen CI/CD-Einstellungen konfigurieren:\n\n```\nAWS_ACCOUNT_ID: Your AWS account number\nAWS_DEFAULT_REGION: Your ECR region\nAWS_ACCESS_KEY_ID: [Masked]\nAWS_SECRET_ACCESS_KEY: [Masked]\nBULK_MIGRATE: true\n```\n\n### Die Migrationspipeline\n\nJetzt wird es interessant. Wir haben die Pipeline mit Docker-in-Docker erstellt, um alle Image-Vorgänge zuverlässig zu verarbeiten:\n\n```yaml\nimage: docker:20.10\nservices:\n  - docker:20.10-dind\n\nbefore_script:\n  - apk add --no-cache aws-cli jq\n  - aws sts get-caller-identity\n  - aws ecr get-login-password | docker login --username AWS --password-stdin\n  - docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} ${CI_REGISTRY}\n```\n\nDie Pipeline hat drei Phasen, die jeweils auf der letzten aufbauen:\n\n1. Entdeckung\n\nZuerst findet sie alle deine Repositories:\n\n```bash\nREPOS=$(aws ecr describe-repositories --query 'repositories[*].repositoryName' --output text)\n```\n\n2. Tag-Auflistung\n\nDann ruft sie für jedes Repository alle Tags ab:\n\n```bash\nTAGS=$(aws ecr describe-images --repository-name $repo --query 'imageDetails[*].imageTags[]' --output text)\n```\n\n3. Übertragung\n\nSchließlich übernimmt sie die eigentliche Migration:\n\n```bash\ndocker pull ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\ndocker tag ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag} ${CI_REGISTRY_IMAGE}/${repo}:${tag}\ndocker push ${CI_REGISTRY_IMAGE}/${repo}:${tag}\n```\n\n## Das Ergebnis\n\nErinnerst du dich an den Platform Engineer, der nicht wochenlang mit der Migration verbringen wollte? Diese Lösung bietet Folgendes:\n\n- automatisierte Erkennung und Migration aller Repositories und Tags\n- konsistente Image-Benennung zwischen ECR und GitLab\n- Fehlerbehandlung für fehlgeschlagene Übertragungen\n- klare Protokollierung zur Verfolgung des Fortschritts\n\nAnstatt Skripte zu schreiben und die Migration zu überwachen, konnte sich der Plattform Engineer auf wertvollere Arbeit konzentrieren.\n\n## Verwendung\n\nDie ersten Schritte sind einfach:\n\n1. Kopiere die Datei `.gitlab-ci.yml` in dein Repository.\n2. Konfiguriere die AWS- und GitLab-Variablen.\n3. Setze `BULK_MIGRATE` auf „true“, um die Migration zu starten.\n\n## Best Practices\n\nBei der Unterstützung von Teams bei ihren Migrationen haben wir einige Dinge gelernt:\n\n- Der Prozess sollte außerhalb der Stoßzeiten durchgeführt werden, um die Auswirkungen auf dein Team zu minimieren.\n- Die Pipeline-Protokolle sind wichtig – darin findest du Informationen, wenn es ein Problem gibt.\n- Die Elastic Container Registry (ECR) sollte erst deaktiviert werden, wenn du überprüft hast, dass alle Images erfolgreich übertragen wurden.\n- Bei sehr großen Migrationen solltest du eine Ratenbegrenzung in Betracht ziehen, um eine Überlastung deines Netzwerks zu vermeiden.\n\nWir haben diese Pipeline in unserem öffentlichen GitLab-Repository quelloffen verfügbar gemacht, weil wir der Meinung sind, dass Plattform Engineers Zeit damit verbringen sollten, wertvolle Infrastrukturen aufzubauen, anstatt Container-Images zu kopieren. Passe sie an deine Bedürfnisse an und stelle Fragen zur Implementierung, wenn etwas unklar ist.\n\n> #### Informationen dazu und zu anderen Paketkomponenten findest du in unserer [CI/CD-Katalog-Dokumentation](https://gitlab.com/explore/catalog/components/package).","engineering",[9,682,683,684,685,686],"AWS","tutorial","DevSecOps platform","product","solutions architecture","2025-04-10",{"slug":689,"featured":91,"template":690},"automating-container-image-migration-from-amazon-ecr-to-gitlab","BlogPost","content:de-de:blog:automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","Automating Container Image Migration From Amazon Ecr To Gitlab","de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"_path":696,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":697,"content":703,"config":710,"_id":712,"_type":14,"title":713,"_source":16,"_file":714,"_stem":715,"_extension":19},"/de-de/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way",{"title":698,"description":699,"ogTitle":698,"ogDescription":699,"noIndex":6,"ogImage":700,"ogUrl":701,"ogSiteName":672,"ogType":673,"canonicalUrls":701,"schema":702},"Einfaches Erstellen einer GitLab-CI/CD-Pipeline für ein Monorepo","Erfahre, wie du eine GitLab-CI/CD-Pipeline für ein Monorepo erstellst, um mehrere Anwendungen in einem Repository zu hosten.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Einfaches Erstellen einer GitLab-CI/CD-Pipeline für ein Monorepo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Morris\"}],\n        \"datePublished\": \"2024-07-30\",\n      }",{"title":698,"description":699,"authors":704,"heroImage":700,"date":706,"body":707,"category":680,"tags":708,"updatedDate":709},[705],"Sam Morris","2024-07-30","Mit Monorepos kannst du den Code von mehreren Anwendungen in einem einzigen Repository hosten. In GitLab bedeutet das, dass du den Quellcode verschiedener Anwendungen in getrennten Verzeichnissen in einem Projekt ablegen musst. So kannst du zwar deinen Code versionskontrolliert speichern, aber die [CI/CD-Pipeline von GitLab](https://about.gitlab.com/de-de/topics/ci-cd/) nicht voll ausschöpfen … bis jetzt!\n\n## Der Idealfall: CI/CD in einem Monorepo\n\nDa du mehr als den Code einer Anwendung in deinem Repository hast, wirst du mehr als eine Pipeline-Konfiguration benötigen. Wenn du z. B. eine .NET-Anwendung und eine Spring-Anwendung in einem Projekt hast, kann es sein, dass für jede Anwendung unterschiedliche Build- und Testjobs ausgeführt werden müssen. Im Idealfall kannst du die Pipelines vollständig entkoppeln und jede Pipeline nur auf der Grundlage von Änderungen am Quellcode der jeweiligen Anwendung ausführen.\n\nDer technische Ansatz hierfür wäre eine `.gitlab-ci.yml`-Pipeline-Konfigurationsdatei auf Projektebene, die eine bestimmte YAML-Datei enthält, die auf Änderungen in einem bestimmten Verzeichnis basiert. Die `.gitlab-ci.yml`-Pipeline dient als Steuerungsebene, die auf der Grundlage der Änderungen am Code die entsprechende Pipeline anstößt.\n\n## Der Legacy-Ansatz\n\nVor GitLab 16.4 war es nicht möglich, eine YAML-Datei bei Änderungen an einem Verzeichnis oder einer Datei in einem Projekt einzubinden. Wir konnten diese Funktionalität jedoch mit einem Workaround realisieren.\n\nIn unserem Monorepo-Projekt haben wir zwei Verzeichnisse für verschiedene Anwendungen. In diesem Beispiel gibt es die Verzeichnisse `java` und `python`, die jeweils eine Java- und eine Python-Anwendung repräsentieren. Jedes Verzeichnis hat eine anwendungsspezifische YAML-Datei, um jede App zu bauen. In der Pipeline-Datei des Projekts binden wir einfach beide Anwendungspipeline-Dateien ein und führen die logische Verarbeitung direkt in diesen Dateien durch.\n\n`.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\ntop-level-job:\n  stage: build\n  script:\n    - echo \"Hello world...\"\n\ninclude:\n  - local: '/java/j.gitlab-ci.yml'\n  - local: '/python/py.gitlab-ci.yml'\n\n```\n\nIn jeder anwendungsspezifischen Pipeline-Datei erstellen wir einen versteckten Auftrag mit dem Namen .java-common oder .python-common, der nur ausgeführt wird, wenn es Änderungen im Verzeichnis der jeweiligen Anwendung gibt. [Versteckte Jobs (nur in englischer Sprache verfügbar](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs) werden standardmäßig nicht ausgeführt und werden oft verwendet, um bestimmte Jobkonfigurationen wiederzuverwenden. Jede Pipeline erweitert diesen versteckten Job, um die Regeln zu übernehmen, die festlegen, welche Dateien auf Änderungen überwacht werden sollen, die dann den Pipeline-Job auslösen.\n\n`j.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\n.java-common:\n  rules:\n    - changes:\n      - '../java/*'\n\njava-build-job:\n  extends: .java-common\n  stage: build\n  script:\n    - echo \"Building Java\"\n\njava-test-job:\n  extends: .java-common\n  stage: test\n  script:\n    - echo \"Testing Java\"\n\n```\n\n`py.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\n.python-common:\n  rules:\n    - changes:\n      - '../python/*'\n\npython-build-job:\n  extends: .python-common\n  stage: build\n  script:\n    - echo \"Building Python\"\n\npython-test-job:\n  extends: .python-common\n  stage: test\n  script:\n    - echo \"Testing Python\"\n\n```\n\nDas hat einige Nachteile, z. B. muss der Job für jeden anderen Job in der YAML-Datei erweitert werden, um sicherzustellen, dass er mit den Regeln übereinstimmt, was eine Menge redundanten Code und Raum für menschliche Fehler schafft. Außerdem können erweiterte Jobs keine doppelten Schlüssel haben, so dass du nicht in jedem Job deine eigene `rules`-Logik definieren kannst, da es zu einer Kollision der Schlüssel kommen würde und ihre [Werte nicht zusammengeführt werden (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/index.html#extends). \n\nDas führt dazu, dass eine Pipeline ausgeführt wird, die die `j.gitlab-ci.yml`-Jobs enthält, wenn `java/` aktualisiert wird, und `py.gitlab-ci.yml`-Jobs, wenn `python/` aktualisiert wird.\n\n## Der neue Ansatz: Bedingtes Einbeziehen von Pipeline-Dateien\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6phvk8jioAo?si=y6ztZODvUtM-cHmZ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIn GitLab 16.4 haben wir [`include` mit `rules:changes` für Pipelines (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/includes.html#include-with-ruleschanges) eingeführt. Bisher konntest du `include` mit `rules:if` verwenden, aber nicht mit `rules:changes`. Das macht diese Aktualisierung extrem effizient. Jetzt kannst du einfach das Schlüsselwort `include` verwenden und die Monorepo-Regeln in deiner Projekt-Pipeline-Konfiguration definieren.\n\nNeue `.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n\ntop-level-job:\n  stage: build\n  script:\n    - echo \"Hello world...\"\n\ninclude:\n  - local: '/java/j.gitlab-ci.yml'\n    rules:\n      - changes:\n        - 'java/*'\n  - local: '/python/py.gitlab-ci.yml'\n    rules:\n      - changes:\n        - 'python/*'\n\n```\n\nJetzt kann sich die YAML jeder Anwendung nur noch auf das Erstellen und Testen des Codes dieser Anwendung konzentrieren, ohne dass ein versteckter Job wiederholt erweitert werden muss. Das ermöglicht mehr Flexibilität bei der Definition von Jobs und reduziert das Neuschreiben von Code für Entwickler(innen).\n\nNeue `j.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\njava-build-job:\n  stage: build\n  script:\n    - echo \"Building Java\"\n\njava-test-job:\n  stage: test\n  script:\n    - echo \"Testing Java\"\n\n```\n\nNeue `py.gitlab-ci.yml`:\n```\nstages:\n  - build\n  - test\n  - deploy\n\npython-build-job:\n  stage: build\n  script:\n    - echo \"Building Python\"\n\npython-test-job:\n  stage: test\n  script:\n    - echo \"Testing Python\"\n\n```\n\nDamit werden die Java- und Python-Jobs nur dann einbezogen, wenn ihre Verzeichnisse geändert werden. Bei deiner Implementierung solltest du bedenken, dass [Jobs unerwartet ausgeführt werden können, wenn du `changes` verwendest (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/jobs/job_troubleshooting.html#jobs-or-pipelines-run-unexpectedly-when-using-changes). Die Regel „changes“ wird immer als wahr interpretiert, wenn ein neuer Branch oder ein neues Tag in GitLab gepusht wird, so dass alle Jobs unabhängig von der Definition von `rules:changes` beim ersten Push in einen Branch ausgeführt werden. Du kannst dieses Problem umgehen, indem du zuerst deinen Feature-Branch erstellst und dann eine Merge Request öffnest, um mit der Entwicklung zu beginnen, da der erste Push auf den Branch, wenn er erstellt wird, alle Jobs zur Ausführung zwingt.\n\nLetztlich sind Monorepos eine Strategie, die mit GitLab und CI/CD genutzt werden kann. Mit unserer neuen Funktion `include` mit `rules:changes` haben wir eine bessere bewährte Methode für die Nutzung von GitLab CI mit Monorepos. Um Monorepos zu verwenden, hol dir noch heute eine kostenlose Testversion von Gitlab Ultimate.\n\n## Weitere CI/CD-Ressourcen\n\n* [5 Tipps für die Verwaltung von Monorepos in GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tips-for-managing-monorepos-in-gitlab/)\n* [Der schnelle Einstieg in CI/CD (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/)",[9,683],"2025-05-26",{"slug":711,"featured":6,"template":690},"building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way","content:de-de:blog:building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way.yml","Building A Gitlab Ci Cd Pipeline For A Monorepo The Easy Way","de-de/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way.yml","de-de/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way",{"_path":717,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":718,"content":724,"config":732,"_id":734,"_type":14,"title":735,"_source":16,"_file":736,"_stem":737,"_extension":19},"/de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":719,"description":720,"ogTitle":719,"ogDescription":720,"noIndex":6,"ogImage":721,"ogUrl":722,"ogSiteName":672,"ogType":673,"canonicalUrls":722,"schema":723},"Datengesteuerte DevSecOps: Entdecke die Dashboards von GitLab Insights","Erfahre, wie du die Dashboards von GitLab Insights nutzen kannst, um wichtige Metriken zu visualisieren, Projekte nachzuverfolgen und die Produktivität deines Teams zu steigern.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097210/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097210214.png","https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Datengesteuerte DevSecOps: Entdecke die Dashboards von GitLab Insights\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ricardo Amarilla Villalba\"}],\n        \"datePublished\": \"2024-11-20\",\n      }\n                  ",{"title":719,"description":720,"authors":725,"heroImage":721,"date":727,"body":728,"category":685,"tags":729,"updatedDate":731},[726],"Ricardo Amarilla Villalba","2024-11-20","Metriken und Analysen spielen eine entscheidende Rolle, wenn es darum geht, Produktivität, Qualität und Erfolg zu steigern. [GitLab](https://about.gitlab.com/de-de/platform/) ist eine umfassende DevSecOps-Plattform und bietet leistungsstarke Tools, um diese wichtigen Metriken über die Insights-Dashboards zu verfolgen und zu visualisieren. In diesem Artikel erfährst du, wie du die Insights-Dashboards in deiner Umgebung verwenden kannst.\n\n## Inhaltsverzeichnis\n\n- [Einführungen in GitLab-Metriken und Analysen](#einführungen-in-gitlab-metriken-und-analysen)\n- [Nutze Labels für bestimmte Metriken](#nutze-labels-für-bestimmte-metriken)\n- [So konfigurierst du GitLab Insights](#so-konfigurierst-du-gitlab-insights)\n- [Einblicke in Merge Requests anpassen](#einblicke-in-merge-requests-anpassen)\n- [Merge-Request-Einblicke für jede Squad und jeden Anforderungstyp](#merge-request-einblicke-für-jede-squad-und-jeden-anforderungstyp)\n  - [Richte Squad-basierte Metriken ein](#richte-squad-basierte-metriken-ein)\n- [Lege jetzt los](#lege-jetzt-los)\n- [Mehr erfahren](#mehr-erfahren)\n\n## Einführungen in GitLab-Metriken und Analysen\n\nGitLab stellt verschiedenste Metriken und Analysetools für unterschiedliche Aspekte des DevSecOps-Lebenszyklus bereit:\n\n1. [Produktivitätsanalyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html): Damit kannst du die Geschwindigkeit deines Teams, Bearbeitungszeiten und Abarbeitungsdauer nachverfolgen.\n2. [Code-Review-Analysen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html): Damit kannst du die Codequalität, die Testabdeckung und die Effizienz der Überprüfung messen.\n3. [CI/CD-Analyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html): Damit kannst du die Pipeline-Performance und die Bereitstellungshäufigkeit überwachen.\n4. [Wertstromanalyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/group/value_stream_analytics/): Damit kannst du den Arbeitsfluss von der Idee bis zur Produktion visualisieren.\n5. [Einblicke (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/insights/): Entdecke und visualisiere Daten über deine Projekte und Gruppen.\n\nDiese Metriken bieten wertvolle Einblicke in deinen Entwicklungsprozess und helfen Teams dabei, Engpässe zu identifizieren, Workflows zu optimieren und datengestützte Entscheidungen zu treffen.\n\n## Nutze Labels für bestimmte Metriken\n\nEine der leistungsstärksten und doch unterschätztesten Funktionen von GitLab sind Labels, mit denen du Metriken mit absoluter Präzision filtern kannst. Wenn du Labels strategisch Tickets, Merge Requests und Epics zuweist, kannst du individuelle Ansichten erstellen, die zielgenaue Einblicke in die Leistung und den Fortschritt deines Projekts bieten.\n\nLabels fungieren in GitLab als vielseitige Kennungen, mit denen du deine Workitems flexibel kategorisieren und organisieren kannst. Egal, ob du die Entwicklung von Funktionen, Bug Fixes oder teamspezifische Aufgaben nachverfolgst: Mit Labels kannst du deine Projektdaten aufschlüsseln und erkenntnisreiche Muster und Entwicklungen aufdecken. \n\nDas Konzept ist ähnlich wie Tags in Cloud-Bereitstellungen, wo die Ressourcen gekennzeichnet werden, um sie einfacher verwalten, die Kosten zuordnen und betriebliche Einblicke gewinnen zu können. Indem du deine Workitems sorgfältig mit Labels kennzeichnest, baust du ein cleveres Label-System auf, mit dem du ganz einfach individuelle Dashboards und Berichte erstellen kannst. Durch diesen Ansatz kannst du dich auf die Metriken konzentrieren, die für dein Team oder deine Stakeholder am wichtigsten sind. So erhältst du eine klare Fokusansicht des Zustands und der Dynamik deines Projekts.\n\n## So konfigurierst du GitLab Insights\n\nMit GitLab Insights kannst du Daten über deine Projekte und Gruppen untersuchen und visualisieren. Sie bieten wichtige Analysen zu verschiedensten Aspekten, wie etwa den in einem bestimmten Zeitraum erstellten und geschlossenen Tickets, die durchschnittliche Zeit, die es bis zur Zusammenführung eines Merge Request dauert, sowie die Qualität der Priorisierung. Einblicke können sowohl für Projekte als auch für Gruppen konfiguriert werden.\n\n**So konfigurierst du Insights:**\n\n1. Für Projekteinblicke:\n   * Erstelle eine Datei mit dem Namen `.gitlab/insights.yml` im Stammverzeichnis deines Projekts.\n2. Für Gruppeneinblicke:\n   * Erstelle die Datei `.gitlab/insights.yml` in einem Projekt, das zu deiner Gruppe gehört.\n * Gehe zu **Einstellungen > Allgemein** deiner Gruppe.\n * Klappe den Abschnitt **Analyse** aus und suche den Abschnitt **Insights**.\n * Wähle das Projekt aus, das die Konfigurationsdatei enthält, und speichere die Änderungen.\n\nDie Datei `.gitlab/insights.yml` ist eine YAML-Datei, in der du die Struktur und Reihenfolge der Diagramme in einem Bericht sowie den Stil der anzuzeigenden Diagramme definieren kannst. Jede Diagrammdefinition enthält Parameter wie Titel, Beschreibung, Typ und Abfrage, um die Datenquelle und die Filterbedingungen anzugeben.\n\nUm Einblicke anzuzeigen, gehe in deinem Projekt oder deiner Gruppe zu **Analysieren > Insights**.\n\n![Standard-Dashboard für Insights anzeigen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378202/Blog/oqek65jmi5kclpbaqsca.png)\n\n## Einblicke in Merge Requests anpassen\n\nWährend die Standardansicht wertvolle Rohinformationen liefert, können wir das Insights-Dashboard anpassen, um zusätzliche Informationsebenen anzuzeigen, z. B. welches Team für welchen Merge Request verantwortlich war und welche Art von Problem gelöst wurde.\n\n## Merge-Request-Einblicke für jede Squad und jeden Anforderungstyp\n\nEs kann herausfordernd sein, die Produktivität einer Squad in GitLab zu messen, vor allem wenn die Gruppen- und Untergruppenstruktur in GitLab nicht perfekt mit der Organisation deines Squad übereinstimmt. So kannst du diese Herausforderungen meistern und die Produktivität deiner Squads effektiv verfolgen:\n\n### Richte Squad-basierte Metriken ein\n\n1. **Erstelle Labels:** Erstelle eindeutige Labels mit begrenztem Geltungsbereich für jede Squad (z. B. `squad::alpha`, `squad::beta`) und jeden Anforderungstyp (z. B. `type::bug`, `type::feature`, `type::maintenance`).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZUOzORIUJeU?si=T8eHeGizS3blYFHB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n2. **Weise Labels zu:** Weise diese Squad-Labels konsequent allen Tickets und Merge Requests zu, die von der jeweiligen Squad bearbeitet werden, egal in welchem Projekt oder welcher Gruppe sie sind.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fJ9entEBZG8?si=MlM6mKirEdkmwDDJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Tipps:**\n   * Verwende die GitLab-API, um Labels gesammelt an bestehende geöffnete, zusammengeführte und geschlossene MRs zuzuweisen.\n   * Du kannst Labels im Rahmen deiner GitLab-CI-Pipeline hinzufügen/entfernen/aktualisieren.\n * Nutze den GitLab Triage Bot, um den Label-Prozess zu automatisieren.\n\n3. Richte ein Dashboard ein: Erstelle die Datei `.gitlab/insights.yml` in deinem Projekt-Repository mit benutzerdefinierten Diagrammen für teamspezifische und typspezifische Einblicke in Merge Requests.\n\n```\n\n## Default Merge Requests insights.yml \nmergeRequests:\n  title: Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week \n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month\n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n\n## Per-teams Merge Requests insights.yml\nmergeRequestsTeams:\n  title: Merge requests dashboard per teams\n  charts:\n    - title: Merge requests merged per week \n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n    - title: Merge requests merged per month\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n\n## Per-teams and Type Merge Requests insights.yml\nmergeRequestsTeamsAndType:\n  title: Per Teams and Type - Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n    - title: Merge requests merged per week - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n\n```\n\nIndem du diese Anpassungen implementierst, kannst du sinnvolle Dashboards erstellen, in denen du einen klaren Überblick über die Merge-Request-Aktivitäten pro Team und Anforderungstyp erhältst. So kannst du Trends im Zeitverlauf visualisieren, die Leistung zwischen Squads vergleichen und die Verteilung der verschiedenen Arbeiten für jede Squad analysieren.\n\n![Dashboards mit Ansicht der MR-Aktivität pro Team und Anforderungstyp](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097217972.png)\n\n![Dashboard zum Vergleich der Leistung zwischen Squads](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097217972.png)\n\n## Lege jetzt los\n\nGitLab Insights ist nur die Spitze des Eisbergs, wenn es um Indikatoren und Analysen geht. Um die gesamte Palette der leistungsstarken Analysefunktionen von GitLab wie Wertstromanalyse, CI/CD-Analyse und Code-Review-Metriken zu entdecken, sieh dir unsere Produkttour zum Wertstrommanagement an:\n\n[![Produkttour zum Wertstrommanagement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097217974.png)]( https://gitlab.navattic.com/vsm)\n\n> Bist du bereit, jetzt selbst Metriken zu nutzen? Melde dich jetzt für eine [kostenlose Testversion von GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F) an und schöpfe das volle Potenzial von datengestützten DevSecOps aus.\n\n## Mehr erfahren\n- [Tool zur Erstellung geplanter Berichte vereinfacht das Wertstrommanagement (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Erste Schritte mit dem neuen Wertstrom-Dashboard von GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n- [KI-Impact-Analyse-Dashboard misst den ROI von KI](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n",[9,684,685,730,683,686],"features","2025-06-06",{"slug":733,"featured":91,"template":690},"data-driven-devsecops-exploring-gitlab-insights-dashboards","content:de-de:blog:data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","Data Driven Devsecops Exploring Gitlab Insights Dashboards","de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"_path":739,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":740,"content":746,"config":757,"_id":759,"_type":14,"title":760,"_source":16,"_file":761,"_stem":762,"_extension":19},"/de-de/blog/demystifying-ci-cd-variables",{"ogTitle":741,"schema":742,"ogImage":743,"ogDescription":744,"ogSiteName":672,"noIndex":6,"ogType":673,"ogUrl":745,"title":741,"canonicalUrls":745,"description":744},"GitLab Umgebungsvariablen einfach erklärt ","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab-Umgebungsvariablen entmystifiziert\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2021-04-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664679/Blog/Hero%20Images/blog-image-template-1800x945__24_.png","Wir zeigen dir, was sich hinter Umgebungsvariablen bei GitLab verbirgt. ✓ Definition ✓ Funktionsweise ✓ Typen ✓ Anwendung ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/demystifying-ci-cd-variables",{"heroImage":743,"body":747,"authors":748,"updatedDate":750,"date":751,"title":741,"tags":752,"description":756,"category":680},"Es gibt viel Flexibilität bei der Definition und Verwendung von Variablen\nfür [CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/). Variablen sind\nsehr nützlich für die Steuerung von Jobs und Pipelines und sie helfen dir zu\nvermeiden, Werte in der Konfigurationsdatei `.gitlab-ci.yml` festlegen zu\nmüssen. Dieser Blogbeitrag soll ein umfassenderes Bild vermitteln, indem er\nalle (oder die meisten) Informationen über die Definition und die Handhabung\nder Variablen zusammenfasst, um das Verständnis des Geltungsbereichs und der\nMöglichkeiten zu erleichtern. Die relevante Dokumentation in dem Beitrag\nverlinkt und ist aktuell nur in englischer Sprache verfügbar.\n\n\nIn [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) können mit Variablen Werte definiert und gespeichert werden, um Jobs anzupassen. Bei der Verwendung von Variablen müssen Werte nicht im Klartext gespeichert werden. In GitLab können CI/CD-Variablen unter **Einstellungen >> CI/CD >> Variablen** oder einfach in der Datei `.gitlab-ci.yml` definiert werden.\n\n\nVariablen sind nützlich, um Dienste von Drittanbietern für verschiedene Bereitstellungsumgebungen zu konfigurieren, z. B. `testing`, `staging`, `production` usw. Passe an, welche Dienste mit diesen Umgebungen verknüpft sind, indem du einfach die Variable änderst, die auf den API-Endpunkt zeigt, den die Dienste verwenden sollen. Verwende auch Variablen, um Jobs zu konfigurieren, und stelle sie dann als Umgebungsvariablen innerhalb der Jobs zur Verfügung, wenn diese ausgeführt werde.\n\n\n![GitLab liest die Datei .gitlab-ci.yml, um die referenzierte Variable zu scannen und sendet die Informationen an den GitLab Runner. Die Variablen werden auf dem Runner angezeigt und vom Runner ausgegeben.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_processing.jpeg)\n\n\n## Die Beziehung zwischen Variablen und Umgebungen\n\n\nDer Prozess der Softwareentwicklung umfasst verschiedene Phasen, in denen ein Produkt getestet wird, bevor es an die Benutzer(innen) ausgeliefert wird. Zur Definition dieser Phasen werden [Umgebungen](https://docs.gitlab.com/ee/ci/environments/) verwendet, die von Team zu Team und zwischen Unternehmen unterschiedlich sein können.\n\n\nVariablen sind dagegen Datenwerte, die sich durch die Interaktion der Benutzer(innen) mit dem Produkt ändern können. Beispielsweise kann ihr Alter, ihre Vorlieben oder eine beliebige andere Eingabe den nächsten Schritt in der Aufgabenfolge des Produkts bestimmen.\n\n\nWir hören oft den Begriff [Umgebungsvariable](https://docs.gitlab.com/ee/administration/environment_variables.html). Dabei handelt es sich um Variablen, die in einer bestimmten Umgebung, aber außerhalb der Anwendung definiert sind. CI/CD-Variablen von GitLab bieten Entwickler(inne)n die Möglichkeit, Werte in ihrem Code zu konfigurieren. Variablen sind hilfreich, da sie sicherstellen, dass der Code flexibel ist. Mit CI/CD-Variablen von GitLab können Beutzer(innen) eine in einer bestimmten Umgebung bereitgestellte Anwendung ändern, ohne den Code zu ändern. Es ist einfach, Tests durchzuführen oder sogar Dienste von Drittanbietern zu integrieren, indem eine Umgebungsvariable außerhalb der Anwendung geändert wird.\n\n\n## Geltungsbereich der Variablen für CI/CD\n\n\n![Hierarchie für CI/CD-Variablen: 1) Variablen für die manuelle Ausführung, Auslösung und Planung von Pipelines, 2) Geschützte Variablen auf Projekt-, Gruppen- und Instanzebene, 3) Geerbte CI/CD-Variablen, 4) Job-Ebene, globale yml-definierte Variablen, 5) Bereitstellungsvariablen, 6) Vordefinierte CI/CD-Variablen](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_precedence.jpeg)\n\n\n### `.gitlab-ci.yml`-definierte Variablen\n\n\nVariablen, die in der Arbeitsumgebung verfügbar sein müssen, können zu GitLab hinzugefügt werden. Diese CI/CD-Variablen sind dazu gedacht, nicht-sensible Projektkonfigurationen wie z. B. die URL der Datenbank in der Datei `.gitlab-ci.yml` zu speichern. Verwende diese Variable in mehreren Jobs oder Skripten, wo immer der Wert benötigt wird. Wenn sich der Wert ändert, musst du die Variable nur einmal aktualisieren und die Änderung wird überall dort übernommen, wo die Variable verwendet wird.\n\n\n### Projekt-CI/CD-Variablen\n\n\nEinen Schritt über die Repository-spezifischen Anforderungen hinaus kannst du CI/CD-Variablen in den [Projekt-Einstellungen](https://docs.gitlab.com/ee/ci/variables/#for-a-project) definieren und für CI/CD-Pipelines verfügbar machen. Diese werden aus dem Repository heraus gespeichert (nicht in der Datei `.gitlab-ci.yml`), sind aber weiterhin in der CI/CD-Konfiguration und den Skripten verfügbar. Durch das Speichern der Variablen außerhalb der Datei `.gitlab-ci.yml` werden diese Werte auf einen reinen Projektgeltungsbereich beschränkt und nicht als Klartext im Projekt gespeichert.\n\n\n### CI/CD-Variablen für Gruppen und Instanzen\n\n\nEinige Variablen sind auf Gruppen- oder sogar Instanzebene relevant und können für alle Projekte in einer Gruppe oder Instanz nützlich sein. Definiere die Variablen in den [Gruppen- oder Instanzeinstellungen](https://docs.gitlab.com/ee/ci/variables/#for-a-group), sodass alle Projekte innerhalb dieser Bereiche die Variablen verwenden können, ohne den Wert zu kennen oder die Variablen für den untergeordneten Bereich erstellen zu müssen. Zum Beispiel kann ein gemeinsamer Wert, der in mehreren Projekten aktualisiert werden muss, leicht verwaltet werden, wenn er an einer einzigen Stelle aktualisiert wird. Alternativ können mehrere Projekte ein bestimmtes Passwort verwenden, ohne den Wert des Passworts selbst kennen zu müssen.\n\n\n## Jobs und Pipelines als Umgebungen\n\n\nDie CI/CD-Variablen von GitLab werden nicht nur als Umgebungsvariablen verwendet, sondern auch in der Konfigurationsdatei `.gitlab-ci.yml`, um das Verhalten der Pipeline unabhängig von der Umgebung zu konfigurieren. Die Variablen können in den Projekt-/Gruppen-/Instanzeinstellungen gespeichert und Jobs in Pipelines zur Verfügung gestellt werden.\n\n\nZum Beispiel:\n\n\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\n\nDie Variable `($CI_COMMIT_BRANCH)` im Skriptabschnitt wird in dem Bereich des Jobs ausgeführt, in dem sie definiert wurde. Dieser Bereich ist die „Job-Umgebung“ – das heißt, wenn der Job gestartet wird, startet der GitLab-Runner einen Docker-Container und führt den Job in dieser Umgebung aus. Der Runner stellt diese Variable (und alle anderen vordefinierten oder benutzerdefinierten Variablen) dem Job zur Verfügung und kann ihren Wert bei Bedarf in der Protokollausgabe anzeigen.\n\n\nDie Variable wird jedoch **auch** im Abschnitt `if:` verwendet, um zu bestimmen, wann der Job ausgeführt werden soll. Dies ist an sich keine Umgebung, weshalb wir diese CI/CD-Variablen aufrufen. Sie können verwendet werden, um CI/CD-Jobs dynamisch zu konfigurieren, **sowie** als Umgebungsvariablen, wenn der Job ausgeführt wird.\n\n\n## Vordefinierte Variablen\n\n\nEine Reihe von Variablen werden [vordefiniert](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html), wenn eine GitLab-CI/CD-Pipeline gestartet wird. Benutzer(innen) können sofort auf Werte für Commit-, Projekt- oder Pipeline-Details zugreifen, ohne die Variablen selbst definieren zu müssen.\n\n\n## Benutzerdefinierte CI/CD-Variablen\n\n\n![Runner können zwei Arten von benutzerdefinierten CI/CD-Variablen erstellen: Typ und Datei.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variable_types.jpeg)\n\n\nWenn eine CI/CD-Variable in den Einstellungen erstellt wird, gibt GitLab den Benutzer(innen) mehr Konfigurationsmöglichkeiten für die Variable. Verwende diese zusätzlichen Konfigurationsoptionen für eine strengere Kontrolle sensibler Variablen:\n\n\n**Geltungsbereich: Umgebung:** Wenn eine Variable nur in einer bestimmten Umgebung verwendet werden soll, konfiguriere sie so, dass sie nur in dieser Umgebung verfügbar ist. Du kannst beispielsweise festlegen, dass ein Bereitstellungstoken nur in der Umgebung `production` verfügbar ist.\n\n\n**Geschützte Variablen:** Ähnlich wie bei der Option „Geltungsbereich: Umgebung“ kann eine Variable so konfiguriert werden, dass sie nur verfügbar ist, wenn die Pipeline in einem geschützten Branch ausgeführt wird, z. B. in deinem Standard-Branch.\n\n\n**Variablentyp:** Für einige Anwendungen musst du die Konfiguration in Form einer Datei übergeben. Wenn du eine Anwendung hast, die diese Konfiguration erfordert, lege den Variablentyp einfach auf „Datei“ fest. Wenn die CI/CD-Variable auf diese Weise konfiguriert wird, schreibt der Runner die Variable in eine temporäre Datei und speichert den Pfad zu dieser Datei als Wert, wenn er sie in der Umgebung verfügbar macht. Als Nächstes können die Benutzer(innen) den Pfad zu der Datei an alle Anwendungen weitergeben, die sie benötigen.\n\n\nZusätzlich zu den genannten Methoden zur Definition und Verwendung von Variablen hat GitLab eine Funktion eingeführt, die vorgefertigte Variablen generiert, wenn eine Pipeline manuell ausgeführt werden muss. Vorgefertigte Variablen reduzieren die Fehlerwahrscheinlichkeit und erleichtern die Bedienung der Pipeline.\n\n\n**Maskierte Variablen:** [Maskierte Variablen](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable) sind CI-Variablen, die in Job-Protokollen **maskiert** wurden, um zu verhindern, dass der Wert der Variablen angezeigt wird. \n\n\n**Maskierte und versteckte Variablen:** Die in [GitLab 17.4](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/#hide-cicd-variable-values-in-the-ui) eingeführten [maskierten und versteckten Variablen](https://docs.gitlab.com/ee/ci/variables/#hide-a-cicd-variable) bieten die gleiche Maskierungsfunktion für Job-Protokolle und **verstecken den Wert** **in der Einstellungsoberfläche**. Wir empfehlen, keine dieser Variablen für sensible Daten (z. B. Geheimnisse) zu verwenden, da diese versehentlich offengelegt werden könnten.\n\n\n## Geheimnisse\n\n\nGeheimnisse sind sensible Zugangsdaten, die vertraulich behandelt werden sollten. Beispiele für Geheimnisse sind\n\n\n* Passwörter  \n\n* SSH-Schlüssel  \n\n* Zugriffstoken  \n\n* Alle anderen Arten von Zugangsdaten, deren Offenlegung für ein Unternehmen schädlich wäre.\n\n\nGitLab ermöglicht es seinen Benutzer(innen) derzeit mit Hilfe von HashiCorp Vault, Google Cloud Secret Manager und Azure Key Vault, [externe Geheimnisse für CI zu verwenden](https://docs.gitlab.com/ee/ci/secrets/), um Schlüssel, Token und andere Geheimnisse auf Projektebene sicher zu verwalten. So können Benutzer(innen) diese Geheimnisse aus Sicherheitsgründen von anderen CI/CD-Variablen trennen.\n\n\n### GitLab Geheimnismanager\n\n\nNeben der Unterstützung für externe Geheimnisse in CI arbeitet GitLab auch an der Einführung einer [nativen Lösung zur Verwaltung von Geheimnissen](https://gitlab.com/groups/gitlab-org/-/epics/10108), um Geheimnisse sicher und bequem in GitLab zu speichern. Diese Lösung wird Kund(inn)en auch dabei helfen, gespeicherte Geheimnisse in GitLab-spezifischen Komponenten und Umgebungen zu verwenden und den Zugriff auf Namensraum-Gruppen und Projektebene einfach zu verwalten. \n\n\n## Mehr lesen\n\n* [Nativer GitLab Geheimnismanager für mehr Sicherheit in der Software-Lieferkette](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/) (nur in englischer Sprache verfügbar)\n\n\n***Haftungsausschlussklausel:** Dieser Blog enthält Informationen über kommende Produkte, Funktionen oder Funktionalitäten. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen, wenn du etwas kaufen oder planen möchtest. Wie bei allen Projekten können sich die in diesem Blog und auf den verlinkten Seiten genannten Punkte ändern oder verzögern. Die Entwicklung, Freigabe und der Zeitplan von Produkten, Funktionen oder Funktionalitäten liegen im alleinigen Ermessen von GitLab.*\n",[749],"Veethika Mishra","2025-01-28","2021-04-09",[753,730,754,755,9,683],"CD","inside GitLab","CI","CI/CD-Variablen sind nützliche (und flexible) Tools zur Steuerung von Jobs und Pipelines. Wir verraten dir alles, was du über GitLab-Umgebungsvariablen wissen musst.",{"slug":758,"featured":6,"template":690},"demystifying-ci-cd-variables","content:de-de:blog:demystifying-ci-cd-variables.yml","Demystifying Ci Cd Variables","de-de/blog/demystifying-ci-cd-variables.yml","de-de/blog/demystifying-ci-cd-variables",{"_path":764,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":765,"content":771,"config":779,"_id":781,"_type":14,"title":782,"_source":16,"_file":783,"_stem":784,"_extension":19},"/de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"ogTitle":766,"schema":767,"ogImage":768,"ogDescription":769,"ogSiteName":672,"noIndex":6,"ogType":673,"ogUrl":770,"title":766,"canonicalUrls":770,"description":769},"Leitfaden: Kontinuierliche Bereitstellung mit GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Vom Code bis zur Produktion: Ein Leitfaden für die kontinuierliche Bereitstellung mit GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Benjamin Skierlak\"},{\"@type\":\"Person\",\"name\":\"James Wormwell\"}],\n        \"datePublished\": \"2025-01-28\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","Erfahre, wie du mit dem Aufbau einer robusten Pipeline für die kontinuierliche Bereitstellung in GitLab beginnen kannst. In diesem Artikel findest du Schritt-für-Schritt-Anleitungen, praktische Beispiele und Best Practices.","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"heroImage":768,"body":772,"authors":773,"updatedDate":776,"date":750,"title":777,"tags":778,"description":769,"category":685},"Die kontinuierliche Bereitstellung ist eine bahnbrechende Praxis, die es\nTeams ermöglicht, schneller und mit höherem Vertrauen Werte zu schaffen. Das\nEintauchen in erweiterte Bereitstellungs-Workflows – wie GitOps,\nContainer-Orchestrierung mit Kubernetes oder dynamische Umgebungen – kann\njedoch für Teams, die gerade erst anfangen, einschüchternd sein.\n\n\nGitLab setzt sich dafür ein, die Bereitstellung nahtlos und skalierbar zu gestalten. Indem wir es den Teams ermöglichen, sich auf die Grundlagen zu konzentrieren, befähigen wir sie, eine starke Basis zu schaffen, die das Wachstum komplexerer Strategien im Laufe der Zeit unterstützt. Dieser Leitfaden enthält wichtige Schritte, um mit der Implementierung der kontinuierlichen Bereitstellung mit GitLab zu beginnen und die Grundlage für deinen langfristigen Erfolg zu schaffen.\n\n\n## Inhaltsverzeichnis\n\n\n- [Beginne mit einem Workflow-Plan](#beginne-mit-einem-workflow-plan)\n  - [Artefakt-Management-Strategie](#artefakt-management-strategie)\n    - [Artefakte und Versionsstrategien](#artefakte-und-versionsstrategien)\n    - [Artefaktaufbewahrung erstellen](#artefaktaufbewahrung-erstellen)\n    - [Registrierungszugriff und Authentifizierung](#registrierungszugriff-und-authentifizierung)\n  - [Umgebungsstrategie](#umgebungsstrategie)\n  - [Bereitstellungsziele](#bereitstellungsziele)\n- [Deine CD-Pipeline implementieren](#deine-cd-pipeline-implementieren)\n  - [Ein Schritt-für-Schritt-Beispiel](#ein-schritt-für-schritt-beispiel)\n    - [Voraussetzungen](#voraussetzungen)\n  - [Best Practices](#best-practices)\n- [Skaliere deine Bereitstellungsstrategie](#skaliere-deine-bereitstellungsstrategie)\n  - [Erweiterte Sicherheitsmaßnahmen](#erweiterte-sicherheitsmaßnahmen)\n  - [Progressive Bereitstellungsstrategien](#progressive-bereitstellungsstrategien)\n  - [Überwachung und Optimierung](#überwachung-und-optimierung)\n- [Warum GitLab](#warum-gitlab)\n\n- [Noch heute starten](#noch-heute-starten)\n\n\n## Beginne mit einem Workflow-Plan\n\n\nBevor du dich mit der technischen Implementierung befasst, nimm dir Zeit, um deinen Bereitstellungs-Workflow zu planen. Der Erfolg liegt in der sorgfältigen Planung und dem methodischen Vorgehen.\n\n\n### Artefakt-Management-Strategie\n\n\nIm Zusammenhang mit der kontinuierlichen Bereitstellung sind Artefakte die Paket-Ausgaben deines Build-Prozesses, die gespeichert, als Versionen verwaltet und bereitgestellt werden müssen. Darunter fallen:\n\n\n- Container-Images für deine Anwendungen\n\n- Pakete\n\n- kompilierte Binärdateien oder ausführbare Dateien\n\n- Bibliotheken\n\n- Konfigurationsdateien\n\n- Dokumentationspakete\n\n- andere Artefakte\n\n\nJede Art von Artefakt spielt eine bestimmte Rolle in deinem Bereitstellungsprozess. Zum Beispiel könnte eine typische Webanwendung Folgendes generieren:\n\n\n- ein Container-Image für den Backend-Service\n\n- ein ZIP-Archiv mit kompilierten Frontend-Assets\n\n- SQL-Dateien für Datenbankänderungen\n\n- umweltspezifische Konfigurationsdateien\n\n\nDie effektive Verwaltung dieser Artefakte ist für erfolgreiche Bereitstellungen von entscheidender Bedeutung. Hier erfährst du, wie du das Artefakt-Management angehen kannst.\n\n\n#### Artefakte und Versionsstrategien\n\n\nEine Best Practice, um mit einer sauberen Struktur zu beginnen, besteht darin, eine klare Versionsstrategie für deine Artefakte festzulegen. Bei der Erstellung von Releases gilt:\n\n\n- Verwende eine semantische Versionsverwaltung (major.minor.patch) für Release-Tags\n  - Beispiel: `myapp:1.2.3` für ein stabiles Release\n  - Wichtige Versionsänderungen (2.0.0) für Breaking Changes\n  - Geringfügige Versionsänderungen (1.3.0) für neue Funktionen\n  - Patch-Versionsänderungen (1.2.4) für Fehlerbehebungen\n- Pflege einen „neuesten“ Tag für die neueste stabile Version\n  - Beispiel: `myapp:latest` für automatisierte Bereitstellungen\n- Beziehe Commit-SHA für präzises Versions-Tracking ein\n  - Beispiel: `myapp:1.2.3-abc123f` zum Debuggen\n- Berücksichtige Branch-basierte Tags für Entwicklungsumgebungen\n  - Beispiel: `myapp: feature-user-auth` für Funktionstests\n\n#### Artefaktaufbewahrung erstellen\n\n\nImplementiere definierte Aufbewahrungsregeln:\n\n\n- Lege explizite Ablaufzeitrahmen für temporäre Artefakte fest\n\n- Definiere, welche Artefakte dauerhaft aufbewahrt werden müssen\n\n- Konfiguriere Bereinigungsrichtlinien zur Verwaltung des Speichers\n\n\n#### Registrierungszugriff und Authentifizierung\n\n\nSchütze deine Artefakte mit den richtigen Zugangskontrollen:\n\n\n- Implementiere persönliche Zugriffstoken für den Entwicklerzugriff\n\n- Konfiguriere CI/CD-Variablen für die Pipeline-Authentifizierung\n\n- Richte ordnungsgemäße Zugangsumfänge ein\n\n\n### Umgebungsstrategie\n\n\nBetrachte deine Umgebungen frühzeitig, da sie deine gesamte Bereitstellungspipeline prägen:\n\n\n- Konfigurationen der Entwicklungs-, Staging- und Produktionsumgebung\n\n- Umgebungsspezifische Variablen und Geheimnisse\n\n- Zugangskontrollen und Schutzregeln\n\n- Ansatz zur Nachverfolgung und Überwachung der Bereitstellung\n\n\n### Bereitstellungsziele\n\n\nSei dir bewusst, wo und wie du bereitstellen wirst. Diese Entscheidungen sind wichtig und die jeweiligen Vor- und Nachteile sollten berücksichtigt werden:\n\n\n- Infrastrukturanforderungen (VMs, Container, Cloud-Services)\n\n- Netzwerkzugriff und Sicherheitskonfigurationen\n\n- Authentifizierungsmechanismen (SSH-Schlüssel, Zugriffstoken)\n\n- Überlegungen zur Ressourcenzuweisung und Skalierung\n\n\nNachdem wir unsere Strategie definiert und grundlegende Entscheidungen getroffen haben, können wir diese Pläne jetzt in eine funktionierende Pipeline umsetzen. Wir werden ein praktisches Beispiel erstellen, das diese Konzepte demonstriert, beginnend mit einer einfachen Anwendung und dem schrittweisen Hinzufügen von Bereitstellungsfunktionen.\n\n\n## Deine CD-Pipeline implementieren\n\n\n### Ein Schritt-für-Schritt-Beispiel\n\n\nSehen wir uns nun die Implementierung einer grundlegenden Pipeline für die kontinuierliche Bereitstellung für eine Webanwendung an. Wir werden eine einfache HTML-Anwendung als Beispiel verwenden, aber diese Prinzipien gelten für jede Art von Anwendung. Wir werden unsere Anwendung auch als Docker Image auf einer einfachen virtuellen Maschine bereitstellen. Somit können wir uns auf ein kuratiertes Bild mit minimalen Abhängigkeiten stützen und sicherstellen, dass keine umgebungsspezifischen Anforderungen unbeabsichtigt eingeführt werden. Wenn wir an einer virtuellen Maschine arbeiten, werden wir die nativen Integrationen von GitLab nicht nutzen, sodass wir zunächst an einem einfacheren, aber weniger skalierbaren Setup arbeiten können.\n\n\n#### Voraussetzungen\n\n\nIn diesem Beispiel zielen wir darauf ab, eine Anwendung zu containerisieren, die wir auf einer virtuellen Maschine ausführen, die auf einem Cloud-Anbieter gehostet wird. Wir werden diese Anwendung auch lokal auf unserem Computer testen. Diese Liste der Voraussetzungen wird nur für dieses Szenario benötigt.\n\n\n##### Einrichtung der virtuellen Maschine\n\n\n- Stelle eine VM in deinem bevorzugten Cloud-Provider (z. B. GCP, AWS, Azure) bereit\n\n- Konfiguriere die Netzwerkregeln, um den Zugriff auf die Ports 22, 80 und 443 zu ermöglichen\n\n- Zeichne die öffentliche IP-Adresse des Computers für die Bereitstellung auf\n\n\n##### SSH-Authentifizierung einrichten:\n\n\n- Generiere ein öffentliches/privates Schlüsselpaar für die Maschine\n\n- Gehe in GitLab zu **Einstellungen > CI/CD > Variablen**\n\n- Erstelle eine Variable mit dem Namen `GITLAB_KEY`\n\n- Wähle als Typ „Datei“ (für SSH-Authentifizierung erforderlich)\n\n- Füge den privaten Schlüssel in das Feld „Wert“ ein\n\n- Definiere eine BENUTZERVARIABLE; dies ist der Benutzer, der sich anmeldet und die Skripte auf deiner VM ausführt\n\n\n##### Bereitstellungsvariablen konfigurieren\n\n\n- Erstelle Variablen für deine Bereitstellungsziele:\n  - `STAGING_TARGET`: deine Staging-Server-IP/-Domäne\n  - `PRODUCTION_TARGET`: deine Produktionsserver-IP/-Domäne\n\n##### Lokales Entwicklungs-Setup\n\n\n- Installiere Docker auf deinem lokalen Computer, um Bereitstellungen zu testen\n\n\n##### GitLab-Container-Registry-Zugriff\n\n\n- Finde deinen Registry-Pfad:\n  - Navigiere zu **Bereitstellen > Container-Registry**\n  - Kopiere den Registry-Pfad (z. B. registry.gitlab.com/group/project)\n- Authentifizierung einrichten:\n  - Gehe zu **Einstellungen > Zugriffstoken**\n  - Erstelle ein neues Token mit Registry-Zugriff\n  - Token-Ablauf: max. 1 Jahr\n  - Speichere das Token sicher\n- Lokalen Registry-Zugriff konfigurieren:\n\n\n```\n\ndocker login registry.gitlab.com\n\n# Der Benutzername, wenn du einen PAT verwendest, ist gitlab-ci-token\n\n# Passwort: your-access-token\n\n```\n\n\n#### 1. Erstelle deine Anwendung\n\n\nBeginne mit einer grundlegenden Webanwendung. In unserem Beispiel verwenden wir eine einfache HTML-Seite:\n\n\n```\n\n\u003C!|||UNTRANSLATED_CONTENT_START|||-- index.html -->\n\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|||-- Dein Inhalt hier -->\n  \u003C/body>\n\u003C/html>\n\n```\n\n\n#### 2. Containerisiere deine Anwendung\n\n\nErstelle ein Dockerfile, um deine Anwendung zu paketieren:\n\n\n```\n\nFROM nginx:1.26.2\n\nCOPY index.html /usr/share/nginx/html/index.html\n\n```\n\n\nDieses Dockerfile:\n\n\n- Verwendet nginx als Basis-Image für die Bereitstellung von Webinhalten\n\n- Kopiert deine HTML-Datei an die richtige Stelle in der nginx-Verzeichnisstruktur\n\n\n#### 3. Richte deine CI/CD-Pipeline ein\n\n\nErstelle eine `.gitlab-ci.yml`-Datei, um deine Pipeline-Phasen zu definieren:\n\n\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\n\nSehen wir uns das genauer an:\n\n\n`TAG_LATEST` besteht aus drei Teilen:\n\n\n- `$CI_REGISTRY_IMAGE` ist der Pfad zum Container-Registry deines Projekts in GitLab\n\n\nZum Beispiel: `registry.gitlab.com/your-group/your-project`\n\n\n- `$CI_COMMIT_REF_NAME` ist der Name deiner Branch oder deines Tags\n\n\nZum Beispiel, wenn du dich im Haupt-Branch befindest: `/main`, und wenn du dich in einem Feature-Branch befindest: `/feature-login`\n\n\n- `:latest` ist ein festes Suffix\n\n\nWenn du dich also im Main-Branch befindest, wird `TAG_LATEST` zu: `registry.gitlab.com/your-group/your-project/main:latest`.\n\n\n`TAG_COMMIT` ist fast identisch, aber anstelle von `:latest` verwendet es: `$CI_COMMIT_SHA`, was die Commit-Kennung ist, zum Beispiel: `:abc123def456`.\n\n\nFür denselben Commit im Haupt-Branch wird `TAG_COMMIT` zu: `registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\n\nDer Grund für beides ist, dass `TAG_LATEST` dir eine einfache Möglichkeit bietet, immer die neueste Version zu erhalten, und `TAG_COMMIT` gibt dir eine bestimmte Version, zu der du bei Bedarf zurückkehren kannst.\n\n\n#### 4. Im Container-Registry veröffentlichen\n\n\nFüge den Veröffentlichungsauftrag zu deiner Pipeline hinzu:\n\n\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\n\nDieser Job:\n\n\n- verwendet Docker-in-Docker, um Bilder zu entwickeln\n\n- erstellt zwei getaggte Versionen deines Bildes\n\n- authentifiziert sich bei der GitLab-Registrierung\n\n- pusht beide Versionen in das Registry \n\n\nJetzt, da unsere Bilder sicher im Registry gespeichert sind, können wir uns darauf konzentrieren, sie in unseren Zielumgebungen bereitzustellen. Beginnen wir mit lokalen Tests, um unser Setup zu validieren, bevor wir zu Produktionsbereitstellungen übergehen.\n\n\n#### 5. In deiner Umgebung bereitstellen\n\n\nVor der Bereitstellung in der Produktion kannst du einen lokalen Test durchführen. Wir haben unser Image gerade im GitLab-Repository veröffentlicht, das wir lokal abrufen werden. Wenn du dir über den genauen Pfad nicht sicher bist, navigiere zu **Bereitstellen > Container-Registry**. Du solltest ein Symbol sehen, um den Pfad deines Bildes am Ende der Zeile für das Container-Image zu kopieren, das du testen möchtest.\n\n\n```\n\ndocker login registry.gitlab.com \n\ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n\n```\n\n\nAuf diese Weise solltest du über deinen Webbrowser lokal über deine lokale Host-Adresse auf deine Anwendung zugreifen können.\n\n\nDu kannst jetzt einen Bereitstellungsjob zu deiner Pipeline hinzufügen:\n\n\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\n\nDieser Job:\n\n\n- richtet einen SSH-Zugriff auf dein Bereitstellungsziel ein\n\n- ruft das neueste Image auf\n\n- entfernt alle vorhandenen Container\n\n- stellt die neue Version bereit\n\n\n#### 6. Bereitstellungen nachverfolgen\n\n\nAktiviere die Nachverfolgung von Bereitstellungen, indem du die Umgebungskonfiguration hinzufügst:\n\n\n```\n\ndeploy:\n  environment:\n    name: production\nurl: https://deine-anwendung-url.com\n\n```\n\n\nDadurch wird ein Umgebungsobjekt im Abschnitt **Betreiben > Umgebungen** von GitLab erstellt, das Folgendes bietet:\n\n\n- Bereitstellungsverlauf\n\n- aktueller Bereitstellungsstatus\n\n- schneller Zugriff auf deine Anwendung\n\n\nWährend eine einzelne Umgebungspipeline ein guter Ausgangspunkt ist, müssen die meisten Teams mehrere Umgebungen verwalten, um ordnungsgemäß zu testen und die Staging-Phase durchzuführen. Lass uns unsere Pipeline erweitern, um dieses realistischere Szenario zu bewältigen.\n\n\n#### 7. Mehrere Umgebungen einrichten\n\n\nFür eine robustere Pipeline, konfiguriere Staging- und Produktionsbereitstellungen:\n\n\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\n\nDieses Setup:\n\n\n- stellt die Staging-Phase deines Main-Branch bereit\n\n- verwendet GitLab-Tags, um Produktionsbereitstellungen auszulösen\n\n- bietet separate Nachverfolgung für jede Umgebung\n\n\nHier und in unserem nächsten Schritt nutzen wir eine sehr nützliche GitLab-Funktion: Tags. Durch manuelles Erstellen eines Tags im Abschnitt **Code > Tags** wird das `$CI_COMMIT_TAG` erstellt, wodurch wir Jobs entsprechend auslösen können.\n\n\n#### 8. Automatisierte Versionshinweise erstellen\n\n\nWir werden die Release-Funktionen von GitLab über unsere CI/CD-Pipeline nutzen. Aktualisiere zuerst deine Phasen in `.gitlab-ci.yml`:\n\n\n```\n\nstages:\n\n\n- publish\n\n- staging\n\n- release # New stage for releases\n\n- version\n\n- production\n\n```\n\n\nAls Nächstes fügst du den Release-Job hinzu:\n\n\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\n\nDu kannst dies verbessern, indem du Links zu deinen Container-Bildern hinzufügst:\n\n\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\n\nFür die automatische Erzeugung von Versionshinweisen basierend auf Commit-Nachrichten:\n\n\n```\n\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release notes for version $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  auto_generate_release_notes: true    # Enables automatic notes\n```\n\n\nFür aussagekräftige automatisierte Versionshinweise:\n\n\n- herkömmliche Commits verwenden (feat:, fix:, etc.)\n\n- Issue-Nummern einschließen (#123)\n\n- Betreff mit leerer Zeile vom Text trennen\n\n\nWenn du benutzerdefinierte Versionshinweise mit Bereitstellungsinformationen möchtest:\n\n\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\n\nNach der Konfiguration werden Releases automatisch erstellt, wenn du ein Git-Tag erstellst. Du kannst sie in GitLab unter **Bereitstellen > Releases** anzeigen.\n\n\n#### 9. Alles zusammensetzen\n\n\nSo sieht unsere finale YAML-Datei aus:\n\n\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\n\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\n\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\n\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\n\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\n\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\n\nDiese komplette Pipeline:\n\n\n- veröffentlicht Images im Registry (Main-Branch)\n\n- stellt das Staging bereit (Main-Branch)\n\n- erstellt Releases (mit Tags)\n\n- bietet die Versionsverwaltung von Images mit Release-Tags \n\n- Stellt die Produktion bereit (für Tags)\n\n\nHauptvorteile:\n\n\n- Saubere, reproduzierbare, lokale Entwicklungs- und Testumgebung\n\n- Klarer Pfad zu Produktionsumgebungen mit Struktur, um Vertrauen in die Bereitstellung aufzubauen\n\n- Muster zur Wiederherstellung nach unerwarteten Fehlern usw.\n\n- Bereit, komplexere Bereitstellungsstrategien zu skalieren/zu übernehmen\n\n\n### Best Practices\n\n\nWährend der gesamten Implementierung solltest du diese Grundsätze einhalten:\n\n\n- Dokumentiere alles, von der variablen Nutzung bis hin zu Bereitstellungsverfahren\n\n- Nutze die integrierten Funktionen von GitLab (Umgebungen, Releases, Registry)\n\n- Implementiere ordnungsgemäße Zugriffskontrollen und Sicherheitsmaßnahmen\n\n- Sorge für Ausfälle mit robusten Rollback-Verfahren vor\n\n- Halte deine Pipeline-Konfigurationen SAUBER (wiederhole dich nicht)\n\n\n## Skaliere deine Bereitstellungsstrategie\n\n\nWie geht es weiter? Hier sind einige Aspekte, die du berücksichtigen solltest, wenn deine kontinuierliche Bereitstellungsstrategie ausgereift ist.\n\n\n### Erweiterte Sicherheitsmaßnahmen\n\n\nErhöhe die Sicherheit durch:\n\n\n- Geschützte Umgebungen mit eingeschränktem Zugang\n\n- Erforderliche Genehmigungen für Produktionseinsätze\n\n- Integriertes Sicherheitsscannen\n\n- Automatisierte Schwachstellenbewertungen\n\n- Branch-Schutzregeln für einsatzbedingte Änderungen\n\n\n### Progressive Bereitstellungsstrategien\n\n\nImplementiere erweiterte Bereitstellungsstrategien:\n\n\n- Feature-Flags für kontrollierte Rollouts\n\n- Canary-Bereitstellungen zur Risikominderung\n\n- Blaugrüne Bereitstellungsstrategien\n\n- A/B-Testfähigkeiten\n\n- Dynamisches Umgebungsmanagement\n\n\n### Überwachung und Optimierung\n\n\nEtabliere robuste Überwachungspraktiken:\n\n\n- Verfolge Bereitstellungsmetriken nach\n\n- Richte eine Leistungsüberwachung ein\n\n- Konfiguriere Bereitstellungswarnungen\n\n- Richte Bereitstellungs-SLOs ein\n\n- Regelmäßige Pipeline-Optimierung\n\n\n## Warum GitLab\n\n\nDurch die kontinuierlichen Bereitstellungsfunktionen ist GitLab eine herausragende Wahl für moderne Bereitstellungsworkflows. Die Plattform zeichnet sich dadurch aus, dass sie den Weg vom Code bis zur Produktion optimiert und eine integrierte Container-Registrierung, ein Umgebungsmanagement und eine Nachverfolgung der Bereitstellung innerhalb einer einzigen Benutzeroberfläche bietet. Die umgebungsspezifischen Variablen von GitLab, die Approval-Gates für die Bereitstellung und die Rollback-Funktionen bieten die Sicherheit und Kontrolle, die für Produktionsbereitstellungen erforderlich sind, während Funktionen wie Review-Apps und Feature-Flags progressive Bereitstellungsansätze ermöglichen. Als Teil der kompletten DevSecOps-Plattform von GitLab lassen sich diese CD-Funktionen nahtlos in deinen gesamten Software-Lebenszyklus integrieren.\n\n\n## Noch heute starten\n\n\nDer Weg zur kontinuierlichen Bereitstellung ist eine Evolution, keine Revolution. Beginne mit den Grundlagen, baue eine solide Grundlage auf und integriere nach und nach erweiterte Funktionen, wenn die Anforderungen deines Teams wachsen. GitLab bietet die Tools und die Flexibilität, um dich in jeder Phase dieser Reise zu unterstützen, von deiner ersten automatisierten Bereitstellung bis hin zu komplexen Bereitstellungspipelines für mehrere Umgebungen.\n\n\n> Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/free-trial/devsecops/) an, um noch heute mit der kontinuierlichen Bereitstellung zu beginnen.\n",[774,775],"Benjamin Skierlak","James Wormwell","2025-05-14","Vom Code bis zur Produktion: Ein Leitfaden für die kontinuierliche Bereitstellung mit GitLab",[753,9,730,685,683],{"slug":780,"featured":6,"template":690},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","content:de-de:blog:from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab","de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"_path":786,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":787,"content":793,"config":800,"_id":802,"_type":14,"title":803,"_source":16,"_file":804,"_stem":805,"_extension":19},"/de-de/blog/getting-started-with-gitlab-understanding-ci-cd",{"title":788,"description":789,"ogTitle":788,"ogDescription":789,"noIndex":6,"ogImage":790,"ogUrl":791,"ogSiteName":672,"ogType":673,"canonicalUrls":791,"schema":792},"Erste Schritte mit GitLab: Grundlegendes zu CI/CD","In diesem Leitfaden für Einsteiger(innen) lernst du die Grundlagen der kontinuierlichen Integration und kontinuierlichen Lieferung kennen. Du erfährst, was CI/CD-Komponenten sind und wie du sie erstellst.","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\": \"Erste Schritte mit GitLab: Grundlegendes zu CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-25\",\n      }",{"title":788,"description":789,"authors":794,"heroImage":790,"date":796,"body":797,"category":685,"tags":798,"updatedDate":799},[795],"GitLab","2025-04-25","Stell dir einen Workflow vor, bei dem jede Codeänderung automatisch erstellt, getestet und für deine Benutzer(innen) bereitgestellt wird. Genau das macht [CI/CD (Kontinuierliche Integration/Kontinuierliche Lieferung)](https://about.gitlab.com/de-de/topics/ci-cd/)! Mit CI/CD kannst du Fehler frühzeitig erkennen, die Qualität des Codes sicherstellen und Software schneller und häufiger bereitstellen.\n\n## Inhaltsverzeichnis\n\n- [Was ist CI/CD?](#was-ist-cicd%3F)\n- [Vorteile von GitLab CI/CD](#vorteile-von-gitlab-cicd)\n- [Die Elemente von GitLab CI/CD](#die-elemente-von-gitlab-cicd)\n- [GitLab CI einrichten](#gitlab-ci-einrichten)\n- [Beispiele für die CI/CD-Konfiguration](#beispiele-für-die-cicd-konfiguration)\n- [GitLab Auto-DevOps](#gitlab-auto-devops)\n- [CI/CD-Katalog](#cicd-katalog)\n- [CI-Vorlagen](#ci-vorlagen)\n- [Entwicklung der nächsten Generation](#entwicklung-der-nächsten-generation)\n- [Reihe „Erste Schritte mit GitLab\"](#reihe-„erste-schritte-mit-gitlab“)\n\n### Was ist CI/CD?\n\n* **Kontinuierliche Integration** ist eine Entwicklungsmethode, bei der Entwickler(innen) häufig, nach Möglichkeit mehrmals am Tag, Codeänderungen in ein gemeinsames Repository integrieren. Jede Integration wird dann durch einen automatisierten Build- und Testprozess überprüft, so dass die Teams Probleme frühzeitig erkennen können.  \n* **Kontinuierliche Lieferung** erweitert CI, indem sie die Bereitstellungspipeline automatisiert und dafür sorgt, dass dein Code *immer* in einem einsatzfähigen Zustand ist. Du kannst deine Anwendung mit einem einzigen Klick oder automatisch in verschiedenen Umgebungen (z. B. Staging, Produktion) bereitstellen.  \n* **Kontinuierliche Bereitstellung** geht noch einen Schritt weiter, indem sie *jeden erfolgreichen Build* automatisch für die Produktion bereitstellt. Dies erfordert ein hohes Maß an Vertrauen in deine automatisierten Tests und deinen Bereitstellungsprozess.\n\n### Vorteile von GitLab CI/CD\n\nGitLab CI/CD ist ein leistungsstarkes, eingegliedertes System, das in GitLab integriert ist. Es bietet ein nahtloses Erlebnis für die Automatisierung deines gesamten Software-Entwicklungsprozesses. Mit GitLab CI/CD kannst du:\n\n* **Alles automatisieren:** Erstelle, teste und stelle deine Anwendungen mit Leichtigkeit bereit.  \n* **Bugs frühzeitig erkennen:** Erkenne und behebe Fehler, bevor sie die Produktion erreichen.  \n* **Schnelleres Feedback erhalten:** Du erhältst sofortige Rückmeldung zu deinen Code-Änderungen.  \n* **Die Zusammenarbeit verbessern:** Arbeite mit automatisierten Workflows effektiver im Team zusammen.  \n* **Die Bereitstellung beschleunigen:** Veröffentliche Software schneller und häufiger.  \n* **Risiken reduzieren:** Minimiere Fehler bei der Bereitstellung und vermeide Rollbacks.\n\n### Die Elemente von GitLab CI/CD\n\n* `.gitlab-ci.yml`**:** Diese [YAML-Datei (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/), die sich im Stammverzeichnis deines Projekts befindet, definiert deine CI/CD-Pipeline, einschließlich Phasen, Jobs und Runner.  \n* [**GitLab Runner** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/)**:** Dieser Agent führt deine CI/CD-Jobs auf deiner Infrastruktur aus (z. B. auf physischen Computern, virtuellen Maschinen, Docker-Containern oder Kubernetes-Clustern).  \n* [**Phasen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/#stages)**:** Phasen definieren die Reihenfolge der Ausführung deiner Jobs (z. B. Erstellen, Testen und Bereitstellen).  \n* [**Jobs** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/#job-keywords)**:** Jobs sind einzelne Arbeitseinheiten innerhalb einer Phase (z. B. Code kompilieren, Tests ausführen und für das Staging bereitstellen).\n\n### GitLab CI einrichten\n\nDie ersten Schritte mit GitLab CI sind einfach. Hier ist ein einfaches Beispiel für eine `.gitlab-ci.yml`-Datei:\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\nDiese Konfiguration definiert drei Phasen: „build“, „test“ und „deploy“. Jede Phase enthält einen Job, der ein einfaches Skript ausführt.\n\n### Beispiele für die CI/CD-Konfiguration\n\nSehen wir uns einige realistischere Beispiele an.\n\n**Erstellen und Bereitstellen einer Node.js-Anwendung**\n\nDie folgende Pipelinedefinition beschreibt die Verwendung von npm, um eine Node.js-Anwendung zu erstellen und zu testen, und [dpl (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/examples/deployment/), um die Anwendung in Heroku bereitzustellen. In der Bereitstellungsphase der Pipeline werden die [GitLab-CI/CD-Variablen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/variables/) verwendet, mit denen Entwickler(innen) vertrauliche Informationen (z. B. Zugangsdaten) speichern und sicher in CI/CD-Prozessen verwenden können. In diesem Beispiel wird ein API-Schlüssel für die Bereitstellung in Heroku unter dem variablen Schlüsselnamen '$HEROKU_API_KEY` gespeichert, den das dpl-Tool verwendet.\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**Bereitstellung in verschiedenen Umgebungen (Staging und Produktivumgebung)**\n\nGitLab bietet auch [Umgebungen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/environments/) mit CI/CD. Mit dieser Funktion können Benutzer(innen) die Bereitstellung von CI/CD auf Infrastrukturziele verfolgen. Im folgenden Beispiel fügt die Pipeline Phasen mit einer Umgebungseigenschaft für eine Staging- und eine Produktivumgebung hinzu. Während die Phase „deploy_staging“ ihr Skript immer ausführt, erfordert die Phase „deploy_production“ eine manuelle Genehmigung, um eine versehentliche Bereitstellung in der Produktionsumgebung zu verhindern.\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 (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/topics/autodevops/) vereinfacht CI/CD, indem es eine vordefinierte Konfiguration bereitstellt, mit der deine Anwendungen automatisch erstellt, getestet und bereitgestellt werden. Es nutzt bewährte Methoden und Branchenstandards, um deinen Workflow zu optimieren.\n\nSo aktivierst du Auto-DevOps:\n\n1. Gehe in deinem Projekt zu **Einstellungen > CI/CD > Allgemeine Pipelines**.  \n2. Aktiviere die Option **Auto-DevOps**.\n\nAuto-DevOps erkennt automatisch die Sprache und das Framework deines Projekts und konfiguriert die erforderlichen Build-, Test- und Bereitstellungsphasen. Du musst nicht einmal eine `.gitlab-ci.yml`-Datei erstellen.\n\n### CI/CD-Katalog\n\nDer [CI/CD-Katalog (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) ist eine Liste von Projekten mit veröffentlichten [CI/CD-Komponenten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/components/), die du zur Erweiterung deines CI/CD-Workflows nutzen kannst. Jeder kann ein Komponentenprojekt erstellen und es zum CI/CD-Katalog hinzufügen oder zu einem bestehenden Projekt beitragen, um die verfügbaren Komponenten zu verbessern. Die veröffentlichten Komponenten findest du im [CI/CD-Katalog](https://gitlab.com/explore/catalog) auf GitLab.com.\n\n> [Tutorial: So richtest du deine erste GitLab-CI/CD-Komponente ein (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n\n### CI-Vorlagen\n\nDu kannst auch deine eigenen [CI-Vorlagen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/examples/) erstellen, um CI/CD-Konfigurationen zu standardisieren und über mehrere Projekte hinweg wiederzuverwenden. Das fördert die Konsistenz und reduziert doppelte Arbeit.\n\nSo erstellst du eine CI-Vorlage:\n\n1. Erstelle eine `.gitlab-ci.yml`-Datei in einem eigenen Projekt oder Repository.  \n2. Definiere deine CI/CD-Konfiguration in der Vorlage. \n3. Verwende in der `.gitlab-ci.yml`-Datei deines Projekts das Schlüsselwort `include`, um die Vorlage einzuschließen.\n\n## Entwicklung der nächsten Generation\n\nGitLab CI/CD ist ein leistungsstarkes Tool, das deinen Workflow bei der Entwicklung verbessern kann. Wenn du die Konzepte von CI/CD verstehst, deine Pipelines konfigurierst und Funktionen wie Auto-DevOps, den CI/CD-Katalog und CI-Vorlagen nutzt, kannst du deinen gesamten Software-Entwicklungsprozess automatisieren und schneller und effizienter hochwertige Software liefern.\n\n> Willst du dein Wissen vertiefen? Registriere dich für die [englischsprachigen Kurse der GitLab University](https://university.gitlab.com/). Du kannst auch sofort mit der [kostenlosen Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/?hosted=saas) loslegen.\n\n## Reihe „Erste Schritte mit GitLab“\n\nWeitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automatisiere Agile-Workflows mit dem gem gitlab-triage](https://about.gitlab.com/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n",[9,755,753,684,685,683],"2025-06-02",{"slug":801,"featured":91,"template":690},"getting-started-with-gitlab-understanding-ci-cd","content:de-de:blog:getting-started-with-gitlab-understanding-ci-cd.yml","Getting Started With Gitlab Understanding Ci Cd","de-de/blog/getting-started-with-gitlab-understanding-ci-cd.yml","de-de/blog/getting-started-with-gitlab-understanding-ci-cd",{"_path":807,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":808,"content":813,"config":820,"_id":822,"_type":14,"title":823,"_source":16,"_file":824,"_stem":825,"_extension":19},"/de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"title":809,"description":810,"ogTitle":809,"ogDescription":810,"noIndex":6,"ogImage":790,"ogUrl":811,"ogSiteName":672,"ogType":673,"canonicalUrls":811,"schema":812},"Erste Schritte mit GitLab: Arbeiten mit CI/CD-Variablen","Erfahre, was CI/CD-Variablen sind, warum sie in DevSecOps wichtig sind und wie du sie am besten einsetzt.","https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: Arbeiten mit CI/CD-Variablen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2025-05-27\",\n      }",{"title":809,"description":810,"authors":814,"heroImage":790,"date":816,"body":817,"category":685,"tags":818,"updatedDate":819},[815],"GitLab Team","2025-05-27","*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.* \n\nIn einem früheren Artikel haben wir uns mit [GitLab CI/CD](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-understanding-ci-cd/) beschäftigt. Jetzt tauchen wir tiefer in die Welt der **CI/CD-Variablen** ein und erschließen ihr volles Potenzial.\n\n## Inhaltsverzeichnis\n\n- [Was sind CI/CD-Variablen?](#was-sind-cicd-variablen%3F)\n- [Warum sind CI/CD-Variablen wichtig?](#warum-sind-cicd-variablen-wichtig%3F)\n- [Geltungsbereiche von CI/CD-Variablen: Projekt, Gruppe und Instanz](#geltungsbereiche-von-cicd-variablen-projekt-gruppe-und-instanz)\n- [Definieren von CI/CD-Variablen](#definieren-von-cicd-variablen)\n- [Verwenden von CI/CD-Variablen](#verwenden-von-cicd-variablen)\n- [Vordefinierte CI/CD-Variablen](#vordefinierte-cicd-variablen)\n- [Bewährte Methoden](#bewährte-methoden)\n- [Entdecke die Leistungsfähigkeit von Variablen](#entdecke-die-leistungsfähigkeit-von-variablen)\n- [Reihe „Erste Schritte mit GitLab\"](#reihe-„erste-schritte-mit-gitlab“)\n\n### Was sind CI/CD-Variablen?\n\nCI/CD-Variablen sind dynamische Schlüssel-Wert-Paare, die du auf verschiedenen Ebenen in deiner GitLab-Umgebung definieren kannst (z. B. Projekt, Gruppe oder Instanz). Diese Variablen fungieren als Platzhalter für Werte, die du in deiner `.gitlab-ci.yml`-Datei verwenden kannst, um deine Pipelines anzupassen, vertrauliche Informationen sicher zu speichern und deine CI/CD-Konfiguration besser zu pflegen.\n\n### Warum sind CI/CD-Variablen wichtig?\n\nCI/CD-Variablen bieten zahlreiche Vorteile:\n\n* **Flexibilität** – Du kannst deine Pipelines leicht an verschiedene Umgebungen, Konfigurationen oder Bereitstellungsziele anpassen, ohne dein zentrales CI/CD-Skript zu ändern. \n* **Sicherheit** – Speichere vertrauliche Informationen wie API-Schlüssel, Passwörter und Token sicher und verhindere so, dass sie in deinem Code offengelegt werden.  \n* **Wartbarkeit** – Verwalte deine CI/CD-Konfiguration sauber und übersichtlich, indem du Werte in Variablen zentralisierst, was Aktualisierungen und Änderungen erleichtert. \n* **Wiederverwendbarkeit** – Definiere Variablen einmal und verwende sie in mehreren Projekten wieder, um die Konsistenz zu fördern und doppelte Arbeit zu vermeiden.\n\n### Geltungsbereiche von CI/CD-Variablen: Projekt, Gruppe und Instanz\n\nMit GitLab kannst du CI/CD-Variablen mit unterschiedlichen Geltungsbereichen definieren und so ihre Sichtbarkeit und Zugänglichkeit steuern:\n\n* **Variablen auf Projektebene** – Diese Variablen sind spezifisch für ein einzelnes Projekt und eignen sich ideal zum Speichern von projektspezifischen Einstellungen, wie zum Beispiel:\n  * Bereitstellungs-URLs: Definiere unterschiedliche URLs für Staging- und Produktivumgebungen. \n  * Datenbank-Zugangsdaten: Speichere Details zur Datenbankverbindung für Tests oder die Bereitstellung.  \n  * Feature-Flags: Aktiviere oder deaktiviere Funktionen in verschiedenen Phasen deiner Pipeline.  \n  * Beispiel: Du hast ein Projekt mit dem Namen „MyWebApp“ und möchtest die URL für die Bereitstellung speichern. Du erstellst eine Variable auf Projektebene mit dem Namen `DPROD_DEPLOY_URL` und dem Wert `https://mywebapp.com`.  \n* **Variablen auf Gruppenebene** – Diese Variablen werden von allen Projekten innerhalb einer GitLab-Gruppe gemeinsam genutzt. Sie sind nützlich für Einstellungen, die für mehrere Projekte gleich sind, wie z. B.:\n\n  * API-Schlüssel für gemeinsam genutzte Dienste: Speichere API-Schlüssel für Dienste wie AWS, Google Cloud oder Docker Hub, die von mehreren Projekten innerhalb der Gruppe genutzt werden.  \n  * Globale Konfigurationseinstellungen: Lege gemeinsame Konfigurationsparameter fest, die für alle Projekte in der Gruppe gelten.  \n  * Beispiel: Du hast eine Gruppe mit dem Namen „Web-Apps“ und möchtest einen API-Schlüssel für Docker Hub speichern. Du erstellst eine Variable auf Gruppenebene mit dem Namen `DOCKER_HUB_API_KEY` und dem entsprechenden API-Schlüsselwert.  \n* **Variablen auf Instanzebene** – Diese Variablen sind für alle Projekte auf einer GitLab-Instanz verfügbar. Sie werden in der Regel für globale Einstellungen verwendet, die für das gesamte Unternehmen gelten, wie z. B.:\n\n  * Standard-Token für die Registrierung von Runnern: Lege ein Standard-Token für die Registrierung neuer [Runner (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/) fest.  \n  * Lizenzinformationen: Hier kannst du Lizenzschlüssel für GitLab-Funktionen oder Tools von Drittanbietern speichern.  \n  * Globale Umgebungseinstellungen: Lege Umgebungsvariablen fest, die für alle Projekte verfügbar sein sollen.  \n  * Beispiel: Du möchtest ein Standard-Docker-Image für alle Projekte in deiner GitLab-Instanz festlegen. Du erstellst eine Variable auf Instanzebene mit dem Namen `DEFAULT_DOCKER_IMAGE` und dem Wert `ubuntu:latest`.\n\n### Definieren von CI/CD-Variablen\n\nSo definierst du eine CI/CD-Variable:\n\n1. Klicke auf die Schaltflächen **Einstellungen > CI/CD** für dein Projekt, deine Gruppe oder deine Instanz.  \n2. Gehe zum Abschnitt **Variablen**.  \n3. Klicke auf **Variable hinzufügen**.  \n4. Gib den **Schlüssel** (z. B. `API_KEY`) und den **Wert** ein.  \n5. Aktiviere optional das Kontrollkästchen **Variable schützen**, wenn es sich um vertrauliche Informationen handelt. Dadurch wird sichergestellt, dass die Variable nur für Pipelines verfügbar ist, die auf geschützten Branches oder Tags ausgeführt werden.  \n6. Aktiviere optional das Kontrollkästchen **Variable maskieren**, um den Wert der Variable in den Job-Protokollen auszublenden und eine versehentliche Offenlegung zu verhindern.  \n7. Klicke auf **Variable speichern**.\n\n### Verwenden von CI/CD-Variablen\n\nUm eine CI/CD-Variable in deiner `.gitlab-ci.yml`-Datei zu verwenden, stellst du dem Variablennamen einfach `$` voran:\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### Vordefinierte CI/CD-Variablen\n\nGitLab stellt [vordefinierte CI/CD-Variablen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/variables/predefined_variables/) bereit, die du in deinen Pipelines verwenden kannst. Diese Variablen liefern Informationen über die aktuelle Pipeline, den Job, das Projekt und mehr.\n\nEinige häufig verwendete vordefinierte Variablen sind:\n\n* `$CI_COMMIT_SHA`: Der Commit-SHA der aktuellen Pipeline.  \n* `$CI_PROJECT_DIR`: Das Verzeichnis, in dem das Projekt geklont wird.  \n* `$CI_PIPELINE_ID`: Die ID der aktuellen Pipeline.  \n*`$CI_ENVIRONMENT_NAME`: Der Name der Umgebung, in der bereitgestellt wird (falls zutreffend).\n\n### Bewährte Methoden\n\n* Verwalte vertrauliche Variablen sicher: Verwende geschützte und maskierte Variablen für API-Schlüssel, Passwörter und andere vertrauliche Informationen. \n* Vermeide das Hardcoding von Werten: Verwende Variablen zum Speichern von Konfigurationswerten, um deine Pipelines flexibler und wartbarer zu machen.  \n* Organisiere deine Variablen: Verwende aussagekräftige Namen und gruppiere verwandte Variablen, um sie besser zu organisieren.  \n* Verwende den richtigen Geltungsbereich: Wähle den richtigen Geltungsbereich (Projekt, Gruppe oder Instanz) für deine Variablen aus, je nach Verwendungszweck und Sichtbarkeit.\n\n### Entdecke die Leistungsfähigkeit von Variablen\n\nCI/CD-Variablen sind ein leistungsstarkes Tool zur Anpassung und Sicherung deiner GitLab-Pipelines. Wenn du verstanden hast, wie Variablen funktionieren und ihre unterschiedlichen Geltungsbereiche kennst, kannst du flexiblere, wartbarere und effizientere Workflows erstellen.\n\nWir hoffen, dass diese Informationen für dich hilfreich waren und du jetzt gut gerüstet bist, um die Möglichkeiten von GitLab für deine Entwicklungsprojekte zu nutzen.\n\n> Lege jetzt los mit CI/CD-Variablen mit einer [kostenlosen Testversion von GitLab Ultimate mit Duo Enterprise](https://about.gitlab.com/de-de/free-trial/).\n\n## Reihe „Erste Schritte mit GitLab“\nLies weitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automatisiere Agile-Workflows mit dem gem gitlab-triage](https://about.gitlab.com/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Grundlegendes zu CI/CD](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-understanding-ci-cd/)\n",[685,683,755,753,9,730],"2025-06-10",{"slug":821,"featured":91,"template":690},"getting-started-with-gitlab-working-with-ci-cd-variables","content:de-de:blog:getting-started-with-gitlab-working-with-ci-cd-variables.yml","Getting Started With Gitlab Working With Ci Cd Variables","de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables.yml","de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"_path":827,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":828,"content":834,"config":844,"_id":846,"_type":14,"title":847,"_source":16,"_file":848,"_stem":849,"_extension":19},"/de-de/blog/gitlab-flow-duo",{"title":829,"description":830,"ogTitle":829,"ogDescription":830,"noIndex":6,"ogImage":831,"ogUrl":832,"ogSiteName":672,"ogType":673,"canonicalUrls":832,"schema":833},"Kombiniere GitLab Flow und GitLab Duo für starke Workflows","Erweitere GitLab Flow um die KI-basierten Funktionen von GitLab Duo, um deine DevSecOps-Workflows so effizient wie noch nie zuvor zu machen (Tutorial mit Video).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png","https://about.gitlab.com/blog/gitlab-flow-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kombiniere GitLab Flow und GitLab Duo für starke Workflows\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2023-07-27\",\n      }\n                  ",{"title":829,"description":830,"authors":835,"heroImage":831,"date":837,"body":838,"category":839,"tags":840,"updatedDate":843},[836],"Cesar Saavedra","2023-07-27","Für den Einstieg in DevSecOps ist ein gut durchdachter Workflow nötig – doch das kann oft eine echte Herausforderung sein. Zum Glück gibt es zwei Dinge, die dir dabei helfen können: \n\n**GitLab Flow und GitLab Duo.**\n\nGitLab Flow ist ein vorgefertigter Ansatz, der Unternehmen dabei hilft, DevSecOps-Prozesse erfolgreich umzusetzen. GitLab Duo ist ein [leistungsstarkes Set an KI-basierten Funktionen](https://about.gitlab.com/blog/supercharge-productivity-with-gitlab-duo/) in der DevSecOps-Plattform von GitLab, das Unternehmen dabei helfen kann, Code zu entwickeln, den Betrieb zu optimieren und Software effizienter zu schützen. Zusammen helfen GitLab Flow und GitLab Duo Unternehmen dabei, die Effizienz ihrer Workflows durchgängig deutlich zu verbessern. Das führt dann zu noch höherer Produktivität, Bereitstellungshäufigkeit, Codequalität und Sicherheit sowie zu Resilienz und Verfügbarkeit der Produktion.\n\nIn diesem Artikel erfährst du, wie GitLab Flow und GitLab Duo zusammen dazu beitragen können, Unternehmen mit DevSecOps zum Erfolg zu führen.\n\n > Entdecke die Zukunft von KI-gestützter Softwareentwicklung mit unserem virtuellen Launch-Event zu GitLab 17.  [Jetzt ansehen!](https://about.gitlab.com/de-de/seventeen/)\n\n## Was ist GitLab Flow?\nGitLab Flow ist ein vorgefertigter, festgelegter und durchgängiger Workflow für den Entwicklungslebenszyklus von Anwendungen mit GitLab, einer KI-basierten DevSecOps-Plattform, die eine einheitliche Benutzeroberfläche und ein einheitliches Datenmodell bietet. GitLab Flow baut auf bewährten Methoden und Erfahrungen aus Kundenfeedback und unserem Dogfooding auf. Außerdem deckt GitLab Flow alle [Phasen des DevSecOps-Lebenszyklus](https://about.gitlab.com/de-de/stages-devops-lifecycle/) ab und ermöglicht so einen effizienten Workflow, der aus einer inneren Feedbackschleife für Reviews bestimmter Updates sowie einer äußeren Feedbackschleife für die Verbesserung der gesamten Anwendung sowie des Entwicklungsprozesses an sich besteht.\n\n![Innere und äußere Feedbackschleifen von GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-feedback-loops.png)\n\u003Ccenter>Innere und äußere Feedbackschleifen von GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nWie du an den vielen Phasen in GitLab Flow erkennen kannst, besteht die Entwicklung einer Software aus viel mehr als dem reinen Programmieren. Im Folgenden erfährst du mehr über jeden Schritt von GitLab Flow und darüber, wie GitLab Duo dich dabei unterstützen kann.\n\n### Planen\nDas erste Element von GitLab Flow ist die Planung, die sich in der äußeren Feedbackschleife von GitLab Flow befindet. Sie umfasst Tickets, Merge Requests, Epics, Meilensteine, Iterationen, Veröffentlichungen, Release-Nachweise und mehr. Im Folgenden erfährst du, welche Rolle diese Komponenten in GitLab Flow spielen und wie dich GitLab Duo dabei unterstützen kann.\n\n![Planen – das erste Element in GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-planning-portion.png)\n\u003Ccenter>Planen – das erste Element in GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\n#### Tickets\nTickets sind die Elemente, in denen Produktprobleme oder neue Funktionen definiert werden und in denen Teammitglieder zusammenarbeiten können. Wenn ein Ticket erstellt wird, kannst du seinen Titel ausfüllen und dann die Funktion GitLab Duo **Issue Description Generation** nutzen, um die Beschreibung zu erstellen. So sparst du Zeit und hast weniger Aufwand. Da viele Beteiligte an Kommentar-Threads in einem Ticket mitarbeiten können, ist die **Diskussionszusammenfassung** eine KI-basierte Funktion von GitLab Duo, die dir hunderte Kommentare zu einem Ticket in einem kurzen Absatz zusammenfasst. So erhalten die Beteiligten rasch einen Überblick über die Konversation, können sich direkt an der Diskussion beteiligen und sofort produktiv werden.\n\nTickets können in Issue-Übersichten organisiert und visualisiert werden. Dabei handelt es sich um ein Software-Projektmanagementtool, das als Kanban- oder Scrum-Board eingesetzt werden kann. Mit diesen Boards können Teams den Workflow einer Funktion oder einer Produkt-Release einfacher planen, organisieren und visualisieren. Es können verschiedene Kategorien von Boards erstellt werden, wobei Tickets ganz einfach per Drag & Drop von einem zum anderen gezogen werden können.\n\n#### Merge Requests\nMerge Requests sind die Elemente, in denen Lösungen entwickelt werden. Tickets und Merge Requests sind Bestandteile einer Release und ermöglichen, dass Änderungen an Anwendungen, die von Beteiligten wie DevOps und Platform Engineers, System- und Datenbankadministrator(innen), Security Engineers und Entwickler(inne)n vorgenommen werden, überprüft und nachverfolgt werden können. Darüber hinaus sind Tickets und Merge Requests wichtige Inputs für den Release-Planungsprozess.\n\nMerge Requests können einzeln oder aus einem Ticket erstellt werden. Wenn du ein Merge Request aus einem Ticket erstellst, wird es automatisch dem Ticket zugeordnet. Wenn der Merge Request dann zusammengeführt wird, wird das zugehörige Ticket automatisch geschlossen. Merge Requests können auch manuell mit einem Ticket verknüpft werden.\n\n![Der Merge Request schließt das Ticket](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/mr-with-its-issue.png)\n\u003Ccenter>Der Merge Request schließt das Ticket\u003C/center>\u003Cp>\u003C/p>\n\nÄhnlich wie Tickets können auch Merge Requests eine lange Liste an Updates an einem Feature-Branch, die durch verschiedene Beteiligte vorgenommen wurden, enthalten. Mitwirkende, die sich mit den Updates vertraut machen möchten oder alle Updates in einem Merge Request verstehen müssen, können die Funktion **Merge-Request-Zusammenfassung** in GitLab Duo nutzen, um einen raschen Überblick über die Änderungen zu erhalten. Darüber hinaus können die Mitwirkenden mit der Funktion GitLab Duo **Code Merge Request Template Population** eine vorab erstellte Merge-Request-Vorlage heranziehen, die automatisch mit den entsprechenden Inhalten ausgefüllt wird. Beschreibungsvorlagen sind eine Möglichkeit, die Zusammenarbeit und Kommunikation im gesamten Entwicklungslebenszyklus zu standardisieren und zu optimieren – und mit GitLab Duo geht das noch schneller!\n\nTickets mit demselben Thema können in einem Epic gruppiert werden, um die zu erledigenden Arbeiten zu organisieren. Epics können untergeordnete Tickets und Sub-Epics haben und/oder mit anderen Epics im gesamten Unternehmen verknüpft werden. Mit Iterationen können Sprints nachverfolgt werden, und sie können manuell oder mithilfe von Iterationskadenzen automatisch geplant werden, um die Planungs-Workflows zu optimieren. Außerdem umfassen Iterationen Abarbeitungs- und Burnup-Diagramme. Abarbeitungsdiagramme helfen dabei, den Gesamtfortschritt im Projektumfang nachzuverfolgen, während Burnup-Diagramme die tägliche Anzahl und Gewichtung von Tickets messen, die in einer bestimmten Timebox hinzugefügt und abgeschlossen wurden.\n\n#### Meilensteine\nMithilfe von Meilensteinen können Teams ihre Tickets und Merge Requests in einer zusammenhängenden Gruppe mit optionalem Start- und Fälligkeitsdatum organisieren. Meilensteine werden in der Regel verwendet, um Releases nachzuverfolgen. Außerdem kann man mit ihnen Tickets und Merge Requests auf Projekt- oder Gruppenebene nachverfolgen. Ähnlich wie Iterationen gibt es auch bei Meilensteinen Abarbeitungs- und Burnup-Diagramme, die den Fortschritt zeigen.\n\nMeilensteine können mit einer Release verknüpft werden, bei deren Erstellung automatisch Artefakte wie etwa ein Release-Nachweis erstellt werden. Der Release-Nachweis ist eine automatisch gesammelte Momentaufnahme der Daten, die mit dieser Release zusammenhängen. Neben Testartefakten und verknüpften Meilensteinen kann der Release-Nachweis auch Jobartefakte enthalten, die sich auf interne Prozesse wie externe Audits beziehen.\n\nEpics, Meilensteine und Iterationen können über Roadmaps visualisiert werden, die dir dabei helfen, den Release-Fortschritt nachzuverfolgen und den Release-Prozess zu optimieren.\n\nSobald die Planung erfolgt ist, können die Arbeiten beginnen, die für die Lösung eines Problems oder die Entwicklung einer neuen Funktion erforderlich sind. Dies geschieht in Merge Requests. Im Folgenden erfährst du, wie das in GitLab Flow funktioniert. \n\n> [Erfahre mehr, indem du GitLab Flow und GitLab Duo ausprobierst](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fblog%2F).\n\n### Merge Requests und Pushen von Code\n\n![Merge Requests und Pushen von Code – das zweite Element in GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-mr-pushing-code-portion.png)\n\u003Ccenter>Merge Requests und Pushen von Code – das zweite Element in GitLab Flow \u003C/center>\u003Cp>\u003C/p>\n\nDas zweite Element von GitLab Flow betrifft Merge Requests und das Pushen von Code. Wie bereits erwähnt sind Merge Requests jene Orte, an denen die Beteiligten in einem Unternehmens an Lösungen zusammenarbeiten. Diese Zusammenarbeit kann verteilt und asynchron erfolgen. Die Mitwirkenden können die Kooperationsfunktionen wie Tagging, Inline-Vorschläge, Inline-Kommentare, Merge-Request-Kommentare, Review Threads und Review Requests nutzen, um gemeinsam die Codequalität, Verfügbarkeit, Zuverlässigkeit und Leistung zu verbessern. Direkt nach der Erstellung eines Merge Requests beginnt die innere Feedbackschleife von GitLab Flow, in der Code, Fix-Pushes, Tests und Scans durchgeführt werden. Hier finden außerdem Reviews zur Zusammenarbeit und zu Updates statt.\n\n#### Pipelines\nWenn Updates über Merge Requests auf einen Feature-Branch angewendet werden, werden automatisch Pipelines ausgeführt, falls diese vorab festgelegt wurden. Pipelines können mehrere Phasen und Jobs haben, um die Anwendung oder den Microservice in einer Review-Umgebung zu erstellen, zu testen und dann bereitzustellen. In dieser Review-Umgebung können Updates dynamisch verifiziert werden, bevor sie in den Haupt-Branch zusammengeführt werden. Diese Automatisierung trägt dazu bei, den Update- und Review-Prozess von Anwendungen zu optimieren.\n\nZudem stellen DevSecOps-Teams, die über Merge Requests Updates an Anwendungen vornehmen, eine Vielzahl an KI-basierten Funktionen zur Verfügung. Wenn sie Code schreiben oder aktualisieren, kann GitLab Duo **Codevorschläge** Code empfehlen, der an dieser Stelle passen würde, und die Entwickler(innen) können entscheiden, ob sie diese Empfehlung annehmen oder ignorieren möchten. Codevorschläge unterstützen dich bei der Codeerstellung über Prompts sowie durch die Code-Vervollständigung, die angezeigt wird, während du schreibst. Codevorschläge können das Programmiererlebnis verbessern, indem sie Fehler reduzieren und es den Entwickler(inne)n ermöglichen, schneller Code zu schreiben. Dies trägt wiederum dazu bei, die Qualität des Produktionscodes zu verbessern. Codevorschläge können außerdem zu einer höheren Produktivität der Entwickler(innen) und schnelleren Iterationen und Rollouts führen.\n\nDa verschiedene Stakeholder innerhalb der Organisation an der Entwicklung oder Überprüfung von Anwendungen beteiligt sind, können sie auf Code stoßen, der schlecht dokumentiert, komplex oder schwer zu verstehen ist oder in einer ihnen unbekannten Programmiersprache geschrieben ist. Die Funktion **Codeerläuterung** von GitLab Duo erklärt den Code in natürlicher Sprache, sodass jeder den Code verstehen und schnell auf dem neuesten Stand sein kann.\n\nWenn Aktualisierungen in den Feature-Branch committet werden, verwendet die GitLab-Duo-Funktion **Vorgeschlagene Prüfer(innen)** die Änderungen in einem Merge Request und das Mitarbeiterdiagramm eines Projekts, um geeignete Prüfer(innen) im Dropdown in der Seitenleiste des Merge Request vorzuschlagen. Die Liste enthält Benutzer(innen), die sich mit einem bestimmten Aspekt der Anwendung auskennen und daher am besten dazu geeignet sind, die Updates zu überprüfen. Entwickler(innen) sparen Zeit, da sie die am besten geeignet Prüfer(innen) nicht suchen und identifizieren müssen sowie den Überprüfungsprozess rationalisieren und Verzögerungen und Reviews von geringer Qualität vermeiden können.Wenn Entwickler(innen) Änderungen am Code vornehmen, fügen sie im Merge Request oft keine Kommentare zu den spezifischen Änderungen hinzu, die sie vorgenommen haben. Mit der **Merge-Request-Zusammenfassung** von GitLab Duo kann die bzw. der Autor(in) von Merge-Request-Änderungen mithilfe der KI einen Kommentar in natürlicher Sprache generieren, der die Updates am Code zusammenfasst. Prüfer(innen) können dann die Änderungen besser verstehen und den gesamten Überprüfungsprozess optimieren.\n\nWenn Prüfer(innen) Updates des Codes in einem Merge Request überprüfen, können sie den Merge Request blockieren. Die Begründung kann aus vielen Kommentaren bestehen, die sich über viele Quelldateien erstrecken. Um der bzw. dem ursprünglichen Autor(in) der Updates zu helfen, das Feedback der Prüferin oder des Prüfers in einem langen Block besser zu verstehen, erstellt die **Code-Review-Zusammenfassung** von GitLab Duo eine Zusammenfassung des Feedbacks der Prüferin bzw. des Prüfers in natürlicher Sprache. Dies ermöglicht eine bessere Übergabe zwischen Autor(inn)en und Prüfer(inne)n, wodurch der Review-Prozess optimiert wird.\n\nWenn Entwickler(innen) neuen Code über einen Merge Request hinzufügen, können sie außerdem die **Testgenerierung** von GitLab Duo nutzen, die mithilfe von KI Unit-Tests für den neuen Code generiert. Dies kann dazu beitragen, die Produktivität der Entwickler(innen) zu erhöhen, die Testabdeckung zu verbessern und Fehler frühzeitig im Entwicklungslebenszyklus zu erkennen. Entwickler(innen) können auch den jederzeit verfügbaren **Chat** von GitLab Duo nutzen, um Code zu refaktorisieren und Inline-Dokumentation wie z. B. Docstrings für ihren Quellcode erstellen.\n\nPipelines werden auf Branch-Updates ausgeführt und können automatisierte Tests und Scans enthalten, die dazu beitragen, die Sicherheit schon im Vorfeld zu kontrollieren.\n\n### Sicherheit im Vorfeld kontrollieren (Shift-Left-Ansatz)\n\n![Sicherheit im Vorfeld kontrollieren – das dritte Element von GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-shift-sec-left-portion.png)\n\u003Ccenter>Sicherheit im Vorfeld kontrollieren – das dritte Element von GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nDas dritte Element von GitLab Flow ist, dass die Sicherheit im Vorfeld kontrolliert wird. Diese Kontrolle ist auch Teil der inneren Feedbackschlaufe von GitLab Flow.\n\nNeben DevOps und Platform Engineers, System- und Datenbankadministrator(innen) und Entwickler(innen) betrifft die Sicherheit und Compliance auch einige der Beteiligten, die in einem Merge Request zusammenarbeiten, also an einem Ort, an dem automatisierte Tests und Sicherheitsscans eine Rolle spielen. Scans können einfach über praktisch nutzbare Vorlagen in eine Pipeline aufgenommen werden und/oder automatisch in einer Merge-Request-Pipeline ausgeführt werden. GitLab bietet eine Reihe an integrierten Sicherheitsscannern und Analysatoren, die von GitLab Flow genutzt werden können, doch auf der DevSecOps-Plattform sind auch Scanner von Drittanbietern sowie benutzerdefinierte Scanner möglich.\n\nGitLab Flow kontrolliert die Sicherheit im Vorfeld und verschiebt sie an den Anfang der Pipeline, um Fehler so früh wie möglich im Softwareentwicklungsprozess zu erkennen und zu beheben. Es ist viel einfacher und günstiger, Sicherheitslücken früh im Entwicklungsprozess zu erkennen und zu beheben, anstatt erst dann, wenn die Anwendung bereits in Produktion ist. Hier könnte ein ungeplanter Ausfall nämlich deine Benutzer(innen) beeinträchtigen und deinem Umsatz schaden.\n\nFolgende integrierte Sicherheitsscanner und Analysatoren sind in GitLab enthalten: Unit Tests, Infrastracture-as-Code-Scans (IaC), statische Anwendungssicherheitstests (SAST), Abhängigkeitssuche, Erkennung von Geheimnissen, Container-Scanning, API-Sicherheit, Web-API-Fuzzing und Abdeckungs-Fuzzing. Darüber hinaus hat GitLab eine Vielzahl an Sicherheitsdashboards und Berichten zu bieten, um Sicherheitslücken zu visualisieren. Dazu zählen die Liste der Abhängigkeiten, das Sicherheitsdashboard, der Sicherheitslückenbericht und die Sicherheitslücken-Seiten.\n\nUm Entwickler(inne)n und Security Engineers zu helfen, Sicherheitslücken besser zu verstehen und effizienter zu beheben, bietet die Funktion GitLab Duo **Vulnerability Explanation** eine Erklärung zu einer bestimmten Sicherheitslücke, wie sie ausgenutzt werden kann, und vor allem eine Empfehlung, wie die Sicherheitslücke behoben werden kann. Entwickler(innen) profitieren außerdem von der Funktion GitLab Duo **Vulnerability Resolution**, mit der automatisch ein Merge Request erstellt wird, der Codeänderungen zur Behebung der Sicherheitslücke enthält. Diese KI-basierten Funktionen tragen dazu bei, eine Anwendung sicherer zu machen und zu härten, um Sicherheitslücken zu vermeiden, die in der Produktion dann Ziel von Cyberangriffen werden könnten.\n\nNeben SAST-Scannern bietet GitLab auch DAST-Scanner (dynamische Anwendungssicherheitstest), für die eine laufende Anwendung erforderlich ist. Wenn diese Scanner eingesetzt werden, kann GitLab automatisch eine DAST-Umgebung für die DAST-Scans bereitstellen und dann nach dem DAST-Test eine komplette Bereinigung aller Ressourcen durchführen. Zudem bietet GitLab für ausgeführte Container das Operational Container Scanning (OCS) an, bei dem Container-Images in deinem Cluster auf Sicherheitslücken überprüft werden.\n\nDie genannten Scans können automatisch in einer Merge-Request-Pipeline ausgeführt werden. In einigen Fällen kann ihre Ausführung auch über Scan-Ausführungs- oder Merge-Request-Approvalrichtlinien geplant werden. Diese Richtlinien können über das GitLab-UI oder YAML-Dateien festgelegt werden und werden in einem separaten Projekt konfiguriert. Dies ermöglicht eine Aufgabentrennung, die die erneute Verwendung, die Wartung und die Verwaltung vereinfacht. Scan-Ausführungsrichtlinien erfordern, dass Sicherheitsscans nach einem bestimmten Zeitplan oder mit der Projektpipeline ausgeführt werden, während Merge-Request-Approvalrichtlinien Maßnahmen auf der Grundlage von Scan-Ergebnissen setzen. Security Engineers oder Sicherheitsteams können diese Richtlinien festlegen, um Sicherheitsprozesse im gesamten Unternehmen durchzusetzen. Da sich GitLab Flow durch alle Schritte zieht, können diese Richtlinien vorkommen bzw. genutzt werden.Um die Sicherheit und Compliance in deinem Unternehmen projektübergreifend durchzusetzen, kannst du Compliance-Labels und -Pipelines verwenden. Du kannst festlegen, dass Compliance-Labels und -Pipelines verpflichtend vor der eigenen Pipeline eines Projekts ausgeführt werden müssen. Mit diesem Ansatz kannst du sicherstellen, dass alle Teams in deinem Unternehmen deine Sicherheits- und Compliance-Standards erfüllen. Darüber hinaus kannst du so deine Anwendungen vor Cyberangriffen schützen, rechtlichen Vorgaben entsprechen und stets für Audits bereit sein.\n\nDas Hauptziel dieser Sicherheitsvorschriften von GitLab Flow ist, Sicherheitslücken früh im Entwicklungsprozess zu beheben, ehe die Anwendung in Produktion ist. Dann kann es nämlich sowohl teuer als auch schlecht für den Ruf sein, eine solche Sicherheitslücke beheben zu müssen.\n\nWenn Sicherheitslücken in der inneren Feedbackschleife von GitLab Flow behoben werden und weitere Updates an der Anwendung im Feature-Branch vorgenommen werden, müssen die Beteiligten auch diese Updates erneut überprüfen, um sicherzustellen, dass sie wirklich vorgenommen wurden und dass keine versehentlichen Regressionen eingeführt wurden.\n\n### Kontinuierlicher Review \n\n![Reviews – das vierte Element von GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-reviewing-features-portion.png)\n\u003Ccenter>Reviews – das vierte Element von GitLab Flow\u003C/center>\u003Cp>\u003C/p>\n\nDas nächste Element von GitLab Flow ist der Review von Funktionen, also eine kontinuierliche Überprüfung von Anwendungen. Die Review-Funktionen umfassen die Möglichkeit, eine Review-Umgebung zu erstellen, in der die vorläufige Anwendung (der sogenannte Feature-Branch) bereitgestellt wird, damit die Beteiligten sie in Echtzeit überprüfen und ihr Feedback dazu abgeben können. Die vorläufige Anwendung kann dann kontinuierlich angepasst werden, bis sie mit dem Haupt-Branch zusammengeführt werden kann. GitLab Flow schreibt außerdem eine Bereinigung aller in der Review-Umgebung bereitgestellten Ressourcen zu dem Zeitpunkt vor, an dem der Merge Request mit dem Haupt-Branch zusammengeführt wird.\n\nDieser iterative automatisierte Review-Prozess ist Teil der inneren Feedbackschleife in GitLab Flow. Wie erwähnt ermöglichen in der inneren Feedbackschleife GitLab-Duo-Funktionen wie Codeerläuterungen, Codevorschläge, vorgeschlagene Prüfer(innen), Merge-Request-Zusammenfassungen, Erstellung von Vorlagen für Merge Requests, Code-Review-Zusammenfassungen, Erläuterungen von Sicherheitslücken, Behebung von Sicherheitslücken und Grundursachenanalyse in GitLab Flow eine bessere Übergabe zwischen Autor(inn)en und Prüfer(inne)n und optimieren den gesamten Review-Prozess.\n\nDie innere Feedbackschleife von GitLab Flow endet, wenn alle Review-Elemente behandelt wurden, der Merge Request freigegeben wurde und mit dem Haupt-Branch zusammengeführt wurde. Dies löst dann die Bereitstellung der Anwendung für die Produktion aus.\n\n### Bereitstellung von Anwendungen und Infrastrukturen\n\n![Bereitstellen – das fünfte Element in GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/The-GitLab-Flow-2023-deploy-apps-portion.png)\n\u003Ccenter>Bereitstellen – das fünfte Element in GitLab Flow]\u003C/center>\u003Cp>\u003C/p>\n\nAbhängig von den Anforderungen eines Unternehmens gibt GitLab Flow entweder kontinuierliche Lieferung oder kontinuierliche Bereitstellung vor. Während man unter kontinuierlicher Lieferung die häufige Veröffentlichung von Code durch manuelles Auslösen der Bereitstellungen (z. B. in die Produktion) versteht, ist die kontinuierliche Bereitstellung die automatische Veröffentlichung von Code (z. B. in die Produktion) ohne menschliches Zutun. Sehen wir uns zunächst die kontinuierliche Lieferung an.\n\nWenn du deine Software mit kontinuierlicher Lieferung veröffentlichst, gibt es verschiedene Bereitstellungsoptionen. Du kannst ein Standbild-Fenster einrichten und dann mit fortschrittlichen Bereitstellungstechniken wie Canary, Blue/Green, zeitlich abgestimmte und inkrementelle Rollouts bereitstellen. Inkrementelle Rollouts können das Risiko von Produktionsausfällen verringern, was zu einer besseren User Experience und einer höheren Kundenzufriedenheit führt. Fortschrittliche Bereitstellungstechniken können auch die Entwicklungs- und Liefereffizienz verbessern und den Release-Prozess optimieren.\n\nWenn du deine Software mit kontinuierlicher Bereitstellung veröffentlichst, gehen alle Änderungen/Updates direkt in die Produktion. Progressive Bereitstellungsansätze wie Feature-Flags, mit denen du die Bereitstellung bestimmter Funktionen von einer Markteinführung trennen kannst, sind eine gute Möglichkeit, die Risiken zu reduzieren und zu verwalten, welche Funktionen den Produktionsbenutzer(inne)n zur Verfügung gestellt werden sollen. Feature-Flags unterstützen mehrere Programmiersprachen und ermöglichen Experimente der Entwickler(innen) und kontrollierte Tests. Du kannst sogar Feature-Flags verwenden, um Funktionen nur für bestimmte Benutzer(innen) auszurollen.\n\nGitLab unterstützt all diese Bereitstellungsansätze, doch GitLab Flow ermöglicht nur die Umsetzung jenes Ansatzes, der am besten zum Unternehmen und/oder zum spezifischen Projekt passt.\n\n### Überwachen von Anwendungen und DevSecOps-Prozessen\nSobald deine Anwendung für die Produktion bereitgestellt wurde, muss sie kontinuierlich überwacht werden, um ihre Stabilität, Leistung und Verfügbarkeit sicherzustellen. Darüber hinaus werden DevSecOps-Prozesse gemessen, während sie ausgeführt werden, damit ihre Leistung und Effizienz verbessert werden kann. Diese Überwachungsfunktionen werden von GitLab bereitgestellt und können daher auch mit GitLab Flow genutzt werden.\n\nGitLab bietet für ausgeführte Container das Operational Container Scanning (OCS) an, bei dem Container-Images in deinem Cluster auf Sicherheitslücken überprüft werden. Diese Scans können automatisiert werden, indem du planst, wann sie ausgeführt werden. Gefundene Sicherheitslücken werden dann automatisch in einem Sicherheitsdashboard angezeigt. Das OCS hilft dir dabei, deine Cluster-Anwendungen zu schützen und Cyberangriffe, die zur Veröffentlichung privater Daten und sogar zu unerwarteten Ausfällen führen können, frühzeitig abzuwehren.\n\nDie Fehlerverfolgung ermöglicht es Entwickler(inne)n, von ihrer Anwendung generierte Fehler zu entdecken und anzuzeigen. Alle von deiner Anwendung generierten Fehler werden in der Fehlerverfolgungsliste in GitLab angezeigt. Die Fehlerverfolgung trägt zu einer besseren Verfügbarkeit und Leistung deiner Anwendungen bei, indem unerwartete Anwendungsbedingungen schnell erkannt und behoben werden.\n\nGitLab kann über einen Webhook-Empfänger Alarme von beliebigen Überwachungsquellen wie Prometheus erhalten. Wenn Alarme eingehen, werden sie in der GitLab-Alarmliste angezeigt, von wo aus du sie dann manuell verwalten kannst. Alarme können auch automatisch die Erstellung von Vorfällen, ChatOps und E-Mails an die entsprechenden Personen oder Gruppen auslösen. All diese Funktionen optimieren den Umgang mit Alarmen sowie deren Bearbeitung.\n\nWenn Vorfälle aufgrund von Produktionsproblemen erstellt werden, werden sie in der GitLab-Vorfall-Liste für das Vorfallmanagement angezeigt. Du kannst einen oder mehrere Vorfälle verwalten, sie sortieren, durchsuchen, zuweisen, ihren Status festlegen und sogar den vorab gesetzten SLA-Countdown-Timer anzeigen. Darüber hinaus kannst du Bereitschaftspläne und -rotationen erstellen, Eskalationsrichtlinien festlegen sowie Paging und Benachrichtigungen für die Bearbeitung von Vorfällen einrichten. Außerdem kannst du einen Vorfall mit einem Alarm verknüpfen. Wenn der Vorfall geschlossen wird, wird der zugehörige Alarm automatisch als gelöst gekennzeichnet. Vorfall-Zeitleisten sind eine weitere Funktion für Führungskräfte und externe Betrachter(innen), um zu sehen, was während eines Vorfalls passiert ist und welche Maßnahmen zur Behebung des Vorfalls getroffen wurden. All diese Funktionen optimieren das Vorfallmanagement, damit Vorfälle so schnell wie möglich gelöst werden können.\n\nAudit Events verfolgen wichtige Ereignisse und zeichnen unter anderem auf, wer die entsprechende Handlung zu welchem Zeitpunkt in GitLab ausgeführt hat. Diese Ereignisse werden in der Audit-Event-Liste in GitLab angezeigt und geben unter anderem Informationen zum Ereignis, das für ein Objekt durchgeführt hatte, sowie die Person, die dieses Ereignis durchgeführt hat, und Datum und Uhrzeit.\n\nAll diese Listen und Dashboards helfen, nicht konforme Szenarien und damit zusammenhängende Strafen früh genug zu vermeiden sowie Audit-Prozesse zu optimieren. Sie generieren Daten und Indikatoren für deine laufenden Anwendungen, die dann in der äußeren Feedbackschleife von GitLab Flow verwendet werden können, um deine Anwendungen zu verbessern und zu optimieren und das Risiko unerwarteter Produktionsausfälle zu verringern.\n\n### Kontinuierliche Verbesserung\nWenn du GitLab Flow einsetzt, hast du auch die Möglichkeit, Einblicke mit GitLab zu nutzen. Du erhältst diese in Form von durchgängigen Prozessmetrik-Dashboards, damit du nicht nur deine Anwendungen, sondern auch die Performance deiner Softwarebereitstellung kontinuierlich verbessern kannst. Diese Dashboards und ihre Metriken werden von GitLab automatisch generiert und sind immer verfügbar.\n\n### Dashboard für die Wertstromanalyse\nDu kannst den Lebenszyklus deiner Anwendungsentwicklung über das Dashboard für die Wertstromanalyse verfolgen und überwachen, denn hier kannst du Projekt- und Gruppenstatistiken im Zeitverlauf anzeigen. Dieses Dashboard ist anpassbar, du kannst aber auch gleich loslegen und eine Wertschöpfungskette über eine der vorgefertigten Vorlagen von GitLab erstellen. Das Standarddashboard zeigt Metriken für jede der vordefinierten Phasen deiner Wertstromanalyse an, also Ticket, Planen, Programmieren, Testen, Review und Staging. Außerdem wird ein Diagramm mit der durchschnittlichen Zeit, die für den Abschluss der einzelnen Phasen benötigt wird, angezeigt. Hier werden auch die wichtigsten Indikatoren der Wertstromanalyse angezeigt: Abarbeitungsdauer, Bearbeitungszeit, neue Tickets, Commits und Bereitstellungen. Du kannst anhand dieser Metriken Verbesserungsbereiche in den einzelnen Phasen deiner Wertschöpfungskette identifizieren.\n\n### DORA-Metrik-Dashboard\nUm die Performance-Metriken anzuzeigen, die die Effektivität der Entwicklung und der Bereitstellungspraktiken in deinem Unternehmen messen, gibt es in GitLab das [DORA-Metrik-Dashboard](https://about.gitlab.com/de-de/solutions/value-stream-management/dora/) (DevOps Research and Assessment), in dem vier wichtige Metriken angezeigt werden: Häufigkeit der Bereitstellung, Vorlaufzeit für Änderungen, Zeit bis zur Wiederherstellung des Service und Änderungsfehlerrate. Die Häufigkeit der Bereitstellung misst, wie oft dein Unternehmen Code in der Produktion bereitstellt oder für Endbenutzer(innen) veröffentlicht. Die Vorlaufzeit für Änderungen misst, wie lange es vom Commiten des Codes bis zur erfolgreichen Ausführung in der Produktion dauert. Die Zeit bis zur Wiederherstellung des Service misst die Zeit, die benötigt wird, um die Services bei einem Vorfall auf dem vorherigen Niveau wiederherzustellen. Die letzte Kennzahl ist die Änderungsfehlerrate, also der Prozentsatz an Änderungen an der Produktion bzw. an für Benutzer(innen) veröffentlichten Anwendungen, die zu einem eingeschränkten Service führen (z. B. durch eine Änderung, die zu einer Einschränkung des Service oder zu einem Ausfall führte) und dementsprechende Behebung benötigen (in Form von Hotfixes, Rollbacks oder Patches). Diese vier Schlüsselkennzahlen sind Ergebnisse deine aktuellen Prozesse und geben dir die Möglichkeit, die Faktoren und Funktionen zu verbessern, die dahinterstehen.\n\n### Anpassung deines Dashboards\nEin weiteres Dashboard ist das Wertstrom-Dashboard, ein anpassbares Dashboard, mit dem Entscheidungsträger(innen) Trends, Muster und Möglichkeiten für Verbesserungen im Bereich der Softwareentwicklung erkennen können. Die gezeigten Metriken sind die DORA-Metriken, gefolgt von Flow-Metriken für die Wertstromanalyse und Zähler für kritische und hohe Sicherheitslücken im jeweiligen Monat bis zum aktuellen Datum, für die zwei vorhergehenden Monate sowie die sechs vorhergehenden Monate.\n\nGitLab Duo kann auch bei deinen Bestrebungen für kontinuierliche Verbesserungen helfen. Die Funktion **Wertstromprognose** zieht historische Daten heran und verwendet Datentrends aus deinem gesamten Entwicklungslebenszyklus, um das zukünftige Verhalten deiner Wertstrom-Metriken zu prognostizieren. Du kannst diese prädiktiven Analysen für deine Optimierungen nutzen.\n\nAll diese Dashboards und die Indikatoren, die sie anzeigen, sind Teil der äußeren Feedbackschleife von GitLab Flow. Sie helfen dir, das Risiko ungeplanter Produktionsausfälle zu verringern sowie deine Anwendungen und DevSecOps-Workflows zu verbessern.\n\n### KI-Impact-Analysen\nUm die Auswirkungen von GitLab Duo (bzw. der KI) im gesamten Entwicklungslebenszyklus besser zu verstehen, steht dir die [KI-Impact-Analyse](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) zur Verfügung. Hier siehst du, wie sich die Nutzung von Codevorschlägen von GitLab Duo auf andere Leistungs-, Qualitäts- und Sicherheitsmetriken auswirkt. Du kannst die letzten sechs Monate der KI-Einführung und ihre Auswirkungen auf andere Indikatoren wie Bearbeitungszeit, Abarbeitungsdauer, Bereitstellungshäufigkeit, Änderungsfehlerrate und kritische Sicherheitslücken im Zeitverlauf visualisieren.\n\nKI-Impact-Analysen helfen dir dabei, die Akzeptanz, Effektivität und Vorteile zu messen, die die KI deinen Teams und deinem Unternehmen bringt. Zudem tragen sie dazu bei, Verbesserungsbereiche zu identifizieren.\n\n## Warum solltest du GitLab Flow verwenden?\nGitLab Flow ist ein vorgefertigter Ansatz, der von unseren Kund(inn)en und Benutzer(inne)n auf der ganzen Welt eingesetzt wird und folgende Vorteile bieten kann:\n\n- Höhere Produktivität durch Automatisierungsmöglichkeiten von GitLab und dessen vereinheitlichter Benutzeroberfläche und des einheitlichen Datenmodells, die beide von GitLab Flow verwendet werden\n- Genaue Einblicke in den gesamten DevSecOps-Lebenszyklus, um kontinuierliche Verbesserungen zu ermöglichen\n- Integrierte Dashboards und Metriken, die dir dabei helfen, deine Anwendungen und DevSecOps-Prozesse zu optimieren\n- Höhere Codequalität und verbesserte Zuverlässigkeit und Verfügbarkeit deiner Anwendungen\n- Bessere Anwendungssicherheit durch integrierte Sicherheitsscanner und -funktionen\n- Einhaltung von Compliance und Vorbereitung für Audits durch integrierte Compliance-Funktionen\n- Kürzere Bearbeitungszeiten für höhere Bereitstellungshäufigkeit\n- Kontinuierliche Reviews durch die innere Feedbackschleife von GitLab Flow\n- Die innere Feedbackschleife von GitLab Flow hilft dir, Anwendungs-Updates zu optimieren, wodurch sich die Codequalität verbessert und deine Anwendungen zuverlässiger und besser verfügbar werden\n- Die äußere Feedbackschleife von GitLab Flow kann dazu beitragen, deine Anwendungen sowie den Entwicklungslebenszyklus an sich zu verbessern\n- Intensive Zusammenarbeit zwischen den Beteiligten in deinem Unternehmen\n- Die Sicherheit wird im Vorfeld kontrolliert, um Sicherheitslücken in den Anwendungen zu finden,  bevor sie in die Produktion gelangen, wo solche Fehler teure, ungeplante Ausfälle verursachen können \n- Niedrigeres Risiko bei der Bereitstellung in die Produktion durch fortschrittliche Bereitstellungstechnicken und den progressiven Lieferansatz von GitLab\n- KI-Funktionen im gesamten Entwicklungslebenszyklus können Produktivität, Codequalität, kontinuierliche Verbesserung, Sicherheit, Compliance und mehr verbessern\n- Unterstützung für Cloud-native und nicht-Cloud-native Anwendungen\n- Multi-Cloud-Support für hybride Anwendungen und Multi-Cloud-Anwendungen\n- Die Sicherheit wird im Vorfeld kontrolliert, um Sicherheitslücken in den Anwendungen zu finden, bevor sie in die Produktion gelangen, wo solche Fehler teure, ungeplante Ausfälle verursachen können\n\nWie kannst du mit GitLab Flow durchstarten? Ein guter Ausgangspunkt, um die Prinzipien von GitLab Flow für deinen Lebenszyklus der Anwendungsentwicklung einzuführen, sind Auto-DevOps von GitLab.\n\n## GitLab Flow und Auto-DevOps\n\n![Auto DevOps – eine Instanziierung von GitLab Flow](https://about.gitlab.com/images/blogimages/gitlab-flow-duo/ado-pipeline.png)\n\u003Ccenter>Auto-DevOps – eine Instanziierung von GitLab Flow\u003C/center>\u003Cp>\u003C/p>Bei [Auto-DevOps](https://docs.gitlab.com/ee/topics/autodevops/) wird GitLab Flow in allen Phasen und Jobs angewendet. Du kannst es dir als ein gutes Beispiel für die Instanziierung von GitLab Flow vorstellen.\n\nAuto-DevOps ist eine Sammlung vordefinierter, sofort einsatzbereiter CI/CD-Vorlagen, die deinen Quellcode automatisch erkennen. Basierend auf bewährten Methoden können diese Vorlagen deine Anwendungen automatisch erkennen, erstellen, testen, bereitstellen und überwachen.\n\nDie Auto-DevOps-Pipeline kontrolliert die Sicherheit im Vorfeld, um Fehler so früh wie möglich im Softwarelieferprozess zu finden und zu vermeiden. Die Pipeline stellt die Anwendung dann zur Verifizierung im Staging und dann inkrementell/zeitgesteuert in der Produktion bereit.\n\nMit Auto-DevOps kannst du rasch durchstarten, die Produktivität der Entwickler(innen) steigern und das Ganze einfach an deine Bedürfnisse anpassen. Außerdem erhältst du Unterstützung für die bekanntesten Programmier-Frameworks und -sprachen. Auto-DevOps ist modular, anpassbar und erweiterbar, sodass du sowohl nur einzelne Elemente in deiner Pipeline nutzen oder das Gesamtpaket für deine Anwendung einsetzen kannst.\n\n## Los geht’s\n[Kombiniere jetzt GitLab Flow und GitLab Duo](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fblog%2F), um die Effizienz deiner Workflows von Anfang bis Ende deutlich zu verbessern. So kannst du eine noch höhere Produktivität, Bereitstellungshäufigkeit, Codequalität und Sicherheit sowie verbesserte Resilienz und Verfügbarkeit deiner Produktion erreichen.\n\nWenn du sehen möchtest, wie ein Workflow funktioniert, der GitLab Flow und GitLab Duo kombiniert und wie du davon profitieren kannst, schau dir das folgende Video an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/CKrZ4_tKY4I?si=Kf6QsYFIzKkJZpJd\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n","ai-ml",[9,841,842],"AI/ML","DevSecOps","2025-04-21",{"slug":845,"featured":6,"template":690},"gitlab-flow-duo","content:de-de:blog:gitlab-flow-duo.yml","Gitlab Flow Duo","de-de/blog/gitlab-flow-duo.yml","de-de/blog/gitlab-flow-duo",{"_path":851,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":852,"content":855,"config":864,"_id":866,"_type":14,"title":867,"_source":16,"_file":868,"_stem":869,"_extension":19},"/de-de/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":853,"title":854},"Ein neues Angebot von GitLab und IBM überbrückt Mainframe- und Cloud-native-Entwicklung mit nahtloser Integration, CI/CD-Runner-Unterstützung, End-to-End-Transparenz und Kosteneffizienz.","GitLab Ultimate für IBM Z: Moderne DevSecOps für Mainframes",{"heroImage":856,"body":857,"authors":858,"updatedDate":861,"date":862,"title":854,"tags":863,"description":853,"category":685},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750440008/myqt5vcjlffh8sszw507.png","GitLab und IBM haben sich zusammengeschlossen, um eine grundlegende Diskrepanz in der Unternehmensentwicklung zu lösen: Mainframe-Entwickler(innen) sollen mit denselben modernen Tools, Workflows und Kollaborationsfunktionen arbeiten können wie ihre Kolleg(inn)en in verteilten Umgebungen.\n\nGitLab Ultimate für IBM Z, eine von GitLab zertifizierte, integrierte DevSecOps-Lösung, die speziell für die Mainframe-Umgebung entwickelt wurde, macht genau das möglich: Sie ermöglicht es Unternehmen, ihre Mainframe-Entwicklungsworkflows zu modernisieren, indem eine nahtlose Migration von veralteten Legacy-Bibliotheksmanagern erleichtert wird. Mit CI/CD-Pipelines, die nativ auf IBM z/OS laufen, erleben Kund(inn)en beschleunigte Innovation und reduzierte Betriebskosten.\n\n## Herausforderungen der heutigen Mainframe-Entwicklung\n\nUnternehmen, die IBM Z-Systeme für geschäftskritische Workloads einsetzen, stehen vor Herausforderungen, für die herkömmliche DevSecOps-Tools nicht ausgestattet sind. Cloud-native Teams profitieren von modernen [CI/CD](https://about.gitlab.com/topics/ci-cd/)-Pipelines, kollaborativer Entwicklung und automatisierten Tests. Im Gegensatz dazu werden Mainframe-Teams oft zurückgelassen – sie stecken mit veralteten Tools fest, die zu kostspieligen Ineffizienzen und operativen Silos führen.\n\nTeams greifen oft auf Workarounds zurück, wie SSH-Verbindungen und manuelle Dateiübertragungen, die Sicherheitslücken schaffen und Audits erschweren. Wenn Compliance-Anforderungen streng sind, werden diese improvisierten Lösungen zu inakzeptablen Risiken. Gleichzeitig unterhalten Organisationen teure parallele Toolchains, wobei Legacy-Mainframe-Entwicklungstools Premium-Lizenzkosten verursachen, während sie im Vergleich zu modernen Alternativen nur eingeschränkte Funktionalität bieten.\n\nDiese Fragmentierung schafft zwei Probleme: langsamere Bereitstellungszyklen und Schwierigkeiten bei der Rekrutierung von Entwickler(inne)n, die modernste Prozesse erwarten.\n\n> **„GitLab Ultimate für IBM Z stellt einen wichtigen Schritt zur Bewältigung einer langjährigen Branchenherausforderung dar. IDC-Forschung zeigt, dass Mainframe-Entwickler(innen) oft mit Legacy-Tools arbeiten, die zu Bereitstellungsineffizienzen beitragen und es schwieriger machen, neue Talente anzuziehen. Mit diesem Angebot werden moderne DevSecOps-Fähigkeiten und einheitliche Workflows direkt auf den Mainframe gebracht. Dies befähigt Entwickler(innen), kollaborativer und effizienter zu arbeiten, während es Organisationen hilft, Innovation zu beschleunigen und Mainframe-Entwicklung in breitere digitale Transformationsstrategien zu integrieren.\"** - Katie Norton, Research Manager, DevSecOps und Software Supply Chain Security bei IDC\n\n## Vereinheitlichte Entwicklungsumgebungen\n\nWahre Modernisierung bedeutet mehr als nur die Aktualisierung der Mainframe-Entwicklung. Es bedeutet, eine einheitliche Plattform zu schaffen, auf der Mainframe-, Cloud-native-, Web- und Mobile-Entwicklungsteams nahtlos zusammenarbeiten.\n\nGitLab Ultimate für IBM Z ermöglicht es Entwickler(inne)n, konsistente Workflows zu verwenden, unabhängig davon, ob sie auf z/OS, Cloud oder On-Premises-Infrastruktur bereitstellen – Wissen wird zwischen Teams übertragen, anstatt in Silos zu verbleiben. Organisationen können schrittweise modernisieren, ohne Geschäftsunterbrechungen, da Legacy-Systeme weiterhin funktionieren, während Teams moderne Praktiken in ihrem eigenen Tempo übernehmen.\n\nWährend Organisationen Hybrid-Cloud-Strategien verfolgen, bietet GitLab die Grundlage für Anwendungen, die sich über Mainframe- und Cloud-native-Umgebungen erstrecken.\n\n## Was ist GitLab Ultimate für IBM Z?\n\nGitLab Ultimate für IBM Z bietet native z/OS-Runner-Unterstützung und ermöglicht eine nahtlose CI/CD-Pipeline-Ausführung direkt auf Ihrer Mainframe-Infrastruktur. Diese von GitLab zertifizierte Lösung hilft, die Notwendigkeit komplexer Workarounds zu eliminieren und gleichzeitig die Sicherheit und Zuverlässigkeit zu gewährleisten, die Ihre Unternehmensanwendungen erfordern.\n\nDie Kombination aus GitLabs umfassender DevSecOps-Plattform und IBMs tiefgreifender Mainframe-Expertise schafft etwas Einzigartiges auf dem Markt: eine zertifizierte Lösung, die eine echte Brücke zwischen unternehmenskritischen Legacy-Systemen und Cloud-nativer Innovation bietet.\n\n## GitLab Ultimate für IBM Z Funktionen\n\nGitLab Ultimate für IBM Z bietet Unternehmensteams die Tools, die sie benötigen, um die Mainframe-Entwicklung zu modernisieren und gleichzeitig kritische Geschäftssysteme zu erhalten.\n\n**Native z/OS-Runner-Unterstützung** hilft, Sicherheitsrisiken und Skalierbarkeitsengpässe im Zusammenhang mit Remote-Verbindungen zu eliminieren, während die Bereitstellung durch CI/CD-Pipelines beschleunigt wird, die direkt dort ausgeführt werden, wo sich Ihr Mainframe-Code befindet.\n\n**Einheitliches Source Code Management** modernisiert Toolchains, indem teure Legacy-Bibliotheksmanager durch GitLabs durchsuchbares, versionskontrolliertes Repository-System ersetzt werden, was zur Reduzierung von Lizenzkosten und Wartungsaufwand beiträgt.\n\n**Nahtlose Integration** mit IBM Developer for z/OS Enterprise Edition (IDzEE) liefert schnellere Software-Releases durch abhängigkeitsbasierte Builds, automatisiertes Code-Scanning und umfassende Debugging-Tools in vertrauten Entwicklerumgebungen, wodurch sowohl Qualität als auch Sicherheit verbessert werden.\n\n**End-to-End-Transparenz** über Mainframe- und verteilte Umgebungen hinweg bietet umfassendes Projektmanagement von der Planung bis zur Produktion und ermöglicht automatisierte DevOps-Workflows, die durch moderne Entwicklungstools der nächsten Generation zur Talentbindung beitragen.\n\n## Modernisiere deine Mainframe-Entwicklungsumgebung noch heute\n\nGitLab Ultimate für IBM Z ist jetzt für Organisationen verfügbar, die bereit sind, ihre Mainframe-Entwicklungserfahrung zu transformieren. Weitere Informationen befinden sich auf der [GitLab und IBM Partnerseite](https://about.gitlab.com/de-de/partners/technology-partners/ibm/).",[859,860],"Mike Flouton","Andy Bradfield","2025-06-23","2025-06-20",[284,685,9,842],{"featured":91,"template":690,"slug":865},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes","content:de-de:blog:gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","Gitlab Ultimate For Ibm Z Modern Devsecops For Mainframes","de-de/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes.yml","de-de/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"_path":871,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":872,"content":879,"config":888,"_id":890,"_type":14,"title":891,"_source":16,"_file":892,"_stem":893,"_extension":19},"/de-de/blog/how-cube-uses-gitlab-to-increase-efficiency-and-productivity",{"ogTitle":873,"schema":874,"ogImage":875,"ogDescription":876,"ogSiteName":672,"noIndex":6,"ogType":673,"ogUrl":877,"title":878,"canonicalUrls":877,"description":876},"Cube reduziert Toolchain-Komplexität und beschleunigt Bereitstellung","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Cube reduziert Toolchain-Komplexität und beschleunigt Bereitstellung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2023-02-07\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668437/Blog/Hero%20Images/faster-cycle-times.jpg","Software-Unternehmen zeigt, wie die DevSecOps-Plattform die Kundenzusammenarbeit verbessert und Releases optimiert.","https://about.gitlab.com/de-de/blog/how-cube-uses-gitlab-to-increase-efficiency-and-productivity","Cube reduziert Toolchain-Komplexität mit GitLab",{"heroImage":875,"body":880,"authors":881,"updatedDate":882,"date":883,"title":873,"tags":884,"description":886,"category":887},"Vor sechs Jahren kämpfte [Cube](https://cube.nl/), ein Software-Entwicklungsunternehmen aus den Niederlanden, mit einer fragmentierten und isolierten Toolchain. Das Unternehmen suchte eine umfassende Lösung, die Entwicklungs-, Sicherheits- und Operations-Teams zusammenführt und eine zentrale Informationsquelle für bessere Zusammenarbeit mit Kund(inn)en schafft. Die Entscheidung fiel auf GitLabs DevSecOps-Plattform.\n\nOperations Manager Mans Booijink und Lead Developer Remi Buijvoets sprachen mit GitLab darüber, wie der Wechsel zu einer All-in-One DevSecOps-Plattform bei Cube – intern und bei Kund(inn)en – einen signifikanten und positiven Unterschied gemacht hat und warum sie mit der Entscheidung zufrieden sind.\n\nBevor wir in die Migrationsgeschichte eintauchen, hier eine Übersicht der Verbesserungen, die Cube mit GitLab erreicht hat:\n\n- Verbesserte [CI/CD](/de-de/topics/ci-cd/)-Bereitstellungsgeschwindigkeit\n- Verbesserte Service-Level-Agreement (SLA)-Reaktionszeit\n- 80% der Cube-Kund(inn)en arbeiten aktiv in GitLab\n- Zentrale Informationsquelle für Zusammenarbeit\n\n![image of Mans Booijink](https://about.gitlab.com/images/blogimages/MansBooijinkCube.jpg) | ![image of Remi Buijvoets](https://about.gitlab.com/images/blogimages/RemiBuijvoetsCube.jpg)\nMans Booijink | Remi Buijvoets\n\n**Warum ist Cube zu GitLab gewechselt?**\n\nVor dem Wechsel nutzten wir eine Kombination aus Bitbucket, Trello und Jira. Die Kombination führte zu einer [fragmentierten, isolierten Toolchain](/blog/battling-toolchain-technical-debt/). Es gab viele Möglichkeiten zur Effizienzsteigerung. Wir begannen GitLab zu nutzen, weil wir ein DevOps-System wollten, das Ticket-Management, Sicherheit und Kundenzusammenarbeit umfasst. GitLab arbeitet nicht nur effizient. Die Einführung ist auch schnell und einfach. Tatsächlich haben wir unsere GitLab-Nutzerbasis in den letzten drei Jahren von 20 auf fast 70 verdreifacht. Jetzt nutzt fast die gesamte Cube-Organisation GitLab. Unsere Kund(inn)en und Kolleg(inn)en (Designer(innen), Entwickler(innen) und Projektmanager(innen)) können einfach kommunizieren, indem sie in derselben GitLab-Umgebung arbeiten. \n\n**Hat Cube vor GitLab andere Lösungen ausprobiert?**\n\nWir haben andere Tools ausprobiert, bevor wir zu GitLab wechselten. Aber GitLab bot alles, was wir brauchten – Ticket-Management, CI/CD, DevOps, Versionsverwaltung, Dateimanagement und Sicherheit. Es dauerte nicht lange zu erkennen, dass GitLab perfekt war, weil wir ein Tool haben wollten, in dem wir alle gemeinsam mit unseren Kund(inn)en und dem Team arbeiten.\n\n**Wie hat sich die Toolchain seit der Nutzung von GitLab verändert?**\n\nGitLab hat alles zu einer zentralen Informationsquelle vereinfacht. Wir deployen in eine Private Cloud in den Niederlanden und haben Sentry zur Fehlerüberwachung in GitLab integriert. Ansonsten läuft alles, was wir tun, in GitLab.\n\n**Wie hat GitLab CI/CD Cube geholfen?**\n\nGitLab CI hilft uns, den Software-Entwicklungsprozess zu automatisieren, indem GitLab-Pipelines und ein Runner zum Deployen unseres Codes verwendet werden. Innerhalb der Pipelines führen wir Linter zur Überprüfung der Code-Qualität aus. Auch Unit- und Funktionstests werden durchgeführt, um die Funktionsfähigkeit der Anwendung sicherzustellen. Wenn ein Fehler auftritt oder ein Test fehlschlägt, schlägt die Pipeline fehl. GitLab CI bringt Mehrwert in unseren Software-Entwicklungslebenszyklus, weil es verhindert, dass Bugs deployed werden, und hilft, Features zu deployen, während andere Features noch in Entwicklung sind. Zusätzlich hilft es uns, die Qualität unserer Projekte zu überwachen, was essentiell ist.\n\nGitLab CI hilft sicherlich bei der Bereitstellungsgeschwindigkeit, aber auch sehr bei der Erleichterung von Rollbacks, wenn ein Release versehentlich einen Fehler enthält. Wir verwenden einen Release-Zeitplan, und GitLab hilft uns, den Großteil der Arbeit zu automatisieren, sodass wir pünktlich liefern können.\n\nGitLab CD verbessert die Geschwindigkeit unserer Code-Deployments. Wenn die Pipelines erfolgreich sind, können Entwickler(innen) sicherstellen, dass alles wie gewünscht funktioniert. Dadurch können sich Entwickler(innen) mehr auf die eigentliche Entwicklung konzentrieren und müssen keine Gedanken an das Deployment verlieren. Wir haben auch eine lokale Maschine eingeführt, die Releases baut. Die Maschine wird vor Ort gehostet und verfügt über viele Ressourcen. Mehrere GitLab Runner nutzen diese Maschine zum Erstellen von Releases. Die Nutzung der GitLab Runner mit einem lokalen Computer war einfach zu konfigurieren.\n\n**Wie haben GitLabs Agile-Funktionen dem Unternehmen geholfen, effizienter zu werden?**\n\nVor GitLab nutzten wir verschiedene Kommunikationskanäle mit unseren Kund(inn)en. Jetzt bietet GitLab uns einen zentralen, zugänglichen Ort für alle Kommunikationen. Wir nutzen auch [GitLab für Agile-Entwicklung](/de-de/solutions/agile-delivery/). Wir haben unsere Epics zur Verwaltung größerer Entwicklungsprojekte und nutzen auch Milestones. Wir machen vier bis sechs Releases pro Woche und verwalten sie alle durch Erstellung von Milestones, die jeder sehen kann, einschließlich Kund(inn)en und Entwicklungsteam. Wir versehen alle Tickets mit Anforderungen, geschätzter Zeit, geplanter Veröffentlichung, Testverantwortlichen usw. Wir nutzen GitLab für 90 % unseres Projektmanagements, Agile-Managements und der Arbeitsfunktionalitäten, was sich als sehr effektiv erweist.\n\n**Wie misst Cube den Erfolg der GitLab-Migration?**\n\nWir messen die Lead Time der Bereitstellung. Die Ergebnisse jeder einzelnen Phase in der Bereitstellung werden genau protokolliert. So können wir nachweisen, dass wir die mit unseren Kund(inn)en getroffenen Vereinbarungen einhalten. Wir verfolgen auch, wie effizient die verschiedenen Phasen während des Entwicklungsprozesses sind und ob sie sich im Vergleich zur Vergangenheit verbessern.\n\nDa wir GitLab durchgehend im gesamten Prozess nutzen, ist es eine sehr wertvolle und nützliche Informationsquelle.",[795],"2025-09-02","2023-02-07",[842,885,9],"customers","So hat das Software-Unternehmen seine Kundenzusammenarbeit massiv verbessert und Releases optimiert.","customer-stories",{"slug":889,"featured":6,"template":690},"how-cube-uses-gitlab-to-increase-efficiency-and-productivity","content:de-de:blog:how-cube-uses-gitlab-to-increase-efficiency-and-productivity.yml","How Cube Uses Gitlab To Increase Efficiency And Productivity","de-de/blog/how-cube-uses-gitlab-to-increase-efficiency-and-productivity.yml","de-de/blog/how-cube-uses-gitlab-to-increase-efficiency-and-productivity",{"_path":895,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":896,"content":902,"config":910,"_id":912,"_type":14,"title":913,"_source":16,"_file":914,"_stem":915,"_extension":19},"/de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab",{"title":897,"description":898,"ogTitle":897,"ogDescription":898,"noIndex":6,"ogImage":899,"ogUrl":900,"ogSiteName":672,"ogType":673,"canonicalUrls":900,"schema":901},"Wie Indeed seine CI-Plattform mit GitLab transformiert hat","Die weltweit führende Jobbörse migrierte Tausende von Projekten zu GitLab CI und konnte so die Produktivität steigern und die Kosten senken. Hier erfährst du, welche Vorteile das Unternehmen umsetzen und damit einen Anstieg der täglichen Pipelines um 79 % erzielen konnte.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","https://about.gitlab.com/blog/how-indeed-transformed-its-ci-platform-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wie Indeed seine CI-Plattform mit GitLab transformiert hat\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Carl Myers\"}],\n        \"datePublished\": \"2024-08-27\",\n      }",{"title":897,"description":898,"authors":903,"heroImage":899,"date":905,"body":906,"category":887,"tags":907,"updatedDate":909},[904],"Carl Myers","2024-08-27","***Anmerkung der Redaktion: Von Zeit zu Zeit laden wir Mitglieder unserer Kunden-Community ein, einen Beitrag für den GitLab-Blog zu verfassen. Danke an Carl Myers, CI-Plattform-Manager bei Indeed, dass du uns von deinen Erfahrungen mit GitLab berichtest.***\n\nHier bei Indeed ist es unsere Mission, Menschen dabei zu helfen, einen Job zu finden. Indeed ist die weltweit [führende Job-Website](https://www.indeed.com/about?isid=press_us&ikw=press_us_press%2Freleases%2Faward-winning-actress-viola-davis-to-keynote-indeed-futureworks-2023_textlink_https%3A%2F%2Fwww.indeed.com%2Fabout) mit mehr als 350 Millionen Besucher(inne)n pro Monat.\n\nFür die Engineering-Plattformteams von Indeed gilt ein etwas anderes Motto: „Wir helfen den Menschen dabei, Menschen zu helfen, einen Job zu finden.“ Als Teil einer datengesteuerten Engineering-Kultur, die gute zwei Jahrzehnte immer die Jobsuchenden in den Vordergrund gestellt hat, sind wir dafür verantwortlich, die Tools zu entwickeln, mit denen dies nicht nur möglich ist, sondern die die Entwickler(innen) auch darin unterstützen, tagtäglich gute Ergebnisse für die Jobsuchenden zu liefern.\n\nMit der kontinuierlichen Integration von GitLab konnte das nur 11 Personen umfassende CI-Plattformteam von Indeed effektiv Tausende von Benutzer(inne)n im gesamten Unternehmen unterstützen. Weitere Vorteile, die Indeed durch den Umstieg auf GitLab CI erreichen konnte:\n- 79 % Anstieg der täglichen Pipelines\n- 10–20 % niedrigere CI-Hardware-Kosten\n- Gesunkener Supportaufwand\n\n## Weiterentwicklung unserer CI-Plattform: von Jenkins zu einer skalierbaren Lösung\n\nWie viele große Technologieunternehmen haben wir unsere CI-Plattform mit dem Wachstum des Unternehmens organisch aufgebaut und nutzten dabei die damals verfügbaren Open-Source- sowie branchenüblichen Lösungen. 2007, als Indeed weniger als 20 Entwickler(innen) hatte, verwendeten wir Hudson, den direkten Vorgänger von Jenkins.\n\nHeute, nach fast zwei Jahrzehnten des Wachstums, haben wir Tausende von Entwickler(inne)n. Als neue Technologien verfügbar wurden, nahmen wir schrittweise Veränderungen vor und wechselten um 2011 herum zu Jenkins. Dank einer weiteren Verbesserung konnten wir die meisten unserer Workloads mithilfe von [AWS EC2](https://aws.amazon.com/ec2/) auf dynamischen Worker Nodes in der Cloud umstellen. Mit dem Eintritt in das Kubernetes-Zeitalter stieß die Systemarchitektur jedoch an ihre Grenzen.\n\nDie Architektur von Jenkins wurde nicht mit Blick auf die Cloud entwickelt. Jenkins funktioniert mit einem „Controller“-Knoten, einem Single Point of Failure, der wichtige Teile einer Pipeline ausführt und bestimmte Schritte an Worker Nodes (die bis zu einem gewissen Grad horizontal skaliert werden können) auslagert. Controller sind auch eine manuelle Skalierungsachse.\n\nWenn man zu viele Jobs für einen Controller hat, muss man sie manuell auf mehrere Controller verteilen. CloudBees bietet Möglichkeiten, dies zu mindern, etwa durch das CloudBees Jenkins Operations Center, in dem man seine Controllerkonstellation zentral verwalten kann. Die Ausführung von Controllern in einer Kubernetes-Umgebung bleibt jedoch eine Herausforderung, da jeder Controller ein anfälliger Single Point of Failure ist. Aktivitäten wie Node-Rollouts oder Hardwareausfälle verursachen Ausfallzeiten.\n\nNeben den technischen Einschränkungen, die Jenkins mit sich bringt, hatte unsere CI-Plattform auch mehrere Probleme, die wir selbst verursacht hatten. Zum Beispiel haben wir die Jenkins-DSL Groovy verwendet, um in jedem Repository Jobs aus Code zu erstellen. Dies führte dazu, dass jedes Projekt seine eigene, kopierte und eingefügte Job-Pipeline hatte, was zu Hunderten von Versionen führte, die schwer zu warten und aktualisieren waren. Obwohle die Engineering-Kultur von Indeed auf Flexibilität Wert legt und es den Teams erlaubt, in separaten Repositories zu arbeiten, wurde diese Flexibilität zu einer Belastung, als Teams zu viel Zeit damit verbrachten, sich um regelmäßige Wartungsanfragen zu kümmern.\n\nAls wir unser Technical Debt erkannten, setzten wir auf das [Golden-Path-Muster](https://tag-app-delivery.cncf.io/whitepapers/platforms/), das Flexibilität bietet und gleichzeitig eine Standardroute vorgibt, um Updates zu vereinfachen und konsistente Praktiken in den Projekten zu fördern.\n\nDas CI-Plattformteam bei Indeed ist nicht sehr groß. Unser Team aus rund 11 Entwickler(inne)n unterstützt Tausende von Benutzer(inne)n, bearbeitet Supportanfragen, führt Updates und Wartungen durch und ermöglicht einen ständig verfügbaren Support für unser globales Unternehmen.\n\nDa unser Team nicht nur unsere GitLab-Instanz unterstützt, sondern die gesamte CI-Plattform einschließlich des Artefakt-Servers, unseres gemeinsamen Build-Codes und zahlreicher anderer, individueller Komponenten unserer Plattform, hatten wir alle Hände voll zu tun. Wir brauchten einen Plan, der uns half, unsere Herausforderungen zu meistern und gleichzeitig unsere vorhandenen Ressourcen so effizient wie möglich zu nutzen.\n\n## Umstieg auf GitLab CI\n\nNach einem sorgfältigen Design-Review mit den wichtigsten Stakeholdern entschieden wir, das gesamte Unternehmen von Jenkins zu GitLab CI zu migrieren. Die Hauptgründe für die Entscheidung für GitLab CI waren:\n- Wir haben GitLab bereits für die Quellcodeverwaltung verwendet.\n- GitLab ist eine Komplettlösung, die alles bietet, was wir für CI benötigen.\n- GitLab CI wurde für Skalierbarkeit und die Cloud entwickelt.\n- GitLab CI ermöglicht es uns, Vorlagen zu schreiben, die andere Vorlagen erweitern, was mit unserer Golden-Path-Strategie kompatibel ist.\n- GitLab ist Open-Source-Software und das GitLab-Team hat uns bei der Bereitstellung von Fehlerkorrekturen immer unterstützt, was uns zusätzliche Flexibilität und Sicherheit gibt.\n\nAls wir offiziell ankündigten, dass die GitLab-CI-Plattform für Benutzer(innen) allgemein verfügbar sein würde, erfolgten bereits 23 % aller Builds in GitLab CI mit einer Kombination von „Grassroots“-Bemühungen und Early Adopters.\n\nDie Herausforderung der Migration lag jedoch in der großen Streuung. Aufgrund der großen Anzahl an benutzerdefinierten Builds in Jenkins hätte ein automatisiertes Migrationstools für die meisten Teams nicht funktioniert. Die meisten Vorteile des neuen Systems kamen erst zum Tragen, als das alte System auf dem Nullstand war. Nur dann konnten wir die Hardware ausschalten und die CloudBees-Lizenzgebühr sparen.\n\n## Funktionsgleichheit und die Vorteile eines Neustarts\n\nObwohl wir bei Indeed viele verschiedene Technologien unterstützen, sind die drei am häufigsten verwendeten Sprachen Java, Python und JavaScript. Mit diesen Programmiersprachen werden Bibliotheken, Bereitstellungen (Webservices oder Anwendungen) und Cron-Jobs (ein Prozess, der in regelmäßigen Abständen abläuft, z. B. um einen Datensatz in unserem Data Lake aufzubauen) erstellt. Jedes davon bildete eine Matrix an Projekttypen (Java Library, Python Cronjob, JavaScript Webapp usw.), für die wir ein Grundgerüst in Jenkins hatten. Daher mussten wir für jeden dieser Projekttypen eine Golden-Path-Vorlage in GitLab CI erstellen.\n\nDie meisten Benutzer(innen) können diese empfohlenen Pfade ohne Änderungen nutzen, aber für jene, die eine Anpassung brauchen, ist der Golden Path trotzdem ein wichtiger Ausgangspunkt, der ihnen ermöglicht, nur das Nötige zu ändern und trotzdem in Zukunft von zentralisierten Vorlagenaktualisierungen zu profitieren.\n\nWir haben schnell gemerkt, dass die meisten Benutzer(innen), auch jene mit Anpassungen, gern den Golden Path nehmen bzw. ihn zumindest ausprobieren. Wenn sie ihre Anpassungen vermissen, können sie sie immer noch später hinzufügen. Das war ein überraschendes Ergebnis! Wir dachten, dass die Teams, die in signifikante Anpassungen investiert hatten, diese nur widerstrebend aufgeben würden, doch in der Mehrheit der Fälle waren sie den Teams nach der Umstellung egal. Dadurch konnten wir viele Projekte sehr schnell migrieren. Wir konnten einfach den Golden Path (eine kleine, etwa 6 Zeilen lange Datei mit Includes) in ihre Projekte einfügen und sie konnten sie von dort aus nutzen.\n\n## InnerSource als Retter in der Not\n\nDas CI-Plattformteam hat auch eine Richtlinie eingeführt, die besagt, dass externe Beiträge Vorrang haben. So werden alle im Unternehmen zur Teilnahme ermutigt. Dies wird manchmal als InnerSource bezeichnet. Wir haben Tests und Dokumentationen geschrieben, um externe Beiträge – Beiträge von außerhalb unseres unmittelbaren Teams – zu ermöglichen, damit Teams, die Anpassungen schreiben wollten, sie stattdessen in den Golden Path hinter einer Feature-Flag einfügen können. So konnten sie ihre Arbeit mit anderen teilen und sicherstellen, dass wir sie im weiteren Verlauf des Projekts nicht beschädigen (denn sie wurde Teil unserer Codebase, nicht ihrer eigenen). \n\nDies hatte auch den Vorteil, dass manche Teams, die auf eine benötigte Funktion warten mussten, selbst an dieser Funktion arbeiten konnten. Wir konnten sagen: „Wir planen, die Funktion in ein paar Wochen zu implementieren. Wenn ihr sie eher braucht, dürft ihr gerne daran mitarbeitet.“ Am Ende wurden viele Kernfunktionen, die für die Gleichschaltung nötig waren, auf diese Weise schneller und besser entwickelt, als es für unser Team alleine möglich gewesen wäre. Ohne dieses Modell wäre die Migration nicht erfolgreich gewesen.\n\n## Vor dem Zeitplan und unter dem Budget\n\nUnsere CloudBees-Lizenz lief am 1. April 2024 aus. Dies gab uns ein ambitioniertes Ziel für die vollständige Migration vor. Dies war besonders ehrgeizig, wenn man bedenkt, dass zu dieser Zeit 80 % aller Builds (60 % aller Projekte) noch Jenkins für ihre CI verwendeten. Dies bedeutete, dass über 2.000 [Jenkins-Dateien](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) noch umgeschrieben oder durch unsere Golden-Path-Vorlagen ersetzt werden mussten.\n\nUm dieses Ziel zu erreichen, stellten wir Dokumentationen und Beispiele zur Verfügung, implementierten Funktionen, wo dies möglich war, und halfen unseren Benutzer(inne)n, Funktionen beizutragen, wo sie konnten.\n\nWir haben regelmäßige Bürozeiten eingeführt, zu denen jeder kommen und Fragen stellen oder unsere Hilfe bei der Migration in Anspruch nehmen konnte. Außerdem haben wir Supportfragen zur Migration vor fast allem anderen priorisiert. Unsere Teammitglieder wurden zu GitLab-CI-Profis und teilten dieses Wissen innerhalb des Teams und im gesamten Unternehmen.\n\nEine automatische Migration war bei den meisten Projekten nicht möglich, aber wir fanden heraus, dass sie für eine kleine Untergruppe an Projekten funktionierte, in denen es wenig Anpassungen gab. Wir erstellten eine Sourcegraph-Stapeländerungskampagne, um Merge Requests für die Migration von hunderten Projekten einzureichen und forderten unsere Benutzer(innen) auf, diese MRs anzunehmen.\n\nWir zogen Erfolgsgeschichten unserer Benutzer(innen) heran und weit verbreitet. Als die Benutzer(innen) neue Funktionen zu unseren Golden Paths beisteuerten, warben wir damit, dass diese Funktionen bei der Migration auf GitLab CI „kostenlos enthalten“ sind. Einige Beispiele sind integrierte Sicherheits -und Compliance-Scans, Slack-Benachrichtigungen für CI-Builds und Integrationen in andere interne Systeme.\n\nWir haben auch eine Kampagne aggressiver „Scream Tests“ durchgeführt. Wir haben Jenkins-Jobs, die schon eine Weile nicht mehr ausgeführt wurden oder schon länger nicht mehr erfolgreich waren, automatisch deaktiviert und teilten den Benutzer(inne)n mit, dass sie diese Jobs wieder aktivieren konnten, wenn sie sie nochmals brauchen würden. So konnten wir auf einfache Weise feststellen, welche Jobs wirklich gebraucht wurden. Wir hatten Tausende von Jobs, die seit unserer letzten CI-Migration (von Jenkins zu Jenkins) nicht ein einziges Mal ausgeführt worden waren. Dies zeigte uns, dass wir fast alle davon sicher ignorieren konnten.\n\nIm Januar 2024 gaben wir unsere Benutzer(inne)n einen Anstoß, indem wir ankündigten, dass alle Jenkins-Controller schreibgeschützt werden (keine Builds), es sei denn, es wird ausdrücklich eine Ausnahme angefordert. Wir hatten viel bessere Informationen zum Eigentum von Controllern und sie entsprachen im Allgemeinen unserer Unternehmensstruktur, also war es sinnvoll, sich auf Controller und nicht auf Jobs zu konzentrieren. Die Liste der Controller war auch viel überschaubarer als die Liste der Jobs.\n\nUm eine Ausnahme zu erhalten, baten wir unsere Benutzer(innen), ihre Controller in einer Tabelle zu suchen und ihre Kontaktinformationen daneben zu schreiben. Dadurch erhielten wir eine sichere, aktuelle Liste der Stakeholder, die wir auf dem Endspurt nachverfolgen konnten. Außerdem konnten uns die Benutzer(innen) dadurch deutlich mitteilen, welche Jobs sie unbedingt brauchten. Zu Spitzenzeiten hatten wir etwa 400 Controller; im Januar hatten wir 220, aber nur 54 Controller benötigten Ausnahmen (einige von ihnen gehörten uns, um unsere Tests und Canary Tests durchzuführen).\n\n![Indeed – Anzahl der Jenkins-Controller](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099357/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099357392.png)\n\nWir hatten eine überschaubare Liste von etwa 50 Teams, die wir unter unseren Teammitgliedern aufteilten, und begannen, Kontakt aufzunehmen, um herauszufinden, wie jedes Team bei der Migration vorankam. Im Januar und Februar stellten wir fest, dass einige Teams planten, ihre Migration ohne unsere Hilfe vor dem 28. Februar abzuschließen. Andere planten wiederum, ihre Projekte vorher einzustellen, und eine sehr kleine Anzahl war sehr besorgt, dass sie es nicht schaffen würden.\n\nWir konnten mit dieser kleineren Gruppe von Teams zusammenarbeiten und ihnen einen maßgeschneiderten Service bieten. Wir erklärten ihnen, dass wir zwar nicht über das nötige Fachwissen verfügten, um die Migration für sie durchzuführen, dass wir aber mit Fachleuten aus ihrem Team zusammenarbeiten konnten. Für einige Projekte schrieben wir und sie überprüften; für andere schrieben sie und wir überprüften. Am Ende hat sich unsere ganze Arbeit ausgezahlt und wir haben Jenkins genau an dem Tag ausgeschaltet, den wir 8 Monate zuvor angekündigt hatten.\n\n## Die Ergebnisse: verbesserte CI-Effizienz und Benutzerzufriedenheit\n\nAuf dem Höhepunkt führte unsere Jenkins CI-Plattform über 14.000 Pipelines pro Tag aus und bediente Tausende Projekte. Heute führt unsere GitLab-CI-Plattform schon einmal über 40.000 Pipelines an einem einzigen Tag aus und regelmäßig über 25.000 pro Tag. Die inkrementellen Kosten für jeden Job jeder Pipeline sind ähnlich wie bei Jenkins, aber ohne den Aufwand für die Hardware zum Ausführen der Controller. Darüber hinaus dienten diese Controller als Single Points of Failure und Skalierungsbegrenzer, die uns zwangen, unsere Plattform künstlich in Segmente zu unterteilen. Ein direkter Vergleich ist immer schwierig, aber wir haben festgestellt, dass die Kosten für unsere CI-Hardware ohne diesem Overhead um 10–20 % niedriger sind. Außerdem ist der Supportaufwand für GitLab CI niedriger, da sich die Anwendung automatisch in der Cloud skaliert, über Verfügbarkeitszonen ausfallsicher ist und für die Vorlagensprache eine hervorragende Dokumentation öffentlich verfügbar ist.\n\nEin ebenso wichtiger Vorteil ist, dass wir jetzt über 70 % Annahmerate unserer Golden Paths erreicht haben. Das bedeutet, dass wir eine Verbesserung umsetzen konnten, von der über 5.000 Projekte bei Indeed sofort ohne weitere Maßnahmen profitieren können. So konnten wir einige Jobs zu kostengünstigeren ARM64-Instanzen verschieben, die Build-Images der Benutzer(innen) einfacher auf dem neuesten Stand halten und unsere Möglichkeiten zur Kosteneinsparung besser verwalten. Am wichtigsten ist aber, dass unsere Benutzer(innen) mit der neuen Plattform zufriedener sind.\n\n__Über den Autor:__\n*Carl Myers lebt in Sacramento, Kalifornien, und ist Manager des CI-Plattformteams bei Indeed. Carl hat seine fast zwei Jahrzehnte lange Berufslaufbahn damit verbracht, interne Tools und Entwicklerplattformen zu entwickeln, die Entwickler(innen) in großen und kleinen Unternehmen begeistern und befähigen.*\n\n**Danksagungen:**\n*Diese Migration wäre ohne die unermüdlichen Bemühungen von Tron Nedelea, Eddie Huang, Vivek Nynaru, Carlos Gonzalez, Lane Van Elderen und dem Rest des CI-Plattformteams nicht möglich gewesen. Unser Teams ist besonders dankbar für die Führung von Deepak Bitragunta. Unser Dank geht auch an Irina Tyree für ihre Unterstützung bei diesem langen Projekt, für die Bereitstellung von Ressourcen und die unternehmensweite Abstimmung. Abschließend möchten wir uns bei allen bei Indeed bedanken, die Code, Feedback und Fehlerberichte beigetragen sowie bei der Migration von Projekten geholfen haben.*\n\n**Dies ist eine überarbeitete Version des Artikels [Wie Indeed seine CI-Plattform durch Gitlab CI ersetzt hat](https://engineering.indeedblog.com/blog/2024/08/indeed-gitlab-ci-migration/), der ursprünglich auf dem Indeed-Engineering-Blog veröffentlicht wurde.**",[885,9,908,684],"user stories","2024-10-31",{"slug":911,"featured":91,"template":690},"how-indeed-transformed-its-ci-platform-with-gitlab","content:de-de:blog:how-indeed-transformed-its-ci-platform-with-gitlab.yml","How Indeed Transformed Its Ci Platform With Gitlab","de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab.yml","de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab",{"_path":917,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":918,"content":924,"config":935,"_id":937,"_type":14,"title":938,"_source":16,"_file":939,"_stem":940,"_extension":19},"/de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":919,"description":920,"ogTitle":919,"ogDescription":920,"noIndex":6,"ogImage":921,"ogUrl":922,"ogSiteName":672,"ogType":673,"canonicalUrls":922,"schema":923},"OCI-Images als Quelle der Wahrheit für die kontinuierliche Lieferung","Die Vorteile der Verwendung von OCI-Images als Teil von GitOps-Workflows und die vielen Funktionen, die GitLab bietet, um die Bereitstellung in Kubernetes zu vereinfachen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"OCI-Images als Quelle der Wahrheit für die kontinuierliche Lieferung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":919,"description":920,"authors":925,"heroImage":921,"date":927,"body":928,"category":929,"tags":930,"updatedDate":934},[926],"Daniel Helfand","2025-02-19","Ist [GitOps](https://about.gitlab.com/de-de/topics/gitops/) immer noch GitOps, wenn du kein Git-Repository als Artefakt für die Bereitstellung verwendest? Git bleibt zwar weiterhin von zentraler Bedeutung für GitOps-Workflows, doch die Speicherung von Infrastrukturdefinitionen als OCI-Artefakte (Open Container Initiative) in Container-Registries hat als Quelle für GitOps-Bereitstellungen an Beliebtheit gewonnen. In diesem Artikel werden wir uns eingehender mit den Ideen hinter diesem Trend befassen und erläutern, wie GitLab-Funktionen diese Verbesserung der GitOps-Workflows unterstützen.\n\n## Was ist GitOps?\n\nDas [OpenGitOps](https://opengitops.dev/)-Projekt hat [vier Prinzipien](https://opengitops.dev/#principles) für den Einsatz von GitOps definiert (Informationen zu OpenGitOps sind nur in englischer Sprache verfügbar):\n- Der gewünschte Zustand eines [Systems, das mit GitOps verwaltet wird](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system), muss [deklarativ ausgedrückt](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description) werden.\n- Der gewünschte Zustand wird so gespeichert, dass Unveränderlichkeit und Versionsverwaltung erzwungen werden und ein vollständiger Versionsverlauf erhalten bleibt.\n- Software-Agents rufen automatisch den gewünschten Zustand aus der Quelle ab.\n- Software-Agents überwachen [kontinuierlich](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous) den tatsächlichen Systemzustand und [versuchen, den gewünschten Zustand anzuwenden](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#reconciliation).\n\nEin Beispiel für GitOps ist das Speichern der Kubernetes-Manifeste für einen Microservice in einem GitLab-Projekt. Diese Kubernetes-Ressourcen werden dann kontinuierlich von einem [Controller](https://kubernetes.io/de/docs/concepts/architecture/controller/) abgeglichen, der auf dem Kubernetes-Cluster ausgeführt wird, auf dem der Microservice bereitgestellt ist. So können Entwickler(innen) die Infrastruktur mit denselben Workflows verwalten wie bei ihrer Arbeit mit regulärem Code, z. B. durch das Erstellen von Merge Requests, um Änderungen vorzunehmen und zu überprüfen, und durch die Versionsverwaltung von Änderungen. GitOps hat auch betriebliche Vorteile, wie z. B. die [Verhinderung von Konfigurationsdrift](https://about.gitlab.com/de-de/topics/gitops/#cicd) und es hilft Entwickler(inne)n bei der Prüfung, welche Änderungen bei der Bereitstellung zu bestimmten Ergebnissen geführt haben.\n\n## Vorteile und Einschränkungen von Git in GitOps-Workflows\n\nGit ist zwar ein wesentlicher Bestandteil von GitOps-Workflows, aber Git-Repositories wurden nicht für die Bereitstellung durch GitOps-Controller entwickelt. Entwickler(innen) können dank Git bei Infrastrukturänderungen zusammenarbeiten und diese Änderungen später überprüfen. Controller müssen jedoch nicht das gesamte Git-Repository herunterladen, um eine erfolgreiche Bereitstellung zu gewährleisten. GitOps-Controller benötigen lediglich die Infrastruktur, die für eine bestimmte Umgebung definiert ist. \n\nDarüber hinaus ist ein wichtiger Bestandteil des Bereitstellungsprozesses das [Signieren und Verifizieren von Bereitstellungen](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing), um sicherzustellen, dass Bereitstellungsänderungen an einer Umgebung aus einer vertrauenswürdigen Quelle stammen. Git-Commits können zwar von GitOps-Controllern signiert und verifiziert werden, aber Commits können auch andere Details erfassen, die nicht mit der Bereitstellung selbst zusammenhängen (z. B. Dokumentationsänderungen, Aktualisierungen anderer Umgebungen und Umstrukturierungen des Git-Repositorys), oder nicht genug vom Bereitstellungsbild, da eine Bereitstellung aus mehreren Commits bestehen kann. Auch hier scheint es sich um einen Fall zu handeln, für den diese Git-Funktion nicht entwickelt wurde.  \n\nEin weiterer herausfordernder Aspekt von Git in GitOps-Workflows ist, dass es manchmal zu mehr Automatisierung als erwartet führen kann. Kurz nach der Zusammenführung wird eine Änderung am beobachteten Branch vorgenommen und dann bereitgestellt. Außerhalb von Git gibt es keine Kontrollen im Prozess. Wie kannst du sicherstellen, dass an einem Freitagnachmittag nichts bereitgestellt wird? Was ist, wenn die für die Bereitstellung verantwortlichen Teams nicht berechtigt sind, in bestimmten GitLab-Projekten Änderungen zusammenzuführen? Durch die Verwendung von OCI-Images wird eine Pipeline in den Prozess eingefügt, die alle Funktionen zur Bereitstellungsteuerung umfasst, wie z. B. [Approvals oder Bereitstellungsstopps (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n## OCI-Images\n\nDie [Open Container Initiative](https://opencontainers.org/) hat dazu beigetragen, Standards für Containerformate zu definieren. Während die meisten Entwickler(innen) mit dem Einbinden von Dockerfiles in Container-Images vertraut sind, sind viele möglicherweise nicht so erfahren im Speichern von Kubernetes-Manifesten in einer Container-Registry. Da die [Container-Registry von GitLab (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/packages/container_registry/) OCI-konform ist, können Benutzer(innen) Kubernetes-Manifeste für eine bestimmte Umgebung in eine Container-Registry übertragen. GitOps-Controller, wie z. B. [Flux CD (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/), können die in diesem OCI-Artefakt gespeicherten Manifeste verwenden, anstatt ein ganzes Git-Repository klonen zu müssen. \n\nIn GitOps-Workflows kann ein Git-Repository oft die Infrastrukturdefinitionen für alle Umgebungen enthalten, in denen ein Microservice bereitgestellt wird. Indem die Kubernetes-Manifeste nur für eine bestimmte Umgebung paketiert werden, muss Flux CD nur genau die Dateien herunterladen, die für die Bereitstellung in einer bestimmten Umgebung erforderlich sind. \n\n### Sicherheitsvorteile der Verwendung von OCI-Artefakten\n\nWie bereits erwähnt, bietet das Signieren und Verifizieren der Artefakte, die in einer Umgebung bereitgestellt werden sollen, eine zusätzliche Sicherheitsebene für Softwareprojekte. Nachdem Kubernetes-Manifeste an eine Container-Registry gepusht wurden, kann ein Tool wie [Sigstore Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/) verwendet werden, um das OCI-Image mit einem privaten Schlüssel zu signieren, der sicher in einem GitLab-Projekt als [CI/CD-Variable (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/variables/) gespeichert werden kann. Flux CD kann dann einen öffentlichen Schlüssel verwenden, der auf einem Kubernetes-Cluster gespeichert ist, um zu überprüfen, ob eine Bereitstellung von einer vertrauenswürdigen Quelle stammt. \n\n## Verwenden von GitLab zum Pushen und Signieren von OCI-Images \n\nGitLab bietet viele Funktionen, die den Prozess des Paketierens, Signierens und der Bereitstellung von OCI-Images vereinfachen. Eine gängige Methode zur Strukturierung von GitLab-Projekten mit GitOps-Workflows besteht darin, separate GitLab-Projekte für den Code der Microservices und ein einziges Infrastruktur-Repository für alle Microservices zu verwenden. Wenn eine Anwendung aus `n`-Microservices besteht, wären für eine Anwendung `n+1`-GitLab-Projekte erforderlich.\n\nDas Artefakt, das aus einem Programmierprojekt hervorgeht, ist in der Regel ein Container-Image, das zum Paketieren der Anwendung verwendet wird. Das Infrastruktur- oder Bereitstellungsprojekt enthält die Kubernetes-Manifeste, in denen alle Ressourcen definiert sind, die für die Skalierung und die Bereitstellung des Datenverkehrs für jeden Microservice erforderlich sind. Das Artefakt, das aus diesem Projekt hervorgeht, ist in der Regel ein OCI-Image, das zur Bereitstellung der Anwendung und anderer Manifeste für Kubernetes verwendet wird. \n\nIn diesem Setup wird die Trennung von Umgebungen durch die Definition von Kubernetes-Manifesten in separaten Ordnern gehandhabt. Diese Ordner stellen Umgebungen (z. B. Entwicklung, Staging und Produktion) dar, in denen die Anwendung gehostet wird. Wenn Änderungen am Codeprojekt vorgenommen und ein neues Container-Image gepusht wird, müssen zur Bereitstellung dieser Änderungen über die Integration von GitLab mit Flux CD lediglich die Manifeste im Ordner „Environment“ bearbeitet werden, um die neue Image-Referenz aufzunehmen, und ein „Merge Request“ geöffnet werden. Sobald dieser Merge Request überprüft, genehmigt und zusammengeführt wurde, wird der CI/CD-Job des Bereitstellungsprojekts ein neues OCI-Image pushen, das Flux CD aufnimmt und in der neuen Umgebung bereitstellt.\n\n![OCI-Images – Flowchart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\nDas Signieren eines OCI-Image ist so einfach wie das Einfügen von Cosign in den CI/CD-Job deines Projekts. Du kannst einfach einen neuen öffentlichen und privaten Schlüssel mit Cosign generieren, indem du die folgenden Befehle lokal ausführst. Stelle einfach sicher, dass du dich mit der [glab-CLI](https://gitlab.com/gitlab-org/cli/#installation) bei deiner GitLab-Instanz anmeldest und die [`PROJECT_ID`] für den Befehl „cosign“ durch die [ID deines Bereitstellungsprojekts](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id) ersetzt.   \n\n```\nglab auth login\ncosign generate-key-pair gitlab://[PROJECT_ID]\n```\n\nSobald der Befehl „cosign“ erfolgreich ausgeführt wurde, findest du die zu deinem Projekt hinzugefügten Cosign-Schlüssel im Abschnitt „CI/CD-Variablen“ unter den Schlüsselnamen `COSIGN_PUBLIC_KEY` und `COSIGN_PRIVATE_KEY`.\n\n### Beispiel für einen CI/CD-Job\n\nEin GitLab-CI/CD-Job zum Pushen eines OCI-Images sieht in etwa so aus:\n\n```yaml\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths: \n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\" \n```\n\nDer [GitLab-CI/CD-Katalog (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) bietet eine von GitLab gepflegte [CI/CD-Komponente für die Arbeit mit OCI-Artefakten und Flux CD](https://gitlab.com/explore/catalog/components/fluxcd). Mit dieser Komponente können Entwicklungsteams Kubernetes-Manifeste als OCI-Images an die Container-Registry von GitLab oder eine externe Container-Registry senden, das OCI-Image mit Cosign signieren und das neu gepushte Image sofort über Flux CD abgleichen. \n\nIm obigen Beispiel ist die Flux CD `component` in einer `.gitlab-ci.yml`-Datei eines GitLab-Projekts enthalten. Mithilfe der `inputs` der Komponente können Benutzer(innen) definieren, in welche Registry das Image gepusht werden soll (d. h. `registry_image_url` und `image tag`), den Dateipfad zu den Kubernetes-Manifesten, die gepusht werden sollen (d. h. `manifest_path`), den privaten Cosign-Schlüssel, der zum Signieren von Images verwendet wird (d. h. `signing_private_key`), sowie den Kubernetes-Namensraum und den Namen des Flux-CD-[OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/), der für die Synchronisierung von Aktualisierungen in einer Umgebung benötigt wird (d. h. `flux_oci_namespace_name` und `flux_oci_repo_name`).\n\nMit der `kubernetes_agent_reference` können GitLab-CI/CD-Jobs das für den Zugriff auf einen Kubernetes-Cluster erforderliche `kubeconfig` erben, ohne dass in jedem GitLab-Projekt eine `kubeconfig`-CI/CD-Variable gespeichert werden muss. Durch die Einrichtung des [GitLab Agent for Kubernetes (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/) können die CI/CD-Jobs aller GitLab-Projekte in einer [GitLab-Gruppe (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/group/) konfiguriert werden, um Berechtigungen für die Bereitstellung im Kubernetes-Cluster zu erben. \n\nDer Agent für den Kubernetes-Kontext wird normalerweise überall dort konfiguriert, wo du den GitLab Agent for Kubernetes in deiner GitLab-Gruppe konfigurierst. Das solltest du in der Regel in dem Projekt zu tun, in dem Flux CD verwaltet wird. Weitere Informationen zur Konfiguration des Agents für den CI/CD-Zugriff findest du in unserer [CI/CD-Workflow-Dokumentation (nur in englischer Sprache verfügbar)]( https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html).\n\nDie Variablen `$COSIGN_PRIVATE_KEY`, `$FLUX_OCI_REPO_NAME` und `$FRONTEND_DEV_NAMESPACE` sind Werte, die als CI/CD-Variablen gespeichert werden, um den Zugriff auf diese vertraulichen Daten in CI/CD-Protokollen zu erleichtern und sie zu maskieren. `$CI_REGISTRY_IMAGE` ist eine Variable, die standardmäßig in GitLab-Jobs verfügbar ist und die Container-Registry des GitLab-Projekts angibt. \n\n### Bereitstellen von OCI-Images\n\nWenn du [Flux CD mit deinen GitLab-Projekten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html) verwendest, kannst du die Bereitstellung und Signaturprüfung für die Umgebungen deiner Microservices automatisieren. Sobald Flux CD für die Synchronisierung von einem GitLab-Projekt konfiguriert ist, kannst du die folgenden [benutzerdefinierten Ressourcendefinitionen](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) von Kubernetes zu deinem Projekt hinzufügen, um dein gepushtes OCI-Image zu synchronisieren. \n\n```yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\napiVersion: bitnami.com/v1alpha1\nkind: SealedSecret\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: OCIRepository\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\napiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n``` \n\nMit der Ressource [`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/) können Kubernetes-Manifeste weiter angepasst werden und sie gibt auch an, in welchem Namensraum Ressourcen bereitgestellt werden sollen. Die Ressource `OCIRepository` für Flux CD ermöglicht es Benutzer(inne)n, die OCI-Image-Repositoryreferenz und das Tag anzugeben, von dem regelmäßig synchronisiert werden soll. Außerdem wirst du die Eigenschaften `verify.provider` und `verify.secretRef` bemerken. Anhand dieser Felder kannst du überprüfen, ob das für den Cluster bereitgestellte OCI-Image mit dem entsprechenden privaten Cosign-Schlüssel signiert wurde, der im früheren CI/CD-Job verwendet wurde. \n\nDer öffentliche Schlüssel muss in einem [Kubernetes-Geheimnis](https://kubernetes.io/docs/concepts/configuration/secret/) gespeichert werden, das sich im selben Namensraum wie die Ressource `OCIRepository` befinden muss. Damit Flux CD dieses Geheimnis verwaltet und es nicht im Klartext gespeichert wird, kannst du [SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/) verwenden, um den Wert zu verschlüsseln und ihn cluster-seitig von einem Controller entschlüsseln zu lassen. \n\nEine einfachere Methode, für die SealedSecrets nicht erforderlich ist, ist die [Bereitstellung des Geheimnisses über einen GitLab-CI/CD-Job (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html) mit der [`kubectl CLI`](https://kubernetes.io/docs/reference/kubectl/). Bei der Variante ohne SealedSecret entfernst du einfach das oben enthaltene SealedSecret und führst den Job zur Bereitstellung des öffentlichen Geheimnis-Schlüssels aus, bevor du den Job zum Pushen des neuen OCI-Images ausführst. Dadurch wird sichergestellt, dass das Geheimnis sicher in GitLab gespeichert ist und dass es im Cluster vom OCIRepository abgerufen werden kann. Dieser Ansatz ist etwas einfacher, aber nicht für die Verwaltung von Geheimnissen in der Produktion geeignet. \n\n## Die Vorteile von OCI, GitLab und GitOps\n\nMit OCI-Artefakten (Oracle Cloud Infrastructure) können GitOps-Teams Bereitstellungen noch weiter optimieren. Sie bieten zusätzliche Sicherheitsvorteile und ermöglichen minimale Bereitstellungen. Benutzer(innen) profitieren weiterhin von allen Vorteilen, die Git bietet, insbesondere von einer zuverlässigen Datenquelle für die Infrastruktur und der Zusammenarbeit an Projekten. OCI-Images erweitern den Bereitstellungsansatz von GitOps um einen Paketierungsansatz.\n\nBei GitLab lernen wir kontinuierlich von unseren Kund(inn)en und der Cloud-nativen Community, um Erfahrungen zu sammeln, die zur Vereinfachung von GitOps-Workflows beitragen. Einige der in diesem Blogbeitrag erwähnten Funktionen kannst du nutzen, indem du dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) anmeldest. Wir freuen uns auch über Erfahrungsberichte von Benutzer(inne)n dieser Tools. Feedback kannst du im [Community-Forum](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965) abgeben.\n","open-source",[9,931,932,536,933,683],"open source","kubernetes","git","2025-05-12",{"slug":936,"featured":6,"template":690},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","content:de-de:blog:how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery","de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":942,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":943,"content":949,"config":956,"_id":958,"_type":14,"title":959,"_source":16,"_file":960,"_stem":961,"_extension":19},"/de-de/blog/jenkins-to-gitlab-migration-made-easy",{"title":944,"description":945,"ogTitle":944,"ogDescription":945,"noIndex":6,"ogImage":946,"ogUrl":947,"ogSiteName":672,"ogType":673,"canonicalUrls":947,"schema":948},"Migration von Jenkins zu GitLab leicht gemacht","In diesem Schritt-für-Schritt-Leitfaden erfährst du, warum und wie du ganz einfach von Jenkins zu GitLab migrieren kannst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migration von Jenkins zu GitLab leicht gemacht\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-01\",\n      }",{"title":944,"description":945,"authors":950,"heroImage":946,"date":952,"body":953,"category":954,"tags":955,"updatedDate":678},[951],"Fernando Diaz","2024-02-01","GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Das bedeutet, dass GitLab alles bietet, was du benötigst, um sichere Software schneller zu planen, zu entwickeln und bereitzustellen – alles in einem Tool.\n\nPlattformen vereinfachen die Integration verschiedener Tools (DIY-DevOps), um den Software-Entwicklungsprozess (SDLC) zu unterstützen. Da Jenkins keine Plattform ist, sind zusätzliche Tools erforderlich, um den Software-Entwicklungsprozess zu vervollständigen. Dieser DIY-DevOps-Ansatz erhöht die Komplexität der Toolchain, was die folgenden Nachteile mit sich bringt:\n\n- Bedarf an individuellem Support für die Integration und Orchestrierung von Tools\n- Schwierigkeiten bei der Wartung/Aktualisierung/Sicherung separater Tools\n- Ineffizienz bei der Evaluierung der Unternehmenstransformation\n- Schlechte Entwicklererfahrung\n- Zusätzliche Management-/Zeit-/Budgetkosten\n- Produktivitätsverlust\n- Ineffizienz im Hinblick auf Kontextwechsel und Zusammenarbeit\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>DIY-DevOps im Vergleich zu einer DevSecOps-Plattform\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nAus diesen Gründen erwägen viele Jenkins-Teams, zu einer DevSecOps-Plattform zu migrieren. Wer nach einer leistungsfähigeren, zuverlässigeren und sichereren Lösung sucht, sollte GitLab wählen! GitLab ist kostenlos für Einsteiger(innen) und bietet verschiedene Abonnementstufen, je nachdem, welche Anforderungen dein Unternehmen hat. Weitere Informationen zu unseren Angeboten und Funktionen findest du auf unserer [Preisseite](https://about.gitlab.com/de-de/pricing/).\n\nIn diesem Blog erfährst du:\n- wie du eine Migration planst\n- wie du Repositories von anderen Tools für die Quellcodeverwaltung (SCM) zu GitLab migrierst\n- wie du CI/CD-Pipelines von Jenkins zu GitLab migrierst\n- welche weiteren Überlegungen du dir zu Migrationen machen solltest\n\n### Planung einer Migration\n\nBevor du eine Migration von einem anderen Tool zu GitLab CI/CD startest, solltest du zunächst einen Migrationsplan erstellen. Ein Migrationsplan ist ein wichtiger technischer Schritt, um Erwartungen festzulegen. CI/CD-Tools unterscheiden sich im Hinblick auf ihren Ansatz und Aufbau sowie ihre technischen Besonderheiten. Das bedeutet, dass Migrationen keine simplen, direkten Zuordnungen von Daten sind. Ein Migrationsplan bietet folgende Vorteile:\n- Er legt eine klare Vorstellung deiner Migrationsziele fest und kommuniziert sie. Dies hilft deinen Benutzer(innen) dabei, zu verstehen, warum sich der Aufwand lohnt. Der Nutzen wird deutlich, wenn die Migration abgeschlossen ist, aber die Beteiligten müssen sich dessen auch während der Migration bewusst sein.\n- Er ermöglicht die Unterstützung und Beteiligung der entsprechenden Führungsteams – dies trägt zum oben genannten Punkt bei.\n- Er bietet die Gelegenheit, Benutzer(innen) über Veränderungen aufzuklären.\n- Er findet Wege, um Teile der Migration zu sequenzieren oder zu verzögern und zu verhindern, dass nicht migrierte (oder teilweise migrierte) Zustände zu lange bestehen bleiben.\n- Er dokumentiert die Vorteile der Verbesserungen, die GitLab CI/CD bietet, und aktualisiert deine Implementierung im Rahmen der Umstellung.\n\nMit einem Migrationsplan kannst du einen Prozess einrichten, bei dem du mit minimalen Unterbrechungen langsam zu GitLab migrieren kannst. Dies kann bedeuten, dass Jenkins und GitLab parallel eingesetzt werden, während bestimmte Projekte zu GitLab verschoben und von Jenkins abgezogen werden.\n\n### Definition eines Change-Management-Prozesses\n\nDer Migrationsplan sollte einen effektiven Change-Management-Prozess definieren. Entwicklungs- und IT Operations-Teams, Cloud-Administrator(inn)en sowie Sicherheits- und Qualitätsteams haben möglicherweise keine Erfahrung mit GitLab und sie wissen möglicherweise nicht, warum du oder deine Führungskraft sich entschieden haben, diesen Weg einzuschlagen.\n\nWer von den Veränderungen betroffen ist, muss Folgendes wissen:\n- __Warum__ die Veränderung vorgenommen wird\n- __Wie__ der zukünftige Zustand aussehen wird\n- __Wie__ das Unternehmen den neuen Zustand erreichen möchte\n- __Wo__ weitere Informationen oder Unterstützung zu finden sind \n\nZu diesem Zweck solltest du die folgenden Schritte in Erwägung ziehen, um Veränderungen für diese funktionalen Rollen zu steuern:\n- __Analysiere den aktuellen Zustand__: Dokumentiere den aktuellen Zustand der Prozesse. Sammle Indikatoren als Basis. Ermittle, was im Hinblick auf CI/CD funktioniert und was nicht, indem du wichtige Teammitglieder befragst. Dokumentiere die Herausforderungen, die du feststellst, sowohl in quantitativer als auch in qualitativer Hinsicht. Du musst andere von der Vision und dem Grund für die Veränderung überzeugen. Je klarer du also die Problemstellung definieren kannst, desto einfacher wird es, die Zustimmung des gesamten Unternehmens zu gewinnen. \n- __Baue eine Vision auf__: Nun, da du die aktuellen Probleme quantitativ mithilfe von Basisindikatoren und qualitativ (mit den Worten deiner Teammitglieder) beschrieben hast, stelle eine Vision des zukünftigen Zustands vor. Erläutere, warum dies wichtig ist (stelle einen Zusammenhang zu geschäftlichen Erfolgsindikatoren her). Biete Live- sowie aufgezeichnete Demos an, um aufzuzeigen, welche Möglichkeiten es gibt, und vergleiche diese Vision mit dem aktuellen Zustand. Betone diese Botschaft auf mehreren Kanäle und in verschiedenen Medien – Chat-Gruppen, allgemeine Meetings, E-Mail-Benachrichtigungen, Banner-Benachrichtigungen auf GitLab usw.\n- __Kläre die Belegschaft auf__: Investiere in [GitLab-CI/CD-Schulungen (nur in englischer Sprache verfügbar)](https://about.gitlab.com/services/education/gitlab-ci/), die von GitLab-Expert(inn)en durchgeführt werden. Evaluiere den Erwerb und das Verinnerlichen von Kenntnissen mithilfe von [GitLab-Zertifizierungen (nur in englischer Sprache verfügbar)](https://levelup.gitlab.com/pages/certifications). \n- __Kommuniziere Roadmap und Ressourcen__: Teile deinen Teammitgliedern den geplanten Zeitplan sowie die verfügbaren Ressourcen für die Migration mit. Nenne Community-Ressourcen wie Chat-Gruppen, Q&A-Boards oder die Kontaktzeiten von GitLab-Influencern oder -Influencerinnen, damit dein Team Fragen stellen und Unterstützung erhalten kann. Der Aufbau eines Belohnungssystems, das das Teams dazu anregt, frühzeitig umzusteigen und ihre Erfahrungen mit anderen Anwendergruppen zu teilen, wäre ein Pluspunkt!\n\nWenn du diese Elemente zu Beginn der Migration sicherstellst, stellst du die Weichen für ihren Erfolg. \n\n### Festlegung von Migrationszielen\nBevor du eine Migration durchführst, solltest du dir über deine Ziele im Klaren sein und wissen, wie du sie erreichen kannst. Einige Fragen, auf die du Antworten haben solltest, sind beispielsweise folgende:\n- Was ist dein Zeitplan für die Migration?\n- Wie ist dein Jenkins-Server aktuell konfiguriert?\n- Wie viele Projekte müssen migriert werden?\n- Wie komplex ist deine Pipeline?\n- Gibt es externe Abhängigkeiten, mehrere Pipeline-Trigger, parallele Builds usw.?\n- Wie/wo stellst du deinen Code bereit?\n- Was ist der Veröffentlichungs-/Überprüfungsprozess für die Bereitstellung von Code?\n- Ist der Workflow in Jenkins integriert oder gibt es einen separaten Workflow, der von Jenkins ausgelöst wird?\n- Welche Build-Artefakte oder Binärdateien sind für den Erfolg der Pipeline erforderlich?\n- Welche Plugins verwenden Jobs in Jenkins derzeit?\n- Welche Software ist auf den Jenkins-Agenten installiert?\n- Welche Lösung für die Quellcodeverwaltung verwendest du aktuell?\n- Verwenden deine Jenkins-Jobs gemeinsam genutzte Bibliotheken?\n- Welche Authentifizierungsmethode kommt für Jenkins zum Einsatz (Basic Authentication, LDAP/AD, SSO)?\n- Gibt es andere Projekte, auf die du von deiner Pipeline aus zugreifen musst?\n- Gibt es Zugangsdaten in Jenkins, die für den Zugriff auf externe Dienste verwendet werden?\n\nWenn du diese Fragen beantwortest, weißt du, wie du bei der Migration vorgehen solltest, wie lange sie dauert und wo du anfangen solltest. Wenn du einen Plan erstellt hast und dir die Erwartungen und möglichen Fallstricke bewusst sind, kannst du mit dem Migrationsprozess beginnen.\n\n### Voraussetzungen für die Migration\nSobald du einen Migrationsplan erstellt und alle Erwartungen an die Migration bedacht hast, kannst du mit der Einrichtung von GitLab beginnen. Hier sind einige empfohlene Voraussetzungen für die Migration:\n- Mache dich mit GitLab vertraut. Informiere dich über die [wichtigsten GitLab CI/CD-Funktionen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/index.html).\n- Folge den englichsprachigen Tutorials, um deine erste [GitLab-Pipeline](https://docs.gitlab.com/ee/ci/quick_start/index.html) und [komplexere Pipelines](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html) zu generieren, die eine statische Website erstellen, testen und bereitstellen.\n- Lies die [Keyword-Referenz für .gitlab-ci.yml (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/index.html).\n- Richte GitLab ein und konfiguriere es.\n- Teste deine GitLab-Instanz.\n\nSobald du mit GitLab vertraut bist und eine Instanz konfiguriert hast, kannst du deinem Migrationsplan folgen und damit beginnen, Projekte von Jenkins zu GitLab zu verschieben. Stelle sicher, dass deine GitLab-Instanz mithilfe von bewährten Methoden für GitLab und gemäß [Referenzarchitekturen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/administration/reference_architectures/) ordnungsgemäß eingerichtet wurde.\n\n### Migration von Repositories zu GitLab\nEiner der wichtigsten Nachteile von Jenkins ist, dass es keine Lösung für die Quellcodeverwaltung (SCM, Source Code Management) bietet. Wenn du Jenkins verwendest, muss dein Code in einer separaten SCM-Lösung gespeichert werden, auf die Jenkins Zugriff haben muss. Da GitLab über eine integrierte Quellcodeverwaltung verfügt, ermöglicht der Umstieg von Jenkins auch die Migration der zuvor genutzten SCM-Lösung. Dies verringert die Kosten zusätzlich.\n\nGitLab bietet Tools, mit denen du dein Repository und seine Metadaten einfach zu GitLab verschieben kannst. Die folgenden Importer (nur in englischer Sprache verfügbar) unterstützen dich bei der Migration deiner Projekte zu GitLab:\n\n- [GitHub](https://docs.gitlab.com/ee/user/project/import/github.html)\n- [Eine weitere GitLab-Instanz](https://docs.gitlab.com/ee/user/project/settings/import_export.html)\n- [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html)\n- [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html)\n- [FogBugz](https://docs.gitlab.com/ee/user/project/import/fogbugz.html)\n- [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html)\n- [Jira (nur Issues)](https://docs.gitlab.com/ee/user/project/import/jira.html)\n– [Repo per Manifestdatei](https://docs.gitlab.com/ee/user/project/import/manifest.html)\n- [Repo per URL](https://docs.gitlab.com/ee/user/project/import/repo_by_url.html)\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\" alt=\"GitHub to GitLab Repo Exporter\">\n   \u003Cfigcaption>Repoitory-Exporter von GitHub zu GitLab\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nJeder Importer importiert unterschiedliche Daten aus einem Projekt. Lies die [Dokumentation zum Import und zur Migration von Projekten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/import/), um mehr Informationen über die bereitgestellten Importer zu erhalten und zu erfahren, welche Daten zu GitLab migriert werden. Darüber hinaus kannst du [den Import von Gruppen und Projekten automatisieren (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/import/#automate-group-and-project-import) und eine benutzerdefinierte Lösung erstellen, welche die Anforderungen deines Unternehmens noch besser erfüllt:\n\n- [Professional Services](https://about.gitlab.com/de-de/services/)\n- [Migrations-Tools](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n- [Häufig gestellte Fragen zur Migration](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n### So migrierst du ein Repository\nMit unseren integrierten Importern kannst du Repositories ganz einfach zu GitLab migrieren. In diesem Beispiel erfährst du, wie du ein Repo zusammen mit [seinen Ressourcen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data) (Tickets, Pull Requests, Meilensteine usw.) aus GitHub zu GitLab kopierst. Um ein Repository aus einem anderen GitHub zu GitLab zu migrieren, führe die folgenden Schritte aus:\n\n1. Wähle oben in der linken Menüleiste **Neu erstellen (+)** aus.\n2. Wähle im Abschnitt „In GitLab“ **Neues Projekt/Repository** aus.\n3. Wähle **Projekt importieren** aus.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>Auswahl des zu importierenden Projekts\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n4. Klicke auf die Schaltfläche **GitHub**.\n    - Wenn du GitLab Self-Managed verwendest, musst du [den GitHub-Importer aktivieren (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources).\n    - Beachte, dass andere Importer auf dieselbe Weise initiiert werden können.\n5. Jetzt kannst du:\n    - dich mit GitHub OAuth autorisieren: Wähle **Mit GitHub autorisieren** aus.\n    - einen persönlichen GitHub-Zugriffstoken verwenden:\n       - Gehe zu [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n       - Gib im Feld **Notizen** eine Token-Beschreibung ein.\n       - Wähle den Geltungsbereich für das Repository aus.\n       - Um Beteiligte zu importieren, wähle optional den Geltungsbereich **read:org** aus.\n       - Klicke auf die Schaltfläche **Token generieren**.\n       - Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein.\n6. Klicke auf die Schaltfläche **Authentifizieren**.\n7. Wähle die Elemente aus, die du migrieren möchtest.\n8. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest.\n9. Klicke auf die Schaltfläche **Importieren**.\n\nNun sollte sich das importierte Projekt in deinem Arbeitsbereich befinden. Weitere Informationen über die Migration von GitHub zu GitLab findest du in diesem englischsprachigen Video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nSobald du die Migration des Repositories abgeschlossen hast, kannst du deine Jenkins-Pipeline so einstellen, dass sie die Jenkins-Datei in GitLab nutzt. Lege dazu die Repository-URL für dein neu importiertes Projekt über das Jenkin-Pipeline-Konfigurationsmenü fest:\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\" alt=\"Jenkins Pipeline SCM settings\">\n   \u003Cfigcaption>SCM-Einstellungen für die Jenkins-Pipeline\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nDies ist nützlich für die anfängliche Repo-Migrationsphase und hilft dir dabei, sowohl Jenkins als auch GitLab parallel zu verwenden. So kannst du Dienstunterbrechungen vermeiden, während du die CI/CD-Funktionalität migrierst.\n\nDarüber hinaus kannst du das [GitLab-Jenkins-Plugin](https://plugins.jenkins.io/gitlab-plugin/) als Hilfestellung bei der Migration nutzen. Mit diesem Plugin kann GitLab den Status von Jenkins-Builds auslösen und abrufen.\n\n### Migration von CI/CD-Pipelines\nSobald du deine Repositories zu GitLab migriert hast, kannst du mit der Migration deiner Jenkins-Pipelines zu GitLab fortfahren. Dieser Prozess kann relativ simpel sein, du solltest dazu jedoch die Konzepte und die Syntax von Jenkins und GitLab verstehen.\n\nJenkins bietet zwei verschiedene Arten von Syntax für die Definition von Pipelines: Declarative und Scripted. Dieser Leitfaden behandelt die Migration von Pipelines des Typs Declarative, da diese am häufigsten vorkommen.\n\n### Schritt-für-Schritt-Migration der Pipeline\nIn diesem Tutorial wird eine Jenkins-Datei (Groovy) im Vergleich zu einer GitLab-CI/CD-Konfigurationsdatei (YAML) analysiert, die einen in Golang geschriebenen Microservice generiert, testet und bereitstellt. Anschließend werden die Pipeline in GitLab aktiviert und die Ergebnisse angezeigt. Die Pipeline wird:\n\n- das Golang-Container-Image mit dem Tag **alpine** verwenden,\n- einen Job zur Erstellung des Golang-Codes in einer ausführbaren Binärdatei ausführen,\n   - die erstellte ausführbare Datei als Artefakt speichern,\n- einen Job ausführen, um Unit-Tests durchzuführen,\n- einen Jobs zur Bereitstellung im Staging ausführen.\n   - Dieser wird nur ausgeführt, wenn der Commit auf den Branch **Staging** abzielt,\n   - beginnt, nachdem die Phase **Test** erfolgreich abgeschlossen wurde,\n   - verwendet das erstellte ausführbare Artefakt aus dem vorherigen Job.\n\nUnten findest du die Pipeline-Definitionen aus Jenkins und GitLab sowie beschreibende Kommentare. Im [Meow-Migrationsprojekt](https://gitlab.com/gitlab-de/projects/blogs/meow-migration) kannst du die Pipeline in Aktion sehen.\n\nSchaue dir eine in Groovy geschriebene Jenkins-Datei an:\n\n```  \n// Die höchste Ebene der Declarative-\n// Pipeline.\npipeline {\n\n  // Definiert den zu verwendenden Standard-Agenten,\n  // sofern nicht explizit in einem Job\n  // definiert.\n    agent any\n\n  // Definiert die Staging-Phasen, die in\n  // numerischer Reihenfolge ausgeführt werden. Jede Staging-Phase\n  // führt nur einen Job aus.\n    stages {\n\n    // Definiert den Namen der Staging-Phase.\n        stage('build') {\n      // Definiert das Container-Image,\n      // das für diesen Job verwendet werden soll. Dies überschreibt\n      // die Standardeinstellung 'agent any'.\n      // Das Jenkins-Docker-Plugin\n      // muss konfiguriert sein, damit dies\n      // ausgeführt wird.\n            agent { docker 'golang:alpine' }\n\n      // Definiert die Abfolge von Schritten,\n      // die bei der Ausführung der Staging-Phase\n      // befolgt werden soll.\n            steps {\n                sh 'go build -o bin/meow-micro'\n                sh 'chmod +x bin/meow-micro'\n            }\n\n      // Die Schritte, die nach Abschluss der\n      // Staging-Phase ausgeführt werden sollen.\n            post {\n              always {\n\n        // Speichert die Artefakte der Staging-Phase,\n        // die zur Verwendung in einem anderen Job\n        // generiert wurden.\n                archiveArtifacts artifacts: 'bin/meow-micro'\n                onlyIfSuccessful: true\n              }\n            }\n        }\n\n    stage('test') {\n            agent { docker 'golang:alpine' }\n            steps {\n                sh 'go test .'\n            }\n        }\n\n        stage('deploy') {\n      // Definiert die Bedingungen,\n      // die zur Ausführung des Jobs\n      // erfüllt sein müssen. In diesem Fall wird der\n      // Bereitstellungs-Job nur auf dem \n      // Staging-Branch ausgeführt.\n            when {\n              branch 'staging'\n            }\n            steps {\n                echo 'Deploying meow-micro to staging'\n        // Verwendet das Artefakt, das in der\n        // Build-Staging-Phase gespeichert wurde.\n                sh './bin/meow-micro'\n            }\n        }\n    }\n}\n```\n\nSchaue dir nun an, wie die gleiche Funktion in GitLab erstellt werden kann:\n\n```\n# Definiert das zu verwendende Standard-Image,\n# sofern nicht explizit in einem Job\n# angegeben.\ndefault:\n  image: alpine:latest\n\n# Definiert die Reihenfolge der auszuführenden Staging-Phasen.\n# Jede Staging-Phase kann mehrere Jobs umfassen.\nstages:\n  - build\n  - test\n  - deploy\n\n# Definiert den Namen des Jobs.\ncreate-binary:\n # Definiert die Staging-Phase, in welcher der Job ausgeführt wird.\n  stage: build\n # Definiert das Container-Image, das für\n # diesen Job verwendet werden soll. Dies überschreibt die Standardeinstellung.\n  image: golang:alpine\n # Definiert die Reihenfolge der Schritte,\n # die bei der Ausführung des Jobs befolgt werden sollen.\n  script:\n    - go build -o bin/meow-micro\n    - chmod +x bin/meow-micro\n # Speichert die Job-Artefakte, die zur\n # Verwendung in einem anderen Job gespeichert wurden.\n  artifacts:\n    paths:\n      - bin/meow-micro\n    expire_in: 1 week\n\nunit-tests:\n  stage: test\n  image: golang:alpine\n  script:\n    - go test .\n # Definiert Befehle, die im Anschluss an den Job\n # ausgeführt werden sollen.\n after_script:\n  - echo \"Tests Complete\"\n\nstaging-deploy:\n  stage: deploy\n # Definiert die Befehle, die vor dem\n # eigentlichen Job ausgeführt werden sollen.\n  before_script:\n    - apk update\n  script:\n    - echo \"Deploying meow-micro to staging environment\"\n    - ./bin/meow-micro\n # Definiert die Bedingungen, die zur\n # Ausführung dieses Jobs erfüllt sein müssen. In\n # diesem Fall wird der Bereitstellungs-Job der Staging-Phase nur \n # auf dem Staging-Branch ausgeführt.\n  rules:\n    - if: $CI_COMMIT_BRANCH == 'staging'\n # Erlaubt die Verwendung der Artefakte, die im\n # Build-Job gespeichert wurden, in diesem Job.\n  artifacts:\n    paths:\n      - bin/meow-micro\n```\n\nWie du vielleicht bemerkt hast, gibt es viele Gemeinsamkeiten zwischen Jenkins und GitLab im Hinblick auf die Syntax. Dies vereinfacht die Pipeline-Migration. Sieh dir die umfassende Liste der [Funktions- und Konzeptvergleiche (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/migration/jenkins.html#comparison-of-features-and-concepts) zwischen den beiden Tools an.\n\nNun, da du verstehst, wie man Jenkins in GitLab abbildet, kannst du damit beginnen, eine Pipeline mit der gleichen Funktionalität in GitLab zu erstellen. Um CI/CD zu migrieren, kannst du die folgenden Schritte ausführen:\n\n##### 1. Öffne das Repository, das du im obigen Abschnitt zu GitLab migriert hast.\n- Klicke oben in der linken Seitenleiste auf **Suchen oder aufrufen …**.\n- Wähle dein Projekt aus.\n\n##### 2. Öffne den [Pipeline-Editor (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/pipeline_editor/).\n- Wähle in der linken Seitenleiste **Build > Pipeline-Editor** aus.\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png\" alt=\"Pipeline editor menu\">\n   \u003Cfigcaption>Pipeline-Editor-Menü\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Klicke auf die Schaltfläche **Pipeline konfigurieren**.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\" alt=\"Configure pipeline selection\">\n   \u003Cfigcaption>Auswahl der Schaltfläche „Pipeline konfigurieren“\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 3. Befülle die Datei [.gitlab-ci.yml (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/).\n- Füge den GitLab-CI-Pipeline-Code hinzu. \n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png\" alt=\"Pipeline editor input\">\n   \u003Cfigcaption>Eingabe im Pipeline-Editor\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Prüfe, ob die Syntax korrekt ist.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\" alt=\"Pipeline syntax validation\">\n   \u003Cfigcaption>Validierung der Pipeline-Syntax\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Visualisiere die Pipeline.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\" alt=\"Pipeline visualization\">\n   \u003Cfigcaption>Visualisierung der Pipeline\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 4. Committe die Datei in den Main-Branch.\n- Füge eine Commit-Nachricht hinzu.\n- Stelle sicher, dass es sich um den Main-Branch handelt.\n- Klicke auf die Schaltfläche **Änderungen committen**.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\" alt=\"Commit changes dialog\">\n   \u003Cfigcaption>Dialog „Änderungen committen“\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nSobald die Datei zusammengeführt wurde, wird die definierte Pipeline gestartet. Du kannst zu deinem Projekt zurückkehren und [die Pipeline anzeigen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines), indem du sie auf der Seite deines Projekts **Build > Pipelines** auswählst. Da sie auf dem **Main**-Branch ausgeführt wurde, siehst du nur den Job **create-binary** sowie die „unit-test“ Jobs. Der Job **staging-deploy** wird nur auf dem Staging-Branch ausgeführt.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\" alt=\"Pipeline running on main branch\">\n   \u003Cfigcaption>Auf dem Main-Branch ausgeführte Pipeline\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nBei der Erstellung eines Staging-Branches wird die folgende Pipeline gestartet.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\" alt=\"Pipeline running on staging branch\">\n   \u003Cfigcaption>Auf dem Staging-Branch ausgeführte Pipeline\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nWenn du auf einen Job klickst, wird dessen Ausgabe angezeigt:   \n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\" alt=\"create-binary job output\">\n   \u003Cfigcaption>Ausgabe des Jobs create-binary\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\" alt=\"unit-tests job output input\">\n   \u003Cfigcaption>Eingabe/Ausgabe des Jobs unit-tests\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\" alt=\"staging-deploy job output\">\n   \u003Cfigcaption>Ausgabe des Jobs staging-deploy\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nDu kannst sehen, wie das Artefakt im Job create-binary gespeichert und im Job staging-deploy verwendet wird. Und so einfach ist es, eine Pipeline von Jenkins zu GitLab zu migrieren!\n\n### Zusätzliche Überlegungen zur Migration\nEinige hilfreiche Überlegungen, die den Bereitstellungsprozess unserer Ansicht nach einfacher machen, sind folgende:\n\n- Versuche nicht, Aufgaben exakt als GitLab-Jobs zu replizieren. Nimm dir Zeit und schaue dir genauer an, was die aktuelle Pipeline bewirkt und welches Problem sie löst.\n\n- Einige Jenkins-Jobs sind möglicherweise zu komplex, um sofort zu GitLab migriert zu werden. Deshalb kann es von Vorteil sein, das [GitLab-Jenkins-Plugin](https://plugins.jenkins.io/gitlab-plugin/) zu verwenden, um Jenkins-Pipelines zu starten und ihre Ergebnisse direkt in GitLab anzuzeigen. Auf diese Weise kannst du bestimmte Aktionen langsam zu GitLab migrieren, bis die gesamte Pipeline verschoben werden kann.\n\n- Implementiere [Sicherheitsscanner und Codequalität (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/) mithilfe von integrierten Vorlagen, die GitLab von Anfang an bereitstellt. So kannst du die Sicherheit im Vorfeld kontrollieren und die Gefahr eines Sicherheitsverstoßes verringern.\nGestalte die CI/CD-Konfiguration nicht zu kompliziert und versuche nicht, alle Funktionsvorteile gleichzeitig zu nutzen. Modularisiere den Code und implementiere ihn in kleinen Iterationen.\n\n- Implementiere Funktionen zur Überwachung und Steuerung von Anfang an.\n\n- Bedenke, dass sich ein GitLab Runner (Go) möglicherweise anders verhält als ein Jenkins-Agent (Java). Die CPU-Auslastung und der Speicherverbrauch können unterschiedlich sein – achte darauf, sie im Laufe der Zeit miteinander zu vergleichen.\n\n- Ziehe in Erwägung, in automatische Skalierungsmechanismen zu investieren, und lege nicht benötigte Ressourcen am Wochenende oder außerhalb der Arbeitszeiten still.\n\n- Modernisiere die Anwendungsentwicklung, indem du deine Jobs containerisierst. Jenkins-Jobs laufen aktuell nicht in einem Container, sondern auf einem Jenkins-Agenten, der als VM ausgeführt wird.\n\nDiese Liste ist nicht erschöpfend, stellt aber einen guten Ausgangspunkt für einige Überlegungen dar, die du beachten solltest. Wenn du zusätzliche Hilfe benötigst, bietet GitLab [Professional Services](https://about.gitlab.com/de-de/get-help/) an, um dich bei deiner Migration zu unterstützen.\n\n### Mehr erfahren\nVielen Dank, dass du diesen Leitfaden gelesen hast! Ich hoffe, dass er dir dabei geholfen hat, besser zu verstehen, warum und wie du von Jenkins zu GitLab migrieren kannst. Noch nicht überzeugt? [Melde dich für eine kostenlose Testversion von GitLab an](https://about.gitlab.com/de-de/free-trial/) und erkenne den Nutzen einer DevSecOps-Plattform!\n\nHier findest du einige englischsprachige Ressourcen mit weiteren Informationen zu GitLab, den Vorteilen einer DevSecOps-Plattform und der Migration aus Jenkins:\n\n- [Migration von Jenkins](https://docs.gitlab.com/ee/ci/migration/jenkins.html)\n- [Planung einer Migration](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html)\n- [GitLab-Projektimporter](https://docs.gitlab.com/ee/user/project/import/)\n- [Tutorial: Einfache Migration von GitHub zu GitLab](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n- [Video: Einfache Migration von GitHub zu GitLab](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n- [Von Jenkins zu GitLab: Der ultimative Leitfaden zur Modernisierung deiner CI/CD-Umgebung](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n","devsecops",[9,842],{"slug":957,"featured":91,"template":690},"jenkins-to-gitlab-migration-made-easy","content:de-de:blog:jenkins-to-gitlab-migration-made-easy.yml","Jenkins To Gitlab Migration Made Easy","de-de/blog/jenkins-to-gitlab-migration-made-easy.yml","de-de/blog/jenkins-to-gitlab-migration-made-easy",{"_path":963,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":964,"content":970,"config":977,"_id":979,"_type":14,"title":980,"_source":16,"_file":981,"_stem":982,"_extension":19},"/de-de/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"title":965,"description":966,"ogTitle":965,"ogDescription":966,"noIndex":6,"ogImage":967,"ogUrl":968,"ogSiteName":672,"ogType":673,"canonicalUrls":968,"schema":969},"Welche Auswirkungen die Ratenbegrenzungen für Docker Hub auf GitLab CI/CD haben","Erfahre, wie sich die bevorstehenden Ratenbegrenzungen für Pulls von Docker Hub auf GitLab-Pipelines auswirken und was du tun kannst, um Störungen zu vermeiden.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","https://about.gitlab.com/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Welche Auswirkungen die Ratenbegrenzungen für Docker Hub auf GitLab CI/CD haben\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-03-24\",\n      }\n                  ",{"title":965,"description":966,"authors":971,"heroImage":967,"date":972,"body":973,"category":974,"tags":975,"updatedDate":843},[677],"2025-03-24","Am 1. April 2025 hat Docker neue [Ratenbegrenzungen für Pulls](https://docs.docker.com/docker-hub/usage/) für Docker Hub eingeführt, die sich erheblich auf CI/CD-Pipelines in der gesamten Branche auswirken können, einschließlich derer, die auf GitLab ausgeführt werden. Die gravierendste Änderung ist die Begrenzung auf 10 Pulls pro Stunde für nicht angemeldete Benutzer(innen).\n\n## Was ändert sich?\n\nAb dem 1. April 2025 hat Docker die folgenden Ratenbegrenzungen für Pulls durchgesetzt:\n\n| Benutzertyp | Ratenbegrenzung für Pulls pro Stunde | Anzahl der öffentlichen Repositories | Anzahl der privaten Repositories |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business, Team, Pro (authentifiziert) | Unbegrenzt (angemessene Nutzung) | Unbegrenzt | Unbegrenzt |\n| Persönlich (authentifiziert) | 100 | Unbegrenzt | Maximal 1 |\n| Nicht angemeldete Benutzer(innen) | 10 pro IPv4-Adresse oder IPv6/64-Subnetz | Nicht zutreffend | Nicht zutreffend |\n\n\u003Cp>\u003C/p>\nDies ist besonders wichtig, weil:\n\n* Der Abhängigkeits-Proxy von GitLab pullt derzeit als nicht angemeldeter Benutzer von Docker Hub.\n* Die meisten CI/CD-Pipelines, die den Abhängigkeits-Proxy nicht verwenden, pullen als nicht angemeldete Benutzer direkt von Docker Hub.\n* Auf gehosteten Runnern für GitLab.com kann es vorkommen, dass sich mehrere Benutzer(innen) die gleiche IP-Adresse oder das gleiche Subnetz teilen. Somit unterliegen sie gemeinsam dieser Begrenzung.\n\n## Wie sich dies auf GitLab-Benutzer(innen) auswirkt\n\n**Auswirkungen auf direkte Pulls von Docker Hub**\n\nWenn deine CI/CD-Pipelines Images direkt und ohne Authentifizierung von Docker Hub pullen, ist die Anzahl auf 10 Pulls pro Stunde und IP-Adresse begrenzt. Bei Pipelines, die häufig oder projektübergreifend mit derselben Runner-Infrastruktur ausgeführt werden, wird dieser Grenzwert schnell erreicht und es kommt zu Pipeline-Fehlern.\n\n**Auswirkungen auf den Abhängigkeits-Proxy von GitLab**\n\nMit dem Abhängigkeits-Proxy von GitLab kannst du Docker-Images in GitLab zwischenspeichern, um Pipelines zu beschleunigen und externe Abhängigkeiten zu reduzieren. Die aktuelle Implementierung pullt allerdings als nicht angemeldeter Benutzer von Docker Hub. Das bedeutet, dass auch hier der Grenzwert von 10 Pulls pro Stunde gilt.\n\n**Auswirkungen auf gehostete Runner**\n\nGehostete Runner auf GitLab.com verwenden den [Pull-Through-Cache von Google Cloud](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=de). Dieser spiegelt häufig gepullte Images, sodass Ratenbegrenzungen vermieden werden. Images von Jobs, die in deiner `.gitlab-ci.yml`-Datei als `image:` oder `services:` definiert sind, sind von Ratenbegrenzungen nicht betroffen.\n\nEtwas schwieriger wird es, wenn Images innerhalb der Runner-Umgebung gepullt werden. Der häufigste Anwendungsfall für das Pullen von Images während der Laufzeit eines Runners ist die Erstellung eines Images mit Docker-in-Docker oder Kaniko. In diesem Szenario wird das in deiner `Dockerfile` definierte Docker-Hub-Image direkt aus dem Docker Hub gepullt und ist wahrscheinlich von den Ratenbegrenzungen betroffen.\n\n## Wie GitLab reagiert\n\nWir arbeiten aktiv an Lösungen, um diese Herausforderungen zu bewältigen:\n\n* **Authentifizierung des Abhängigkeits-Proxy:** Wir haben die Unterstützung für die Docker-Hub-Authentifizierung im [GitLab-Abhängigkeits-Proxy](https://gitlab.com/gitlab-org/gitlab/-/issues/331741) hinzugefügt. Dadurch kann der Abhängigkeits-Proxy Images als angemeldeter Benutzer von Docker Hub pullen, wodurch die Grenzwerte erheblich erhöht werden.\n* **Aktualisierung der Dokumentation:** Wir haben unsere [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials) aktualisiert. Sie stellt jetzt eine klare Anleitung zur Konfiguration der Pipeline-Authentifizierung für Docker Hub zur Verfügung.\n* **Vorbereitung der internen Infrastruktur:** Wir bereiten unsere interne Infrastruktur vor, um die Auswirkungen auf gehostete Runner für GitLab.com zu minimieren.\n\n## So kannst du dich vorbereiten\n\n**Option 1: Konfiguriere die Docker-Hub-Authentifizierung in deinen Pipelines**\n\nFür Pipelines, die direkt von Docker Hub pullen, kannst du die Authentifizierung so konfigurieren, dass deine Ratenbegrenzung auf 100 Pulls pro Stunde erhöht wird (mit einem kostenpflichtigen Docker-Hub-Abo ist sie sogar unbegrenzt).\n\nFüge die Docker-Hub-Anmeldedaten zu den CI/CD-Variablen deines Projekts oder deiner Gruppe hinzu (nicht in deiner `.gitlab-ci.yml`-Datei). Ausführliche Anweisungen zur korrekten Einrichtung der CI/CD-Variable `DOCKER_AUTH_CONFIG` findest du in unserer [Dokumentation zur Verwendung von Docker-Images (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials).\n\n**Option 2: Verwende die GitLab-Container-Registry**\n\nDu kannst deine häufig verwendeten Docker-Images in deine [GitLab-Container-Registry (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/container_registry/) übertragen. So musst du während der CI/CD-Ausführung nicht mehr von Docker Hub pullen:\n\n1. Pulle das Image von Docker Hub.\n2. Kennzeichne es für deine GitLab-Container-Registry.\n3. Pushe es in deine GitLab-Container-Registry.\n4. Aktualisiere deine Pipelines, dass sie das Image von der GitLab-Container-Registry abrufen.\n\n```\ndocker pull busybox:latest\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n```\n\nIn deiner `.gitlab-ci.yml`-Datei fügst du dann folgende Zeile hinzu:\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n**Option 3: Verwende den GitLab-Abhängigkeits-Proxy**\n\nMit dem Abhängigkeits-Proxy von GitLab kannst du Docker-Images zwischenspeichern und übertragen. Dies reduziert externe Abhängigkeiten und somit Probleme mit der Ratenbegrenzung.\n\nAktuelle Authentifizierungsoptionen:\n* GitLab 17.10: Konfiguriere die Docker-Hub-Authentifizierung für den Abhängigkeits-Proxy mit der [GraphQL API (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api)\n* GitLab 17.11: Verwende die neue UI-basierte Konfiguration in den Einstellungen deiner Gruppe (bereits auf GitLab.com verfügbar)\n\nSobald die Authentifizierung ordnungsgemäß konfiguriert ist, kannst du Folgendes tun:\n\n1. Konfiguriere die Docker-Hub-Anmeldeinformationen in den Einstellungen des Abhängigkeits-Proxys deiner Gruppe:\n  - Für GitLab 17.11+ (oder die aktuelle Version von GitLab.com): Navigiere zu den Einstellungen deiner Gruppe > Pakete und Registries > Abhängigkeits-Proxy.\n  - Für GitLab 17.10: Verwende die GraphQL-API, um die Authentifizierung zu konfigurieren.\n2. Aktualisiere deine Pipelines, sodass sie die Dependency-Proxy-URLs in deiner CI/CD-Konfiguration verwenden:\n`image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n**Option 4: Überlege dir, ein kostenpflichtiges Docker-Hub-Abonnement abzuschließen**\n\nUnternehmen, die Docker Hub intensiv nutzen, ist das Upgrade auf ein kostenpflichtiges Docker-Abonnement (Team oder Business) möglicherweise die einfachste Lösung, da es unbegrenzt viele Pulls ermöglicht.\n\n## Best Practices zur Reduzierung der Auswirkungen der Docker-Hub-Ratenbegrenzung\n\nUnabhängig davon, welche Option du wählst, helfen dir diese Best Practices dabei, die Auswirkungen der Docker-Hub-Ratenbegrenzung zu minimieren:\n\n* Verwende eindeutige Image-Tags anstelle von `latest`, um unnötige Pulls zu vermeiden.\n* Konsolidiere deine Docker-Dateien, sodass sie projektübergreifend dieselben Basis-Images verwenden.\n* Plane weniger kritische Pipelines so, dass sie außerhalb der Stoßzeiten ausgeführt werden.\n* Verwende Caching effektiv, um zu vermeiden, dass dieselben Images wiederholt gepullt werden.\n\n**Hinweis:** Gemäß der [Dokumentation](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition) von Docker Hub wird der Counter für die Anzahl der Pulls erhöht, wenn das Image-Manifest gepullt wird, und nicht basierend auf der Image-Größe oder der Anzahl der Ebenen.\n\n## Zeitplan und nächste Schritte\n\n**Jetzt**\n  * Implementiere die Authentifizierung für direkte Pulls von Docker Hub.\n  * Als Benutzer(in) von GitLab.com kannst du die Docker-Hub-Authentifizierung für den Abhängigkeits-Proxy bereits konfigurieren, indem du entweder:\n    * die GraphQL-API oder\n    * die Benutzeroberfläche in den Gruppeneinstellungen verwendest\n  * Benutzer(innen) von GitLab Self-Managed 17.10 können die Abhängigkeits-Proxy-Authentifizierung über die GraphQL-API konfigurieren.\n\n**1. April 2025**\n  * Die Ratenbegrenzungen für Docker Hub treten in Kraft.\n\n**17. April 2025**\n  * GitLab 17.11 wird mit UI-basierter Unterstützung für die Authentifizierung des Abhängigkeits-Proxy für Self-Managed-Instanzen veröffentlicht. \n\nDu solltest rechtzeitig vor Ablauf der Frist am 1. April Maßnahmen ergreifen, um unerwartete Pipeline-Fehler zu vermeiden. Für die meisten Benutzer(innen) ist die Konfiguration des Abhängigkeits-Proxys mit der Docker-Hub-Authentifizierung die effizienteste Langzeitlösung.\n\n> Hast du Fragen oder benötigst du Hilfe bei der Implementierung? Sieh dir [dieses Ticket an](https://gitlab.com/gitlab-org/gitlab/-/issues/526605), wo unser Team aktiv Unterstützung bietet.","bulletin-board",[9,976,684],"news",{"slug":978,"featured":91,"template":690},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd","content:de-de:blog:prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd.yml","Prepare Now Docker Hub Rate Limits Will Impact Gitlab Ci Cd","de-de/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd.yml","de-de/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"_path":984,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":985,"content":990,"config":1001,"_id":1003,"_type":14,"title":1004,"_source":16,"_file":1005,"_stem":1006,"_extension":19},"/de-de/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"ogTitle":986,"schema":987,"ogImage":670,"ogDescription":988,"ogSiteName":672,"noIndex":6,"ogType":673,"ogUrl":989,"title":986,"canonicalUrls":989,"description":988},"Jira zu GitLab Migration 2025: Kosten sparen & mehr Features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nahtlose Migration von Jira zu GitLab mit Jira2Lab im großen Maßstab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Maximilien Belinga\"}],\n        \"datePublished\": \"2024-10-10\",\n      }","Atlassian erhöht Preise um bis zu 30 %. Erfahre, wie du mit GitLab mehr bekommst und dabei Geld sparst. Komplette Migrationsanleitung mit Jira2Lab.","https://about.gitlab.com/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"heroImage":670,"body":991,"authors":992,"updatedDate":994,"date":995,"title":996,"tags":997,"description":999,"category":1000},"[Atlassian Server wurde Ende Februar eingestellt](https://about.gitlab.com/de-de/move-to-gitlab-from-atlassian/), sodass viele Kund(inn)en sich nach Alternativen wie Atlassian Cloud oder Atlassian Data Center umsehen. Viele Unternehmen, die bislang Atlassian Server genutzt haben, setzen jedoch vermehrt auf Lösungen im Bereich Agile Planning, die flexiblere, kosteneffizientere und robustere DevSecOps-Integrationen bieten. Außerdem müssen sie Herausforderungen hinsichtlich Datenvolumen, Anpassbarkeit, Benutzerabbildung, Leistung und Datenintegrität bei der Migration bewältigen. Hier kommt [Jira2Lab von GitLab](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/jira2lab) ins Spiel – diese nahtlose Lösung ermöglicht eine Migration von Jira zu GitLab im großen Maßstab und bietet gleichzeitig eine vollständige CI/CD-Integration.\n\n## Das Problem bei großen Jira-Migrationen\n\nDie Migration von Jira zu GitLab kann eine enorme Herausforderung sein, vor allem für Unternehmen mit komplexen Workflows und tausenden Tickets, die migriert werden müssen. Das sind die häufigsten Herausforderungen bei solchen Migrationen:\n\n- **Massive Datenmigration:** Wenn die Anzahl der Tickets, Anhänge, Kommentare und Projekte steigt, steigt auch die Schwierigkeit, diese ohne Leistungsprobleme oder Datenverluste zu migrieren.\n\n- **Benutzerdefinierte Felder und Workflows:** Jira-Instanzen enthalten oft benutzerdefinierte Workflows, Felder und Tickettypen, die keine direkte Entsprechung in GitLab haben. Diese Diskrepanzen sorgen bei der Migration für Schwierigkeiten, da bei bestehenden Tools oft eine manuelle Intervention nötig ist, um diese Elemente richtig zu übertragen.\n\n- **Mangel an einer vollständigen DevSecOps-Integration:** Viele Migrationstools schaffen zwar, Projektmanagementdaten zu migrieren, integrieren jedoch nicht die vollständigen DevSecOps-Funktionen von GitLab. Dadurch müssen Teams ihre [CI/CD-Pipelines](https://about.gitlab.com/de-de/topics/ci-cd/) und Managementsysteme der Versionskontrolle nach der Migration manuell konfigurieren.\n\n## Die Lösung: Jira2Lab\n\nJira2Lab wurde von Grund auf neu für die spezifischen Herausforderungen entwickelt, die eine Migration von Jira zu GitLab im großen Maßstab mit sich bringt. Es geht nicht nur darum, Daten zu verschieben, sondern Teams ohne Ausfallzeiten oder Datenverluste den nahtlosen Umstieg auf die leistungsstarke DevSecOps-Umgebung von GitLab zu ermöglichen.\n\n### Schlüsselfunktionen von Jira2Lab\n\n1. Effizienter Umgang mit Daten im großen Maßstab\u003Cbr>\nJira2Lab wurde dafür optimiert, tausende Tickets, Anhänge, Kommentare und benutzerdefinierte Projekte in mehreren Projekten ohne Leistungseinbußen zu bewältigen. Es lässt sich mühelos skalieren, um sogar Migrationen der größten Unternehmen zu meistern.\n\n2. Benutzerdefinierte Workflow- und Felder-Zuordnung\u003Cbr>\nEine der herausragenden Funktion von Jira2Lab ist die automatische Zuordnung von benutzerdefinierten Workflows und Feldern von Jira zu GitLab. Das Tool bietet eine flexible Mapping-Konfiguration, dank der keine manuelle Intervention beim Migrationsprozess nötig ist und die sicherstellt, dass alles reibungslos von Jira nach GitLab migriert wird.\n\n3. CI/CD-Pipeline-Integration\u003Cbr>\nJira2Lab migriert nicht nur Tickets und Projekte, sondern integriert sogar die komplette CI/CD-Pipeline von GitLab in den Migrationsprozess. Dadurch wird sichergestellt, dass die Entwicklungsteams sofort nach der Migration die DevSecOps-Funktionen von GitLab wie automatisierte Tests und Bereitstellungs-Pipelines nutzen können.\n\n4. Testmigrationen\u003Cbr>\nUnser Tool unterstützt Testmigrationen, damit Teams ihre Konfigurationen und Workflows vor der Skalierung testen können. Dadurch wird sichergestellt, dass Probleme frühzeitig erkannt werden, sodass es bei der richtigen Migration zu keinen Unterbrechungen und Ausfällen kommt.\n\n5. Echtzeit-Überwachung\u003Cbr>\nDas Tool bietet Echtzeit-Überwachung und -Protokolle während der Migration sowie vollständige Transparenz, um sicherzustellen, dass jeder Schritt korrekt und fehlerfrei ausgeführt wird.\n\n6. Anpassbar und flexibel\u003Cbr>\nAuch wenn deine Jira-Instanz einzigartige Konfigurationen oder Workflows hat, ist Jira2Lab flexibel genug, um die Migration an deine spezifischen Anforderungen anzupassen. So wird sichergestellt, dass bei der Übertragung nichts verloren geht.\n\n### Jira und GitLab im Vergleich\n\nDie Migration von Jira zu GitLab hilft, Workflows zu konsolidieren und erweiterte Funktionen zu nutzen, die in GitLab nativ sind. Hier ist ein kurzer Vergleich der Kernfunktionen der beiden Plattformen:\n\n| **Funktion** | **Jira** | **GitLab** |\n|----------|------|--------|\n| Ticketverfolgung | Ja (stark anpassbar) | Ja (in DevSecOps integriert) |\n| Agile Boards | Ja (Kanban, Scrum) | Ja (Issue-Übersichten, Meilensteine) |\n| CI/CD | Nein (externe Tools erforderlich) | Ja (integrierte CI/CD) |\n| Versionskontrolle | Nein (GitHub/Bitbucket erforderlich) | Ja (nativer Git-Support) |\n| DevSecOps-Tools | Begrenzte Integrationen | Kompletter DevSecOps-Lebenszyklus |\n| **KI-Funktionen** | **Atlassian Intelligence (Premium/Enterprise)** | **GitLab Duo (alle Stufen verfügbar)** |\n| **KI-Kosten** | **Zusätzlich ab Premium-Plan** | **In GitLab Ultimate enthalten** |\n| **Sicherheitsscans** | **Über Marketplace-Apps** | **Nativ integriert (SAST, DAST, etc.)** |\n\n\nMit Jira2Lab stellen wir sicher, dass alle wichtigen Aspekte – von der Ticketverfolgung bis hin zu CI/CD-Pipelines – reibungslos migriert werden. Dabei wird der integrierte Ansatz von GitLab hinsichtlich Entwicklung und Betrieb vollständig genutzt.\n\n### Die wahren Kosten einer Jira-Implementierung\n\nWährend Jira auf den ersten Blick kostengünstig erscheinen mag, zeigt sich bei genauerer Betrachtung ein anderes Bild:\n\n**Versteckte Kosten bei Jira:**\n- Separate Lizenzen für Confluence (Dokumentation), Bitbucket (Code) und Bamboo (CI/CD)\n- Marketplace-Apps für grundlegende Funktionen (durchschnittlich 5-10 Apps pro Installation)\n- Atlassian Intelligence nur in teuren Premium/Enterprise-Plänen\n- Assets und Virtual Service Agent mit verbrauchsbasierter Abrechnung\n\n**GitLabs All-in-One-Vorteil:**\nMit GitLab erhalten Teams eine vollständige DevSecOps-Plattform ohne zusätzliche Lizenzkosten. Wiki, Code-Repository, CI/CD, Sicherheitsscans und KI-Funktionen sind bereits enthalten, was bei vergleichbarem Atlassian-Stack leicht das 2-3-fache kosten kann.\n\n### Warum jetzt der richtige Zeitpunkt für eine Migration ist\n\nAtlassian hat in den letzten 18 Monaten eine aggressive Preisstrategie verfolgt, die viele Unternehmen zum Umdenken bewegt:\n- **Oktober 2024**: Cloud-Preise stiegen um 5-20%, wobei größere Teams besonders betroffen waren\n- **Februar 2025**: Data Center-Preise erhöhten sich nochmals um 5-30%, mit besonders drastischen Anstiegen bei Jira Software\n- **Funktionsverlagerung**: Wichtige ITSM-Funktionen wie Incident-, Problem- und Change-Management wurden von Standard auf Premium/Enterprise verschoben\n\nDiese kontinuierlichen Preiserhöhungen machen GitLab zu einer wirtschaftlich attraktiven Alternative, die gleichzeitig einen vollständigen DevSecOps-Ansatz ohne zusätzliche Tool-Kosten bietet.\n\n## Die Migrationsmethodik \n\nJira2Lab folgt einer strukturierten, fünfphasigen Migrationsmethodik, die eine nahtlose Migration mit minimalen Unterbrechungen gewährleistet:\n\n### 1. Entdeckung und Planung\n\nWir beginnen damit, das Jira-Setup des Kunden bzw. der Kundin genau zu verstehen und alle erforderlichen benutzerdefinierten Workflows, Felder und Projekte zu identifizieren, die migriert werden müssen. In dieser Phase wird auch eine Lückenanalyse durchgeführt, um die Funktionen von Jira und GitLab zu vergleichen und den Migrationsprozess abzubilden.\n\n### 2. Einrichtung\nIn dieser Phase konfigurieren wir das Migrationstool und richten die erforderlichen Umgebungen für Jira und GitLab ein. Dabei überprüfen wir alle Berechtigungen und richten vor Beginn der Migration eine Sicherung der Jira-Daten ein.\n\n### 3. Testmigrationen\nVor der Migration des gesamten Datensatzes führen wir Testmigrationen für ausgewählte Projekte durch, um den Migrationsprozess, die Workflows und die Datenintegrität zu testen. So können wir Probleme früh im Prozess erkennen und lösen.\n\n### 4. Skalierte Migrationen\nNach der Validierung der Testmigration skalieren wir die Migration über alle Projekte hinweg, um minimale Ausfallzeiten und reibungslose Übergänge für die Entwicklungsteams zu gewährleisten.\n\n### 5. Abschluss und Unterstützung nach der Migration\nSobald die Migration abgeschlossen ist, bieten wir fortlaufenden Support, um sicherzustellen, dass alle Teams in GitLab voll einsatzfähig sind. In dieser Phase werden auch die Benutzer(innen) geschult und die Jira-Instanz bei Bedarf außer Betrieb genommen.\n\n## Fallstudie: Skalierung mit Jira2Lab\n\nIn einer kürzlich durchgeführten Migration stand ein großes Unternehmen vor der Herausforderung, über 20 000 Tickets in 50 Projekten von Jira zu GitLab zu migrieren. Das Projekt wies hochgradig benutzerdefinierte Workflows und Tausende von Kommentaren und Anhängen auf, die übertragen werden mussten.\n\nMit Jira2Lab konnten wir:\n\n- Alle Daten, einschließlich benutzerdefinierter Felder, ohne Datenverlust migrieren.\n- CI/CD-Pipelines in GitLab einrichten, damit Teams nach der Migration sofort weiterarbeiten konnten.\n- Eine Testmigration von zwei Projekten durchführen, die es uns ermöglichte, kleinere Workflow-Diskrepanzen zu identifizieren und zu beheben, bevor wir die Migration auf das gesamte Unternehmen skalierten.\n\nDas Ergebnis war ein nahtloser Übergang zu GitLab, bei dem der gesamte Prozess innerhalb der geplanten Zeit abgeschlossen wurde und es zu keinen signifikanten Ausfallzeiten kam.\n\n## Lege jetzt mit Jira2Lab los\n\nJira2Lab hebt sich auf dem Markt dadurch ab, dass es genau auf die Einschränkungen eingeht, die andere Migrationstools nicht bewältigen können. Es wurde speziell für große Migrationen entwickelt und kann den kompletten DevSecOps-Lebenszyklus von GitLab integrieren  – anders als die meisten anderen Tools, die nur Projektmanagementdaten migrieren können. Da das Tool benutzerdefinierte Workflows abbilden und CI/CD-Pipelines integrieren kann, ist es die perfekte Lösung für Unternehmen, die ihre Entwicklungs-Workflows verbessern und gleichzeitig zu GitLab migrieren möchten.\n\n> Bist du bereit, deine Entwicklungsprozesse mit GitLab zu skalieren? Sieh dir unseren [Katalog für professionelle Services](https://about.gitlab.com/services/catalog/) an, um zu erfahren, wie wir deinem Team bei einer effizienten und effektiven Migration helfen können. Kontaktiere uns über das Formular am Ende dieser Seite, um eine personalisierte Demo von Jira2Lab von GitLab zu erhalten.\n",[993],"Maximilien Belinga","2025-06-24","2024-10-10","Von Jira zu GitLab wechseln: Der komplette Migrationsleitfaden 2025",[998,9,842,730,685],"agile","Atlassians Preiserhöhungen treiben viele Teams zu Alternativen. Entdecke, warum GitLab die bessere Wahl für moderne DevSecOps-Teams ist - mit mehr Features, integrierten Sicherheitstools und transparenter Preisgestaltung. Inklusive Schritt-für-Schritt-Migration mit Jira2Lab.","agile-planning",{"slug":1002,"featured":91,"template":690},"seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale","content:de-de:blog:seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","Seamlessly Migrate From Jira To Gitlab With Jira2lab At Scale","de-de/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale.yml","de-de/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"_path":1008,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1009,"content":1016,"config":1026,"_id":1028,"_type":14,"title":1029,"_source":16,"_file":1030,"_stem":1031,"_extension":19},"/de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":1010,"description":1011,"ogTitle":1010,"ogDescription":1011,"noIndex":6,"ogImage":1012,"ogUrl":1013,"ogSiteName":672,"ogType":1014,"canonicalUrls":1013,"schema":1015},"GitLab-Tutorial: Releases & Versionshinweise automatisieren","Mit GitLab kannst du Release-Artefakte, Versionshinweise und Änderungsprotokolle, die benutzerbezogenen Software-Änderungen enthalten, automatisieren.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab","Artikel","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Releases und Versionshinweise mit GitLab automatisieren\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\",\n      }",{"title":1010,"description":1011,"authors":1017,"heroImage":1012,"date":1019,"body":1020,"category":685,"tags":1021,"updatedDate":1025},[1018],"Ben Ridley","2023-11-01","***Update 2025** - Die Änderungsprotokoll-API wurde weiterentwickelt und enthält jetzt geniale neue Funktionen, auf die wir in diesem Blog nicht eingehen, wie die Möglichkeit, benutzerdefinierte Änderungsprotokolle mit Vorlagenwerten aus deinem Commit-Verlauf bereitzustellen. [Mehr dazu erfährst du in der offiziellen Dokumentation zu Änderungsprotokollen (nur in englischer Sprache verfügbar).](https://docs.gitlab.com/user/project/changelogs/)*\n\nWenn du Software entwickelst, auf die sich Benutzer(innen) verlassen, ist eine effektive Kommunikation über Änderungen bei jeder Release unerlässlich. Indem du Benutzer(innen) über neue Funktionen sowie darüber informierst, was geändert oder entfernt wurde, stellst du sicher, dass sie die Vorteile der Software wirklich nutzen können und sie bei Upgrades keine unangenehmen Überraschungen erwarten.\n\nIn der Vergangenheit war das Erstellen von Versionshinweisen und die Pflege eines Änderungsprotokolls eine mühsame Aufgabe, bei der Entwickler(innen) die Änderungen extern überwachen oder eigene Release Manager den Verlauf der Zusammenführungen durcharbeiten mussten. Mit der Änderungsprotokoll-API von GitLab kannst du den umfassenden Verlauf, der in unserem Git-Repository gespeichert ist, heranziehen, um ganz einfach Versionshinweise zu erstellen und ein Änderungsprotokoll zu führen.\n\nIn diesem Tutorial sehen wir uns an, wie du Releases mit GitLab automatisieren kannst und finden heraus, wie man Release-Artefakte, Versionshinweise und ein umfassendes Änderungsprotokoll, das alle benutzerbezogenen Software-Änderungen enthält, erstellt.\n\n## Releases in GitLab\nZuerst wollen wir uns ansehen, wie Releases in GitLab funktionieren.\n\nIn GitLab ist eine Release eine bestimmte Version deines Codes, die durch ein Git-Tag identifiziert wird. Dieses enthält Details zu den Änderungen seit der letzten Release (und Versionshinweise) sowie zugehörige Artefakte, die aus dieser Version des Codes erstellt wurden, wie Docker-Images, Installationspakete und Dokumentation.\n\nDu kannst Releases in GitLab über die UI erstellen und nachverfolgen, indem du unsere Release-API aufrufst oder den Job `release` innerhalb einer CI-Pipeline aufrufst. In diesem Tutorial verwenden wir den Job `release` in einer CI/CD-Pipeline, sodass wir die Automatisierung, die wir in unserer Pipeline zum Testen, für Code-Scans und mehr verwenden, auch für automatisierte Releases nutzen können.\n\nUm unsere Releases zu automatisieren, müssen wir zunächst die folgende Frage beantworten: Wo bekommen wir für unsere Versionshinweise und unser Änderungsprotokoll Informationen zu den vorgenommenen Änderungen? Die Antwort: In unserem Git-Repository, in dem wir durch Commit-Nachrichten und den Merge-Commit-Verlauf eine umfassende Übersicht über die Entwicklungsaktivitäten haben. Sehen wir uns an, ob wir diesen umfassenden Verlauf nutzen können, um automatisch unsere Versionshinweise und Änderungsprotokolle zu erstellen.\n\n## Einführung in Commit-Trailer\n[Commit-Trailer](https://git-scm.com/docs/git-interpret-trailers) sind strukturierte Einträge in deinen Git-Commits, die erstellt werden, indem du einfach die Formatierungsnachrichten `\u003CHEADER>:\u003CBODY>` am Ende deines Commits einfügst. Das CLI-Tool `git` kann diese dann parsen und für die Verwendung in anderen Systemen extrahieren. Ein Beispiel, das du vielleicht schon einmal verwendet hast, ist `git commit --sign-off`, um ein Commit zu beenden. Dies wird implementiert, indem der Trailer `Signed-off-by: \u003CDein Name>` zum Commit hinzugefügt wird. Wir können hier beliebige strukturierte Daten hinzufügen, sodass dies eine tolle Möglichkeit ist, Informationen zu speichern, die für das Änderungsprotokoll nützlich sein könnten.\n\nWenn wir in unseren Commits den Trailer `Changelog: \u003Cadded/changed/removed>` verwenden, parst die Änderungsprotokoll-API von GitLab diese und verwendet sie, um automatisch ein Änderungsprotokoll für uns zu erstellen!\n\nSehen wir uns das in Aktion an, indem wir Änderungen an einer echten Codebase vornehmen, eine Release durchführen und dann Versionshinweise und Änderungsprotokoll-Einträge generieren.\n\n## Beispielprojekt\nFür diesen Blog verwende ich ein einfaches Python-Web-App-Repository. Nehmen wir an, dass Version 1.0.0 der Anwendung gerade veröffentlicht wurde und die aktuelle Version des Codes ist. Ich habe auch die Release 1.0.0 in GitLab erstellt, was ich manuell tun musste, da wir unsere automatisierte Release-Pipeline ja noch nicht erstellt haben:\n\n![Ein Screenshot der GitLab-UI, die eine Release für Version 1.0.0 zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n## Nehmen wir unsere Änderungen vor\nWir entwickeln rasend schnell und arbeiten daher schon daran, Version 2.0.0 unserer Anwendung heute zu veröffentlichen. Im Rahmen unserer Release 2.0.0 fügen wir eine neue Funktion zu unserer App hinzu: einen Chatbot! Wir werden auch die Quanten-Blockchain-Funktion entfernen, da wir diese nur für die erste Finanzierungsrunde benötigt haben. Außerdem fügen wir einen automatisierten Release-Job zu unserer CI/CD-Pipeline für unsere Release 2.0.0 hinzu.\n\nZuerst entfernen wir die nicht benötigten Funktionen. Ich habe einen Merge Request erstellt, der die notwendigen Änderungen enthält. Wir müssen sicherstellen, dass wir eine Commit-Nachricht haben, die den Trailer `Changelog: removed` enthält. Dazu gibt es mehrere Möglichkeiten: Wir können ihn unter anderem direkt in einen Commit einbauen oder einen interaktiven Rebase durchführen und über das CLI hinzufügen. Der einfachste Weg in unserem Fall ist meiner Meinung nach, bis zum Ende zu warten und dann die Schaltfläche `Edit commit message` in GitLab zu verwenden, um den Trailer folgendermaßen zum Merge-Commit hinzuzufügen:\n\n![Screenshot der GitLab-UI, der einen Merge Request zum Entfernen nicht verwendeter Funktionen zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\nMit dieser Methode kannst du auch den Titel des Merge-Commits auf einen prägnanteren Titel ändern. Ich habe den Titel meines Merge-Commit auf „Nicht verwendete Funktionen entfernen“ geändert, da dies im Eintrag im Änderungsprotokoll angezeigt wird.\n\nAls nächstes fügen wir einige neue Funktionen für die Version 2.0.0 hinzu. Hier müssen wir nur einen weiteren Merge Request öffnen, der unsere neuen Funktionen enthält, und dann den Merge-Commit bearbeiten, sodass er den Trailer `Changelog: added` enthält, und dann den Commit-Titel auf einen prägnanteren Titel ändern:\n\n![Screenshot der GitLab-UI, der einen Merge Request zum Hinzufügen neuer Funktionen zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png)\n\nJetzt sind wir eigentlich bereit, 2.0.0 zu veröffentlichen. Aber dieses Mal möchten wir unsere Release nicht manuell erstellen. Deshalb fügen wir vor der Release einige Jobs zur Datei `.gitlab-ci.yml` hinzu, die die Release automatisch für uns durchführen und die entsprechenden Versionshinweise und Einträge ins Änderungsprotokoll erstellen, wenn wir unseren Code mit einer neuen Version wie z. B. `2.0.0` taggen.\n\n**Hinweis:** Wenn du Änderungsprotokoll-Trailer erzwingen möchtest, solltest du überlegen, etwas wie [Gefahr bei der Durchführung automatischer Überprüfungen für MR-Konventionen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/development/dangerbot.html) zu verwenden.\n\n## Erstellen einer automatisierten Release-Pipeline\nDamit unsere Pipeline funktioniert, müssen wir ein Projektzugriffstoken erstellen, mit dem wir die GitLab-API aufrufen können, damit sie die Einträge im Änderungsprotokoll erstellt. [Erstelle ein Projektzugriffstoken im API-Bereich (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) und [speichere das Token dann als CI/CD-Variable (nur in englischer Sprache verfügbar)]((https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui) mit dem Namen `CI_API_TOKEN`. Wir verweisen auf diese Variable, um uns bei der API zu authentifizieren.\n\nNun fügen wir zwei neue Jobs zu unserer Datei `gitlab-ci.yml` hinzu:\n```yaml\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\nIn der oben angeführten Konfiguration verwendet `prepare_job` die Befehle `curl` und `jq`, um den Endpunkt der Änderungsprotokoll-API von GitLab aufzurufen und übergibt dies dann an unser `release_job`, um die Release zu erstellen. Genauer gesagt sieht das so aus:\n- Wir verwenden das Projektzugriffstoken, dass wir zuvor erstellt haben, um die Änderungsprotokoll-API von GitLab aufzurufen, die dann die Versionshinweise erstellt. Wir speichern dies als Artefakt.\n- Wir verwenden die Variable `$CI_COMMIT_TAG` als Version. Dazu müssen wir eine semantische Versionierung für unsere Tags verwenden (beispielsweise so etwas wie `2.0.0`). Du wirst auch bemerkt haben, dass ich den Release-Job mit dem Abschnitt `rules` eingeschränkt habe, der auf ein semantisches Versions-Tag überprüft.\n\t- Damit die Änderungsprotokoll-API von GitLab funktioniert, ist eine semantische Versionierung erforderlich. Sie verwendet dieses Format, um die neueste Release zu finden und sie mit unserer aktuellen Release zu vergleichen.\n- Wir verwenden das offizielle Image `release-cli` von GitLab. „release-cli“ ist erforderlich, um das Schlüsselwort `release` in einem Job zu verwenden.\n- Wir verwenden das Schlüsselwort `release`, um eine Release in GitLab zu erstellen. Dies ist ein spezielles Job-Schlüsselwort, das für die Erstellung einer Release und das Ausfüllen der erforderlichen Felder reserviert ist.\n- Wir können eine Datei als Argument an die `description` der Release übergeben. In unserem Fall ist es die Datei, die wir in `prepare_job` erstellt haben und die als Artefakt an diesen Job übergeben wurde.\n- Wir haben auch unser Container-Image, das früher in der Pipeline erstellt wurde, als Release-Asset hinzugefügt. Du kannst alle Assets aus deinem Build-Prozess anhängen, die du möchtest, z. B. Binärdateien oder Dokumentationen, indem du eine URL zu dem Ort angibst, an den du sie zuvor in der Pipeline hochgeladen hast.\n\n## Durchführen einer automatisierten Release\nMit dieser Konfiguration müssen wir nur ein Tag in unser Repository übertragen, das unserem Versionsschema entspricht, um eine Release durchzuführen. Du kannst einfach ein Tag mit dem CLI pushen. Für dieses Beispiel wird die GitLab-UI verwendet, um ein Tag im main-Branch zu erstellen. Erstelle ein Tag, indem du in der Seitenleiste „Code“ -> „Tags“ -> „Neues Tag“ auswählst:\n![Screenshot der GitLab-UI, der zeigt, wie man ein Tag erstellt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\nNach der Erstellung werden unsere Pipelines ausgeführt. Die Änderungsprotokoll-API von GitLab generiert automatisch Versionshinweise für uns als Markdown, der alle Änderungen zwischen dieser Release und der vorherigen Release enthält. Hier ist der Markdown, der in unserem Beispiel generiert wurde:\n\n```md\n## 2.0.0 (2023-08-25)\n\n### added (1 change)\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n### removed (1 change)\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n```\n\nWie du sehen kannst, hat GitLab die Einträge für unsere Versionshinweise automatisch mit unseren Git-Commit-Trailern extrahiert. Außerdem werden hilfreiche Links zum Merge Request bereitgestellt, damit die Leser(innen) weitere Details und Diskussionen zu den Änderungen sehen können.\n\nUnd jetzt folgt unsere letzte Release:\n![GitLab-Release-UI, die ein Release für Version 2.0.0 zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n## Erstellen des Änderungsprotokolls\nAls nächstes möchten wir unser Änderungsprotokoll aktualisieren (das im Grunde ein gesammelter Verlauf aller deiner Versionshinweise ist). Du kannst dazu eine `POST`-Anfrage an den Änderungsprotokoll-API-Endpunkt senden, den wir zuvor verwendet haben.\n\nDu kannst dies auch als Teil deiner Release-Pipeline tun, wenn du möchtest. Dazu kannst du beispielswiese den folgenden Code in den Abschnitt `script` deines Vorbereitungsjobs einfügen:\n```sh\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n```\n\n**Beachte dabei, dass dies das Repository ändert.** Es wird ein Commit erstellt, um die neuesten Notizen zu einer Datei `CHANGELOG.md` hinzuzufügen:\n![Screenshot des Repositorys, der einen Commit zeigt, der die Änderungsprotokolldatei aktualisiert](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\nUnd das war’s auch schon! Indem wir den umfassenden Verlauf, den uns `git` bietet, mit praktischen Commit-Trailern nutzen, können wir die leistungsstarke API und die CI/CD-Pipelines von GitLab optimal einsetzen, um unsere Release-Prozesse zu automatisieren und Versionshinweise für uns zu erstellen.\n\n> Wenn du das Projekt erkunden möchtest, das wir für diesen Artikel verwendet haben, [findest du es unter diesem Link](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo).\n",[1022,755,9,1023,842,1024],"Tutorial","DevOps","Git","2025-06-05",{"slug":1027,"featured":6,"template":690},"tutorial-automated-release-and-release-notes-with-gitlab","content:de-de:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"_path":1033,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1034,"content":1039,"config":1047,"_id":1049,"_type":14,"title":1050,"_source":16,"_file":1051,"_stem":1052,"_extension":19},"/de-de/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":1035,"description":1036,"ogTitle":1035,"ogDescription":1036,"noIndex":6,"ogImage":700,"ogUrl":1037,"ogSiteName":672,"ogType":673,"canonicalUrls":1037,"schema":1038},"Der ultimative CI/CD-Leitfaden: Grundlagen für die erweiterte Implementierung","Erfahre, wie du die kontinuierliche Integration/kontinuierliche Bereitstellung modernisierst und die Entwicklung, Lieferung und Sicherheit von Pipelines automatisierst.","https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der ultimative CI/CD-Leitfaden: Grundlagen für die erweiterte Implementierung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2025-01-06\",\n      }",{"title":1035,"description":1036,"authors":1040,"heroImage":700,"date":1042,"body":1043,"category":954,"tags":1044,"updatedDate":1046},[1041],"Sandra Gittlen","2025-01-06","Die kontinuierliche Integration/kontinuierliche Lieferung ([CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)) hat die Art und Weise revolutioniert, wie Softwareteams Werte für ihre Benutzer(innen) schaffen. Vorbei sind die Zeiten manueller Bereitstellungen und komplizierter Integrationen – moderne Entwicklung erfordert Automatisierung, Zuverlässigkeit und Geschwindigkeit.\n\nIm Grunde geht es bei CI/CD darum, eine nahtlose Pipeline zu erstellen, die Code von der Umgebung der Entwickler(innen) bis hin zur Produktion überführt und Feedback in Echtzeit einbezieht. [CI](https://about.gitlab.com/de-de/topics/ci-cd/benefits-continuous-integration/) hilft Teams, Mängel frühzeitig zu erkennen – bevor sie zu kostspieligen Problemen werden –, indem sichergestellt wird, dass Codeänderungen häufig in einem gemeinsamen Repository zusammengeführt, automatisch getestet und validiert werden. [CD](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-delivery-cd) führt diesen Ansatz fort, indem es den Bereitstellungsprozess automatisiert und die Releases vorhersehbar und stressfrei macht.\n\nAnstatt sich auf manuelle Prozesse und komplexe Toolchains für die Softwareentwicklung zu verlassen, können Teams eine robuste CI/CD-Pipeline verwenden, um Software zu erstellen, zu testen und bereitzustellen. Die KI kann diesen Prozess noch weiter optimieren und automatisch CI/CD-Pipelines erstellen, die konsistente Qualität, Compliance und Sicherheitsüberprüfungen ermöglichen.\n\nIn diesem Leitfaden werden moderne CI/CD-Pipelines von den Grundprinzipien über Best Practices bis hin zu fortschrittlichen Strategien erklärt. Du erfährst außerdem, wie führende Unternehmen CI/CD nutzen, um wirkungsvolle Ergebnisse zu erzielen. Mit den Erkenntnissen dieses Leitfadens kannst du deine DevSecOps-Umgebung skalieren und Software [agil](https://about.gitlab.com/de-de/topics/ci-cd/continuous-integration-agile/), automatisiert und effizient entwickeln und bereitstellen.\n\n## Inhalt: Das erwartet dich\n\n- [Was ist kontinuierliche Integration?](#was-ist-kontinuierliche-integration%3F)\n- [Was ist kontinuierliche Lieferung?](#was-ist-kontinuierliche-lieferung%3F)\n- [Wie hängt die Quellcodeverwaltung mit CI/CD zusammen?](#wie-hängt-die-quellcodeverwaltung-mit-cicd-zusammen%3F)\n- [Die Vorteile von CI/CD in der modernen Softwareentwicklung](#die-vorteile-von-cicd-in-der-modernen-softwareentwicklung)\n - [Hauptunterschiede zwischen CI/CD und traditioneller Entwicklung](#hauptunterschiede-zwischen-cicd-und-traditioneller-entwicklung)\n- [Grundlagen von CI/CD verstehen](#grundlagen-von-cicd-verstehen)\n - [Was ist eine CI/CD-Pipeline?](#was-ist-eine-cicd-pipeline%3F)\n- [Best Practices für CI/CD-Implementierung und -Management](#best-practices-für-cicd-implementierung-und--management)\n - [Best Practices für CI](#best-practices-für-ci)\n - [Best Practices für CD](#best-practices-für-cd)\n- [Erste Schritte mit CI/CD](#erste-schritte-mit-cicd)\n- [Sicherheit, Compliance und CI/CD](#sicherheit-compliance-und-cicd)\n- [CI/CD und die Cloud](#cicd-und-die-cloud)\n- [Erweitertes CI/CD](#erweitertes-cicd)\n - [Wiederverwendung und Automatisierung in CI/CD](#wiederverwendung-und-automatisierung-in-cicd)\n - [Problembehebung für Pipelines mithilfe von KI](#problembehebung-für-pipelines-mithilfe-von-ki)\n- [So migrierst du zu GitLab CI/CD](#so-migrierst-du-zu-gitlab-cicd)\n- [Erfahrungsberichte von führenden Unternehmen](#erfahrungsberichte-von-führenden-unternehmen)\n- [CI/CD-Tutorials](#cicd-tutorials)\n\n## Was ist kontinuierliche Integration?\n\nUnter [kontinuierlicher Integration](https://about.gitlab.com/de-de/topics/ci-cd/benefits-continuous-integration/) (CI) versteht man das Vorgehen, alle Codeänderungen frühzeitig und häufig in den main-Branch eines gemeinsamen Quellcode-Repositorys zu integrieren, Änderungen automatisch zu testen, wenn sie committet oder zusammengeführt werden, und automatisch einen Build zu starten. Mit kontinuierlicher Integration können Teams Fehler und Sicherheitsprobleme leichter und viel früher im Entwicklungsprozess erkennen und beheben.\n\n## Was ist kontinuierliche Lieferung?\n[Kontinuierliche Lieferung](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-delivery-cd) (CD) – manchmal auch _kontinuierliche Bereitstellung_ genannt – ermöglicht es Unternehmen, ihre Anwendungen automatisch bereitzustellen, sodass Entwickler(innen) mehr Zeit haben, sich auf die Überwachung des Bereitstellungsstatus zu konzentrieren und den Erfolg sicherzustellen. Bei der kontinuierlichen Lieferung legen DevOps-Teams die Kriterien für die Codefreigabe im Voraus fest. Wenn diese Kriterien erfüllt und validiert sind, wird der Code in der Produktivumgebung bereitgestellt. So können Unternehmen flexibler sein und neue Funktionen den Benutzer(inne)n schneller zur Verfügung stellen.\n\n## Wie hängt die Quellcodeverwaltung mit CI/CD zusammen?\n\nQuellcodeverwaltung ([Source Code Management, SCM](https://about.gitlab.com/de-de/solutions/source-code-management/)) und CI/CD bilden die Grundlage moderner Softwareentwicklungsverfahren. SCM-Systeme wie [Git](https://about.gitlab.com/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/) bieten eine zentrale Möglichkeit, Änderungen zu verfolgen, verschiedene Codeversionen zu verwalten und die Zusammenarbeit zwischen den Teammitgliedern zu erleichtern. Wenn Entwickler(innen) an neuen Funktionen oder Fehlerbehebungen arbeiten, erstellen sie Branches aus der main-Codebase, nehmen ihre Änderungen vor und [führen sie dann über Merge Requests zusammen](https://docs.gitlab.com/ee/user/project/merge_requests/) (Artikel nur in englischer Sprache verfügbar). Diese Branching-Strategie macht es möglich, dass mehrere Entwickler(innen) gleichzeitig arbeiten können, ohne sich gegenseitig in die Quere zu kommen, und gleichzeitig einen stabilen main-Branch zu bewahren, der immer produktionsreifen Code enthält.\n\nCI/CD übernimmt den von SCM-Systemen verwalteten Code und erstellt, testet und validiert ihn automatisch, wenn Änderungen gepusht werden. Wenn Entwickler(innen) Codeänderungen einreichen, ruft das CI/CD-System automatisch den neuesten Code ab, kombiniert ihn mit der vorhandenen Codebase und führt eine Reihe automatisierter Überprüfungen durch. Dazu gehören in der Regel das Kompilieren des Codes, das Ausführen von Unit-Tests, das Durchführen einer statischen Codeanalyse und das Überprüfen der Testabdeckung. Wenn einer dieser Schritte fehlschlägt, wird das Team sofort benachrichtigt, sodass es Probleme beheben kann, bevor sie sich auf andere Entwickler(innen) auswirken oder in die Produktivumgebung überführt werden. Durch diese enge Integration zwischen Versionskontrolle und kontinuierlicher Integration entsteht eine Feedbackschleife, die dazu beiträgt, die Codequalität aufrechtzuerhalten, und verhindert, dass sich Integrationsprobleme ansammeln.\n\n## Die Vorteile von CI/CD in der modernen Softwareentwicklung\n\n[CI/CD bringt transformative Vorteile für die moderne Softwareentwicklung](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/) (Blogbeitrag nur in englischer Sprache verfügbar), indem die Zeit und das Risiko drastisch reduziert werden, die neue Funktionen und Fixes mit sich bringen. Durch die kontinuierliche Feedbackschleife können DevSecOps-Teams sicher sein, dass ihre Änderungen automatisch für die gesamte Codebase validiert werden. Das Ergebnis sind hochwertigere Software, kürzere Lieferzeiten und häufigere Veröffentlichungen, mit denen man schneller auf Benutzer- und Marktanforderungen reagieren kann.\n\nEiner der wichtigsten Aspekte ist jedoch, dass CI/CD eine Kultur der Zusammenarbeit und Transparenz innerhalb von Softwareentwicklungsteams fördert. Wenn jeder den Status von Builds, Tests und Bereitstellungen in Echtzeit sehen kann, wird es einfacher, Engpässe im Bereitstellungsprozess zu identifizieren und zu beheben. Die von CI/CD ermöglichte Automatisierung reduziert auch die kognitive Belastung für Entwickler(innen) und gibt ihnen die Möglichkeit, sich auf das Schreiben von Code zu konzentrieren, anstatt manuelle Bereitstellungsprozesse zu verwalten. Dies führt zu einer höheren Zufriedenheit und Produktivität der Entwickler(innen) und reduziert gleichzeitig das Risiko, das traditionell mit dem gesamten Softwareveröffentlichungsprozess verbunden ist. Teams können freier experimentieren, wenn sie wissen, dass schnelle Code Reviews Teil des Prozesses sind, und sie können Änderungen bei Bedarf schnell zurücknehmen, was Innovationen und kontinuierliche Verbesserungen fördert.\n\n### Hauptunterschiede zwischen CI/CD und traditioneller Entwicklung\n\nCI/CD unterscheidet sich in vielerlei Hinsicht von der traditionellen Softwareentwicklung:\n\n**Häufige Code-Commits** \n\nEntwickler(innen) arbeiten oft unabhängig und laden ihren Code selten in eine main-Codebase hoch, was zu Merge-Konflikten und anderen zeitaufwändigen Problemen führt. Mit CI/CD pushen Entwickler(innen) Commits den ganzen Tag über, um sicherzustellen, dass Konflikte frühzeitig erkannt werden und die Codebase auf dem neuesten Stand bleibt.\n\n**Reduziertes Risiko**\n\nLangwierige Testzyklen und eine umfassende Vorabplanung kennzeichnen die traditionelle Softwareentwicklung. Dadurch sollen Risiken minimiert werden, jedoch wird die Möglichkeit eingeschränkt, Probleme zu finden und zu beheben. Das Risikomanagement in CI/CD basiert darauf, dass kleine, inkrementelle Änderungen vorgenommen werden, die genau überwacht und leicht rückgängig gemacht werden können.\n\n**Automatisierte und kontinuierliche Tests**\n\nIn der traditionellen Softwareentwicklung werden Tests durchgeführt, sobald die Entwicklung abgeschlossen ist. Dies führt jedoch zu Problemen wie verspäteter Lieferung und kostspieliger Fehlerbehebungen. CI/CD unterstützt automatisierte Tests, die während der gesamten Entwicklung kontinuierlich durchgeführt und durch jeden Code-Commit ausgelöst werden. Entwickler(innen) erhalten außerdem Feedback, auf das sie schnell reagieren können.\n\n**Automatisierte, wiederholbare und häufige Bereitstellungen**\n\nMit CI/CD sind Bereitstellungen automatisierte Prozesse, die den typischen Stress und Aufwand für große Software-Rollouts reduzieren. Der gleiche Bereitstellungsprozess kann in allen Umgebungen wiederholt werden, was Zeit spart und Fehler und Inkonsistenzen reduziert.\n\n## Grundlagen von CI/CD verstehen\n\nCI/CD dient als Framework für den Aufbau skalierbarer, wartbarer Bereitstellungsprozesse. Daher ist es für DevSecOps-Teams wichtig, die Kernkonzepte wirklich zu verstehen. Durch ein solides Verständnis der CI/CD-Prinzipien können Teams, Strategien und Praktiken an die Entwicklung der Technologie anpassen, anstatt an alte Ansätze gebunden zu sein. Hier sind einige der Grundlagen.\n\n### Was ist eine CI/CD-Pipeline?\n\nEine [CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) ist eine Reihe von Schritten wie Erstellen, Testen und Bereitstellen, durch die der Softwarebereitstellungsprozess automatisiert und optimiert wird. [Jede Phase dient als Qualitätsüberprüfung](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/) (Blogbeitrag nur in englischer Sprache verfügbar) und stellt sicher, dass nur validierter Code weiterentwickelt wird. In den frühen Phasen werden in der Regel grundlegende Überprüfungen wie Kompilierung und Unit-Tests durchgeführt, während spätere Phasen Integrationstests, Leistungstests, Konformitätstests und gestaffelte Bereitstellungen in verschiedenen Umgebungen umfassen können.\n\nDie Pipeline kann so konfiguriert werden, dass manuelle Genehmigungen an kritischen Punkten erforderlich sind, z. B. vor der Bereitstellung für die Produktion, während gleichzeitig Routineaufgaben automatisiert werden und Entwickler(innen) schnelles Feedback über den Zustand ihrer Änderungen erhalten. Dieser strukturierte Ansatz sorgt für Konsistenz, reduziert menschliche Fehler und bietet einen klaren Audit-Trail, wie Codeänderungen sich von der Entwicklung bis in die Produktion bewegen. Moderne Pipelines werden oft als Code implementiert, so dass sie wie Anwendungscode versioniert, getestet und gepflegt werden können.\n\nAuch die folgenden Begriffe sind für CI/CD wichtig:\n- **Commit:** eine Codeänderung\n- **Job:** Anweisungen, die ein Runner ausführen muss\n- **Runner:** ein Agent oder Server, der jeden Job einzeln ausführt und nach Bedarf hoch- oder herunterfahren kann\n- **Phase:** ein Schlüsselwort, das bestimmte Jobphasen definiert, z. B. „Erstellen“ und „Bereitstellen“. Jobs der gleichen Phase werden parallel ausgeführt. Pipelines werden mithilfe der versionierten YAML-Datei `.gitlab-ci.yml` auf der Root-Ebene eines Projekts konfiguriert.\n\n![CI/CD-Pipeline-Schema](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673928/Blog/Content%20Images/1690824533476.png)\n\n## Best Practices für die Implementierung und das Management von CI/CD\n\nWie erfolgreich du mit CI/CD bist, hängt stark von den [Best Practices](https://about.gitlab.com/de-de/blog/how-to-keep-up-with-ci-cd-best-practices/) ab, die du implementierst. \n\n#### Best Practices für CI\n\n* Committe früh und oft.\n* Optimiere die Pipeline-Phasen.\n* Erstelle Builds schnell und einfach.\n* Nutze Fehlschläge, um Prozesse zu verbessern.\n* Stelle sicher, dass die Testumgebung die Produktion widerspiegelt.\n\n#### Best Practices für CD\n\n* Beginne dort, wo du gerade bist – du kannst jederzeit iterieren.\n* Die beste kontinuierliche Lieferung erfolgt mit minimalen Mitteln.\n* Verfolge, was passiert, damit Probleme und Merge Requests nicht außer Kontrolle geraten.\n* Optimiere Benutzerakzeptanztests und Staging mit Automatisierung.\n* Verwalte die Release-Pipeline durch Automatisierung.\n* Implementiere Überwachung für Transparenz und Effizienz. \n\n> ### Setz dir ein Lesezeichen!\n>\n>Sieh dir unser englischsprachiges [Webinar „Intro to CI/CD“](https://www.youtube.com/watch?v=sQ7Nw3o0izc) (Einführung in CI/CD) an!\n>\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sQ7Nw3o0izc?si=3HpNqIClrc2ncr7Y\" title=\"Intro to CI/CD webinar\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Erste Schritte mit CI/CD\n\nDer Einstieg in CI/CD beginnt mit einem einfachen, aber repräsentativen Projekt, das als Pilotprojekt dienen soll. Wähle eine einfache Anwendung mit simplen Testanforderungen aus, damit du dich auf das Erlernen der Pipeline-Mechanismen konzentrieren kannst, anstatt dich mit komplexen Bereitstellungsszenarien zu befassen. Stelle zunächst sicher, dass dein Code [versioniert](https://about.gitlab.com/de-de/topics/version-control/) ist und einige [grundlegende automatisierte Tests](https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci/) (Blogbeitrag nur in englischer Sprache verfügbar) enthält  – dabei reichen schon ein paar Unit-Tests aus. Das Ziel besteht darin, [eine minimale Pipeline zu erstellen](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/) (Blogbeitrag nur in englischer Sprache verfügbar), die du mit zunehmendem Verständnis nach und nach ausbauen kannst.\n\nIm Fall von GitLab beginnt der Prozess mit dem Erstellen der Datei `.gitlab-ci.yml` im Stammverzeichnis deines Projekts. Diese YAML-Datei definiert deine Pipeline-Phasen (grundlegende Phasen wie Erstellen, Testen und Bereitstellen) und Jobs. Eine einfache Pipeline könnte so aussehen: In der Phase „Erstellen“ wird deine Code kompiliert und es werden Artefakte erstellt, die Testphase führt deine Unit-Tests aus und die Phase „Bereitstellen“ pusht deine Anwendung in eine Staging-Umgebung. GitLab erkennt diese Datei automatisch und beginnt, deine Pipeline auszuführen, wenn Änderungen in dein Repository gepusht werden. Die Plattform bietet [integrierte Runner](https://docs.gitlab.com/runner/) (Artikel nur in englischer Sprache verfügbar), um deine Pipeline-Jobs auszuführen, aber du kannst auch eigene Runner einrichten, wenn du mehr Kontrolle haben willst.\n\nWenn du mit den Grundlagen vertraut bist, kannst du nach und nach anspruchsvollere Elemente zu deiner Pipeline hinzufügen. Du kannst zum Beispiel Code-Qualitätsprüfungen, [Sicherheitsscans](https://docs.gitlab.com/ee/user/application_security/#security-scanning) (Artikel nur in englischer Sprache verfügbar) oder die automatisierte Bereitstellung für die Produktion hinzufügen. Die DevSecOps-Plattform von GitLab bietet Funktionen wie [Compliance-Management](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/), [Bereitstellungsvariablen](https://about.gitlab.com/blog/demystifying-ci-cd-variables/) (Blogbeiträge nur in englischer Sprache verfügbar) und manuelle Genehmigungsprüfungen, die du integrieren kannst, wenn deine Pipeline ausgereift ist. Achte auf die Ausführungszeit der Pipeline und suche nach Möglichkeiten, Jobs parallel auszuführen. Denke daran, die richtige Fehlerbehandlung und Benachrichtigungen hinzuzufügen, damit deine Teammitglieder umgehend über alle Pipeline-Ausfälle informiert werden. Beginne damit, häufige Probleme und Lösungen zu dokumentieren, wenn sie auftauchen – dies wird von unschätzbarem Wert sein, wenn dein Team wächst.\n\n> ### Möchtest du mehr über die ersten Schritte mit CI/CD erfahren? Registriere dich für einen [kostenlosen, englischsprachigen CI/CD-Kurs auf GitLab University](https://university.gitlab.com/courses/continuous-integration-and-delivery-ci-cd-with-gitlab).\n\n## Sicherheit, Compliance und CI/CD\n\nEiner der größten Vorteile von CI/CD ist die Möglichkeit, Sicherheits- und Compliance-Prüfungen frühzeitig und häufig in den Software-Entwicklungsprozess einzubetten. In GitLab können Teams die Konfiguration `.gitlab-ci.yml` verwenden, um automatisch Sicherheitsscans in mehreren Phasen auszulösen, vom ersten Code Commit bis zur Bereitstellung in der Produktivumgebung. Container-Scanning, Abhängigkeitsuche und Sicherheitsscans auf der Plattform ([Dynamische Anwendungssicherheitstests](https://docs.gitlab.com/ee/user/application_security/dast/) und [Erweitertes SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/); beide nur in englischer Sprache verfügbar) können so konfiguriert werden, dass sie bei jeder Codeänderung automatisch ausgeführt werden, um auf Sicherheitslücken, Compliance-Verstöße und Sicherheitsfehlkonfigurationen zu prüfen. Die API der Plattform ermöglicht die Integration mit [externen Sicherheitstools](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) (Blogbeitrag nur in englischer Sprache verfügbar) und die Testabdeckungsfunktionen stellen sicher, dass die Sicherheitstests die erforderlichen Anforderungen erfüllen.\n\nDie Sicherheitstestberichte von GitLab enthalten detaillierte Informationen zu den Ergebnissen und sollen sicherstellen, dass Sicherheitsprobleme schnell behoben werden können, bevor sie in die Produktion kommen. Das Sicherheitsdashboard bietet eine zentrale Ansicht von Sicherheitslücken in allen Projekten, während [Sicherheitsrichtlinien](https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/) (Blogbeitrag nur in englischer Sprache verfügbar) durch Merge-Request-Genehmigungen und Pipeline-Gates durchgesetzt werden können. Darüber hinaus bietet GitLab mehrere Sicherheitsebenen, um vertrauliche Daten während des gesamten CI/CD-Prozesses zu schützen, Audit-Protokolle, um den Zugriff auf Geheimnisse zu verfolgen, und rollenbasierte Zugriffskontrolle (RBAC), um sicherzustellen, dass nur autorisierte Benutzer(innen) vertrauliche Konfigurationsdaten anzeigen oder ändern können.\n\nGitLab unterstützt auch die Erstellung einer Software-Stückliste ([SBOM](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)), die eine umfassende Bestandsaufnahme aller Softwarekomponenten, Abhängigkeiten und Lizenzen in einer Anwendung bietet und es den Teams ermöglicht, Sicherheitslücken schnell zu identifizieren, darauf zu reagieren und behördliche Auflagen zu erfüllen.\n\n## CI/CD und die Cloud\n\nDie CI/CD-Plattform von GitLab bietet eine robuste Integration mit großen Cloud-Anbietern wie [Amazon Web Services](https://about.gitlab.com/de-de/partners/technology-partners/aws/), [Google Cloud Platform](https://about.gitlab.com/blog/provision-group-runners-with-google-cloud-platform-and-gitlab-ci/) (Blogbeitrag nur in englischer Sprache verfügbar) und [Microsoft Azure](https://docs.gitlab.com/ee/install/azure/) (Artikel nur in englischer Sprache verfügbar), sodass Teams ihre Cloud-Bereitstellungen direkt aus ihren Pipelines heraus automatisieren können. Durch die Cloud-Integrationen von GitLab können Teams Cloud-Ressourcen verwalten, Anwendungen bereitstellen und Cloud-Dienste innerhalb der GitLab-Oberfläche überwachen. Die integrierten Cloud-Bereitstellungsvorlagen und [Auto-DevOps-Funktionen](https://docs.gitlab.com/ee/topics/autodevops/) (Artikel nur in englischer Sprache verfügbar) der Plattform reduzieren die Komplexität von Cloud-Bereitstellungen erheblich, sodass sich die Teams auf die Anwendungsentwicklung konzentrieren können und sich nicht mit dem Infrastrukturmanagement befassen müssen. Für Unternehmen, die ihre IT-Infrastruktur mit GitOps automatisieren möchten, bietet GitLab eine [Flux-CD-Integration](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/) (Blogbeitrag nur in englischer Sprache verfügbar).\n\nDie Cloud-Funktionen von GitLab gehen weit über die einfache Automatisierung der Bereitstellung hinaus. Die [Kubernetes-Integration](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/) (Blogbeitrag nur in englischer Sprache verfügbar) der Plattform ermöglicht es den Teams, die Container-Orchestrierung über mehrere Cloud-Anbieter hinweg zu verwalten, während die [Cloud-nativen Installationsoptionen von GitLab](https://about.gitlab.com/de-de/topics/ci-cd/cloud-native-continuous-integration/) den Betrieb der Plattform selbst in Cloud-Umgebungen ermöglichen. Durch die Cloud-nativen Funktionen von GitLab können Teams Runner mit automatischer Skalierung implementieren, die dynamisch Cloud-Ressourcen für die Pipeline-Ausführung bereitstellen und so Kosten und Leistung optimieren. Die Integration der Plattform mit den Sicherheitsdiensten von Cloud-Anbietern macht es möglich, dass die Sicherheits- und Konformitätsanforderungen während des gesamten Bereitstellungsprozesses erfüllt werden.\n\nFür Multi-Cloud-Umgebungen stellt GitLab konsistente Workflows und Tools zur Verfügung, unabhängig vom zugrunde liegenden Cloud-Anbieter. Teams können die Umgebungsverwaltung von GitLab verwenden, um verschiedene Cloud-Konfigurationen in Entwicklungs-, Staging- und Produktivumgebungen zu verwalten. Da die Plattform [Infrastructure as Code](https://docs.gitlab.com/ee/user/infrastructure/iac/) (Artikel nur in englischer Sprache verfügbar) unterstützt – insbesondere die native Integration mit Terraform – können Teams ihre Cloud-Infrastruktur-Bereitstellung steuern und automatisieren. Die Überwachungs- und Beobachtungsfunktionen von GitLab lassen sich in die Metriken von Cloud-Anbietern integrieren und bieten einen umfassenden Überblick über den Zustand von Anwendungen und Infrastruktur in allen Cloud-Umgebungen.\n\n## Erweitertes CI/CD \nCI/CD hat sich weit über das einfache Erstellen und Bereitstellen von Pipelines hinaus entwickelt. In umfassenderen Implementierungen bietet CI/CD eine ausgefeilte Orchestrierung von automatisierten Tests, Sicherheitsscans, Infrastrukturbereitstellung, KI und mehr. Hier findest du einige Strategien für Erweitertes CI/CD, die Entwicklungsteams dabei helfen können, ihre Pipelines zu skalieren und Probleme zu beheben, auch wenn die architektonische Komplexität zunimmt.\n\n### Wiederverwendung und Automatisierung in CI/CD\n\nGitLab verändert die Art und Weise, wie Entwicklungsteams CI/CD-Pipelines erstellen und verwalten. Dazu tragen vor allem zwei wichtige Innovationen bei: der [CI/CD-Katalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) und [CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/) (Blogbeiträge nur in englischer Sprache verfügbar), eine neue Programmiersprache für DevSecOps-Automatisierung, die derzeit getestet wird. Der CI/CD-Katalog ist eine zentralisierte Plattform, auf der Entwickler(innen) CI/CD-Komponenten entdecken, wiederverwenden und beitragen können. Komponenten fungieren als wiederverwendbare Bausteine mit einem einzigen Zweck und sollen die Pipeline-Konfiguration vereinfachen – du kannst sie dir wie Legosteine für CI/CD-Workflows vorstellen. CI/CD Steps unterstützt komplexe Workflows, indem es Entwickler(inne)n ermöglicht, Eingaben und Ausgaben für einen CI/CD-Job zu erstellen. Mit dem CI/CD-Katalog und CI/CD Steps können DevSecOps-Teams CI/CD und seine Komponenten einfach standardisieren und so die Entwicklung und Pflege von CI/CD-Pipelines vereinfachen.\n\n> Weitere Informationen findest du in unseren [CI/CD-Katalog-FAQ](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) und der [Dokumentation für CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/) (beide nur in englischer Sprache verfügbar).\n\n### Problembehebung für Pipelines mithilfe von KI\n\nCI/CD-Pipelines können zwar ab und zu ausfallen, aber eine schnelle Problembehebung kann die Auswirkungen minimieren. GitLab Duo Root Cause Analysis, schafft als Teil eines Programmpakets KI-basierter Funktionen Klarheit, indem es [die Grundursache für eine defekte CI/CD-Pipeline ermittelt](https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/) (Blogbeitrag nur in englischer Sprache verfügbar). Wenn eine Pipeline fehlschlägt, stellt GitLab detaillierte Job-Protokolle, Fehlermeldungen und Ausführungsverläufe bereit, die genau zeigen, wo und warum der Fehler aufgetreten ist. Root Cause Analysis schlägt dann mithilfe von KI eine Lösung vor.\nSieh dir GitLab Duo Root Cause Analysisin Aktion an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## So migrierst zu GitLab CI/CD\n\nFür die Migration auf die DevSecOps-Plattform und ihr integriertes CI/CD ist ein systematischer Ansatz nötig, um deine vorhandene Pipeline-Konfigurationen, Abhängigkeiten und Bereitstellungsprozesse zu analysieren und dann den entsprechenden Funktionen und der Syntax von GitLab zuzuordnen. Die folgenden englischsprachigen Anleitungen sollen dir den Einstieg erleichtern.\n\n* [So migrierst du von Bamboo zu GitLab CI/CD](https://about.gitlab.com/blog/migrating-from-bamboo-to-gitlab-cicd/)\n* [Von Jenkins zu GitLab: der ultimative Leitfaden zur Modernisierung deiner CI/CD-Umgebung](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n* [Einfache Migration von GitHub zu GitLab](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n\n## Erfahrungsberichte von führenden Unternehmen\n\nDiese führenden Unternehmen sind zu GitLab migriert und profitieren von den unzähligen Vorteilen von CI/CD. Lies ihre Stories.\n\n- [Lockheed Martin](https://about.gitlab.com/de-de/customers/lockheed-martin/)\n- [Indeed](https://about.gitlab.com/de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab/)\n- [CARFAX](https://about.gitlab.com/de-de/customers/carfax/)\n- [HackerOne](https://about.gitlab.com/de-de/customers/hackerone/)\n- [Betstudios](https://about.gitlab.com/blog/betstudios-cto-on-improving-ci-cd-capabilities-with-gitlab-premium/) (nur in englischer Sprache verfügbar)\n- [Thales und Carrefour](https://about.gitlab.com/blog/how-carrefour-and-thales-are-evolving-their-ci-cd-platforms/) (nur in englischer Sprache verfügbar)\n\n## CI/CD-Tutorials\n\nWerde mit diesen einfach verständlichen Tutorials zum CI/CD-Profi. (Die Tutorials sind im Moment nur in englischer Sprache verfügbar.)\n\n* [Grundlagen von CI: So führst du Jobs sequenziell, parallel oder unregelmäßig aus](https://about.gitlab.com/blog/basics-of-gitlab-ci-updated/)\n* [So richtest du deine erste CI/CD-Komponente mit GitLab ein](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n* [Einfacher Aufbau einer CI/CD-Pipeline mit GitLab für ein Monorepo](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n* [Verwendung von untergeordneten Pipelines für die kontinuierliche Bereitstellung in fünf Umgebungen](https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/)\n* [CI/CD-Automatisierung: Maximiere die Auswirkungen eines Bereitstellungsstopps auf GitLab-Gruppen](https://about.gitlab.com/blog/ci-cd-automation-maximize-deploy-freeze-impact-across-gitlab-groups/)\n* [Refaktorisierung einer CI/CD-Vorlage zu einer CI/CD-Komponente](https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component/)\n* [Kommentiere Container-Images mit Build-Provenienz mithilfe von Cosign in GitLab CI/CD](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd)\n\n> #### Erste Schritte mit GitLab CI/CD. [Registriere dich für GitLab Ultimate](https://gitlab.com/-/trials/new) und teste die KI-basierte DevSecOps-Plattform kostenlos.",[9,842,684,683,1045,685],"security","2025-05-08",{"slug":1048,"featured":91,"template":690},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation","content:de-de:blog:ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","Ultimate Guide To Ci Cd Fundamentals To Advanced Implementation","de-de/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","de-de/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"_path":1054,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1055,"content":1061,"config":1071,"_id":1073,"_type":14,"title":1074,"_source":16,"_file":1075,"_stem":1076,"_extension":19},"/de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"title":1056,"description":1057,"ogTitle":1056,"ogDescription":1057,"noIndex":6,"ogImage":1058,"ogUrl":1059,"ogSiteName":672,"ogType":673,"canonicalUrls":1059,"schema":1060},"Ultimativer Leitfaden für die Migration von AWS CodeCommit zu GitLab","In diesem umfassenden Tutorial erfährst du, wie du von AWS Services zu GitLab migrieren und die DevSecOps-Plattform nahtlos integrieren kannst. ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097810/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2828%29_4mi0l4wzUa5VI4wtf8gInx_1750097810027.png","https://about.gitlab.com/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ultimativer Leitfaden für die Migration von AWS CodeCommit zu GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"},{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"},{\"@type\":\"Person\",\"name\":\"Bart Zhang\"}],\n        \"datePublished\": \"2024-08-26\",\n      }\n                  ",{"title":1056,"description":1057,"authors":1062,"heroImage":1058,"date":1067,"body":1068,"category":685,"tags":1069,"updatedDate":1070},[1063,1064,1065,1066],"Tsukasa Komatsubara","Darwin Sanoy","Samer Akkoub","Bart Zhang","2024-08-26","Am 25. Juli 2024 hat AWS eine wichtige Ankündigung in Bezug auf den CodeCommit-Service des Unternehmens veröffentlicht. Wie in ihrem [offiziellen Blogbeitrag](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/) beschrieben, hat AWS beschlossen, Neukund(inn)en den Zugriff auf CodeCommit zu entziehen. Bestehende Kund(inn)en können den Service zwar weiterhin nutzen, aber AWS führt keine neuen Funktionen mehr ein und konzentriert sich nur noch auf die Verbesserung von Sicherheit, Verfügbarkeit und Leistung.\n\nDiese Ankündigung hat Entwicklerteams dazu veranlasst, eine Migration ihrer Repositorys zu alternativen Git-Anbietern in Betracht zu ziehen. Angesichts dieser Änderungen haben wir diese umfassende Anleitung erstellt, um Teams bei der Migration zu GitLab und der Integration mit anderen AWS-Services zu unterstützen.\n\n**Hinweis:** Weitere Einzelheiten zu den offiziellen Migrationsempfehlungen von AWS findest du im [entsprechenden Blogbeitrag](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/).\n\n## Über diesen Leitfaden\n\nDieser Leitfaden enthält umfassende Informationen für Entwicklungsteams, die GitLab nutzen und eine Integration mit AWS-Services in Betracht ziehen oder eine Migration von AWS-gehosteten Git-Repositories zu GitLab.com planen. Der Leitfaden ist in drei Hauptabschnitte unterteilt:\n\n- [Parallele Migration zu GitLab](#section-1-parallel-migration-to-gitlab): Beschreibt die schrittweise Migration vorhandener, in AWS gehosteter Repositories zu GitLab.com bei gleichzeitiger Minimierung von Risiken.\n\n- [Integration mit AWS CodeBuild](#section-2-integrating-gitlab-with-aws-codebuild): Beschreibt die Schritte zur Integration von GitLab-Repositories mit AWS CodeBuild und zur Einrichtung einer leistungsstarken Umgebung mit kontinuierlicher Integration.\n\n- [Integration mit AWS CodePipeline](#section-3-integrating-gitlab-with-aws-codepipeline): Enthält Details zur Verbindung von GitLab-Repositories mit AWS CodePipeline, um effiziente Pipelines für kontinuierliche Lieferung zu erstellen.\n\n- [Downstream-Integrationen für CodePipeline- und CodeStar-Verbindunge](#section-4-migrating-to-gitlab): Beschreibt die Nutzung von GitLab-AWS-Verbindungen für umfassende Servicezugriffe mit zahlreichen Integrationsmöglichkeiten im gesamten AWS-Ökosystem.\n\nIn dieser Anleitung erfährst du, wie du die leistungsstarken Funktionen von GitLab und AWS kombinieren kannst, um einen effizienten und flexiblen Entwicklungs-Workflow zu erstellen.\n\n## Abschnitt 1: Parallele Migration zu GitLab \n\nWenn du vorhast, Git-Repositories, die auf AWS gehostet werden, auf GitLab.com zu migrieren, findest du in diesem Abschnitt eine Anleitung für eine schrittweise Migration, die die Risiken minimiert. Mit den Mirroring-Funktionen von GitLab kannst du bestehende Entwicklungsabläufe beibehalten und gleichzeitig die neue Umgebung testen.\n\n### Warum ist die parallele Migration wichtig?\n\nUmfangreiche Systemmigrationen sind immer mit Risiken verbunden, insbesondere mit potenziellen Auswirkungen auf die laufende Entwicklungsarbeit, bestehende Integrationen und automatisierte Prozesse. Ein paralleler Migrationsansatz bietet die folgenden Vorteile:\n\n1. Risikominimierung: Teste die neue Umgebung, während bestehende Systeme betriebsbereit bleiben.\n2. Nahtloser Übergang: Entwicklungsteams können sich allmählich an das neue System gewöhnen.\n3. Integrationstests: Teste alle Integrationen und Automatisierungen in der neuen Umgebung gründlich.\n4. Zukunftsfähigkeit: Ermögliche es den Teams, schrittweise auf GitLab CI/CD zu migrieren, parallel zur bestehenden CI.\n\nEine parallele Migration ist nicht erforderlich, wenn du bereits weißt, dass du direkt zu GitLab wechseln möchtest.\n\n### Schritte für die Migration zu GitLab.com\n\n#### Schritt 1: Einrichtung auf GitLab.com\n\n- Überprüfe, ob dein Unternehmen bereits eine Gruppe auf GitLab.com besitzt und ob Single Sign-On (SSO) eingerichtet ist. Wenn ja, solltest du nach Möglichkeit beides verwenden.\n\n- Wenn dein Unternehmen noch nicht auf GitLab.com vertreten ist, besuche [GitLab.com](www.gitlab.com) und erstelle ein neues Konto oder melde dich bei einem bestehenden Konto an.\n- Erstelle einen neuen Unternehmens-Namensraum (eine Gruppe auf der Stammebene von gitlab.com).\n- Wähle einen Namen, der dein gesamtes Unternehmen widerspiegelt (und noch nicht vergeben ist).\n\n#### Schritt 2: Repository importieren\nBei paralleler Migration: Verwende die Pull-Mirroring-Funktion von GitLab, um Änderungen von in AWS gehosteten Repositories automatisch mit GitLab.com zu synchronisieren.\n\n1. Gehe zur Zielgruppe auf GitLab.com.\n2. Klicke oben rechts auf „Neues Projekt“.\n3. Klicke auf der Seite „Neues Projekt erstellen“ auf „Projekt importieren“.\n4. Klicke auf der Seite „Projekt importieren“ auf „Repository nach URL“.\n5. Gib die URL deines in AWS gehosteten Repositorys in das Feld „Git-Repository-URL“ ein.\n6. Aktiviere unter dem Feld „Git-Repository-URL“ die Option „Repository spiegeln“.\n7. Authentifizierung einrichten: Wähle in der AWS-CodeCommit-Konsole die Klon-URL für das Repository aus, das du migrieren möchtest. Wenn du CodeCommit-Repositories in GitLab importieren möchtest, kannst du die HTTPS-CodeCommit-URL verwenden, um das Repository über die GitLab-Repository-Spiegelung zu klonen. Außerdem musst du deine Git-Zugangsdaten von AWS für deinen IAM-Benutzer (Identity and Access Management) in GitLab angeben. Du kannst Git-Zugangsdaten für AWS CodeCommit erstellen, indem du dieser [AWS-Anleitung](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) folgst.\n\n![Klon-URL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/clone-url-screenshot__1__aHR0cHM6_1750097822121.png)\n\nMit dieser Einrichtung werden Änderungen aus dem von AWS gehosteten Repository automatisch alle fünf Minuten auf GitLab.com übertragen.\n\nWeitere Informationen findest du in unserer [Dokumentation zur Repository-Spiegelung](https://docs.gitlab.com/ee/user/project/repository/mirror/).\n\n#### Schritt 3: Integrationen testen und validieren\n\n1. CI/CD-Pipelines: Richte die Datei `.gitlab-ci.yml` in GitLab CI ein, um vorhandene Pipelines zu replizieren. Weitere Informationen zur [Planung einer Migration von anderen CI-Tools nach GitLab CI/CD](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html).\n2. Ticketverfolgung: Importiere Projekt-Tickets und teste Workflows.\n3. Code Review: Richte den Merge-Request-Prozess ein und teste die Review-Workflows.\n#### Schritt 4: Schrittweise Migration\n\n1. Beginne mit kleinen oder unkritischen Projekten, um dich mit der Arbeit auf GitLab.com vertraut zu machen.\n2. Biete Schulungen für Teammitglieder an und plane Zeit für die Anpassung an neue Workflows ein.\n3. Migriere nach und nach weitere Projekte und stelle dabei sicher, dass die Integrationen und Workflows problemlos funktionieren.\n\nWeitere Informationen findest du unter [Automatisieren von Migrationen von CodeCommit nach GitLab](https://gitlab.com/guided-explorations/aws/migrating-from-codecommit-to-gitlab/-/blob/main/migrating_codecommit_to_gitlab.md).\n\n#### Schritt 5: Migration abschließen\nWenn alle Tests und Validierungen abgeschlossen sind und das Team mit der neuen Umgebung vertraut ist, kannst du die vollständige Migration planen. Gehe für jedes Projekt wie folgt vor:\n\n1. Lege ein Migrationsdatum fest und benachrichtige alle Stakeholder.\n2. Führe die abschließende Datensynchronisierung durch.\n3. Entferne die Spiegelungseinstellungen aus dem GitLab-Projekt.\n4. Lege in AWS gehostete Repositories als schreibgeschützt fest und übertrage alle Entwicklungsarbeiten nach GitLab.com.\n\n#### Schritt 6: Bewerten der Akzeptanz der neuen Funktionen\n\nDie Zusammenarbeit in GitLab und die Automatisierung von Workflows für Entwickler(innen) sind weitaus umfangreicher als in CodeCommit. Nimm dir etwas Zeit, um diese Fähigkeiten kennenzulernen. Der Merge-Request-Prozess ist im Vergleich zu CodeCommit besonders vielseitig.\n\nWenn die Repositories auf GitLab stabil sind, kannst du GitLab CI/CD mühelos parallel zu einer vorhandenen Lösung ausprobieren. Die Teams können sich Zeit nehmen, um ihre GitLab-CI/CD-Automatisierung zu optimieren, ohne dass die Produktions-Workflows davon betroffen sind.\n\nAuch die Artefaktverwaltung von GitLab ist mit der Release-Funktion und vielen Paketregistrierungen sehr leistungsfähig.\n\n### Abschnitt 1: Zusammenfassung\nMit einem parallelen Migrationsansatz zu GitLab kannst du einen reibungslosen Übergang erreichen und gleichzeitig die Risiken minimieren. Mit diesem Prozess können sich Teams schrittweise an die neue Umgebung anpassen und sicherstellen, dass alle Integrationen und Automatisierungen ordnungsgemäß funktionieren. Bei der Übernahmemigration wird nur ein einziges Kontrollkästchen ausgelassen, wenn bekannt ist, dass eine parallele Migration nicht notwendig ist.\n\n## Abschnitt 2: Integration von GitLab mit AWS CodeBuild\n\nWenn du Code aus GitLab-Repositories mit AWS CodeBuild erstellen und testen möchtest, hilft dir diese umfassende Anleitung beim Einrichten einer effizienten CI-Pipeline.\n\n### Voraussetzungen\n\n- GitLab.com-Konto\n- AWS-Konto\n- AWS CLI (konfiguriert)\n\n### Schritt 1: GitLab-Verbindung in AWS CodeStar-Verbindungen erstellen\n\n1. Melde dich in der AWS-Managementkonsole an und navigiere zum CodeBuild-Service.\n2. Wähle in der linken Navigationsleiste „Einstellungen“ > „Verbindungen“ aus.\n3. Klicke auf die Schaltfläche „Verbindung erstellen“.\n4. Wähle „GitLab“ als Anbieter aus.\n5. Gib einen Verbindungsnamen ein und klicke auf „Mit GitLab verbinden“.\n6. Daraufhin wirst du zur GitLab-Authentifizierungsseite weitergeleitet.\n7. Erteile die erforderlichen Berechtigungen.\n8. Nach erfolgreichem Abschluss ändert sich der Verbindungsstatus in „Verfügbar“.\n\n![CodeStar-Connect-Einrichtung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Schritt 2: AWS-CodeBuild-Projekt erstellen\n\n1. Klicke im CodeBuild-Dashboard auf „Build-Projekt erstellen“.\n2. Gib einen Projektnamen und eine Beschreibung ein.\n3. Wähle in den Quelleneinstellungen „GitLab“ als Anbieter aus.\n4. Wähle die soeben erstellte Verbindung aus und gib das GitLab-Repository und den Branch an.\n\n![CodeBuild-Projekt hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_3_add_codebuild_aHR0cHM6_1750097822123.png)\n\n**Hinweis: Konfiguriere ab Schritt 3 die Einstellungen für deine spezifische Umgebung und deine Anforderungen.**\n\n### Zusammenfassung von Abschnitt 2\nIn diesem Abschnitt wurde ausführlich beschrieben, wie du GitLab-Repositories in AWS CodeBuild integrieren kannst. Diese Einrichtung ermöglicht eine kontinuierliche Integrationspipeline, bei der Codeänderungen in GitLab automatisch mit AWS CodeBuild erstellt und getestet werden.\n\n## Abschnitt 3: GitLab mit AWS CodePipeline integrieren\n\nWenn du die kontinuierliche Lieferung von GitLab-Repositories mit AWS CodePipeline implementieren möchtest, wird dir diese detaillierte Anleitung helfen. Die Integration ist jetzt noch einfacher geworden, da GitLab als AWS-CodeStar-Connections-Anbieter verfügbar ist.\n\n### Voraussetzungen\n\n- GitLab.com-Konto\n- AWS-Konto\n- AWS CLI (konfiguriert)\n\n### Schritt 1: GitLab-Verbindung in AWS CodeStar-Verbindungen erstellen\n\n1. Melde dich in der AWS-Managementkonsole an und navigiere zum CodePipeline-Service.\n2. Wähle in der linken Navigationsleiste „Einstellungen“ > „Verbindungen“ aus.\n3. Klicke auf die Schaltfläche „Verbindung erstellen“.\n4. Wähle „GitLab“ als Anbieter aus.\n5. Gib einen Verbindungsnamen ein und klicke auf „Mit GitLab verbinden“.\n6. Daraufhin wirst du zur GitLab-Authentifizierungsseite weitergeleitet.\n7. Erteile die erforderlichen Berechtigungen.\n8. Nach erfolgreichem Abschluss ändert sich der Verbindungsstatus in „Verfügbar“.\n\n![CodeStar Connections einrichten](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Schritt 2: AWS CodePipeline erstellen\n\n1. Klicke im CodePipeline-Dashboard auf „Pipeline erstellen“.\n2. Gib einen Pipeline-Namen ein und klicke auf „Weiter“.\n3. Wähle „GitLab“ als Quellenanbieter aus.\n4. Wähle die soeben erstellte Verbindung aus und gib das GitLab-Repository und den Branch an.\n5. Wähle den Triggertyp aus: Du kannst die Ausführung der CodePipeline-Pipeline anhand von Pull- oder Push-Ereignissen für bestimmte Branches und Dateitypen in deinem Repository auslösen.\n\n![Quellenanbieter hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822125.png)\n\n![Quellkonfiguration hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_provider_aHR0cHM6_1750097822127.png)\n\n**Hinweis: Konfiguriere ab Schritt 3 die Einstellungen für deine spezifische Umgebung und deine Anforderungen.**\n\n### Zusammenfassung von Abschnitt 3\nIn diesem Abschnitt wurde beschrieben, wie du GitLab-Repositories in die AWS CodePipeline integrierst. Diese Einrichtung ermöglicht eine CD-Pipeline, bei der Codeänderungen in GitLab automatisch in deiner AWS-Umgebung bereitgestellt werden.\n\n## Abschnitt 4: Migration zu GitLab\n\nDie Integration von GitLab in AWS eröffnet dir leistungsstarke Möglichkeiten zur Optimierung deiner Entwicklungs- und Bereitstellungs-Workflows und hilft dir, deine Probleme bei der Quellcodeverwaltung zu lösen. Diese Integration kann auf verschiedene Arten erreicht werden, die jeweils einzigartige Vorteile bieten:\n\n- Wenn du AWS-CodeStar-Verbindungen verwendest, um GitLab mit AWS-Services zu verknüpfen, erhältst du einen kohärenten Workflow, da du externe Git-Repositories wie GitLab mit verschiedenen AWS-Services verbinden kannst. Diese Einrichtung unterstützt automatisierte Builds, Bereitstellungen und andere wichtige Aktionen direkt von deinem GitLab-Repository aus und macht deinen Entwicklungsprozess integrierter und effizienter.\n\n- Die Verbindung von GitLab mit AWS CodePipeline über AWS CodeStar Connections treibt die Automatisierung voran und ermöglicht es dir, eine vollständige CI/CD-Pipeline zu erstellen. Dieser Ansatz integriert GitLab mit AWS CodePipeline und ermöglicht es dir, den gesamten Prozess – von der Quellcodeverwaltung über Builds bis hin zu Tests und Bereitstellung – mit AWS-Services wie CodeBuild und CodeDeploy zu automatisieren. So wird ein robuster, skalierbarer und effizienter Bereitstellungsprozess gewährleistet.\n\n![Diagramm neuer Technologien und Lösungen für die gemeinsame Nutzung von GitLab und AWS](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_configured_aHR0cHM6_1750097822129.png)\n\n1\\. Verbindung von GitLab mit AWS-Services über AWS CodeStar Connections\n\nAWS CodeStar Connections ist ein Service, mit dem du externe Git-Repositories (wie GitHub oder Bitbucket) mit den AWS-Services verbinden kannst. Du kannst GitLab auch über CodeStar Connections mit AWS-Services verbinden. Wenn du GitLab verwendest, musst du möglicherweise eine benutzerdefinierte Verbindung als HTTP-Git-Server einrichten.\nDie folgenden AWS-Services können mit dieser Methode mit GitLab verbunden werden:\n\n- **AWS Service Catalog **\n\nDer AWS Service Catalog hilft Unternehmen bei der Standardisierung und Verwaltung von AWS-Ressourcen. Die Integration mit GitLab verbessert die Transparenz beim Ressourcenmanagement und vereinfacht die Nachverfolgung von Änderungen. Insbesondere kannst du Katalogaktualisierungen auf der Grundlage von GitLab-Commits automatisieren und so die Effizienz deines Vorgangs verbessern.\n\n- __AWS CodeBuild__\n\nAWS CodeBuild ist ein verwalteter Build-Service, der Quellcode kompiliert, Tests durchführt und bereitstellbare Softwarepakete erstellt. Die Integration von GitLab mit CodeBuild ermöglicht es, automatisierte Build-Prozesse zu starten, wenn Codeänderungen an GitLab übertragen werden. Dies garantiert einheitliche Builds und erleichtert die Zusammenarbeit und Versionskontrolle.\n\n- __AWS Glue Notebook Jobs__\n\nAWS Glue Notebook Jobs ist ein Service, mit dem du interaktiv Datenaufbereitungs- und ETL-Aufgaben (Extract, Transform, Load) entwickeln und ausführen kannst. Die Integration von GitLab mit Glue Notebook Jobs ermöglicht die Versionskontrolle für Notebooks und ETL-Skripte, fördert die Zusammenarbeit zwischen Teammitgliedern und verbessert das Qualitätsmanagement von Datenverarbeitungs-Pipelines.\n\n- __AWS Proton__\n\nAWS Proton ist ein Service, der die Entwicklung und Bereitstellung von Microservices und serverlosen Anwendungen automatisiert. Durch die Integration von GitLab mit AWS Proton kannst du Infrastructure as Code verwalten, Bereitstellungen automatisieren und ein konsistentes Umgebungsmanagement sicherstellen, was zu effizienteren Entwicklungsprozessen führt.\n\nWenn AWS CodeStar Connections in Zukunft mehr Dienste unterstützen, wird es immer einfacher, GitLab mit zusätzlichen AWS-Services zu verbinden. Du solltest regelmäßig prüfen, ob es neue Services gibt, die CodeStar Connections unterstützen.\n\n2. Verbindung von CodePipeline mit GitLab über AWS CodeStar Connections (einschließlich CodeDeploy)\n\nAWS CodePipeline ist ein kontinuierlicher Bereitstellungsdienst, der den Freigabeprozess für Software automatisiert. Um GitLab mit CodePipeline zu verbinden, musst du AWS CodeStar Connections verwenden. Mit dieser Einrichtung kannst du ein GitLab-Repository als Quelle festlegen und die gesamte CI/CD-Pipeline automatisieren.\nBeispiele für wichtige Aktionen, die CodePipeline unterstützt:\n- **Quellcode-Kontrolle:** AWS CodeCommit, GitHub, Bitbucket, GitLab\n- **Erstellen und Testen:** AWS CodeBuild, Jenkins\n- **Bereitstellen:** AWS CodeDeploy, Elastic Beanstalk, ECS, S3\n- **Genehmigen:** Manuelle Genehmigung\n- **Infrastruktur-Management:** AWS CloudFormation\n- **Serverlos:** AWS Lambda\n- **Tests:** AWS Device Farm\n- **Benutzerdefinierte Aktionen:** AWS Step Functions\n\nDurch die Integration von GitLab mit CodePipeline kannst du die Pipeline automatisch auslösen, wenn Codeänderungen nach GitLab gepusht werden, um einen konsistenten Prozess vom Build bis zur Bereitstellung sicherzustellen. In Kombination mit den Versionskontrollfunktionen von GitLab ist es außerdem einfacher, den Verlauf und die Zustände der Bereitstellung zu verfolgen, was zu einer flexibleren und zuverlässigeren Softwarebereitstellung führt.\n\n## Das hast du gelernt\nDiese Anleitung enthält umfassende Informationen über die Migration zu und die Integration von GitLab in AWS. In den vier Abschnitten haben wir Folgendes behandelt:\n- Parallele Migration zu GitLab: Wie du schrittweise von bestehenden, bei AWS gehosteten Repositories zu GitLab.com migrierst und dabei die Risiken minimierst.\n- Integration mit AWS CodeBuild: Schritte zum Einrichten einer leistungsstarken CI-Umgebung, die mit GitLab-Repositories integriert ist.\n- Integration mit AWS CodePipeline: Wie du effiziente Continuous-Delivery-Pipelines mit GitLab-Repositories aufbaust.\n- Nachgelagerte Integrationen für CodePipeline und CodeStar Connections: Die Nutzung von GitLab-AWS-Verbindungen für einen weitreichenden Service-Zugang, wodurch eine Reihe von Integrationsmöglichkeiten im gesamten AWS-Ökosystem entstehen.\n\nDa die Code-Hosting- und Integrationsstrategie jedes Unternehmens einzigartig ist, kannst du dieses Tutorial als Ausgangspunkt für deine eigene GitLab- und AWS- Integrations- und Implementierungsstrategie nutzen.\n\n## Zusätzliche Ressourcen\n\nWeitere Informationen und erweiterte Konfigurationen findest du in den folgenden Ressourcen:\n\n- [GitLab-Dokumentation](https://docs.gitlab.com/)\n- [AWS-CodeBuild-Benutzerhandbuch](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)\n- [AWS-CodePipeline-Benutzerhandbuch](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)\n- [GitLab-CI/CD-Dokumentation](https://docs.gitlab.com/ee/ci/)\n- [Integration mit AWS](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_integration.html)\n\nWenn du Fragen hast oder Unterstützung benötigst, wende dich bitte an den [GitLab-Support](https://about.gitlab.com/support/) oder den AWS-Support. Wir hoffen, dass dir diese umfassende Anleitung bei deiner AWS-GitLab-Integration hilft",[9,682,684,683,686,685,233],"2024-11-27",{"slug":1072,"featured":91,"template":690},"ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","content:de-de:blog:ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","Ultimate Guide To Migrating From Aws Codecommit To Gitlab","de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"_path":1078,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1079,"content":1085,"config":1095,"_id":1097,"_type":14,"title":1098,"_source":16,"_file":1099,"_stem":1100,"_extension":19},"/de-de/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"ogTitle":1080,"schema":1081,"ogImage":1082,"ogDescription":1083,"ogSiteName":672,"noIndex":6,"ogType":673,"ogUrl":1084,"title":1080,"canonicalUrls":1084,"description":1083},"Konfigurationsmanagement mit GitLab und Ansible | Ein Leitfaden","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Konfigurationsmanagement mit GitLab und Ansible\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brad Downey\"},{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-07-01\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665322/Blog/Hero%20Images/gitlab-ansible-cover.png","Wir zeigen dir, wie das Konfigurationsmanagement mit GitLab und Ansible funktioniert! ✓ Definition ✓ Einstellungen ✓ Anleitung ✓ Demo ➤Jetzt Tutorial lesen!","https://about.gitlab.com/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"title":1086,"description":1087,"authors":1088,"heroImage":1082,"date":1091,"body":1092,"category":680,"tags":1093},"Konfigurationsmanagement mit GitLab und Ansible","Entdecke die beeindruckende Leistungsfähigkeit von GitLab CI, wenn es darum geht, Ansible-Playbooks im Rahmen von Infrastructure as Code umzusetzen.",[1089,1090],"Brad Downey","Sara Kassabian","2019-07-01","[GitLab CI](https://about.gitlab.com/de-de/solutions/continuous-integration/\n\"GitLab CI\") ist ein vielseitiges Tool, das für eine Vielzahl von\nAufgabenbereichen wie [Infrastructure as\nCode](https://about.gitlab.com/topics/gitops/infrastructure-as-code/\n\"Infrastructure as Code\") und\n[GitOps](https://about.gitlab.com/de-de/topics/gitops/ \"GitOps\") eingesetzt\nwerden kann. Eine der Eigenschaften von GitLab ist seine Unabhängigkeit von\nspezifischen Tools. In dieser Demonstration liegt der Fokus auf Ansible, da\nviele Entwickler(innen) dieses Tool für Konfigurationsmanagement bevorzugen.\n\n\n## Was ist Ansible?\n\n\nAnsible ist ein Open-Source-Automatisierungstool, das für die Bereitstellung, Konfiguration und Verwaltung von Computersystemen genutzt wird. Es gehört zur Kategorie der Konfigurationsmanagement-Tools. Entwickler(innen) und Systemadministrator(inn)en können damit komplexe, wiederholbare Prozesse wie Serverkonfiguration, Anwendungsbereitstellung und Netzwerkgerätemanagement automatisieren. Ansible verwendet YAML, um deklarative Aufgabenbeschreibungen zu erstellen, bekannt als Playbooks. Diese beschreiben den gewünschten Systemzustand, den Ansible durch SSH-Verbindungen zu den Zielhosts erreicht, um Befehle auszuführen.\n\n\n## Demo: GitLab CI und Ansible\n\n\nEine Funktion von GitLab CI ist die Möglichkeit, den Code aus dem Ansible-Playbook zu bearbeiten und bereitzustellen, ohne lokale Abhängigkeiten zu installieren. So kann das Demo-Projekt, das eine monatliche Aktualisierung der SNMP-Strings auf allen Geräten gemäß unseren Sicherheitsrichtlinien erfordert, problemlos auf [GitLab.com](https://about.gitlab.com/de-de/pricing/ \"GitLab Pricing\") durchgeführt werden.\n\n\nBeginnen Sie, indem Sie das Ansible-Playbook öffnen, das vier Aufgaben beinhaltet:\n\n\n- Erfassen der Router-Fakten\n\n- Anzeigen der Version\n\n- Anzeigen der Seriennummer\n\n- Konfigurieren von SNMP\n\n\nDer Schwerpunkt dieser Demo liegt auf der Konfiguration der SNMP-Strings, die in einer einfachen Reihe von Schritten durchgeführt werden kann.\n\n\n## Zu Beginn: das Issue Board\n\n\nJeder Plan bei GitLab beginnt an derselben Stelle: mit einem Problem. Der erste Schritt im GitLab-Workflows besteht darin, das Issue Board des [„ansible-demo“-Projekts (auf Englisch)](https://gitlab.com/bdowney/ansible-demo/-/boards \"ansible-demo\") zu überprüfen. Dort sehen wir bereits ein Issue zur Änderung der SNMP-Strings auf allen Routern. Das Issue verweist auf das GitLab-Sicherheitsrichtlinien-Wiki, das besagt, dass SNMP-Strings monatlich geändert werden müssen und unterschiedliche Strings für „read-only“ und „read-write“ erforderlich sind.\n\n\n![Security policies](https://about.gitlab.com/images/blogimages/ansible_screenshots/security_policies_1A.png){: .shadow.medium.center}\n\n\nGemäß unserer GitLab-Sicherheitsrichtlinien müssen die SNMP-Strings monatlich aktualisiert werden. Als Nächstes prüfst du, ob die Befehle zur Konfiguration der SNMP-Strings in der [Zwei-Router-Demo (auf Englisch)](https://gitlab.com/bdowney/ansible-demo/blob/master/ci-cd-demo/ci.yml \"Zwei-Router-Demo\") den in diesem Issue beschriebenen GitLab-Sicherheitsrichtlinien entsprechen.\n\n\n![Ansible SNMP change](https://about.gitlab.com/images/blogimages/ansible_screenshots/ansible_snmp_change_2.png){: .shadow.medium.center}\n\n\nDie Befehle zur Konfiguration der SNMP-Strings findest du im Ansible-Playbook.\n\n\nGeh danach zurück zum Issue und weise es dir selbst zu. Ändere in der rechten Seitenleiste des Issues oder indem du es zwischen den Spalten des Issue Boards von „to-do“ auf „doing“ ziehst.\n\n\n## Merge Request erstellen\n\n\nAls Nächstes erstellst du einen Merge Request (MR) für das Issue. Stelle sicher, dass du das Kennzeichen „Draft“ deinem MR hinzufügst, damit er nicht vorzeitig mit dem Master zusammengeführt wird. Statt eine lokale Verbindung herzustellen, nutze die Web IDE von GitLab, da die Änderungen an den SNMP-Strings minimal sind. \n\n\n- Öffne den CI/CD-Demo-Bereich\n\n- Rufe das Ansible-Playbook auf\n\n- Bearbeite den SNMP-Abschnitt wie folgt:\n\n```\n\n-snmp-server community New-SNMP-DEMO1 RO\n\n\n-snmp-server community Fun-SNMP-RW-STR RW\n\n```\n\n- Achte darauf, dass read-only (RO) und read-write (RW) auf unterschiedliche Strings gemäß den GitLab-Sicherheitsrichtlinien gesetzt sind, wie sie im Issue beschrieben werden.\n\n\n## Änderungen übertragen\n\n\nNachdem du den SNMP-String gemäß den Richtlinien aktualisiert hast, committe die Änderungen. Öffne den Seite-an-Seite-Vergleich der Änderungen, um zu sehen, dass der MR mit deinem letzten Commit aktualisiert wurde.\n\n\n![Commit changes](https://about.gitlab.com/images/blogimages/ansible_screenshots/side-by-side_3.png){: .shadow.medium.center}\n\n\nDer Seite-an-Seite-Vergleich ist eine einfache Möglichkeit, deine Änderungen zu visualisieren.\n\n\n## Ausgabe des Merge-Request\n\n\nDurch den Commit der Änderungen wird automatisch eine GitLab CI-Pipeline gestartet. Diese führt beispielsweise folgende Aufgaben durch:\n\n\n- Syntaxprüfung\n\n- Dry Run\n\n- Testen der Änderungen in einer Labor-/Simulationsumgebung\n\n\nDu kannst den Fortschritt und die Ausgabe jedes Auftrags in der GitLab-CI-Pipeline anzeigen, um die SNMP-Aktualisierungen durchzuführen.\n\n\n![Job running](https://about.gitlab.com/images/blogimages/ansible_screenshots/job_running_4.png){: .shadow.medium.center}\n\n\nSchau dir die Ergebnisse deines Auftrags an, die zeigen, dass die SNMP-Aktualisierungen in der simulierten Umgebung erfolgreich waren. Alle diese Aufgaben werden im Merge Request durchgeführt und dokumentiert.\n\n\n![Pipeline](https://about.gitlab.com/images/blogimages/ansible_screenshots/pipeline_5A.png){: .shadow.medium.center}\n\n\nDie grünen Häkchen zeigen an, dass jeder Job in der GitLab CI-Pipeline erfolgreich abgeschlossen wurde. Anschließend kannst du dich auf den Lab-Routern einloggen und die durchgeführten Änderungen sehen.\n\n\n![routers snmp](https://about.gitlab.com/images/blogimages/ansible_screenshots/routersnmp_6.png){: .shadow.medium.center}\n\n\nDie Änderungen an den RO- und RW-SNMP-Strings werden in den Routern berücksichtigt.\n\n\n## MR-Review\n\n\nEine weitere Möglichkeit besteht darin, MR-Approvals zu aktivieren. Dadurch haben mehr Benutzer(innen) die Chance, Änderungen zu überprüfen, bevor sie in die Produktionsumgebung übernommen werden.\n\n\n![approvers](https://about.gitlab.com/images/blogimages/ansible_screenshots/approvers_7.png){: .shadow.medium.center}\n\n\nDu kannst den MR so einstellen, dass eine andere Person deine Arbeit überprüfen muss, bevor sie in den Master-Branch übernommen wird.\n\n\n## Merge in den Master-Branch\n\n\nSobald die Tests abgeschlossen sind, können die Änderungen in den Master-Branch übernommen werden, welcher den Code der Produktionsumgebung enthält.\n\nWenn du bereit bist, klickst du auf die Schaltfläche Mark as ready (Als bereit markieren). Anschließend klickst du auf `Merge`.\n\n\nDurch das Auflösen des WIP-Status kann der MR zusammengeführt und das Issue abgeschlossen werden.\n\n\nNun startet eine neue Pipeline, die alle durchgeführten Tests erneut ausführt, mit dem zusätzlichen Schritt, das Playbook in der Produktionsumgebung auszuführen.\n\n\nDu kannst den Fortschritt und die Protokolle auf dem „Pipelines“-Seite anzeigen. Sobald dieser Prozess abgeschlossen ist, kannst du dich bei deinen Produktionsroutern anmelden und sehen, dass die SNMP-Sicherheitsstrings aktualisiert wurden.\n\n\n## Die Magie von GitLab CI\n\n\nDie Magie, die all dies möglich gemacht hat, ist GitLab CI. GitLab CI-Pipelines sind eine Reihe von aufeinanderfolgenden Aufgaben, die alles ausführen, was du zum Testen und Implementieren deines Ansible-Codes benötigst.\n\n\nGitLab CI wird mit einer einzigen einfachen YAML-Datei konfiguriert, die im Repository unter dem Namen `.gitlab-ci.yml` zu finden ist.\n\nIn dieser Demo siehst du, dass die `.gitlab-ci.yml` Datei drei Schritte beinhaltet:\n\n\n1. Deploy: Damit wird das Zwei-Router-Simulationsnetzwerk in AWS mithilfe von Ansible erstellt.\n\n2. Demo: Damit wird das Playbook ausgeführt, das die SNMP-Strings ändert.\n\n3. Destroy: Hiermit wird das Zwei-Router-Simulationsnetzwerk zerstört.\n\n\nGitLab CI startet mit einem Basis-Image. In diesem Fall verwenden wir ein Docker-Image, das alle erforderlichen Ansible-Binärdateien und Abhängigkeiten enthält. Wir geben die Befehle an, die in jeder Phase ausgeführt werden sollen, und die Abhängigkeiten, soweit erforderlich.\n\n\n![More code](https://about.gitlab.com/images/blogimages/ansible_screenshots/more_code_9A.png){: .shadow.medium.center}\n\n\nEine einfache YAML-Datei enthält die drei Phasen des GitLab-CI.\n\n\n![More Code](https://about.gitlab.com/images/blogimages/ansible_screenshots/more_code_10A.png){: .shadow.medium.center}\n\n\nEin Blick in die Demostufe von GitLab CI, die das Ansible-Playbook ausführt.\n\n\nWenn du dir die Pipelines ansiehst, kannst du sehen, wie GitLab CI verwendet wird, um Konfigurationsmanagement umzusetzen, ohne Ansible auf deinem Computer installieren zu müssen. Dies ist nur ein Beispiel dafür, wie GitLab CI genutzt werden kann, um Infrastruktur als Code auszuführen. Schau dir das Video unten an, um das vollständige Tutorial zu sehen:\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/M-SgRTKSeOg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n## FAQ – Häufig gestellte Fragen\n\n\n### Wie nutze ich den Ansible Tower?\n\n\nAnsible Tower ist eine webbasierte Benutzeroberfläche und eine Enterprise-Ergänzung zu Ansible, die zusätzliche Funktionen zur Automatisierung, Verwaltung und Überwachung von Ansible-Umgebungen bietet. Teams können mit Ansible Tower ihre Automatisierungsprozesse zentralisieren, Zugriffskontrollen verwalten, Zeitpläne für Aufgaben erstellen, Berichte generieren und mehr. Es erleichtert die Skalierung und den Einsatz von Ansible in großen Umgebungen und bietet eine benutzerfreundliche Oberfläche für die Automatisierung von IT-Abläufen.\n\n\n### Was ist der Ansible GitLab Runner?\n\n\nEin Ansible GitLab Runner ist ein integraler Bestandteil des GitLab CI/CD-Ökosystems, der speziell für die Ausführung von Ansible-Playbooks entwickelt wurde. Er ist ein Prozess, der von GitLab genutzt wird, um Jobs in CI/CD-Pipelines auszuführen. Entwickler(innen) können einen GitLab Runner so konfigurieren, dass er Ansible-Playbooks auf den Zielhosts ausführt, was es ermöglicht, die Infrastruktur automatisiert und ohne zusätzliche Ressourcen zu verwalten.\n",[1094,9],"demo",{"slug":1096,"featured":6,"template":690},"using-ansible-and-gitlab-as-infrastructure-for-code","content:de-de:blog:using-ansible-and-gitlab-as-infrastructure-for-code.yml","Using Ansible And Gitlab As Infrastructure For Code","de-de/blog/using-ansible-and-gitlab-as-infrastructure-for-code.yml","de-de/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"_path":1102,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1103,"content":1109,"config":1116,"_id":1118,"_type":14,"title":1119,"_source":16,"_file":1120,"_stem":1121,"_extension":19},"/de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"title":1104,"description":1105,"ogTitle":1104,"ogDescription":1105,"noIndex":6,"ogImage":1106,"ogUrl":1107,"ogSiteName":672,"ogType":673,"canonicalUrls":1107,"schema":1108},"Kontinuierliche Bereitstellung in fünf Umgebungen mithilfe von untergeordneten Pipelines","Erfahre, wie du die kontinuierliche Bereitstellung in verschiedenen Umgebungen – darunter temporäre, sofort einsatzbereite Sandboxes – mit einem minimalistischen GitLab-Workflow verwalten kannst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097012/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750097011626.jpg","https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kontinuierliche Bereitstellung in fünf Umgebungen mithilfe von untergeordneten Pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Olivier Dupré\"}],\n        \"datePublished\": \"2024-09-26\",\n      }",{"title":1104,"description":1105,"authors":1110,"heroImage":1106,"date":1112,"body":1113,"category":680,"tags":1114,"updatedDate":1115},[1111],"Olivier Dupré","2024-09-26","Manchmal brauchen DevSecOps-Teams die Möglichkeit, die kontinuierliche Bereitstellung über mehrere Umgebungen übergreifend zu verwalten, ohne dabei ihre Workflows zu verändern. Die [DevSecOps-Plattform von GitLab](https://about.gitlab.com/de-de/) macht dies mit einem minimalistischen Ansatz möglich, unter anderem für temporäre, sofort einsatzbereite Sandboxes. In diesem Artikel erfährst du, wie du die kontinuierliche Bereitstellung der Infrastruktur mit Terraform in verschiedenen Umgebungen ausführen kannst.\n\nDiese Strategie kann einfach auf andere Projekte umgesetzt werden, egal, ob es sich um Infrastructure as Code (IaC), die auf einer anderen Technologie wie [Pulumi](https://www.pulumi.com/) oder [Ansible](https://www.ansible.com/) basiert, um Quellcode in beliebigen Sprachen oder ein Monorepo handelt, bei dem viele Sprachen gemischt verwendet werden.\n\nDie letzte Pipeline, die du am Ende dieses Tutorials hast, stellt Folgendes bereit:\n\n* Eine temporäre **Review-Umgebung** für jeden Feature-Branch.\n* Eine **Integrationsumgebung**, die einfach zu löschen und vom Haupt-Branch aus bereitzustellen ist.\n* Eine **QA-Umgebung**, die ebenfalls von dem Haupt-Branch bereitgestellt wird, um Qualitätssicherungsschritte durchzuführen.\n* Eine **Staging-Umgebung**, die für jedes Tag bereitgestellt wird. Dies ist die letzte Runde vor der Produktion.\n* Eine **Produktionsumgebung**, die direkt nach der Staging-Umgebung folgt. Diese wird zur Demonstration manuell ausgelöst, kann aber auch kontinuierlich bereitgestellt werden.\n\n>Hier findest du die Legende für die Flussdiagramme in diesem Artikel:\n> * Runde Boxen sind die GitLab-Branches.\n> * Eckige Boxen sind die Umgebungen.\n> * Der Text auf den Pfeilen sind die Aktionen, die von einem Feld zum nächsten fließen sollen.\n> * Eckige Quadrate sind Entscheidungsschritte.\n\n\u003Cpre class=\"mermaid\">\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\nBei jedem Schritt erfährst du das [Warum](#why) und das [Was](#what), bevor du zum [Wie](#how) übergehst. Dies wird dir helfen, dieses Tutorial vollständig zu verstehen und zu replizieren.\n\n## Warum\n\n* [Kontinuierliche Integration](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-integration-ci) ist fast ein De-facto-Standard. Die meisten Unternehmen haben CI-Pipelines implementiert oder sind bereit, ihre Arbeitsweise zu standardisieren.\n\n* [Kontinuierliche Bereitstellung](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-delivery-cd), wobei Artefakte in ein Repository oder eine Registry am Ende der CI-Pipeline gepusht werden, ist ebenfalls beliebt.\n\n* Kontinuierliche Bereitstellung, die weiter geht und diese Artefakte automatisch bereitstellt, ist allerdings weniger verbreitet. Wenn, dann wird sie vor allem im Bereich von Anwendungen implementiert. Wenn es um die kontinuierliche Bereitstellung von Infrastruktur geht, scheint das Bild weniger klar zu sein und es dreht sich vieles um das Management mehrerer Umgebungen. Im Gegensatz dazu scheint das Testen, Sichern und Überprüfen des Infrastruktur-Codes schwieriger zu sein. Dies ist eines der Felder, in denen DevOps noch nicht ausgereift ist. Ein anderer Anwendungsbereich ist, die Sicherheit im Vorfeld zu kontrollieren und Sicherheitsteams sowie – was noch wichtiger ist – Sicherheitsbedenken früher in den Lebenszyklus der Bereitstellung zu integrieren und so von DevOps auf ***DevSecOps*** upzugraden.\n\nAngesichts dessen wirst du in diesem Tutorial eine einfache und doch effiziente Möglichkeit erarbeiten, DevSecOps für deine Infrastruktur zu implementieren, indem du beispielsweise Ressourcen in fünf Umgebungen bereitstellst und dich schrittweise von der Entwicklung bis zur Produktion vorarbeitest.\n\n__Hinweis:__ Auch wenn ich einen FinOps-Ansatz und eine Reduktion der Umgebungen befürworte, gibt es manchmal gute Gründe, mehr als nur Entwicklung, Staging und Produktion aufrechtzuerhalten. Bitte passe die folgenden Beispiele an deine Bedürfnisse an.\n\n## Was\n\nDer Aufstieg der Cloud-Technologie hat die Nutzung von IaC vorangetrieben. Ansible und Terraform gehörten in diesem Bereich zu den Pionieren. OpenTofu, Pulumi, AWS CDK, Google Deploy Manager und viele andere folgten.\n\nIaC gilt als perfekte Lösung, um sich bei der Bereitstellung von Infrastruktur sicher zu fühlen. Du kannst sie testen, bereitstellen und immer wieder abspielen, bis du dein Ziel erreicht hast.\n\nLeider sehen wir oft, dass Unternehmen für jede ihrer Zielumgebungen mehrere Branches oder sogar Repositories unterhalten. Und hier beginnen die Probleme. Sie setzen einen Prozess nicht mehr durch. Sie stellen nicht mehr sicher, dass Änderungen in der Produktions-Codebase in früheren Umgebungen genauestens getestet wurden. Und sie beginnen, Drifts von einer Umgebung in die andere zu erleben.\n\nMir wurde klar, dass dieses Tutorial notwendig war, als auf einer Konferenz alle Teilnehmenden sagten, dass sie keinen Workflow haben, der durchsetzt, dass Infrastruktur genau getestet wird, bevor sie für die Produktion bereitgestellt wird. Und sie waren sich alle einig, dass sie manchmal den Code direkt in die Produktion patchen. Klar geht das schnell, aber ist es auch sicher? Wie meldet man an frühere Umgebungen zurück? Wie stellt man sicher, dass es keine Nebeneffekte gibt? Wie kontrolliert man, ob man das Unternehmen in Gefahr bringt, wenn neue Sicherheitslücken zu schnell in die Produktion gepusht werden?\n\nDie Frage, *warum* DevOps-Teams direkt in die Produktion implementieren, ist hier entscheidend. Liegt es daran, dass die Pipeline effizienter oder schneller sein könnte? Gibt es keine Automatisierung? Oder, noch schlimmer, gibt es *keine Möglichkeit, außerhalb der Produktion genau zu testen*?\n\nIm nächsten Abschnitt erfährst du, wie du Automatisierung für deine Infrastruktur implementieren und sicherstellen kannst, dass dein DevOps-Team effektiv testet, bevor etwas in eine Umgebung gepusht wird, die sich auf andere auswirkt. Du wirst sehen, wie dein Code gesichert und seine Bereitstellung durchgehend kontrolliert wird.\n\n## Wie\n\nWie bereits erwähnt, gibt es heutzutage viele Programmiersprachen für IaC, und wir können ganz einfach nicht *alle* in einem einzigen Artikel behandeln. Ich werde mich also auf einen grundlegenden Terraform-Code konzentrieren, der auf Version 1.4 läuft. Bitte fixiere dich nicht auf die Programmiersprache für IaC selbst, sondern auf den Prozess, den du für dein eigenes Ökosystem umsetzen kannst.\n\n### Der Terraform-Code\n\nBeginnen wir mit einem grundlegenden Terraform-Code.\n\nWir werden auf AWS bereitstellen, eine virtuelle private Cloud (VPC), die ein virtuelles Netzwerk ist. In dieser VPC werden wir ein öffentliches und ein privates Subnetz bereitstellen. Wie der Name schon sagt, handelt es sich um Subnetze der Haupt-VPC. Abschließend fügen wir eine EC2-Instanz (Elastic Cloud Compute; eine virtuelle Maschine) zum öffentlichen Subnetz hinzu.\n\nDies zeigt, wie vier Ressourcen bereitgestellt werden können, ohne zu komplex zu werden. Die Idee ist, sich auf die Pipeline zu konzentrieren, nicht auf den Code.\n\nHier ist das Ziel, das wir für dein Repository erreichen möchten.\n\n![Ziel für Repository](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097033415.png)\n\nGehen wir Schritt für Schritt vor.\n\nZuerst deklarieren wir alle Ressourcen in der Datei `terraform/main.tf`:\n\n```terraform\nprovider \"aws\" {\n  region = var.aws_default_region\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\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}\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\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\nWie du sehen kannst, sind für diesen Code einige Variablen erforderlich, die wir also in der Datei `terraform/variables.tf` deklarieren:\n\n```terraform\nvariable \"aws_ami_id\" {\n  description = \"The AMI ID of the image being deployed.\"\n  type        = string\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\nvariable \"aws_vpc_cidr\" {\n  description = \"The CIDR of the VPC.\"\n  type        = string\n  default     = \"10.0.0.0/16\"\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\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\nvariable \"aws_default_region\" {\n  description = \"Default region where resources are deployed.\"\n  type        = string\n  default     = \"eu-west-3\"\n}\n\nvariable \"aws_resources_name\" {\n  description = \"Default name for the resources.\"\n  type        = string\n  default     = \"demo\"\n}\n```\n\nAuf der IaC-Seite sind wir damit auch schon fast fertig. Was fehlt, ist eine Möglichkeit, die Terraform-Zustände zu teilen. Für diejenigen, die es nicht wissen: Terraform funktioniert schematisch wie folgt:\n\n* `plan` überprüft die Unterschiede zwischen dem aktuellen Status der Infrastruktur und dem, was im Code definiert ist. Dann gibt es die Unterschiede aus.\n* `apply` wendet die Unterschiede im `plan` an und aktualisiert den Status.\n\nIn der ersten Runde ist der Status leer, dann wird er mit den Details (ID usw.) der von Terraform angewendeten Ressourcen gefüllt.\n\nDas Problem ist: Wo wird dieser Zustand gespeichert? Wie können wir ihn teilen, damit mehrere Entwickler(innen) am Code zusammenarbeiten können?\n\nDie Lösung ist ziemlich einfach: Nutze GitLab, um den Status über ein [Terraform-HTTP-Backend](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html) zu speichern und freizugeben.\n\nDer erste Schritt bei der Verwendung dieses Backends besteht darin, die einfachste Datei, nämlich `terraform/backend.tf` zu erstellen. Der zweite Schritt erfolgt in der Pipeline.\n\n```terraform\nterraform {\n  backend \"http\" {\n  }\n}\n```\n\nEt voilà! Wir haben einen minimalen Terraform-Code, um diese vier Ressourcen bereitzustellen. Wir werden die Variablenwerte zur Laufzeit bereitstellen, also machen wir das später.\n\n### Der Workflow\n\nDer Workflow, den wir jetzt implementieren werden, sieht folgendermaßen aus:\n\n\u003Cpre class=\"mermaid\">\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\n1. Erstelle einen **Feature-Branch**. Dadurch werden alle Scanner kontinuierlich auf dem Code ausgeführt, um sicherzustellen, dass er immer konform und gesichert bleibt. Dieser Code wird kontinuierlich in der temporären Umgebung `review/feature_branch` mit dem Namen des aktuellen Branches bereitgestellt. Dies ist eine sichere Umgebung, in der die Entwickler(innen) und IT-Betriebsteams ihren Code ohne Auswirkungen auf andere testen können. Hier setzen wir auch den Prozess durch, z. B. indem Code Reviews durchgesetzt und Scanner ausgeführt werden, damit die Qualität und Sicherheit des Codes akzeptabel sind und deine Assets nicht gefährdet werden. Die von diesem Branch bereitgestellte Infrastruktur wird automatisch zerstört, wenn der Branch geschlossen wird. So behältst du dein Budget unter Kontrolle.\n\n\u003Cpre class=\"mermaid\">\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\u003C/pre>\n\n2. Nach der Genehmigung wird der Feature-Branch mit dem Main-Branch **zusammengeführt**. Dies ist ein [geschützter Branch](https://docs.gitlab.com/ee/user/project/protected_branches.html), in den niemand pushen kann. Dies ist obligatorisch, um sicherzustellen, dass jede Änderungsanfrage an die Produktion gründlich getestet wird. Dieser Branch wird auch kontinuierlich bereitgestellt. Das Ziel hier ist die Umgebung `integration`. Damit diese Umgebung etwas stabiler bleibt, wird das Löschen nicht automatisiert, sondern kann manuell ausgelöst werden.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main) -->|auto deploy| E[integration]\n\u003C/pre>\n\n3. Von dort aus ist eine manuelle Genehmigung erforderlich, um die nächste Bereitstellung auszulösen. Dadurch wird der Haupt-Branch in der Umgebung `qa` bereitgestellt. Hier habe ich eine Regel festgelegt, um das Löschen aus der Pipeline zu verhindern. Diese Umgebung sollte ziemlich stabil sein (schließlich ist es bereits die dritte Umgebung), und ich möchte das versehentliche Löschen verhindern. Du kannst die Regeln gerne an deine Prozesse anpassen.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main)-->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\u003C/pre>\n\n4. Um fortzufahren, müssen wir den Code **taggen**. Wir setzen hier auf [geschützte Tags](https://docs.gitlab.com/ee/user/project/protected_tags.html), um sicherzustellen, dass nur eine bestimmte Gruppe von Benutzer(inne)n in diese letzten beiden Umgebungen bereitstellen darf. Dadurch wird sofort eine Bereitstellung in der Umgebung `staging` ausgelöst.\n\n\u003Cpre class=\"mermaid\">\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. Schließlich landen wir bei `production`. Wenn es um Infrastruktur geht, ist es oft schwierig, sie schrittweise bereitzustellen (10 %, 25 % usw.), sodass wir gleich die gesamte Infrastruktur bereitstellen werden. Dennoch steuern wir diese Bereitstellung, indem dieser letzte Schritt manuell ausgelöst wird. Und um maximale Kontrolle über diese hochkritische Umgebung zu erzwingen, werden wir sie als [geschützte Umgebung](https://docs.gitlab.com/ee/ci/environments/protected_environments.html) kontrollieren.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    H[staging] -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n### Die Pipeline\n\nUm den oben genannten [Workflow](#the-workflow) zu implementieren, implementieren wir jetzt eine Pipeline mit zwei [Downstream-Pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html).\n\n#### Die Haupt-Pipeline\n\nBeginnen wir mit der Haupt-Pipeline. Dies ist diejenige, die automatisch bei jedem **Push zu einem Feature-Branch**, jedem Zusammenführen zum Standard-Branch** oder jedem **Tag** ausgelöst wird. *Die Pipeline*, die eine echte **kontinuierliche Bereitstellung** in den folgenden Umgebungen durchführt: `dev`, `integration` und `staging`. Und das wird in der Datei `.gitlab-ci.yml` im Stamm deines Projekts deklariert.\n\n![Repository-Ziel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097033417.png)\n\n```yml\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# This tweak is needed to display vulnerability results in the merge widgets.\n# As soon as this issue https://gitlab.com/gitlab-org/gitlab/-/issues/439700 is resolved, the `include` instruction below can be removed.\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# Note: This workaround is perfectly safe and will not slow down your pipeline.\ninclude:\n  - template: Security/SAST-IaC.gitlab-ci.yml\n#### END TWEAK\n\n```\n\nDiese Pipeline läuft nur in zwei Phasen: `test` und `environments`. Erstere wird benötigt, damit der *TWEAK* Scanner ausführen kann. Zweitere löst eine untergeordnete Pipeline mit einem anderen Satz von Variablen für jeden oben definierten Fall aus (Push zum Branch, Zusammenführen zum Standard-Branch oder Tag).\n\nWir fügen hier eine Abhängigkeit mit dem Schlüsselwort [strategy:depend](https://docs.gitlab.com/ee/ci/yaml/index.html#triggerstrategy) zu unserer untergeordneten Pipeline hinzu, sodass die Pipeline-Ansicht in GitLab erst aktualisiert wird, wenn die Bereitstellung abgeschlossen ist.\n\nWie du hier sehen kannst, definieren wir einen Basisjob, [hidden](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs), und erweitern ihn um bestimmte Variablen und Regeln, um nur eine Bereitstellung für jede Zielumgebung auszulösen.\n\nNeben den [vordefinierten Variablen](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) verwenden wir zwei neue Einträge, die wir definieren müssen:\n1. [Die für jede Umgebung spezifischen Variablen](#the-variable-definitions): `../vars/$variables_file.tfvars`\n2. [Die untergeordnete Pipeline](#the-child-pipeline), definiert in `.gitlab-ci/.first-layer.gitlab-ci.yml`\n\nBeginnen wir mit dem kleinsten Teil, den Variablendefinitionen.\n\n### Die Variablendefinitionen\n\nWir werden hier zwei Lösungen mischen, um Terraform Variablen zur Verfügung zu stellen:\n\n* Die erste nutzt [.tfvars-Dateien](https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files) für alle nicht sensiblen Eingaben, die in GitLab gespeichert werden sollten.\n\n![Lösung 1 zur Bereitstellung von Variablen für Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097033419.png)\n\n* Die zweite verwendet [Umgebungsvariablen](https://developer.hashicorp.com/terraform/language/values/variables#environment-variables) mit dem Präfix `TF_VAR`. Diese zweite Möglichkeit, Variablen zu injizieren, die mit der GitLab-Fähigkeit verbunden sind, [Variablen zu maskieren](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable), [sie zu schützen](https://docs.gitlab.com/ee/ci/variables/#protect-a-cicd-variable) und [sie in Umgebungen zu übertragen](https://docs.gitlab.com/ee/ci/environments/index.html#limit-the-environment-scope-of-a-cicd-variable), ist eine leistungsstarke Lösung, um **Datenlecks sensibler Informationen zu verhindern**. (Wenn du das private CIDR deiner Produktion als sehr sensibel betrachtest, könntest du es so schützen, indem du sicherstellst, dass es nur für die Umgebung `production` verfügbar ist, für Pipelines, die gegen geschützte Branches und Tags ausgeführt werden, und dass sein Wert in den Protokollen des Jobs maskiert ist.)\n\n![Lösung 2 zur Bereitstellung von Variablen für Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097033422.png)\n\nDarüber hinaus sollte jede Variablendatei über eine [Datei `CODEOWNERS`](https://docs.gitlab.com/ee/user/project/codeowners/) gesteuert werden, um festzulegen, wer sie ändern darf.\n\n```\n[Production owners] \nvars/production.tfvars @operations-group\n\n[Staging owners]\nvars/staging.tfvars @odupre @operations-group\n\n[CodeOwners owners]\nCODEOWNERS @odupre\n```\n\nDieser Artikel ist kein Terraform-Training, daher halten wir das kurz und zeigen hier einfach die Datei `vars/review.tfvars`. Die nachfolgenden Umgebungsdateien sind sich natürlich sehr ähnlich. Lege hier einfach die nicht-sensiblen Variablen und ihre Werte fest.\n\n```shell\naws_vpc_cidr = \"10.1.0.0/16\"\naws_public_subnet_cidr = \"10.1.1.0/24\"\naws_private_subnet_cidr = \"10.1.2.0/24\"\n```\n\n#### Die untergeordnete Pipeline\n\nHier wird die eigentliche Arbeit erledigt. Sie ist also etwas komplexer als die erste Pipeline. Es gibt aber auch hier keine Schwierigkeit, die wir nicht gemeinsam überwinden können!\n\nWie wir bei der Definition der [Haupt-Pipeline](#the-main-pipeline) gesehen haben, wird diese Downstream-Pipeline in der Datei `.gitlab-ci/.first-layer.gitlab-ci.yml` deklariert.\n\n![In Datei deklarierte Downstream-Pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097033424.png)\n\nZerlegen wir sie in kleine Stücke. Am Ende sehen wir dann das große Ganze.\n\n##### Terraform-Befehle ausführen und den Code sichern\n\nZuerst wollen wir eine Pipeline für Terraform ausführen. GitLab ist Open Source. Unsere Terraform-Vorlage ist also auch Open Source. Du kannst sie einfach einbeziehen. Dies erreichst du mit folgendem Code-Schnipsel:\n\n```yml\ninclude:\n  - template: Terraform.gitlab-ci.yml\n```\n\nDiese Vorlage führt für dich die Terraform-Prüfungen für die Formatierung durch und validiert deinen Code, bevor er geplant und angewendet wird. Es ermöglicht dir auch, das zu zerstören, was du bereitgestellt hast.\n\nDa GitLab eine vereinheitlichte DevSecOps-Plattform ist, fügen wir dieser Vorlage automatisch zwei Sicherheitsscanner hinzu, um potenzielle Bedrohungen in deinem Code zu finden und dich zu warnen, bevor du ihn in den nächsten Umgebungen bereitstellst.\n\nJetzt, da wir unseren Code überprüft, gesichert, erstellt und bereitgestellt haben, folgen ein paar Tricks.\n\n##### Zwischenspeicher zwischen Jobs teilen\n\nWir werden Job-Ergebnisse zwischenspeichern, um sie in folgenden Pipeline-Jobs wiederzuverwenden. Dies ist einfach, denn du musst nur den folgenden Code hinzufügen:\n\n```yml\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\nHier definieren wir einen anderen Zwischenspeicher für jeden Commit und greifen bei Bedarf auf den Namen des Haupt-Branchs zurück.\n\nWenn wir uns die Vorlagen, die wir verwenden, genau ansehen, stellen wir fest, dass sie einige Regeln haben, die zu kontrollieren sind, wenn Jobs ausgeführt werden. Wir wollen alle Kontrollen (sowohl QA als auch Sicherheit) in allen Branchen ausführen. Wir werden diese Einstellungen also überschreiben.\n\n##### Kontrollen in allen Branches ausführen\n\nGitLab-Vorlagen sind eine leistungsstarke Funktion, bei der man auch nur einen Teil der Vorlage überschreiben kann. Hier wollen wir die Regeln einiger Jobs überschreiben, um immer Qualitäts- und Sicherheitskontrollen durchzuführen. Alles andere, was für diese Jobs definiert ist, bleibt wie in der Vorlage definiert.\n\n```yml\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\nDa wir nun die Qualitäts- und Sicherheitskontrollen durchgesetzt haben, wollen wir unterscheiden, wie sich die Hauptumgebungen (Integration und Staging) im [Workflow](#the-workflow) und Review-Umgebungen verhalten. Beginnen wir mit der Definition des Verhaltens der Hauptumgebung. Wir werden dann diese Konfiguration für die Review-Umgebungen optimieren.\n\n##### CD für Integration und Staging\n\nWie zuvor definiert, möchten wir den Haupt-Branch und die Tags in diesen beiden Umgebungen bereitstellen. Wir fügen Regeln hinzu, um das sowohl bei den Jobs `build` als auch `deploy` zu kontrollieren. Dann wollen wir `destroy` nur für `integration` aktivieren, da wir definiert haben, dass `staging` zu kritisch ist, um mit einem einzigen Klick gelöscht zu werden. Das ist fehleranfällig, was wir nicht wollen.\n\nSchließlich verknüpfen wir den Job `deploy` mit dem Job `destroy`, damit wir die Umgebung direkt von der GitLab-GUI aus mit `stop` stoppen können.\n\nDie `GIT_STRATEGY` soll verhindern, dass der Code beim Zerstören aus dem Quell-Branch im Runner abgerufen wird. Dies würde fehlschlagen, wenn der Branch manuell gelöscht wurde. Daher verlassen wir uns auf den Zwischenspeicher, um alles zu erhalten, was wir zum Ausführen der Terraform-Anweisungen benötigen.\n\n```yml\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  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\nWie gesagt müssen diese Matches in `integration` und `staging` bereitstellen. Uns fehlt jedoch immer noch eine temporäre Umgebung, in der die Entwickler(innen) ihren Code ohne Auswirkungen auf andere erleben und validieren können. Hier findet die Bereitstellung in der Umgebung `review` statt.\n\n##### CD für Review-Umgebungen\n\nDie Bereitstellung in der Review-Umgebung unterscheidet sich nicht allzu sehr von der Bereitstellung in `integration` und `staging`. Wir werden also erneut die Möglichkeit von GitLab nutzen, hier nur Teile der Jobdefinition zu überschreiben.\n\nZuerst legen wir Regeln fest, um diese Jobs nur in Feature-Branches auszuführen.\n\nDann verknüpfen wir den Job `deploy_review` mit `destroy_review`. Dies ermöglicht es uns, die Umgebung **manuell** von der GitLab-Bedienoberfläche aus zu stoppen und – was noch wichtiger ist – es wird **automatisch die Zerstörung der Umgebung ausgelöst**, wenn der Feature-Branch geschlossen wird. Dies ist eine gute FinOps-Praxis, um dir zu helfen, deine Betriebsausgaben zu kontrollieren.\n\nDa Terraform eine Plandatei benötigt, um eine Infrastruktur zu zerstören (genau wie es eine solche Datei benötigt, um eine Infrastruktur aufzubauen), fügen wir eine Abhängigkeit von `destroy_review` zu `build_review` hinzu, um Artefakte abzurufen.\n\nSchließlich sehen wir hier, dass der Name der Umgebung auf `$environment` festgelegt ist. Es wurde in der [Haupt-Pipeline](#the-main-pipeline) auf `review/$CI_COMMIT_REF_SLUG` gesetzt und mit der Anweisung `trigger:forward:yaml_variables:true` an diese untergeordnete Pipeline weitergeleitet.\n\n```yml\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\nZusammenfassend können wir also sagen, dass wir jetzt eine Pipeline haben, die Folgendes kann:\n\n* Temporäre Review-Umgebungen bereitstellen, die automatisch gelöscht werden, wenn der Feature-Branch geschlossen wird\n* Den **Standard-Branch** kontinuierlich auf `integration` bereitstellen\n* Die **Tags** kontinuierlich auf `staging` bereitstellen\n\nFügen wir nun eine zusätzliche Ebene hinzu, auf der wir diesmal mit einem manuellen Auslöser in den Umgebungen `qa` und `production` bereitstellen werden.\n\n##### Kontinuierliche Bereitstellung in QA und Produktion\n\nDa nicht jedes Unternehmen kontinuierlich in der Produktion bereitstellen möchte, fügen wir den nächsten beiden Bereitstellungen eine manuelle Validierung hinzu. Aus einer reinen **CD**-Perspektive würden wir diesen Auslöser nicht hinzufügen, aber betrachte dies als Gelegenheit, zu lernen, wie man Jobs von anderen Auslösern aus ausführt.\n\nBisher haben wir eine [untergeordnete Pipeline](#the-child-pipeline) aus der [Haupt-Pipeline](#the-main-pipeline) gestartet, um alle Bereitstellungen auszuführen.\n\nDa wir andere Bereitstellungen aus dem Standard-Branch und den Tags ausführen möchten, fügen wir eine weitere Ebene für diese zusätzlichen Schritte hinzu. Hier gibt es nichts Neues. Wir wiederholen einfach genau das, was wir nur für die [Haupt-Pipeline](#the-main-pipeline) gemacht haben. Auf diese Weise kannst du so viele Ebenen bearbeiten, wie du brauchst. Ich habe schon einmal bis zu neun Umgebungen gesehen.\n\nWir wollen hier nicht über die Vorteile diskutieren, die es mit sich bringt, weniger Umgebungen zu haben. Der hier verwendete Prozess macht es jedenfalls sehr einfach, die gleiche Pipeline von der Anfangsphase bis zur endgültigen Lieferung zu implementieren, während deine Pipeline-Definition einfach und in kleine, einfach zu wartende Teile aufgeteilt bleibt.\n\nUm hier Variablenkonflikte zu vermeiden, verwenden wir nur neue Variablennamen, um den Terraform-Status und die Eingabedatei zu identifizieren.\n\n```yml\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. Andernfalls schlagen alle Pipelines fehl, wenn eine Pipeline-Zeitüberschreitung vor der Bereitstellung auf die 2. Ebene erreicht wurde.\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**Ein wichtiger Trick ist hier die Strategie, die für die neue Downstream-Pipeline verwendet wird.** Wir belassen `trigger:strategy` auf ihrem Standardwert. Andernfalls würde die [Haupt-Pipeline](#the-main-pipeline) warten, bis deine [Pipeline der zweiten Ebene](#the-grand-child-pipeline) abgeschlossen ist. Bei einem manuellen Auslöser kann dies sehr lange dauern und das Lesen und Verstehen deines Pipeline-Dashboards erschweren.\n\nDu hast dich wahrscheinlich schon gefragt, was der Inhalt der Datei `.gitlab-ci/.second-layer.gitlab-ci.yml` ist, die wir hier anführen. Wir gehen im nächsten Abschnitt darauf ein.\n\n##### Vollständige Pipeline-Definition auf der ersten Ebene\n\nWenn du eine vollständige Ansicht dieser ersten Ebene möchtest (gespeichert in `.gitlab-ci/.first-layer.gitlab-ci.yml`), erweitere einfach den Abschnitt unten.\n\n```yml\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## Integration env. and Staging. env\n##  * Auto-deploy to Integration on merge to main.\n##  * Auto-deploy to Staging on tag.\n##  * Integration can be manually destroyed if TF_DESTROY is set to true.\n##  * Destroy of next env. is not automated to prevent errors.\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## Dev env.\n##  * Temporary environment. Lives and dies with the Merge Request.\n##  * Auto-deploy on push to feature branch.\n##  * Auto-destroy on when Merge Request is closed.\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## Second layer\n##  * Deploys from main branch to qa env.\n##  * Deploys from tag to production.\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\nIn dieser Phase stellen wir bereits sicher in drei Umgebungen bereit. Das ist meine persönliche Idealempfehlung. Wenn du jedoch mehr Umgebungen benötigst, füge diese deiner CD-Pipeline hinzu.\n\nDu hast sicherlich schon bemerkt, dass wir eine Downstream-Pipeline mit dem Stichwort `trigger:include` einbinden. Dazu gehört die Datei `.gitlab-ci/.second-layer.gitlab-ci.yml`. Da wir fast die gleiche Pipeline ausführen wollen, ist ihr Inhalt offensichtlich sehr ähnlich zu dem, den wir oben detailliert beschrieben haben. Der Hauptvorteil bei der Definition dieser [Pipeline der zweiten Ebene](#the-grand-child-pipeline) ist, dass sie allein besteht, was die Definition von Variablen und Regeln erleichtert.\n\n### Die Pipeline der zweiten Ebene\n\nDiese Pipeline der zweiten Ebene ist eine brandneue Pipeline. Daher muss es die Definition der ersten Ebene nachahmen mit:\n\n* [Aufnahme der Terraform-Vorlage](#run-terraform-commands-and-secure-the-code).\n* [Durchsetzung von Sicherheitskontrollen](#run-controls-on-all-branches). Bei der Terraform-Validierung handelt es sich um Duplikate der ersten Ebene. Sicherheitsscanner können jedoch Bedrohungen finden, die noch nicht vorhanden waren, als die Scanner zuvor ausgeführt wurden (z. B. wenn du einige Tage nach der Bereitstellung im Staging in der Produktion bereitstellst).\n* [Überschreiben von Build- und Bereitstellungs-Jobs, um spezifische Regeln festzulegen](#cd-to-review-environments). Beachte bitte, dass die Phase `destroy` nicht mehr automatisiert ist, um zu schnelle Löschvorgänge zu verhindern.\n\nWie oben erläutert, wurden `TF_STATE_NAME` und `TF_CLI_ARGS_plan` von der [Haupt-Pipeline](# the-main-pipeline) zur [untergeordneten Pipeline](#the-child-pipeline) bereitgestellt. Wir brauchten einen weiteren Variablennamen, um diese Werte von der [untergeordneten Pipeline](#the-child-pipeline) hierher, also an die [Pipeline der zweiten Ebene](#the-grand-child-pipeline), zu übergeben. Deshalb werden sie in der untergeordneten Pipeline mit dem Postfix `_2` versehen und der Wert wird während des `before_script` hier zurück in die entsprechende Variable kopiert.\n\nDa wir oben bereits jeden Schritt aufgeschlüsselt haben, können wir hier direkt auf die breite Ansicht der globalen Definition der zweiten Ebene zoomen (gespeichert in `.gitlab-ci/.second-layer.gitlab-ci.yml`).\n\n```yml\n# Use to deploy a second environment on both the default branch and the tags.\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## QA env. and Prod. env\n##  * Manually trigger build and auto-deploy in QA\n##  * Manually trigger both build and deploy in Production\n##  * Destroy of these env. is not automated to prevent errors.\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\nEt voilà. **Wir sind bereit.** Du kannst die Art und Weise ändern, wie du deine Jobausführungen kontrollierst, indem du bspw. die Möglichkeit von GitLab nutzt, [einen Job zu verzögern](https://docs.gitlab.com/ee/ci/jobs/job_control.html#run-a-job-after-a-delay), bevor du ihn in der Produktion bereitstellst.\n\n## Probiere es selbst\n\nWir haben endlich unser Ziel erreicht. Wir sind jetzt in der Lage, **Bereitstellungen in fünf verschiedenen Umgebungen** zu kontrollieren, wobei nur die **Feature-Branches**, der **Haupt-Branch** und **Tags** verwendet werden.\n* Wir verwenden Open-Source-Vorlagen von GitLab intensiv wieder, um Effizienz und Sicherheit in unseren Pipelines zu gewährleisten.\n* Wir nutzen GitLab-Vorlagen, um nur die Blöcke zu überschreiben, die eine benutzerdefinierte Kontrolle benötigen.\n* Wir haben die Pipeline in kleine Teile aufgeteilt und kontrollieren die Downstream-Pipelines so, dass sie genau dem entsprechen, was wir brauchen.\n\nAb hier gehört die Bühne ganz dir. Du kannst beispielsweise die Haupt-Pipeline einfach aktualisieren, um Downstream-Pipelines für deinen Software-Quellcode mit dem Schlüsselwort [trigger:rules:changes](https://docs.gitlab.com/ee/ci/yaml/#ruleschanges) auszulösen. Und verwende je nach den aufgetretenen Änderungen eine andere [Vorlage](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/). Aber das ist eine andere Geschichte.",[9,755,753,684,683],"2024-11-05",{"slug":1117,"featured":6,"template":690},"using-child-pipelines-to-continuously-deploy-to-five-environments","content:de-de:blog:using-child-pipelines-to-continuously-deploy-to-five-environments.yml","Using Child Pipelines To Continuously Deploy To Five Environments","de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments.yml","de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"_path":1123,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1124,"content":1127,"config":1136,"_id":1138,"_type":14,"title":1139,"_source":16,"_file":1140,"_stem":1141,"_extension":19},"/de-de/blog/why-now-is-the-time-for-embedded-devsecops",{"noIndex":6,"title":1125,"description":1126,"ogTitle":1125,"ogDescription":1126},"Embedded DevSecOps: Warum 2025 der richtige Zeitpunkt ist","Embedded-Teams reduzieren Feedback-Zyklen von Wochen auf Stunden. Lerne, wie DevSecOps manuelle Compliance automatisiert und Innovation beschleunigt.",{"heroImage":1128,"body":1129,"authors":1130,"updatedDate":7,"date":1132,"title":1133,"tags":1134,"description":1135,"category":954},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749659978/Blog/Hero%20Images/automation.png","Für Embedded-Systeme-Teams schien DevSecOps traditionell eher ein Ansatz für SaaS-Anwendungen als für die Firmware-Entwicklung zu sein. Aber das ändert sich. Software ist jetzt ein primärer Differenzierungsfaktor bei Hardwareprodukten. Neue Erwartungen der Marktteilnehmer erfordern moderne Entwicklungspraktiken. Als Reaktion darauf verfolgen Unternehmen \"Embedded DevSecOps\".\n\nWas ist Embedded DevSecOps? Die Anwendung kollaborativer Engineering-Praktiken, integrierter Toolchains und Automatisierung für das Erstellen, Testen und Sichern von Software auf die Entwicklung eingebetteter Systeme. Embedded DevSecOps umfasst notwendige Anpassungen für die Hardware-Integration.\n\n## Drei Marktkräfte, welche die Embedded-Entwicklung revolutionieren\n\nDrei mächtige Marktkräfte konvergieren und zwingen Embedded-Teams dazu, ihre Entwicklungspraktiken zu modernisieren.\n\n### 1. Software wird zum primären Differenzierungsfaktor\n\nProdukte, die einst hauptsächlich durch ihre Hardware definiert wurden, unterscheiden sich jetzt durch ihre Softwarefähigkeiten. Der Markt für softwaredefinierte Fahrzeuge (SDV) erzählt in dieser Hinsicht eine überzeugende Geschichte. Er wird voraussichtlich von 213,5 Milliarden US-Dollar im Jahr 2024 auf [1,24 Billionen US-Dollar (Artikel auf Englisch)](https://www.marketsandmarkets.com/Market-Reports/software-defined-vehicles-market-187205966.html) bis 2030 wachsen – eine massive jährliche Wachstumsrate von 34%.\n\nDer Softwareanteil in diesen Produkten wächst erheblich. Bis Ende 2025 wird erwartet, dass das durchschnittliche Fahrzeug [650 Millionen Codezeilen (Artikel auf Englisch)](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/) enthält. Traditionelle Embedded-Entwicklungsansätze können diese Softwarekomplexität nicht bewältigen.\n\n### 2. Hardware-Virtualisierung ermöglicht neue Arbeitsweisen\n\nHardware-Virtualisierung ist ein wichtiger technischer Enabler für Embedded DevSecOps. Virtuelle elektronische Steuergeräte (vECUs), Cloud-basierte ARM-CPUs und anspruchsvolle Simulationsumgebungen werden immer verbreiteter. Virtuelle Hardware ermöglicht Tests, die einst physische Hardware erforderten.\n\nDiese Virtualisierungstechnologien bieten eine Grundlage für Continuous Integration ([CI](https://about.gitlab.com/topics/ci-cd/)). Aber ihr Wert wird nur vollständig realisiert, wenn sie in einen automatisierten Workflow integriert sind. In Kombination mit kollaborativen Entwicklungspraktiken und automatisierten Pipelines helfen virtuelle Tests den Teams, Probleme viel früher zu erkennen, wenn Korrekturen noch viel kostengünstiger sind. Ohne Embedded-DevSecOps-Praktiken und Tools zur Orchestrierung dieser virtuellen Ressourcen können Unternehmen den Virtualisierungstrend nicht nutzen.\n\n### 3. Der Wettbewerbsdruck steigt exponentiell\n\nDrei miteinander verbundene Kräfte gestalten die Wettbewerbslandschaft für die Embedded-Entwicklung neu:\n\n* Der Kampf um die größten Talente hat sich entscheidend verschoben. Wie ein Embedded-Systems-Leader bei einem GitLab-Kunden erklärte: \"Kein Embedded-Ingenieur, der heute vom College kommt, kennt Legacy-Tools wie Perforce. Sie kennen Git. Diese jungen Ingenieure arbeiten sechs Monate in einem Unternehmen mit Legacy-Tools und kündigen dann.\" Unternehmen, die veraltete Tools verwenden, könnten ihre technische Zukunft verlieren.\n* Dieser Vorsprung durch die besten Talente führt zu Wettbewerbsvorteilen. Technologieorientierte Unternehmen, die Top-Ingenieure mit modernen Praktiken anziehen, erzielen bemerkenswerte Ergebnisse. Beispielsweise führte [SpaceX (Artikel auf Englisch)](https://spacenews.com/spacex-launch-surge-helps-set-new-global-launch-record-in-2024/) im Jahr 2024 mehr Orbitalstarts durch als der Rest der Welt zusammen. Technologieorientierte Unternehmen zeichnen sich durch Softwareentwicklung aus und haben eine moderne Entwicklungskultur. Dies schafft unter anderem Effizienzen, die Legacy-Unternehmen nur schwer erreichen können.\n* Die steigenden Kosten der Embedded-Entwicklung – getrieben durch lange Feedback-Zyklen – schaffen einen dringenden Bedarf an Embedded DevSecOps. Wenn Entwickler(innen) wochenlang warten müssen, um Code auf Hardware-Testbänken zu testen, bleibt die Produktivität von Natur aus niedrig. Ingenieur(innen) verlieren den Kontext und müssen den Kontext wechseln, wenn die Ergebnisse eintreffen. Das Problem verschlimmert sich, wenn Fehler ins Spiel kommen. Bugs werden teurer zu beheben, je später sie entdeckt werden. Lange Feedback-Zyklen vergrößern dieses Problem in eingebetteten Systemen.\n\nUnternehmen setzen Embedded DevSecOps ein, um diese Herausforderungen zu bewältigen.\n\n## So setzen führende Unternehmen Embedded DevSecOps um\n\nBasierend auf diesen Marktkräften implementieren zukunftsorientierte Embedded-Systems-Leader Embedded DevSecOps auf folgende Weise.\n\n### Hardware-Tests automatisieren und beschleunigen\n\nHardware-Test-Engpässe stellen eine der bedeutendsten Einschränkungen in der traditionellen Embedded-Entwicklung dar. Diese Verzögerungen schaffen die zuvor beschriebene ungünstige Wirtschaftlichkeit – wenn Entwickler(innen) wochenlang auf Hardware-Zugriff warten, steigen die Fehlerkosten spiralförmig an.\n\nDie Bewältigung dieser Herausforderung erfordert einen facettenreichen Ansatz, einschließlich:\n\n* Automatisierung der Orchestrierung teurer gemeinsam genutzter Hardware-Testbänke unter Embedded-Entwickler(inne)n\n* Integration sowohl von SIL (Software-in-the-Loop) als auch HIL (Hardware-in-the-Loop) Tests in automatisierte CI-Pipelines\n* Standardisierung von Builds mit versionskontrollierten Umgebungen\n\nEmbedded-Entwickler(innen) können dies mit GitLabs [On-Premises Device Cloud (Seite auf Englisch)](https://gitlab.com/gitlab-accelerates-embedded/comp/device-cloud) erreichen, einer CI/CD-Komponente. Durch die Automatisierung der Orchestrierung von Firmware-Tests auf virtueller und realer Hardware sind Teams besser positioniert, um Feedback-Zyklen von Wochen auf Stunden zu reduzieren. Sie können auch mehr Bugs früh im Software-Entwicklungslebenszyklus erkennen.\n\n### Automatisierung von Compliance und Security Governance\n\nEingebettete Systeme unterliegen strengen regulatorischen Anforderungen. Manuelle Compliance-Prozesse sind nicht nachhaltig.\n\nFührende Unternehmen transformieren die Art und Weise, wie sie diese Anforderungen erfüllen, durch:\n\n* Ersetzen manueller Workflows durch automatisierte [Compliance-Frameworks](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)\n* Integration spezialisierter Funktionssicherheits-, Sicherheits- und Code-Qualitäts-Tools in automatisierte Continuous-Integration-Pipelines\n* Automatisierung von Genehmigungsworkflows, Durchsetzung von Code-Reviews und Pflege von Audit-Trails\n* Konfiguration von Compliance-Frameworks für spezifische Standards wie ISO 26262 oder DO-178C\n\nDieser Ansatz ermöglicht eine höhere Compliance-Reife ohne zusätzliches Personal – was einst eine Last war, wird zu einem Wettbewerbsvorteil. Ein führender Hersteller von Elektrofahrzeugen (EV) führt mit GitLab täglich 120.000 CI/CD-Jobs aus, von denen viele Compliance-Prüfungen beinhalten. Und sie können Fehlerbehebungen innerhalb einer Stunde nach der Entdeckung beheben und in Fahrzeuge bereitstellen. Dieses Maß an Skalierung und Geschwindigkeit wäre ohne automatisierte Compliance-Workflows extrem schwierig.\n\n### Compliance-Prozesse in CI/CD-Pipelines integrieren\n\nHistorisch gesehen haben Embedded-Entwickler(innen) aus berechtigten geschäftlichen und technischen Gründen weitgehend allein an ihren Schreibtischen gearbeitet. Die Zusammenarbeit war begrenzt. Innovative Unternehmen durchbrechen diese Barrieren, indem sie gemeinsame Code-Sichtbarkeit durch integrierte Source-Control- und CI/CD-Workflows ermöglichen. Diese modernen Praktiken ziehen Ingenieur(innen) an und halten sie, während sie Innovationen freischalten, die in isolierten Workflows verborgen bleiben würden.\n\nWie ein Director of DevOps bei einem technologieorientierten Automobilhersteller (ein GitLab-Kunde) erklärt: \"Es ist wirklich entscheidend für uns, eine einzige Übersicht zu haben, auf die wir schauen und die Status sehen können. Die Entwickler(innen) sind sich beim Einbringen eines Merge Requests des Status eines bestimmten Workflows bewusst, um sich so schnell wie möglich zu bewegen.\" Diese Transparenz beschleunigt die Innovation und ermöglicht es Automobilherstellern, schnell auf Softwarefunktionen zu iterieren, die ihre Fahrzeuge in einem zunehmend wettbewerbsintensiven Markt differenzieren.\n\n## Silos aufbrechen durch kollaborative Entwicklung\n\nEmbedded-Systems-Leader haben ein klares Zeitfenster, um durch die DevSecOps-Einführung einen Wettbewerbsvorteil zu erlangen. Aber das Fenster wird nicht für immer offen bleiben. Software wird weiterhin zum primären Differenzierungsfaktor in eingebetteten Produkten, und die Kluft zwischen Leadern und Nachzüglern wird nur größer werden.\n\nUnternehmen, die DevSecOps erfolgreich einführen, werden Kosten senken, die Markteinführungszeit beschleunigen und Innovationen freischalten, die sie auf dem Markt differenzieren. Die Embedded-Systems-Leader von morgen sind diejenigen, die heute DevSecOps annehmen.\n\n> Während dieser Artikel untersuchte, warum jetzt die kritische Zeit für Embedded-Teams ist, DevSecOps einzuführen, fragst du dich vielleicht nach den praktischen Schritten für den Einstieg. Erfahre, wie du diese Konzepte mit unserem Leitfaden in die Praxis umsetzen kannst: [4 Wege zur Beschleunigung der Embedded-Entwicklung mit GitLab (Artikel auf Englisch)](https://about.gitlab.com/blog/4-ways-to-accelerate-embedded-development-with-gitlab/).",[1131],"Matt DeLaney","2025-07-03","Warum jetzt die Zeit für Embedded DevSecOps ist",[9],"Erfahre, wie Embedded-Entwicklungsteams lange Feedback-Zyklen, manuelle Compliance und isolierte Entwicklung mit DevSecOps bewältigen.",{"featured":6,"template":690,"slug":1137},"why-now-is-the-time-for-embedded-devsecops","content:de-de:blog:why-now-is-the-time-for-embedded-devsecops.yml","Why Now Is The Time For Embedded Devsecops","de-de/blog/why-now-is-the-time-for-embedded-devsecops.yml","de-de/blog/why-now-is-the-time-for-embedded-devsecops",{"_path":1143,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1144,"content":1149,"config":1154,"_id":1156,"_type":14,"title":1157,"_source":16,"_file":1158,"_stem":1159,"_extension":19},"/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"title":1145,"description":1146,"ogTitle":1145,"ogDescription":1146,"noIndex":6,"ogImage":790,"ogUrl":1147,"ogSiteName":672,"ogType":673,"canonicalUrls":1147,"schema":1148},"Automatisiere Agile-Workflows mit dem gem gitlab-triage","In unserer Serie „Erste Schritte mit GitLab“ erfährst du, wie du wiederkehrende Aufgaben – zum Beispiel die Triage von Tickets und Merge Requests – automatisierst und deinen Entwickler(inne)n dadurch wertvolle Zeit sparst.","https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisiere Agile-Workflows mit dem gem gitlab-triage\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-13\",\n      }",{"title":1145,"description":1146,"authors":1150,"heroImage":790,"date":1151,"body":1152,"category":685,"tags":1153,"updatedDate":843},[795],"2025-03-13","*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Einsteiger(inne)n helfen, die GitLabs DevSecOps-Plattform kennenzulernen.*\n\nIn diesem Beitrag geht es um das gem [`gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage), ein leistungsstarkes Tool, mit dem du Bots erstellen kannst, um deinen Agile-Workflow zu automatisieren.\n\n## Warum solltest du deinen Workflow automatisieren?\n\nEffizienz ist in der Softwareentwicklung ausschlaggebend. Indem du wiederkehrende Aufgaben wie die Triage von Tickets und Merge Requests automatisierst, schaffst du wertvolle Zeit für dein Team, in der es sich auf das Wichtigste konzentrieren kann: tolle Software zu entwickeln.\n\nMit `gitlab-triage` kannst du Folgendes tun:\n\n* **Konsistenz sicherstellen:** Wende Labels an und weise Tickets automatisch anhand vordefinierter Regeln zu.\n* **Reaktionszeit verbessern:** Erhalte sofortiges Feedback zu neuen Tickets und Merge Requests.\n* **Manuellen Aufwand reduzieren:** Mache manuelle Triage und Updates überflüssig.\n* **Produktivität steigern:** Entlaste dein Team, damit es sich auf das Programmieren und auf Innovationen konzentrieren kann.\n\n## Wir stellen vor: das gem `gitlab-triage`\n\nDas gem `gitlab-triage` ist eine Ruby-Bibliothek, mit der du Bots erstellen kannst, die mit deinen GitLab-Projekten interagieren. Diese Bots können automatisch verschiedenste Aktionen durchführen, darunter:\n\n* **Labels zuweisen:** Kategorisiere Tickets und Merge Requests automatisch.\n* **Kommentare verfassen:** Gib Neuheiten bekannt, fordere Informationen an oder hinterlasse Feedback.\n* **Aufgaben zuweisen:** Weise Tickets und Merge Request dem passenden Teammitglied zu.\n* **Abschließen:** Schließe veraltete oder gelöste Tickets und Merge Requests.\n* **Tickets erstellen:** Erstelle neue Tickets basierend auf bestimmten Ereignissen oder Bedingungen.\n* **Und vieles mehr!**\n\nSieh dir das [gem-Repository `gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) an.\n\n## Einrichtung deines Triage-Bots\n\nRichten wir jetzt deinen ersten Triage-Bot ein und bringen ihn zum Laufen.\n\n1. Installiere das gem. (Hinweis: Der Befehl gem ist verfügbar, wenn die Programmiersprache Ruby installiert ist.)\n\n```bash\ngem install gitlab-triage\n```\n\n2. Rufe dein GitLab-API-Token ab.\n\n* Gehe zu deinen GitLab-[Profileinstellungen](https://gitlab.com/-/profile/preferences).  \n* Gehe zu **Zugriffstoken**.\n* Erstelle ein neues Token mit dem Geltungsbereich `api`.\n* **Bewahre dein Token sicher auf und lege ein Ablaufdatum dafür fest, sodass es abläuft, wenn du diese Anleitung abgeschlossen hast.**\n\n3. Definiere deine Triage-Richtlinien.\n\nErstelle im Root-Verzeichnis deines Projekts eine Datei mit dem Namen `.triage-policies.yml`. Diese Datei enthält die Regeln, die das Verhalten deines Bots steuern. Hier ist ein einfaches Beispiel:\n\n```yaml\n\n---\n- name: \"Apply 'WIP' label\"\n  condition:\n    draft: true\n  action:\n    labels:\n      - status::wip\n\n- name: \"Request more information on old issue\"\n  condition:\n   date:\n    attribute: updated_at\n    condition: older_than\n    interval_type: months\n    interval: 12\n  action:\n    comment: |\n      {{author}} This issue has been open for more than 12 months, is this still an issue?\n```\n\nDiese Konfiguration definiert zwei Richtlinien:\n\n* Mit der ersten Richtlinie wird das Label `status::wip` allen Tickets zugewiesen, die im Entwurfsstatus sind.\n* Mit der zweiten Richtlinie wird ein Kommentar zu einem Ticket hinzugefügt, in dem angemerkt wird, dass das Ticket in den letzten 12 Monaten nicht aktualisiert wurde.\n\n4. Führe deinen Bot aus.\n\nDu kannst deinen Bot manuell mit dem folgenden Befehl ausführen:\n\n```bash\ngitlab-triage -t \u003Cyour_api_token> -p \u003Cyour_project_id>\n```\n\nErsetze `\u003Cyour_api_token>` mit deinem GitLab-API-Token und `\u003Cyour_project_id>` mit der [ID deines GitLab-Projekts](https://docs.gitlab.com/user/project/working_with_projects/#access-a-project-by-using-the-project-id). Wenn du sehen möchtest, welche Auswirkungen die Aktionen haben, bevor sie tatsächlich ausgeführt hast, kannst du `-n` oder `--dry-run` hinzufügen, um die Richtlinien erst einmal zu testen.\n\n## Automatisierung mit GitLab CI/CD\n\nUm die Ausführung deines Triage-Bots zu automatisieren, integrierst du ihn in [GitLab CI/CD (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation/). Hier ist ein Beispiel für eine `.gitlab-ci.yml`-Konfiguration:\n\n```yaml\n\ntriage:\n  script:\n    - gem install gitlab-triage\n    - gitlab-triage -t $GITLAB_TOKEN -p $CI_PROJECT_ID\n  only:\n    - schedules\n```\n\nDiese Konfiguration definiert einen Job mit dem Namen „Triage“, der das gem `gitlab-triage` installiert und den Bot mit dem `$GITLAB_TOKEN` (eine vordefinierte [CI/CD-Variable](https://docs.gitlab.com/ci/variables/); Dokumentation nur in englischer Sprache verfügbar) und der Variable `$CI_PROJECT_ID` ausführt. Die Klausel `only: schedules` stellt sicher, dass der Auftrag nur nach einem Zeitplan ausgeführt wird.\n\nUm einen [Zeitplan (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) zu erstellen, gehe zu den **CI/CD-Einstellungen** des Projekts und dann zu **Zeitpläne**. Erstelle einen neuen Zeitplan und lege fest, wie häufig dein Bot ausgeführt werden soll (z. B. täglich, stündlich, usw.).\n\n## Erweiterte Triage-Richtlinien\n\n`gitlab-triage` bietet eine Reihe von erweiterten Funktionen, mit denen du ausgefeiltere Triage-Richtlinien erstellen kannst:\n\n* **Reguläre Ausdrücke:** Verwende reguläre Ausdrücke für einen leistungsstarken Musterabgleich.\n* **Zusammenfassungsrichtlinien:** Konsolidiere ähnliche Tickets in ein Übersichtsticket.\n* **Benutzerdefinierte Aktionen:** Definiere mit [Ruby-Codeblöcken](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage#can-i-customize) benutzerdefinierte Aktionen, um komplexere Abläufe über die GitLab-API auszuführen.\n\nHier sind zwei umfassendere Praxisbeispiele aus dem Triage-Bot, der vom Developer Advocacy Team bei GitLab verwendet wird. Die vollständigen Richtlinien findest du in [dieser Datei](https://gitlab.com/gitlab-da/projects/devrel-bot/-/blob/master/.triage-policies.yml?ref_type=heads).\n\n```yaml\n- name: Issues where DA team member is an assignee outside DA-Meta project i.e. DevRel-Influenced\n  conditions:\n    assignee_member:\n      source: group\n      condition: member_of\n      source_id: 1008\n    state: opened\n    ruby: get_project_id != 18 \n    forbidden_labels:\n      - developer-advocacy\n  actions:   \n    labels:\n      - developer-advocacy\n      - DevRel-Influenced\n      - DA-Bot::Skip\n```\n\nDieses Beispiel zeigt Tickets in einer Gruppe. Dabei werden diejenigen ausgeschlossen, die sich im Projekt mit der ID 18 befinden und die Beauftragte haben, die Mitglieder der Gruppe mit der ID 1008 sind und nicht das Label `developer-advocacy` aufweisen. Mit dieser Richtlinie kann das Developer Advocacy Team bei GitLab Tickets finden, die Mitgliedern des Teams zugewiesen sind, aber nicht im Projekt des Teams enthalten sind. Indem die Labels der Teams hinzugefügt werden, kann das Team Beiträge identifizieren und nachverfolgen, die von Personen außerhalb des Teams gemacht wurden.\n\n```\n- name: Missing Due Dates\n  conditions:\n    ruby: missing_due_date\n    state: opened\n    labels:\n      - developer-advocacy\n    forbidden_labels:\n      - DA-Due::N/A\n      - DA-Bot::Skip\n      - DA-Status::FYI\n      - DA-Status::OnHold\n      - CFP\n      - DA-Bot::Triage\n  actions:\n    labels:\n      - DA-Bot-Auto-Due-Date\n    comment: |\n      /due #{get_current_quarter_last_date}\n```\n\nDer Bot in diesem zweiten Beispiel sucht nach allen Tickets mit dem Label `developer-advocacy`, die keine Labels aus der Liste der verbotenen Labes enthalten und deren Fälligkeitsdatum überschritten wurde. Er aktualisiert die Fälligkeitstermine automatisch, indem er dem Ticket mit einem Slash-Befehl und einem Datum, das über Ruby generiert wird, einen Kommentar hinzufügt.\n\nDie in den Richtlinien verwendeten Ruby-Skripte werden in einer separaten Datei definiert, wie unten gezeigt. Mit dieser Funktion kannst du flexibel mit Filtern und Aktionen arbeiten. Du siehst, dass Funktionen für verschiedene Ruby-Befehle erstellt werden, die wir in unseren Richtlinien verwendet haben.\n\n```\nrequire 'json'\nrequire 'date'\nrequire \"faraday\"\nrequire 'dotenv/load'\n\nmodule DATriagePlugin\n  def last_comment_at\n    conn = Faraday.new(\n      url: notes_url+\"?sort=desc&order_by=created_at&pagination=keyset&per_page=1\",\n      headers: {'PRIVATE-TOKEN' => ENV.fetch(\"PRIV_KEY\"), 'Content-Type' => 'application/json' }\n    )\n\n    response = conn.get()\n    if response.status == 200\n      jsonData = JSON.parse(response.body)\n      if jsonData.length > 0\n        Date.parse(jsonData[0]['created_at'])\n      else\n        Date.parse(resource[:created_at])\n      end\n    else\n      Date.parse(resource[:created_at])\n    end\n  end\n\n  def notes_url\n    resource[:_links][:notes]\n  end\n\n  def get_project_id\n    resource[:project_id]\n  end\n\n  def get_current_quarter_last_date()\n    yr = Time.now.year\n    case Time.now.month\n    when 2..4\n      lm = 4\n    when 5..7\n      lm = 7\n    when 8..10\n      lm = 10\n    when 11..12\n      lm = 1\n      yr = yr + 1\n    else\n      lm = 1    \n    end\n\n    return Date.new(yr, lm, -1) \n  end\n\n  def one_week_to_due_date\n    if(resource[:due_date] == nil)\n      false\n    else\n      days_to_due = (Date.parse(resource[:due_date]) - Date.today).to_i\n      if(days_to_due > 0 && days_to_due \u003C 7)\n        true\n      else\n        false\n      end\n    end\n  end\n\n  def due_date_past\n    if(resource[:due_date] == nil)\n      false\n    else\n      Date.today > Date.parse(resource[:due_date])\n    end\n  end\n\n  def missing_due_date\n    if(resource[:due_date] == nil)\n      true\n    else\n      false\n    end\n  end\n\nend\n\nGitlab::Triage::Resource::Context.include DATriagePlugin\n\n```\nDer Triage-Bot wird mit folgendem Befehl ausgeführt:\n\n``` \n`gitlab-triage -r ./triage_bot/issue_triage_plugin.rb --debug --token $PRIV_KEY --source-id gitlab-com --source groups`  \n```\n\n- `-r`: Übergibt eine Datei mit Anforderungen für die Ausführung der Triage. In diesem Fall übergeben wir unsere Ruby-Funktionen.  \n- `--debug`: Fügt der Ausgabe Debugging-Informationen hinzu.  \n- `--token`: Wird verwendet, um ein gültiges GitLab-API-Token zu übergeben.  \n- `--source`: Gibt an, ob die Quellen des Tickets, die durchsucht werden, in einer Gruppe oder einem Projekt liegen.\n- `--source-id`: Übernimmt die ID des ausgewählten Quelltyps – in diesem Fall eine Gruppe.\n\nDas GitLab-Projekt [triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) ist ein weiteres Praxisbeispiel, das etwas komplexer ist und bei dem du lernen kannst, deinen eigenen Triage-Bot zu erstellen.\n\n## Best Practices\n\n* **Beginne einfach:** Beginne mit grundlegenden Richtlinien und erhöhe die Komplexität schrittweise nach Bedarf. \n* **Teste gründlich:** Teste deine Richtlinien in einer Staging-Umgebung, bevor du sie in der Produktion bereitstellst.  \n* **Überwache regelmäßig:** Überwache die Aktivität deines Bots, um sicherzustellen, dass er sich wie erwartet verhält.\n* **Verwende beschreibende Namen:** Gib deinen Richtlinien klare und beschreibende Namen, damit sie einfach gepflegt werden können. \n* **Achte auf den Umfang deiner Filter:** Vielleicht kommst du in Versuchung, Tickets über Gruppen hinweg zu filtern, die Tausende von Tickets enthalten. Dies kann jedoch die Triage verlangsamen und der Prozess kann aufgrund von Ratenbeschränkungen für die GitLab-API auch fehlschlagen.  \n* **Priorisiere die Verwendung von Labels für die Triage:** Um unnötige Benachrichtigungen an andere Benuzter(innen) zu vermeiden, sind Labels eine tolle Möglichkeit, eine Triage durchzuführen, ohne Kommentare und Tickets zu überladen.\n\n## Übernimm die Kontrolle über deinen Workflow\n\nMit dem gem `gitlab-triage` kannst du deinen GitLab-Workflow automatisieren und eine ganz neue Effizienz ermöglichen. Erstelle zunächst einen einfachen Traige-Bot und lerne dann nach und nach die fortschrittlicheren Funktionen kennen. Du wirst erstaunt sein, wie viel Zeit und Aufwand du einsparen kannst\\!\n\n## Serie: Erste Schritte mit GitLab\n\nWeitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n",[684,683,685,998,9],{"slug":1155,"featured":6,"template":690},"automating-agile-workflows-with-the-gitlab-triage-gem","content:de-de:blog:automating-agile-workflows-with-the-gitlab-triage-gem.yml","Automating Agile Workflows With The Gitlab Triage Gem","de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem.yml","de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem",3,[665,695,716,738,763,785,806,826,850],1758326265033]