[{"data":1,"prerenderedAt":1261},["ShallowReactive",2],{"/de-de/blog/tags/devsecops/":3,"navigation-de-de":20,"banner-de-de":441,"footer-de-de":454,"DevSecOps-tag-page-de-de":664},{"_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},"/de-de/blog/tags/devsecops","tags",false,"",{"tag":9,"tagSlug":10},"DevSecOps","devsecops",{"template":12},"BlogTag","content:de-de:blog:tags:devsecops.yml","yaml","Devsecops","content","de-de/blog/tags/devsecops.yml","de-de/blog/tags/devsecops","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":437,"_type":14,"title":438,"_source":16,"_file":439,"_stem":440,"_extension":19},"/shared/de-de/main-navigation","de-de",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":378,"minimal":414,"duo":428},{"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,188,193,299,359],{"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":170},"Produkt",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Alle Lösungen anzeigen",{"href":97,"dataGaName":93,"dataGaLocation":28},"/de-de/solutions/",[99,125,148],{"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,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/de-de/solutions/continuous-integration/",{"text":113,"config":114},"KI-unterstützte Entwicklung",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Quellcodeverwaltung",{"href":119,"dataGaLocation":28,"dataGaName":120},"/de-de/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Automatisierte Softwarebereitstellung",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":28,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Bewertung",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Sichtbarkeit und Bewertung",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Wertstrommanagement",{"href":163,"dataGaLocation":28,"dataGaName":164},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Analysen und Einblicke",{"href":168,"dataGaLocation":28,"dataGaName":169},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab für",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/de-de/enterprise/","enterprise",{"text":179,"config":180},"Kleinunternehmen",{"href":181,"dataGaLocation":28,"dataGaName":182},"/de-de/small-business/","small business",{"text":184,"config":185},"den öffentlichen Sektor",{"href":186,"dataGaLocation":28,"dataGaName":187},"/de-de/solutions/public-sector/","public sector",{"text":189,"config":190},"Preise",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/de-de/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"Ressourcen",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Alle Ressourcen anzeigen",{"href":200,"dataGaName":196,"dataGaLocation":28},"/de-de/resources/",[202,235,258],{"title":203,"items":204},"Erste Schritte",[205,210,215,220,225,230],{"text":206,"config":207},"Installieren",{"href":208,"dataGaName":209,"dataGaLocation":28},"/de-de/install/","install",{"text":211,"config":212},"Kurzanleitungen",{"href":213,"dataGaName":214,"dataGaLocation":28},"/de-de/get-started/","quick setup checklists",{"text":216,"config":217},"Lernen",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Produktdokumentation",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Best-Practice-Videos",{"href":228,"dataGaName":229,"dataGaLocation":28},"/de-de/getting-started-videos/","best practice videos",{"text":231,"config":232},"Integrationen",{"href":233,"dataGaName":234,"dataGaLocation":28},"/de-de/integrations/","integrations",{"title":236,"items":237},"Entdecken",[238,243,248,253],{"text":239,"config":240},"Kundenerfolge",{"href":241,"dataGaName":242,"dataGaLocation":28},"/de-de/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":28},"/de-de/blog/","blog",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/de-de/teamops/","teamops",{"title":259,"items":260},"Vernetzen",[261,266,271,276,281],{"text":262,"config":263},"GitLab-Services",{"href":264,"dataGaName":265,"dataGaLocation":28},"/de-de/services/","services",{"text":267,"config":268},"Community",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Veranstaltungen",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"Partner",{"href":284,"dataGaName":285,"dataGaLocation":28},"/de-de/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":291,"config":292},"the source promo card",{"src":293},"/images/navigation/the-source-promo-card.svg",{"text":295,"config":296},"Lies die News",{"href":297,"dataGaName":298,"dataGaLocation":28},"/de-de/the-source/","the source",{"text":300,"config":301,"lists":303},"Unternehmen",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"Über",{"href":309,"dataGaName":310,"dataGaLocation":28},"/de-de/company/","about",{"text":312,"config":313,"footerGa":316},"Karriere",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"Geschäftsführung",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"Team",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"Handbuch",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Investor Relations",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Trust Center",{"href":342,"dataGaName":343,"dataGaLocation":28},"/de-de/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":28},"/de-de/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":360,"config":361,"lists":362},"Kontakt",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":35,"config":366},{"href":37,"dataGaName":367,"dataGaLocation":28},"talk to sales",{"text":369,"config":370},"Support",{"href":371,"dataGaName":372,"dataGaLocation":28},"/support/","get help",{"text":374,"config":375},"Kundenportal",{"href":376,"dataGaName":377,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":379,"login":380,"suggestions":387},"Schließen",{"text":381,"link":382},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":383,"config":384},"gitlab.com",{"href":42,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Vorschläge",[390,393,398,400,405,410],{"text":57,"config":391},{"href":62,"dataGaName":392,"dataGaLocation":386},"GitLab Duo (AI)",{"text":394,"config":395},"Code Suggestions (KI)",{"href":396,"dataGaName":397,"dataGaLocation":386},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":399},{"href":111,"dataGaName":109,"dataGaLocation":386},{"text":401,"config":402},"GitLab auf AWS",{"href":403,"dataGaName":404,"dataGaLocation":386},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":406,"config":407},"GitLab auf Google Cloud",{"href":408,"dataGaName":409,"dataGaLocation":386},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":411,"config":412},"Warum GitLab?",{"href":70,"dataGaName":413,"dataGaLocation":386},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425},{"text":416,"config":417},"Kostenlos testen",{"href":418,"dataGaName":33,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"GitLab-Symbol",{"src":423,"dataGaName":424,"dataGaLocation":419},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"/images/brand/gitlab-logo-type.svg",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"Erfahre mehr über GitLab Duo",{"href":62,"dataGaName":432,"dataGaLocation":419},"gitlab duo",{"altText":421,"config":434},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":436},{"src":427,"dataGaName":424,"dataGaLocation":419},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":442,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":443,"button":444,"config":449,"_id":451,"_type":14,"_source":16,"_file":452,"_stem":453,"_extension":19},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":445,"config":446},"Beta testen",{"href":447,"dataGaName":448,"dataGaLocation":28},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":450},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":455,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":660,"_type":14,"title":661,"_source":16,"_file":662,"_stem":663,"_extension":19},"/shared/de-de/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":652},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":459,"config":460},"Quelltext der Seite anzeigen",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Diese Seite bearbeiten",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Beteilige dich",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,558,588,622],{"title":46,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":55,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":189,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":191,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Vorteile von Premium",{"href":496,"dataGaName":497,"dataGaLocation":463},"/de-de/pricing/premium/","why premium",{"text":499,"config":500},"Vorteile von Ultimate",{"href":501,"dataGaName":502,"dataGaLocation":463},"/de-de/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Lösungen",[506,511,514,516,521,526,530,533,536,541,543,545,548,553],{"text":507,"config":508},"Digitale Transformation",{"href":509,"dataGaName":510,"dataGaLocation":463},"/de-de/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sicherheit und Compliance",{"href":137,"dataGaName":138,"dataGaLocation":463},{"text":122,"config":515},{"href":105,"dataGaName":106,"dataGaLocation":463},{"text":517,"config":518},"Agile Entwicklung",{"href":519,"dataGaName":520,"dataGaLocation":463},"/de-de/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Cloud-Transformation",{"href":524,"dataGaName":525,"dataGaLocation":463},"/de-de/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":119,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":109,"config":531},{"href":111,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":161,"config":534},{"href":163,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":174,"config":542},{"href":176,"dataGaName":177,"dataGaLocation":463},{"text":179,"config":544},{"href":181,"dataGaName":182,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":186,"dataGaName":187,"dataGaLocation":463},{"text":549,"config":550},"Bildungswesen",{"href":551,"dataGaName":552,"dataGaLocation":463},"/de-de/solutions/education/","education",{"text":554,"config":555},"Finanzdienstleistungen",{"href":556,"dataGaName":557,"dataGaLocation":463},"/de-de/solutions/finance/","financial services",{"title":194,"links":559},[560,562,564,566,569,571,574,576,578,580,582,584,586],{"text":206,"config":561},{"href":208,"dataGaName":209,"dataGaLocation":463},{"text":211,"config":563},{"href":213,"dataGaName":214,"dataGaLocation":463},{"text":216,"config":565},{"href":218,"dataGaName":219,"dataGaLocation":463},{"text":221,"config":567},{"href":223,"dataGaName":568,"dataGaLocation":463},"docs",{"text":244,"config":570},{"href":246,"dataGaName":247,"dataGaLocation":463},{"text":239,"config":572},{"href":573,"dataGaName":242,"dataGaLocation":463},"/customers/",{"text":249,"config":575},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":262,"config":577},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":254,"config":579},{"href":256,"dataGaName":257,"dataGaLocation":463},{"text":267,"config":581},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":583},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":585},{"href":279,"dataGaName":280,"dataGaLocation":463},{"text":282,"config":587},{"href":284,"dataGaName":285,"dataGaLocation":463},{"title":300,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":307,"config":591},{"href":309,"dataGaName":302,"dataGaLocation":463},{"text":312,"config":593},{"href":314,"dataGaName":315,"dataGaLocation":463},{"text":320,"config":595},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":597},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":599},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":335,"config":601},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":463},"/sustainability/",{"text":607,"config":608},"Vielfalt, Inklusion und Zugehörigkeit",{"href":609,"dataGaName":610,"dataGaLocation":463},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":612},{"href":342,"dataGaName":343,"dataGaLocation":463},{"text":350,"config":614},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":355,"config":616},{"href":357,"dataGaName":358,"dataGaLocation":463},{"text":618,"config":619},"Transparenzerklärung zu moderner Sklaverei",{"href":620,"dataGaName":621,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":623,"links":624},"Nimm Kontakt auf",[625,628,630,632,637,642,647],{"text":626,"config":627},"Sprich mit einem Experten/einer Expertin",{"href":37,"dataGaName":38,"dataGaLocation":463},{"text":369,"config":629},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":374,"config":631},{"href":376,"dataGaName":377,"dataGaLocation":463},{"text":633,"config":634},"Status",{"href":635,"dataGaName":636,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":638,"config":639},"Nutzungsbedingungen",{"href":640,"dataGaName":641,"dataGaLocation":463},"/terms/","terms of use",{"text":643,"config":644},"Datenschutzerklärung",{"href":645,"dataGaName":646,"dataGaLocation":463},"/de-de/privacy/","privacy statement",{"text":648,"config":649},"Cookie-Einstellungen",{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,658],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":463},{"text":643,"config":657},{"href":645,"dataGaName":646,"dataGaLocation":463},{"text":648,"config":659},{"dataGaName":650,"dataGaLocation":463,"id":651,"isOneTrustButton":91},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"allPosts":665,"featuredPost":1238,"totalPagesCount":1259,"initialPosts":1260},[666,696,718,739,760,783,803,823,847,868,888,910,931,951,973,995,1016,1036,1060,1082,1106,1131,1151,1172,1192,1216],{"_path":667,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":676,"config":689,"_id":692,"_type":14,"title":693,"_source":16,"_file":694,"_stem":695,"_extension":19},"/de-de/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"ogTitle":669,"schema":670,"ogImage":671,"ogDescription":672,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":675,"title":669,"canonicalUrls":675,"description":672},"GitLab Duo – die KI löst Probleme bei CI/CD-Pipelines ","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Entwicklung von GitLab Duo: mit KI und Ursachenanalyse zur Problembehebung bei CI/CD-Pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rutvik Shah\"},{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-06-06\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097321/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750097321081.png","Entdecke, wie wir die Ursachenanalyse mit KI aufgepeppt haben, um fehlerhafte CI/CD-Pipelines wieder zum Laufen zu bringen. Dabei erwarten dich Beispiele und Übungen, die du selbst ausprobieren kannst.","https://about.gitlab.com","article","https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"title":677,"description":672,"authors":678,"heroImage":671,"date":681,"body":682,"category":683,"tags":684},"Entwicklung von GitLab Duo: mit KI und Ursachenanalyse zur Problembehebung bei CI/CD-Pipelines",[679,680],"Rutvik Shah","Michael Friedrich","2024-06-06","***Generative KI bedeutet einen monumentalen Wandel in der\nSoftwareindustrie, da sie die Entwicklung, die Sicherheit und den Betrieb\nvon Software vereinfacht. Unsere neue Blog-Reihe, von unseren Produkt- und\nEntwicklungsteams, gibt einen Einblick darin, wie wir die\nKI-Funktionalitäten entwickeln, testen und bereitstellen, die in deinem\nUnternehmen benötigt werden. Lerne neue Funktionen innerhalb von GitLab Duo\nkennen und erfahre, wie diese DevSecOps-Teams dabei helfen werden, bessere\nErgebnisse für Kund(inn)en zu erzielen.***\n\n\nHattest du schon einmal eine defekte [CI/CD-Pipeline](https://about.gitlab.com/topics/ci-cd/benefits-continuous-integration/) und musstest deinen DevSecOps-Workflow unterbrechen oder sogar das Deployment verzögern, um die Ursache herauszufinden? Wenn bei der Entwicklung von Software etwas schief läuft, müssen Entwickler(innen) traditionellerweise die Fehler selbst beheben, Logdatei über Logdatei durchforsten und oft viele Behebungsversuche durchführen. Mit der [Ursachenanalyse von GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/), die Teil unserer Suite aus KI-Funktionen ist, hat das Rätselraten nun ein Ende, denn diese findet für dich die Ursache einer defekten CI/CD-Pipeline. In diesem Artikel erfährst du, was die Ursachenanalyse ist und wie du die KI-Funktionen von GitLab Duo in deinen DevSecOps-Workflow einbauen kannst.\n\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\n## Was ist eine Ursachenanalyse?\n\n\nDie Ursachenanalyse von GitLab Duo ist eine KI-Funktionalität, die dir dabei hilft, die Grundursache eines fehlerhaften CI/CD-Joblauf herauszufinden. Sie analysiert die Protokolle und schlägt dir dann Möglichkeiten zur Behebung vor. Während die Ursachenanalyse oft im Incident Management angesiedelt ist, sind ihre Workflows und die Fehlersuche Teil eines jeden DevSecOps-Workflows. Ops-Teams, Adminstrator(inn)en und Plattformentwickler(innen) stehen durch Bereitstellungsprobleme, die durch Infrastructure as Code (IaC) entstehen, Kubernetes- und GitOps-Probleme oder durch die lange Nachverfolgung von Stacktraces und Untersuchung von Pipeline-Fehlschlägen vor Herausforderungen.\n\n\nMit der Ursachenanalyse von GitLab Duo nutzen alle dasselbe Interface. Mit Hilfe von KI werden Fehler zusammengefasst, analysiert und Lösungsvorschläge gemacht, damit Unternehmen schneller sichere Software veröffentlichen können.\n\n\nEine Pipeline kann aus verschiedensten Gründen Fehler aufweisen, darunter Syntax-Fehler im Code, fehlende Abhängigkeiten, auf denen die Pipeline basiert, Testfehler während des Build-Vorgangs, Zeitüberschreitungen bei Kubernetes- und IaC-Bereitstellungen sowie zahlreiche weitere Probleme. Wenn solche Probleme auftreten, liegt es in der Verantwortung von allen, die durch die Pipeline erstellten Logs genauestens zu überprüfen. Bei der Überprüfung der Logs wird dann der detaillierte Output untersucht, um spezifische Fehlschläge aufzudecken und die Ursache der defekten Pipeline zu finden. Die folgende Pipeline hat beispielsweise mehrere fehlgeschlagene Jobs, die untersucht und repariert werden müssen.\n\n\n![Bild mit mehreren Job-Ausfällen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097332601.png)\n\n\nEs kann unterschiedlich lange dauern, diese Probleme zu beheben. Das hängt zum Großteil von Faktoren wie den folgenden ab:\n\n\n* Wie vertraut die Entwickler(innen) mit dem Projekt sind\n\n* Ihr Erfahrungsniveau beim Umgang mit ähnlichen Problemen\n\n* Ihr allgemeines Kenntnislevel in der Fehlerbehebung im Kontext der Pipeline.\n\n\nDie manuelle Analyse kann unglaublich herausfordernd und zeitaufwändig sein, da die Logs aus Anwendungsprotokollen und Systemmeldungen mit einer Vielzahl an Fehlerquellen bestehen. Die typische Behebung einer Pipeline besteht aus mehreren Iterationen und Kontextwechseln. Aufgrund der Komplexität und der unstrukturierten Natur der Protokolle ist dies ein idealer Bereich, in dem generative KI die Arbeit beschleunigen kann. Durch den Einsatz von KI können Fehler in einer Pipeline signifikant schneller erkannt und behoben werden. Außerdem ist weniger Expertise für die Behebung einer Pipeline wie im obigen Beispiel erforderlich.Sieh dir die Ursachenanalyse von GitLab Duo in Aktion an:\n\n\n\u003C!-- blank line -->\n\n\n\u003Cfigure class=\"video_container\">\n\n \u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\n\u003C!-- blank line -->\n\n\n## Wie funktioniert die Ursachenanalyse?\n\n\nBei der [Ursachenanalyse](https://docs.gitlab.com/ee/user/ai_experiments.html#root-cause-analysis) wird ein Teil des CI/CD-Stacktraces an ein [GitLab-KI-Gateway](https://docs.gitlab.com/ee/architecture/blueprints/ai_gateway/) weitergeleitet. GitLab stellt sicher, dass der weitergeleitete Teil in die Limitierungen des umfangreichen Sprachmodells (LLM) passt und erstellt einen vorgefertigten Prompt, um herauszufinden, warum der Job fehlgeschlagen sein könnte. Der Prompt weist das LLM außerdem an, ein Beispiel aufzuzeigen, wie ein(e) Benutzer(in) den fehlerhaften Job beheben könnte. Nachfolgend sind zwei Beispielszenarien, in denen die Ursachenanalyse hilfreich sein kann.\n\n\n#### 1. Analyse eines Abhängigkeitsfehlers in Python\n\n\nEine Python-Anwendung kann zusätzliche Bibliotheken mit Funktionen importieren, die nicht in der Standardbibliothek enthalten sind. Das Projekt [Ursachenanalyse – Python-Konfiguration](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config) implementiert eine Anwendung, die die Konfiguration parst und eine SQLite-Datenbank initialisiert, wobei beide auch ohne zusätzlich installierte Abhängigkeiten funktionieren. Das Beispiel verwendet Best Practices in CI/CD mit einer Python-Umgebung sowie Cashing. Zuletzt wurde nun ein Redis-Caching-Client hinzugefügt, und jetzt schlägt der CI/CD-Build aus irgendeinem Grund fehl. \n\n\nDurch die Ursachenanalyse erfährst du sofort, dass `ModuleNotFoundError` bedeutet, dass das Modul tatsächlich nicht in der Python-Umgebung installiert ist. GitLab Duo schlägt außerdem einen Fix vor: Installiere das Redis-Modul über den PIP-Paketmanager.\n\n\n![Bild mit „modulenotfounderror“ und Lösungsvorschlag von GL Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097332602.png)\n\n\nDie fehlerhafte Pipeline kann [hier](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config/-/jobs/6992716398) eingesehen werden. \n\n\nDas Ergebnis der Ursachenanalyse gibt eine Zusammenfassung des Problems aus, das offensichtlich ein Fehler mit einem fehlenden `redis`-Modul ist. Versuchen wir nun, das Problem zu beheben, indem das `redis`-Modul installiert wird. Du kannst entweder `pip install redis` im Abschnitt `script` des CI/CD-Jobs aufrufen oder einen generellen Weg über die Datei `requirements.txt` wählen. Letztere ist nützlich für eine Single Source of Truth (einzige Quelle der Wahrheit) für Abhängigkeiten, die in der Entwicklungsumgebung und in CI/CD-Pipelines installiert wurden.\n\n\n```yaml\n\ntest:\n  extends: [.python-req]\n  stage: test \n  before_script:\n    # [🦊] hint: Root cause analysis. # Solution 1: Install redis using pip\n    - pip install redis\n    # Solution 2: Add redis to requirements.txt, use pip\n    - pip install -r requirements.txt \n\n  script:\n    - python src/main.py\n```\n\n\nNachdem du die fehlende Python-Abhängigkeit behoben hast, schlägt der CI/CD-Job erneut fehl. Führe erneut eine Ursachenanalyse durch, um zu erfahren, dass kein Redis-Service den Job ausführt. Wechsle zum GitLab Duo Chat und gib den Prompt `How to start a Redis service in CI/CD` ein, um zu erfahren, wie du das Attribut `services` im CI/CD-Job konfigurierst.\n\n\n![Zeigt die Aufforderung zum Starten eines Redis-Dienstes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097333/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097332602.png)\n\n\nÄndere `.gitlab-ci.yml` mit dem Job `test` und gib unter service den Dienst `redis` an.\n\n\n```yaml\n\ntest:\n  extends: [.python-req]\n  stage: test \n  before_script:\n    # [🦊] hint: Root cause analysis.\n    # Solution 1: Install redis using pip\n    - pip install redis\n    # Solution 2: Add redis to requirements.txt, use pip\n    - pip install -r requirements.txt \n\n  script:\n    - python src/main.py\n\n  # Solution 3 - Running Redis\n  services:\n    - redis\n```\n\n\nWenn der Redis-Server ausgeführt wird, kannst du die Python-Anwendung erfolgreich ausführen und die Ausgabe im CI/CD-Log sehen.\n\n\n![Ausgabe der Python-Anwendung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097332603.png)\n\n\nDie Lösung kann auch im Unterordner in [/solution](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-python-config/-/tree/main/solution?ref_type=heads) eingesehen werden.\n\n\n**Tipp:** Du kannst den [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) auch bitten, zukünftige Probleme zu verfolgen:\n\n\n```markdown\n\nHow to lint Python code? Which tools are recommended for CI/CD.\n\nHow to pin a package version in Python requirements file?\t\n\nWhat are possible ways that this exception stacktrace is triggered in the future?\n\nAre there ways to prevent the application from failing?\n\n```\n\n\nDas nächste Beispiel ist fortgeschrittener und umfasst mehrere Probleme.\n\n\n#### 2. Fehlende Go-Laufzeit analysieren\n\n\nCI/CD-Jobs können in Containern ausgeführt werden, die über das Attribut `image` konfiguriert werden. Wenn der Container keine Programmiersprachen-Laufzeit bereitstellt, schlagen die ausgeführten Kommandos in `script`, die auf die Binärdatei `go` referenzieren, fehl. Beispielsweise muss dann die Fehlermeldung `/bin/sh: eval: line 149: go: not found` verstanden und behoben werden. \n\n\nWenn der Befehl `go` nicht im Laufzeit Kontext des Containers gefunden wird, kann dies mehrere Gründe haben:\n\n\n1. Der Job verwendet ein minimales Container-Image, z. B. `alpine`, und die Go-Laufzeit wurde nicht installiert.\n\n2. Der Job verwendet das falsche Standard-Container-Image, z. B. das oben in der CI/CD-Konfiguration angegebene oder das Schlüsselwort `default`.\n\n3. Der Job verwendet kein Container-Image, sondern den Shell Executor. Auf dem Host-Betriebssystem ist die Go-Laufzeit nicht installiert oder ist anderweitig defekt/nicht konfiguriert.\n\n\nDas Projekt [Ursachenanalyse – Go GitLab Release Fetcher](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-go-gitlab-release-fetcher) bietet ein Übungsprojekt zur Analyse und Behebung von CI/CD-Problemen mit einer in Go geschriebenen GitLab-Release-Fetcher-Anwendung. Die CI/CD-Jobs `build` und `docker-build` schlagen fehl. Für die Behebung des Problems sind verschiedene Voraussetzungen erforderlich: Du musst verstehen, warum die Go-Laufzeit nicht installiert ist, und etwas über die Syntax `Dockerfile` erfahren.\n\n\n![Screenshot zeigt den fehlgeschlagenen Job „Change Docker Label“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097332603.png)\n\n\nDas [`solution/`-Verzeichnis](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/root-cause-analysis/challenge-root-cause-analysis-go-gitlab-release-fetcher) bietet nach der Ursachenanalyse zwei mögliche Lösungen.\n\n\n## Probiere die Ursachenanalyse aus\n\n\nDie folgenden Szenarien kannst du verwenden, um die Ursachenanalyse auszuprobieren.\n\n\n* Wenn du auf Kubernetes-Bereitstellungsfehler oder Zeitüberschreitungen stößt. \n\n* Wenn OpenTofu- oder Terraform-IAC-Pipelines die Cloud-Ressourcen nicht bereitstellen können.\n\n* Wenn das Ansible-Playbook mit einem kryptischen Berechtigungsfehler in CI/CD fehlschlägt.\n\n* Wenn der Java Stacktracer 10 Seiten lang ist.\n\n* Mit einem Shell-Skript, das einen Ausführungsfehler provoziert.\n\n* Wenn ein Perl-Skript in einer Zeile fehlschlägt, die die einzige Zeile im Skript ist.\n\n* Wenn der CI/CD-Job eine Zeitüberschreitung aufweist und nicht klar ist, welcher Abschnitt diese verursacht.\n\n* Wenn eine Zeitüberschreitung der Netzwerkverbindung erreicht wird und du denkst, dass es kein DNS sein kann.\n\n\n### Wie geht es mit der Ursachenanalyse von GitLab Duo in Zukunft weiter?\n\n\nWir wollen unseren Nutzer(inne)n langfristig helfen, ihre Pipelines in weniger Iterationen und schneller zu reparieren. Die Ursachenanalyse wird dabei in GitLab Duo Chat, unserem KI Assistenten, geöffnet und zeigt die Antwort dort. Benutzer(innen) können die Empfehlung dann direkt verwenden oder weiter mit dem Chat agieren, indem sie spezifische, weiterführende Fragen stellen (z. B. spezifische Fixes für eine bestimmte Programmiersprache) oder indem sie je nach Ursache nach alternativen Lösungen fragen.\n\n\nZum Beispiel ist hier die Ursachenanalyse für einen fehlgeschlagenen Job:\n\n\n![Antwort auf die Grundursachenanalyse](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097332/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097332603.png)\n\n\nBenutzer(innen) können Folgefragen stellen, die auf der von der KI generierten Antwort basieren.\n\n\n* Ich möchte kein eigenes Docker Image erstellen. Bitte erkläre mir andere Möglichkeiten, das Problem zu beheben.\n\n* Ich habe keinen Zugriff auf die Docker-Image-Erstellung. Es sieht so aus, als würde die Go-Binärdatei fehlen. Gibt es alternative Images, die du vorschlagen kannst?\n\n\nGitLab führt außerdem Qualitäts-Vergleiche für die erstellten Antworten durch, um das Nutzererlebnis langfristig zu verbessern.\n\n\nWeitere Informationen findest du in unserem [Epic zur Ursachenanalyse](https://gitlab.com/groups/gitlab-org/-/epics/13080). Wir würden uns auch über dein Feedback zu dieser Funktionalität freuen. Bitte hinterlasst dafür einen Kommentar in unserem [Feedback-Ticket zur Ursachenanalyse](https://gitlab.com/groups/gitlab-org/-/epics/13872).\n\n\n## Erste Schritte mit der Ursachenanalyse\n\n\nIn unserer [Dokumentation](https://docs.gitlab.com/ee/user/ai_experiments.html#root-cause-analysis) findest du Informationen dazu, wie du die Funktion als GitLab-Ultimate-Kund(inn)en aktivieren kannst. Außerdem ist die Ursachenanalyse von GitLab Duo bald in GitLab Self-Managed und GitLab Dedicated verfügbar.\n\n\nBist du kein(e) GitLab-Ultimate-Kunde/Kundin? Starte jetzt [deine kostenlose Testversion](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n","ai-ml",[685,686,9,687,688],"AI/ML","tutorial","DevSecOps platform","features",{"slug":690,"featured":91,"template":691},"developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd","BlogPost","content:de-de:blog:developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd.yml","Developing Gitlab Duo Blending Ai And Root Cause Analysis To Fix Ci Cd","de-de/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd.yml","de-de/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"_path":697,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":698,"content":704,"config":712,"_id":714,"_type":14,"title":715,"_source":16,"_file":716,"_stem":717,"_extension":19},"/de-de/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"ogTitle":699,"schema":700,"ogImage":701,"ogDescription":702,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":703,"title":699,"canonicalUrls":703,"description":702},"GitLab Duo – Wie wir LLMs validieren & testen","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Entwicklung von GitLab Duo: Wie wir KI-Modelle im großen Maßstab validieren und testen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"}],\n        \"datePublished\": \"2024-05-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659856/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25.png","Unsere Blog-Serie beginnt mit einem Blick hinter die Kulissen, wie wir LLMs evaluieren, sie an Anwendungsfälle anpassen und sie optimieren, um bessere Ergebnisse für die Benutzer(innen) zu erzielen.","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"title":705,"description":702,"authors":706,"heroImage":701,"date":708,"body":709,"category":683,"tags":710},"Entwicklung von GitLab Duo: Wie wir KI-Modelle im großen Maßstab validieren und testen",[707],"Susie Bitters","2024-05-09","**_Generative KI markiert einen monumentalen Wandel in der Softwareentwicklungsbranche, der es einfacher macht, Software zu entwickeln, sicherer zu machen und sie zu betreiben. Unsere neue Blog-Serie von unseren Produkt- und Entwicklungsteams gibt einen Einblick darin, wie wir die KI-Funktionen erstellen, testen und bereitstellen, die in deinem Unternehmen benötigt werden. Lerne neue Funktionen innerhalb von GitLab Duo kennen und wie sie DevSecOps-Teams dabei helfen, bessere Ergebnisse für Kund(inn)en zu erzielen._**\n\nGitLab schätzt das Vertrauen unserer Kund(inn)en in uns. Ein Teil der Aufrechterhaltung dieses Vertrauens ist die Transparenz darüber, wie wir die hochwertige Funktionalität unserer [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) KI-Funktionen erstellen, bewerten und gewährleisten. Die Funktionen von GitLab Duo basieren auf einer Vielzahl von Modellen, die es uns ermöglichen, eine Vielzahl von Anwendungsfällen zu unterstützen und unseren Kund(inn)en Flexibilität zu bieten. GitLab ist von vornherein nicht an einen einzigen Modellanbieter gebunden. Wir verwenden derzeit Foundation-Modelle von [Google](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/vertex_text.py?ref_type=heads#L86) und [Anthropic](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/anthropic.py?ref_type=heads#L62). Wir wägen jedoch kontinuierlich ab, welche Modelle für die Anwendungsfälle von GitLab Duo geeignet sind. In diesem Artikel geben wir einen Einblick in unseren Validierungsprozess für KI-Modelle.\n\n## Was sind LLMs\n\nUmfangreiche Sprachmodelle (Large language models, LLMs) sind generative KI-Modelle, die viele KI-Funktionen innerhalb der GitLab Plattform unterstützen. LLMs wurden mit riesigen Datensätzen trainiert und prognostizieren das nächste Wort in einer Sequenz basierend auf dem vorhergehenden Kontext. Als Antwort auf eine Eingabe (Prompt) von Benutzer(innen) erzeugen sie Text, der der Antwort eines Menschen ähnelt, indem sie abhängig vom Prompt aus der Wahrscheinlichkeitsverteilung von Wörtern ein Muster wiedergeben.\n\nLLMs ermöglichen es, intelligente Codevorschläge, Konversations-Chatbots, Code-Erklärungen, Analysen von Sicherheitslücken und mehr umzusetzen. Ihre Fähigkeit, für einen bestimmten Prompt unterschiedliche Antworten zu erzeugen, macht eine standardisierte Qualitätsbewertung schwierig. Da LLMs für verschiedene Eigenschaften optimiert werden können, werden so viele unterschiedliche KI-Modelle aktiv entwickelt.\n\n## Testen im großen Maßstab\n\nIm Gegensatz zu herkömmlichen Softwaresystemen, bei denen Ein- und Ausgaben einfacher definiert und getestet werden können, erzeugen LLMs Ausgaben, die oft nuanciert, vielfältig und kontextabhängig sind. Um diese Modelle zu testen, sind umfassende Strategien erforderlich, die die subjektiven und variablen Interpretationen von Qualität sowie die stochastische Natur ihrer Ergebnisse berücksichtigen. Wir können daher die Qualität der Ergebnisse eines LLM nicht individuell oder anekdotisch beurteilen. Stattdessen müssen wir in der Lage sein, das Gesamtmuster des Verhaltens eines LLM zu untersuchen. Um ein Gefühl für diese Muster zu bekommen, müssen wir in großem Maßstab testen. Darunter versteht man den Prozess der Bewertung der Leistung, Zuverlässigkeit und Robustheit eines Systems oder einer Anwendung über eine große und vielfältige Anzahl von Datensätzen und Anwendungsfällen. Unser [Centralized Evaluation Framework (CEF)](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/) verwendet Tausende von Prompts, die mit Dutzenden von Anwendungsfällen verknüpft sind, um signifikante Muster zu identifizieren und das Gesamtverhalten unserer grundlegenden LLMs und der GitLab Duo-Funktionen, in die sie integriert sind, zu bewerten.\n\nTesten im großen Maßstab hilft uns bei der:\n\n- **Gewährleistung von Qualität:** Durch Tests im großen Maßstab können wir die Qualität und Zuverlässigkeit dieser Modelle in einer Vielzahl von Szenarien und Inputs bewerten. Indem wir die Ergebnisse dieser Modelle in großem Maßstab validieren, können wir Muster identifizieren und potenzielle Probleme wie systematische Verzerrungen, Anomalien und Ungenauigkeiten abmildern.\n- **Optimierung der Leistung:** Die Intensivierung der Tests ermöglicht es GitLab, die Leistung und Effizienz von LLMs unter realen Bedingungen zu beurteilen. Dazu gehört die Bewertung von Faktoren wie Ausgabequalität, Latenz und der Kosten für die Optimierung der Bereitstellung und des Einsatzes dieser Modelle in GitLab Duo-Funktionen.\n- **Minderung von Risiken:** Das Testen von LLMs im großen Maßstab trägt dazu bei, die mit der Bereitstellung von LLMs in kritischen Anwendungen verbundenen Risiken zu mindern. Durch gründliche Tests über verschiedene Datensätze und Anwendungsfälle hinweg können wir potenzielle Fehlermodi, Sicherheitslücken und ethische Bedenken identifizieren und diese adressieren und beheben, bevor sie sich auf unsere Kund(inn)en auswirken.\n\nDas Testen von LLMs im großen Maßstab ist unerlässlich, um ihre Zuverlässigkeit und Robustheit für ihre Bereitstellung innerhalb der GitLab-Plattform sicherzustellen. Durch die Investition in umfassende Teststrategien, die verschiedene Datensätze, Anwendungsfälle und Szenarien umfassen, arbeitet GitLab daran, das volle Potenzial von KI-gestützten Workflows auszuschöpfen und gleichzeitig potenzielle Risiken zu mindern.\n\n### Wie wir in großem Maßstab testen\n\nDies sind die notwendigen Schritte, um LLMs in großem Maßstab zu testen.\n\n#### Schritt 1: Erstellen einer Prompt-Bibliothek als Proxy für die Produktion\nWährend andere Unternehmen Kundendaten einsehen und verwenden, um ihre KI-Funktionen zu trainieren, tut GitLab dies derzeit nicht.  Deshalb mussten wir eine umfassende Prompt-Bibliothek entwickeln, die sowohl den Umfang als auch die Aktivität der Produktionsumgebung abbildet.\n\nDiese Prompt-Bibliothek besteht aus Fragen und Antworten. Die Fragen stellen die Art von Abfragen oder Eingaben dar, die wir in der Produktionsumgebung erwarten würden, während die Antworten eine Grundwahrheit darüber darstellen, was unsere ideale Antwort wäre. Diese Referenzantwort könnte auch als Zielantwort formuliert werden. Sowohl die Frage als auch die Antwort können, aber müssen nicht von Menschen generiert werden. Diese Frage-Antwort-Paare geben uns eine Vergleichsbasis und einen Bezugsrahmen, mit dem wir die Unterschiede zwischen Modellen und Funktionen herausarbeiten können. Wenn mehreren Modellen dieselbe Frage gestellt wird und sie unterschiedliche Antworten erzeugen, können wir anhand unserer Referenzantwort feststellen, welches Modell eine Antwort gegeben hat, die unserem Ziel am nächsten kommt, und sie entsprechend bewerten.\n\nAuch hier ist ein zentrales Element einer umfassenden Prompt-Bibliothek, dass sie repräsentativ für die Eingaben ist, die wir in der Produktionsumgebung erwarten. Wir möchten wissen, wie gut die grundlegenden Modelle zu unserem spezifischen Anwendungsfall passen und wie gut unsere Funktionen funktionieren. Es gibt zahlreiche Datensätze mit Benchmark-Prompts, aber diese Datensätze spiegeln möglicherweise nicht die Anwendungsfälle wider, die wir bei GitLab annehmen. Unsere Prompt-Bibliothek ist so konzipiert, dass sie speziell auf die Funktionen und Anwendungsfälle von GitLab zugeschnitten ist.\n\n#### Schritt 2: Leistung des Basismodells\n\nSobald wir eine Prompt-Bibliothek erstellt haben, die die Produktionsaktivitäten genau widerspiegelt, geben wir diese Fragen in [verschiedene Modelle](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/foundation_models/) ein, um zu testen, wie gut sie den Bedürfnissen unserer Kund(inn)en entsprechen. Wir vergleichen jede Antwort mit unserer Grundwahrheit und reihen sie in eine Rangfolge ein, die auf einer Reihe von Metriken basiert, wie zum Beispiel: [Cosine Similarity Score](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#similarity-scores), [Cross Similarity Score](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#cross-similarity-score),  [LLM Judge](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#llm-judge), und [Consensus Filtering mit LLM Judge](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#consensus-filtering-with-llm-judge). Diese erste Iteration liefert uns einen Anhaltspunkt dafür, wie gut die einzelnen Modelle abschneiden, und hilft uns bei der Auswahl eines grundlegenden Modells für unsere Einsatzbereiche. Um uns kurz zu fassen, werden wir hier nicht ins Detail gehen, aber du kannst [hier mehr über die Metriken erfahren](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/). Es ist wichtig zu wissen, dass dieses Problem nicht gelöst ist. Die KI-Branche forscht aktiv an neuen Techniken und entwickelt sie weiter. Das Modellvalidierungsteam von GitLab behält die Branche im Auge und arbeitet ständig daran, wie wir die von GitLab Duo verwendeten LLMs prüfen und bewerten.\n\n#### Schritt 3: Funktionsentwicklung\n\nJetzt, da wir eine Grundlage für die Leistung unseres ausgewählten Modells haben, können wir mit den gewonnen Daten unsere Plattform weiterentwickeln. Prompt-Engineering ist zwar sehr populär, aber wenn man sich ausschließlich darauf konzentriert, das Verhalten eines Modells durch Prompting (oder eine andere Technik) zu verändern, ohne es zu validieren, stochert man im Dunkeln und passt sein Prompting sehr wahrscheinlich zu stark an. Man löst vielleicht ein Problem, aber verursacht ein Dutzend andere. Und es würde wahrscheinlich nie auffallen. Wenn wir eine Grundlinie für die Leistung eines Modells festlegen, können wir verfolgen, wie sich das Verhalten im Laufe der Zeit für alle notwendigen Anwendungsfälle verändert. Bei GitLab überprüfen wir die Leistung unserer GitLab Duo Funktionen während der aktiven Entwicklung täglich neu, um sicherzustellen, dass alle Änderungen die Gesamtfunktionalität verbessern.\n\n#### Schritt 4: Iterieren, iterieren, iterieren\n\nUnsere experimentellen Iterationen funktionieren wie folgt: In jedem Durchgang untersuchen wir die Ergebnisse unserer Tests im großen Maßstab, um Muster zu erkennen:\n\n- Was haben unsere schwächsten Bereiche gemeinsam?\n- Verhält sich unsere Funktion für eine bestimmte Metrik oder in einem bestimmten Anwendungsfall ungünstig?\n- Gibt es bei bestimmten Fragen immer wieder dieselben Fehler?\n\nSolche Muster tauchen nur dann auf, wenn wir in großem Maßstab testen, und nur so können wir unsere Experimente optimieren. Auf der Grundlage dieser Muster schlagen wir verschiedene Experimente oder Ansätze vor, um die Leistung in einem bestimmten Bereich und für eine bestimmte Metrik zu verbessern.\n\nTesten im großen Maßstab ist jedoch sowohl teuer als auch zeitaufwendig. Um eine schnellere und kostengünstigere Iteration zu ermöglichen, erstellen wir einen kleineren Datensatz, der als Mini-Proxy fungiert. Die begrenzte Teilmenge wird so gewichtet, dass sie genau die Frage-Antwort-Paare enthält, die wir verbessern möchten. Die erweiterte Teilmenge enthält auch eine Auswahl aller anderen Anwendungsfälle und Bewertungen, um sicherzustellen, dass sich unsere Änderungen nicht nachteilig auf die allgemeine Funktionalität auswirken. Wir nehmen also Änderungen vor und überprüfen sie gegen eine begrenzte Teilmenge der Daten. Wie sieht die neue Antwort im Vergleich zur Ausgangslage aus? Wie verhält es sich mit der Grundwahrheit?\n\nSobald wir einen Prompt gefunden haben, der sich auf den spezifischen Anwendungsfall bezieht, an dem wir gerade mit der begrenzten Teilmenge arbeiten, validieren wir diesen Prompt anhand einer erweiterten Teilmenge von Daten, um sicherzustellen, dass er sich nicht nachteilig auf andere Bereiche auswirkt. Nur wenn wir durch die Validierungsmetriken der Meinung sind, dass der neue Prompt unsere Leistung in unserem Zielbereich verbessert UND die Leistung an anderer Stelle nicht verschlechtert, setzen wir diese Änderung in der Produktionsumgebung um.\n\nDas gesamte Centralized Evaluation Framework wird dann mit dem neuen Prompt ausgeführt und wir überprüfen, ob die Leistung der gesamten Funktionalität gegenüber der Ausgangssituation vom Vortag verbessert wurde. Auf diese Weise stellt GitLab durch ständige Iterationen sicher, dass du im gesamten GitLab-Ökosystem die neueste und beste Leistung der KI-gestützten Funktionen erhältst. So können wir sicherstellen, dass wir gemeinsam immer schneller arbeiten.\n\n### GitLab Duo noch besser machen\n\nWir hoffen, dass wir dir hiermit einen Einblick geben konnten, wie wir die Funktionen von GitLab Duo verantwortungsvoll entwickeln. Dieser Prozess wurde entwickelt, um [GitLab Duo Codevorschläge](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/) und [GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) allgemein verfügbar zu machen. Wir haben diesen Validierungsprozess auch in unseren Entwicklungsprozess integriert, wenn wir die Funktionen von GitLab Duo weiterentwickeln. Es bedeutet unzählige Versuche und Fehlschläge, und oft macht die Korrektur eines Punkts drei andere kaputt. Aber wir erhalten dabei auch datengestützte Einblicke in diese Auswirkungen und können so sicherstellen, dass GitLab Duo immer besser wird.\n\n> Starte noch heute deine [kostenlose Testversion von GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial)!\n\n\u003Cfigure class=video_container>\n\u003Ciframe width=560 height=315 src=\"https://www.youtube-nocookie.com/embed/LifJdU3Qagw?si=A4kl6d32wPYC4168\" title=\"YouTube video player\" frameborder=0 allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen=\"\">\u003C/iframe>\n\u003C/figure>",[685,9,687,688,711],"inside GitLab",{"slug":713,"featured":91,"template":691},"developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale","content:de-de:blog:developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","Developing Gitlab Duo How We Validate And Test Ai Models At Scale","de-de/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","de-de/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"_path":719,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":720,"content":726,"config":733,"_id":735,"_type":14,"title":736,"_source":16,"_file":737,"_stem":738,"_extension":19},"/de-de/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation",{"title":721,"description":722,"ogTitle":721,"ogDescription":722,"noIndex":6,"ogImage":723,"ogUrl":724,"ogSiteName":673,"ogType":674,"canonicalUrls":724,"schema":725},"Effiziente DevSecOps-Workflows: Praktische python-gitlab-API-Automatisierung","Die Python-GitLab-Bibliothek ist eine nützliche Basis für die GitLab-API. In diesem Tutorial erfährst du mehr über praktische Beispiele und bewährte Verfahren.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659883/Blog/Hero%20Images/post-cover-image.jpg","https://about.gitlab.com/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Effiziente DevSecOps-Workflows: Praktische python-gitlab-API-Automatisierung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2023-02-01\",\n      }",{"title":721,"description":722,"authors":727,"heroImage":723,"date":728,"body":729,"category":730,"tags":731,"updatedDate":732},[680],"2023-02-01","Ein oft zitiertes Sprichwort aus einer Konferenzpräsentation lautet:\n„Manuelle Arbeit ist ein Fehler“. Bei sich wiederholenden Aufgaben in\nArbeitsabläufen ist es ratsam, so viel wie möglich zu automatisieren. Ein\nBeispiel dafür ist die Nutzung einer REST-API zur Bestandsaufnahme von\nEinstellungen oder das Erstellen neuer Kommentare in GitLab-Issues und\nMerge-Anfragen mittels API-Aktionen.\n\n\n## GitLab-API-Interaktion: Möglichkeiten und Unterstützung durch\nAPI-Abstraktionsbibliotheken\n\n\nDie Interaktion mit der REST-API von GitLab kann auf verschiedene Weise\nerfolgen: entweder durch HTTP-Anfragen mit curl (oder hurl) in der\nBefehlszeile oder durch das Schreiben von Skripten in einer\nProgrammiersprache. Letzteres kann dazu führen, dass der Code für\nHTTP-Anfragen und das Parsen der JSON-Antworten neu entwickelt werden muss.\nGlücklicherweise unterstützt die umfangreiche GitLab-Community viele\nProgrammiersprachen mit API-Abstraktionsbibliotheken.\n\n\nDiese Bibliotheken bieten Unterstützung für alle API-Attribute, fügen\nHilfsfunktionen zum Abrufen, Erstellen und Löschen von Objekten hinzu und\nhelfen Entwicklern dabei, sich auf ihre Kernaufgaben zu konzentrieren. Die\n[python-gitlab Bibliothek](https://python-gitlab.readthedocs.io/en/stable/)\nist ein besonders funktionsreiches und einfach zu verwendendes Beispiel für\neine solche Bibliothek in Python.\n\n\nIn diesem Blogbeitrag wird die grundlegende Nutzung der\npython-gitlab-Bibliothek erläutert, einschließlich der Arbeit mit\nAPI-Objekten, Attributen, Paginierung und Resultsets. Zudem werden\nspezifischere Anwendungsfälle vorgestellt, in denen Daten gesammelt,\nZusammenfassungen gedruckt und Daten in die API geschrieben werden, um\nKommentare und Commits zu erstellen. Viele dieser Anwendungsfälle basieren\nauf Fragen aus der Community in Foren, auf Hacker News oder in Issues.\n\n\n## Inhaltsverzeichnis\n\n- [GitLab-API-Interaktion: Möglichkeiten und Unterstützung durch\nAPI-Abstraktionsbibliotheken](#gitlab-api-interaktion-möglichkeiten-und-unterstützung-durch-api-abstraktionsbibliotheken)\n\n- [Los geht's: python-gitlab Install](#los-geht's-python-gitlab-install)\n\n- [GitLab API Python: Konfiguration](#gitlab-api-python-konfiguration)\n\n- [Objekte verwalten: das\nGitLab-Objekt](#objekte-verwalten-das-gitlab-objekt)\n  - [Objektmanager und Laden von Objekten](#objektmanager-und-laden-von-objekten)\n  - [Paginierung der Ergebnisse](#paginierung-der-ergebnisse)\n  - [Arbeiten mit Objektbeziehungen](#arbeiten-mit-objektbeziehungen)\n  - [Arbeiten mit verschiedenen Objektsammlungsbereichen](#arbeiten-mit-verschiedenen-objektsammlungsbereichen)\n- [DevSecOps-Anwendungsfälle für\nAPI-Leseaktionen](#devsecops-anwendungsfälle-für-api-leseaktionen)\n  - [Zweige nach Zusammenführungsstatus auflisten](#zweige-nach-zusammenführungsstatus-auflisten)\n  - [Drucken von Projekteinstellungen zur Überprüfung: MR-Genehmigungsregeln](#drucken-von-projekteinstellungen-zur-überprüfung-mr-genehmigungsregeln)\n  - [Inventarisierung: Abrufen aller CI/CD-Variablen, die geschützt oder maskiert sind](#inventarisierung-abrufen-aller-cicd-variablen-die-geschützt-oder-maskiert-sind)\n  - [Herunterladen einer Datei aus dem Repository](#herunterladen-einer-datei-aus-dem-repository)\n  - [Hilfe zur Migration: Auflistung aller zertifikatsbasierten Kubernetes-Cluster](#hilfe-zur-migration-auflistung-aller-zertifikatsbasierten-kubernetes-cluster)\n  - [Team-Effizienz: Prüfe, ob bestehende Merge-Requests nach dem Mergen einer großen Refactoring-MR neu gebasht werden müssen](#team-effizienz-prüfe-ob-bestehende-merge-requests-nach-dem-mergen-einer-großen-refactoring-mr-neu-gebasht-werden-müssen)\n- [DevSecOps-Anwendungsfälle für\nAPI-Schreibaktionen](#devsecops-anwendungsfälle-für-api-schreibaktionen)\n  - [Verschieben von Epics zwischen Gruppen](#verschieben-von-epics-zwischen-gruppen)\n  - [Automatisierung des Verschiebens von Epics](#automatisierung-des-verschiebens-von-epics)\n  - [Compliance: Sicherstellen, dass Projekteinstellungen nicht überschrieben werden](#compliance-sicherstellen-dass-projekteinstellungen-nicht-überschrieben-werden)\n  - [Notizen machen, Fälligkeitsübersicht erstellen](#notizen-machen-fälligkeitsübersicht-erstellen)\n\n## Los geht's: python-gitlab Install\n\n\nDie Dokumentation von python-gitlab bietet eine umfassende Einführung in die\nNutzung, einschließlich Anleitungen für den Einstieg, Informationen zu\nObjekttypen und deren Methoden sowie kombinierte Workflow-Beispiele.\nErgänzend dazu ist die Dokumentation der GitLab-API-Ressourcen hilfreich, da\nsie die verfügbaren Objektattribute detailliert beschreibt. Zusammen sind\ndiese beiden Dokumentationen die besten Ressourcen für den Einstieg.\n\n\nDie Code-Beispiele in diesem Blogbeitrag setzen Python 3.8+ und die\npython-gitlab-Bibliothek voraus. Weitere notwendige Abhängigkeiten sind in\nder Datei requirements.txt aufgeführt. Ein Beispiel erfordert die Bibliothek\npyyaml zum Parsen von YAML-Konfigurationen. Um den Code der Anwendungsfälle\nnachzuvollziehen und zu üben, empfiehlt es sich, das Projekt zu klonen, die\nAnforderungen zu installieren und die Skripte auszuführen.\n\n\n```shell\n\ngit clone\nhttps://gitlab.com/gitlab-de/use-cases/gitlab-api/gitlab-api-python.git\n\n\ncd gitlab-api-python\n\n\nbrew install python\n\n\npip3 install -r requirements.txt\n\n\npython3 \u003Cscriptname>.py\n\n```\n\nDie Skripte verwenden absichtlich keine gemeinsam genutzte Bibliothek, die\nz. B. generische Funktionen für das Lesen von Parametern oder zusätzliche\nHilfsfunktionen bereitstellt. Die Idee ist, einfach zu verstehende Beispiele\nzu zeigen, die eigenständig zum Testen verwendet werden können und lediglich\ndie Installation der python-gitlab-Bibliothek erfordern.\n\n\nEs wird empfohlen, den Code für den Produktionseinsatz zu verbessern. Dies\nkann auch beim Aufbau eines gewarteten API-Tooling-Projekts helfen, das z.\nB. Container-Images und CI/CD-Vorlagen für Entwickler enthält, die auf einer\nDevSecOps-Plattform genutzt werden können.\n\n\n## GitLab API Python: Konfiguration\n\n\nOhne Konfiguration führt python-gitlab unauthentifizierte Anfragen an den\nStandardserver https://gitlab.com aus. Die häufigsten\nKonfigurationseinstellungen beziehen sich auf die GitLab-Instanz, mit der\neine Verbindung hergestellt werden soll, und die Authentifizierungsmethode\ndurch Angabe von Zugriffstokens. python-gitlab unterstützt verschiedene\nArten der Konfiguration: Eine Konfigurationsdatei oder Umgebungsvariablen.\n\n\nDie Konfigurationsdatei ist für die API-Bibliotheksbindungen und die CLI\nverfügbar (die CLI wird in diesem Blogpost nicht erläutert). Die\nKonfigurationsdatei unterstützt Credential Helpers für den direkten Zugriff\nauf Token.\n\n\nUmgebungsvariablen als alternative Konfigurationsmethode bieten eine\neinfache Möglichkeit, das Skript auf dem Terminal auszuführen, in\nContainer-Images zu integrieren und sie für die Ausführung in\nCI/CD-Pipelines vorzubereiten.\n\n\nDie Konfiguration muss in den Kontext des Python-Skripts geladen werden.\nBeginne mit dem Import der os-Bibliothek, um die Umgebungsvariablen mit der\nMethode os.environ.get() abzurufen. Der erste Parameter gibt den Schlüssel\nan, der zweite Parameter legt den Standardwert fest, wenn die Variable in\nder Umgebung nicht verfügbar ist.\n\n\n```python\n\nimport os\n\n\ngl_server = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\n\nprint(gl_server)\n\n```\n\n\nDie Parametrisierung auf dem Terminal kann direkt nur für den Befehl\nerfolgen oder in die Shell-Umgebung exportiert werden.\n\n\n```shell\n\n$ GL_SERVER=’https://gitlab.company.com’ python3 script.py\n\n\n$ export GL_SERVER=’https://gitlab.company.com’\n\n$ python3 script.py\n\n```\n\n\nEs wird empfohlen, Sicherheitsprüfungen hinzuzufügen, um sicherzustellen,\ndass alle Variablen gesetzt sind, bevor das Programm weiter ausgeführt wird.\nDer folgende Ausschnitt importiert die erforderlichen Bibliotheken, liest\ndie Umgebungsvariable GL_SERVER und erwartet, dass der Benutzer die Variable\nGL_TOKEN setzt. Wenn dies nicht der Fall ist, gibt das Skript Fehler aus und\nruft sys.exit(1) auf, um einen Fehlerstatus anzuzeigen.\n\n\n```python\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n```\n\n\nFolgend siehst du ein ausführlicheres Beispiel, das eine Verbindung zur API\nherstellt und eine tatsächliche Datenabfrage durchführt.\n\n\n## Objekte verwalten: das GitLab-Objekt\n\n\nFür jede Interaktion mit der API muss das GitLab-Objekt instanziiert werden.\nDies ist der Einstiegspunkt für die Konfiguration des GitLab-Servers für die\nVerbindung, die Authentifizierung mithilfe von Zugriffstokens und weitere\nglobale Einstellungen für die Paginierung, das Laden von Objekten und mehr.\n\n\nIm folgenden Beispiel wird eine nicht authentifizierte Anfrage an gitlab.com\nausgeführt. Es ist möglich, auf öffentliche API-Endpunkte zuzugreifen und\nzum Beispiel eine bestimmte [.gitignore Vorlage für\nPython](https://python-gitlab.readthedocs.io/en/stable/gl_objects/templates.html#gitignore-templates)\nabzurufen.\n\n\n[python_gitlab_object_unauthenticated.py](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/python_gitlab_object_unauthenticated.py)\n\n\n```python\n\nimport gitlab\n\n\ngl = gitlab.Gitlab()\n\n\n# Get .gitignore templates without authentication\n\ngitignore_templates = gl.gitignores.get('Python')\n\n\nprint(gitignore_templates.content)\n\n```\n\n\nDie nächsten Abschnitte geben weitere Einblicke in:\n\n\n- Objektmanager und Laden von Objekten\n\n- Paginierung von Ergebnissen\n\n- Arbeiten mit Objektbeziehungen\n\n- Arbeiten mit verschiedenen Objektsammlungsbereichen\n\n\n### Objektmanager und Laden von Objekten\n\n\nDie python-gitlab-Bibliothek ermöglicht den Zugriff auf GitLab-Ressourcen\nüber sogenannte\n„[Manager](https://python-gitlab.readthedocs.io/en/stable/api-usage.html#managers)\".\nJeder Managertyp implementiert Methoden zur Arbeit mit den Datensätzen\n(list, get, etc.).\n\n\nDas Skript zeigt, wie man auf Untergruppen, direkte Projekte, alle Projekte\neinschließlich Untergruppen, Issues, Epics und To-dos zugreifen kann. Diese\nMethoden und der API-Endpunkt erfordern eine Authentifizierung für den\nZugriff auf alle Attribute. Der Codeschnipsel verwendet daher Variablen, um\ndas Authentifizierungs-Token abzurufen sowie die GROUP_ID-Variable, um eine\nHauptgruppe anzugeben, bei der die Suche beginnen soll.\n\n\n```python\n\n#!/usr/bin/env python\n\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\n# https://gitlab.com/gitlab-de/use-cases/\n\nGROUP_ID = os.environ.get('GL_GROUP_ID', 16058698)\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n\n# Main\n\nmain_group = gl.groups.get(GROUP_ID)\n\n\nprint(\"Sub groups\")\n\nfor sg in main_group.subgroups.list():\n    print(\"Subgroup name: {sg}\".format(sg=sg.name))\n\nprint(\"Projects (direct)\")\n\nfor p in main_group.projects.list():\n    print(\"Project name: {p}\".format(p=p.name))\n\nprint(\"Projects (including subgroups)\")\n\nfor p in main_group.projects.list(include_subgroups=True, all=True):\n     print(\"Project name: {p}\".format(p=p.name))\n\nprint(\"Issues\")\n\nfor i in main_group.issues.list(state='opened'):\n    print(\"Issue title: {t}\".format(t=i.title))\n\nprint(\"Epics\")\n\nfor e in main_group.issues.list():\n    print(\"Epic title: {t}\".format(t=e.title))\n\nprint(\"Todos\")\n\nfor t in gl.todos.list(state='pending'):\n    print(\"Todo: {t} url: {u}\".format(t=t.body, u=t.target_url\n```\n\n\nDu kannst das Skript\n[`python_gitlab_object_manager_methods.py`](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/python_gitlab_object_manager_methods.py)\nausführen, indem du die GROUP_ID-Variable auf GitLab.com SaaS für deine\neigene zu analysierende Gruppe überschreibst. Die Variable GL_SERVER muss\nfür selbstverwaltete Instanzziele angegeben werden. GL_TOKEN muss das\npersönliche Zugriffstoken enthalten.\n\n\n```shell\n\nexport GL_TOKEN=xxx\n\n\nexport GL_SERVER=”https://gitlab.company.com”\n\n\nexport GL_SERVER=”https://gitlab.com”\n\n\nexport GL_GROUP_ID=1234\n\n\npython3 python_gitlab_object_manager_methods.py\n\n```\n\nIn Zukunft werden die Beispiel-Snippets die Python-Header und das Parsen von\nUmgebungsvariablen nicht mehr zeigen, um sich auf den Algorithmus und die\nFunktionalität zu konzentrieren. Alle Skripte sind Open Source unter der\nMIT-Lizenz und in [diesem\nProjekt](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python)\nverfügbar.\n\n\n### Paginierung der Ergebnisse\n\n\nStandardmäßig gibt die GitLab-API nicht alle Ergebnissätze zurück und\nerfordert, dass die Clients die Paginierung verwenden, um durch alle\nErgebnisseiten zu iterieren. Mit der python-gitlab-Bibliothek können\nBenutzer die Einstellungen global im GitLab-Objekt oder bei jedem\nlist()-Aufruf\n[festlegen](https://python-gitlab.readthedocs.io/en/stable/api-usage.html#pagination).\nStandardmäßig würden alle Ergebnissätze API-Anfragen auslösen, was die\nSkriptausführung verlangsamen kann. Die empfohlene Methode ist die\nVerwendung von iterator=True, die ein Generatorobjekt zurückgibt, und\nAPI-Aufrufe werden beim Zugriff auf das Objekt bei Bedarf ausgelöst.\n\n\nDas folgende Beispiel sucht nach dem Gruppennamen everyonecancontribute und\nverwendet eine\n[Paginierung](https://docs.gitlab.com/ee/api/rest/index.html#pagination) der\nSchlüsselsätze mit 100 Ergebnissen auf jeder Seite. Der Iterator wird bei\ngl.groups.list(iterator=True) auf true gesetzt, um bei Bedarf neue\nErgebnissätze abzurufen. Wird der gesuchte Gruppenname gefunden, bricht die\nSchleife ab und gibt eine Zusammenfassung aus, einschließlich der Messung\nder Dauer der gesamten Suchanfrage.\n\n\n```python\n\nSEARCH_GROUP_NAME=\"everyonecancontribute\"\n\n\n# Use keyset pagination\n\n# https://python-gitlab.readthedocs.io/en/stable/api-usage.html#pagination\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN,\n    pagination=\"keyset\", order_by=\"id\", per_page=100)\n\n# Iterate over the list, and fire new API calls in case the result set does\nnot match yet\n\ngroups = gl.groups.list(iterator=True)\n\n\nfound_page = 0\n\nstart = timer()\n\n\nfor group in groups:\n    if SEARCH_GROUP_NAME == group.name:\n        # print(group) # debug\n        found_page = groups.current_page\n        break\n\nend = timer()\n\n\nduration = f'{end-start:.2f}'\n\n\nif found_page > 0:\n    print(\"Pagination API example for Python with GitLab{desc} - found group {g} on page {p}, duration {d}s\".format(\n        desc=\", the DevSecOps platform\", g=SEARCH_GROUP_NAME, p=found_page, d=duration))\nelse:\n    print(\"Could not find group name '{g}', duration {d}\".format(g=SEARCH_GROUP_NAME, d=duration))\n```\n\n\nBeim Ausführen von python_gitlab_pagination.py wurde die Gruppe\n[everyonecancontribute](https://gitlab.com/everyonecancontribute) auf Seite\n5 gefunden.\n\n\n```shell\n\n$ python3 python_gitlab_pagination.py\n\nPagination API example for Python with GitLab, the DevSecOps platform -\nfound group everyonecancontribute on page 5, duration 8.51s\n\n```\n\n\n### Arbeiten mit Objektbeziehungen\n\n\nBei der Arbeit mit Objektbeziehungen – z. B. beim Sammeln aller Projekte in\neiner bestimmten Gruppe – müssen zusätzliche Schritte unternommen werden.\nDie zurückgegebenen Projektobjekte enthalten standardmäßig nur begrenzte\nAttribute. Für verwaltbare Objekte ist ein zusätzlicher get()-Aufruf\nerforderlich, der das vollständige Projektobjekt von der API im Hintergrund\nanfordert. Dieser On-Demand-Workflow hilft, Wartezeiten und Datenverkehr zu\nvermeiden, indem er die sofort zurückgegebenen Attribute reduziert.\n\n\nDas folgende Beispiel veranschaulicht das Problem, indem es eine Schleife\ndurch alle Projekte in einer Gruppe durchläuft und versucht, die Funktion\nproject.branches.list() aufzurufen, was eine Ausnahme im try/except-Flow\nauslöst. Im zweiten Beispiel wird ein verwaltbares Projektobjekt ermittelt\nund der Funktionsaufruf erneut versucht.\n\n\n```python\n\n# Main\n\ngroup = gl.groups.get(GROUP_ID)\n\n\n# Collect all projects in group and subgroups\n\nprojects = group.projects.list(include_subgroups=True, all=True)\n\n\nfor project in projects:\n    # Try running a method on a weak object\n    try:\n       print(\"🤔 Project: {pn} 💡 Branches: {b}\\n\".format(\n        pn=project.name,\n        b=\", \".join([x.name for x in project.branches.list()])))\n    except Exception as e:\n        print(\"Got exception: {e} \\n ===================================== \\n\".format(e=e))\n\n    # Retrieve a full manageable project object\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n    manageable_project = gl.projects.get(project.id)\n\n    # Print a method available on a manageable object\n    print(\"🤔 Project: {pn} 💡 Branches: {b}\\n\".format(\n        pn=manageable_project.name,\n        b=\", \".join([x.name for x in manageable_project.branches.list()])))\n```\n\n\nDer Exception-Handler in der python-gitlab-Bibliothek gibt die Fehlermeldung\naus und verlinkt auch auf die Dokumentation. Es ist hilfreich, bei der\nFehlersuche zu beachten, dass Objekte möglicherweise nicht verwaltet werden\nkönnen, wenn du nicht auf Objektattribute oder Funktionsaufrufe zugreifen\nkannst.\n\n\n```shell\n\n$ python3 python_gitlab_manageable_objects.py\n\n\n🤔 Project: GitLab API Playground 💡 Branches: cicd-demo-automated-comments,\ndocs-mr-approval-settings, main\n\n\nGot exception: 'GroupProject' object has no attribute 'branches'\n\n\n\u003Cclass 'gitlab.v4.objects.projects.GroupProject'> was created via a\n\nlist() call and only a subset of the data may be present. To ensure\n\nall data is present get the object using a get(object.id) call. For\n\nmore details, see:\n\n\nhttps://python-gitlab.readthedocs.io/en/v3.8.1/faq.html#attribute-error-list\n =====================================\n```\n\n\nHier findest du das vollständige\n[Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/python_gitlab_manageable_objects.py).\n\n\n### Arbeiten mit verschiedenen Objektsammlungsbereichen\n\n\nManchmal muss das Skript alle Projekte aus einer selbstverwalteten Instanz,\naus einer Gruppe mit Untergruppen oder aus einem einzelnen Projekt sammeln.\nLetzteres ist hilfreich, um die erforderlichen Attribute schneller testen zu\nkönnen, und der Gruppenabruf hilft später beim Testen im großen Maßstab. Das\nfolgende Snippet sammelt alle Projektobjekte in der projects-Liste und fügt\nObjekte aus verschiedenen eingehenden Konfigurationen hinzu. Du wirst auch\nwieder das verwaltbare Objektmuster für Projekte in Gruppen sehen.\n\n\n```python\n    # Collect all projects, or prefer projects from a group id, or a project id\n    projects = []\n\n    # Direct project ID\n    if PROJECT_ID:\n        projects.append(gl.projects.get(PROJECT_ID))\n\n    # Groups and projects inside\n    elif GROUP_ID:\n        group = gl.groups.get(GROUP_ID)\n\n        for project in group.projects.list(include_subgroups=True, all=True):\n            # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n            manageable_project = gl.projects.get(project.id)\n            projects.append(manageable_project)\n\n    # All projects on the instance (may take a while to process)\n    else:\n        projects = gl.projects.list(get_all=True)\n```\n\n\nDas vollständige Beispiel befindet sich in [diesem\nSkript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_mr_approval_rules.py)\nfür die Auflistung der Einstellungen der MR-Genehmigungsregeln für bestimmte\nProjektziele.\n\n\n## DevSecOps-Anwendungsfälle für API-Leseaktionen\n\n\nDas authentifizierte Zugriffstoken benötigt den Bereich [`read_api`\nscope](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-token-scopes).\n\n\nDie folgenden Anwendungsfälle werden diskutiert:\n\n\n- Zweige nach Zusammenführungsstatus auflisten\n\n- Drucken von Projekteinstellungen zur Überprüfung: MR-Genehmigungsregeln\n\n- Inventarisierung: Abrufen aller CI/CD-Variablen, die geschützt oder\nmaskiert sind\n\n- Herunterladen einer Datei aus dem Repository\n\n- Hilfe zur Migration: Auflistung aller zertifikatsbasierten\nKubernetes-Cluster\n\n- Team-Effizienz: Prüfen Sie, ob bestehende Merge-Requests nach dem Mergen\neiner großen Refactoring-MR neu gebasht werden müssen\n\n\n### Zweige nach Zusammenführungsstatus auflisten\n\n\nEin häufiges Anliegen ist es, in einem Projekt ein wenig Git-Housekeeping zu\nbetreiben und zu sehen, wie viele zusammengeführte und nicht\nzusammengeführte Zweige im Umlauf sind. Eine\n[Frage](https://forum.gitlab.com/t/python-gitlab-project-branch-list-filter/80257)\nim GitLab-Community-Forum zum Filtern von Zweiglisten hat mich dazu\ninspiriert, ein\n[Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_branches_by_state.py)\nzu schreiben, mit dem sich dieses Ziel erreichen lässt. Die Methode\nbranches.list() gibt alle Zweigobjekte zurück, die in einer temporären Liste\nfür die spätere Verarbeitung in zwei Schleifen gespeichert werden: Sammeln\nder Namen der zusammengeführten Zweige und der Namen der nicht\nzusammengeführten Zweige. Das Attribut merged des branch-Objekts ist ein\nboolescher Wert, der angibt, ob der Zweig zusammengeführt wurde.\n\n\n```python\n\nproject = gl.projects.get(PROJECT_ID, lazy=False, pagination=\"keyset\",\norder_by=\"updated_at\", per_page=100)\n\n\n# Get all branches\n\nreal_branches = []\n\nfor branch in project.branches.list():\n    real_branches.append(branch)\n\nprint(\"All branches\")\n\nfor rb in real_branches:\n    print(\"Branch: {b}\".format(b=rb.name))\n\n# Get all merged branches\n\nmerged_branches_names = []\n\nfor branch in real_branches:\n    if branch.default:\n        continue # ignore the default branch for merge status\n\n    if branch.merged:\n        merged_branches_names.append(branch.name)\n\nprint(\"Branches merged: {b}\".format(b=\", \".join(merged_branches_names)))\n\n\n# Get un-merged branches\n\nnot_merged_branches_names = []\n\nfor branch in real_branches:\n    if branch.default:\n        continue # ignore the default branch for merge status\n\n    if not branch.merged:\n        not_merged_branches_names.append(branch.name)\n\nprint(\"Branches not merged: {b}\".format(b=\",\n\".join(not_merged_branches_names)))\n\n```\n\n\nDer Arbeitsablauf ist absichtlich schrittweise zu lesen. Du kannst die\nOptimierung des Python-Codes für die bedingte Zweignamensammlung üben.\n\n\n### Drucken von Projekteinstellungen zur Überprüfung: MR-Genehmigungsregeln\n\n\nDas folgende\n[Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_mr_approval_rules.py)\ngeht durch alle gesammelten Projektobjekte und prüft, ob Genehmigungsregeln\nangegeben sind. Wenn die Länge der Liste größer als Null ist, durchläuft es\ndie Liste in einem Loop und druckt die Einstellungen mit einer JSON-Ph\npretty-print-Methode aus.\n\n\n```python\n    # Loop over projects and print the settings\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/merge_request_approvals.html\n    for project in projects:\n        if len(project.approvalrules.list()) > 0:\n            #print(project) #debug\n            print(\"# Project: {name}, ID: {id}\\n\\n\".format(name=project.name_with_namespace, id=project.id))\n            print(\"[MR Approval settings]({url}/-/settings/merge_requests)\\n\\n\".format(url=project.web_url))\n\n            for ar in project.approvalrules.list():\n                print(\"## Approval rule: {name}, ID: {id}\".format(name=ar.name, id=ar.id))\n                print(\"\\n```json\\n\")\n                print(json.dumps(ar.attributes, indent=2)) # TODO: can be more beautiful, but serves its purpose with pretty print JSON\n                print(\"\\n```\\n\")\n\n```\n\n\n### Inventarisierung: Abrufen aller CI/CD-Variablen, die geschützt oder\nmaskiert sind\n\n\n[CI/CD Variablen](https://docs.gitlab.com/ee/ci/variables/) sind hilfreich\nfür die Pipeline-Parametrisierung und können global auf der Instanz, in\nGruppen und in Projekten konfiguriert werden. Auch Daten, Passwörter und\nandere sensible Informationen können dort gespeichert werden. Manchmal kann\nes notwendig sein, sich einen Überblick über alle CI/CD-Variablen zu\nverschaffen, die entweder geschützt oder maskiert sind, um ein Gefühl dafür\nzu bekommen, wie viele Variablen aktualisiert werden müssen, wenn Token zum\nBeispiel rotieren.\n\n\nDas folgende\n[Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_all_cicd_variables_masked_or_protected.py)\nruft alle Gruppen und Projekte ab und versucht, die CI/CD-Variablen der\nglobalen Instanz (erfordert Admin-Rechte), der Gruppen und Projekte\n(erfordert Maintainer-/Eigentümer-Rechte) zu sammeln. Es gibt alle\nCI/CD-Variablen aus, die entweder geschützt oder maskiert sind, und fügt\nhinzu, dass ein möglicher geheimer Wert gespeichert ist.\n\n\n```python\n\n#!/usr/bin/env python\n\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\n# Helper function to evaluate secrets and print the variables\n\ndef eval_print_var(var):\n    if var.protected or var.masked:\n        print(\"🛡️🛡️🛡️ Potential secret: Variable '{name}', protected {p}, masked: {m}\".format(name=var.key,p=var.protected,m=var.masked))\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN') # token requires maintainer+\npermissions. Instance variables require admin access.\n\nPROJECT_ID = os.environ.get('GL_PROJECT_ID') #optional\n\nGROUP_ID = os.environ.get('GL_GROUP_ID', 8034603) #\nhttps://gitlab.com/everyonecancontribute\n\n\nif not GITLAB_TOKEN:\n    print(\"🤔 Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n\n# Collect all projects, or prefer projects from a group id, or a project id\n\nprojects = []\n\n# Collect all groups, or prefer group from a group id\n\ngroups = []\n\n\n# Direct project ID\n\nif PROJECT_ID:\n    projects.append(gl.projects.get(PROJECT_ID))\n\n# Groups and projects inside\n\nelif GROUP_ID:\n    group = gl.groups.get(GROUP_ID)\n\n    for project in group.projects.list(include_subgroups=True, all=True):\n        # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n        manageable_project = gl.projects.get(project.id)\n        projects.append(manageable_project)\n\n    groups.append(group)\n\n# All projects/groups on the instance (may take a while to process, use\niterators to fetch on-demand).\n\nelse:\n    projects = gl.projects.list(iterator=True)\n    groups = gl.groups.list(iterator=True)\n\nprint(\"# List of all CI/CD variables marked as secret (instance, groups,\nprojects)\")\n\n\n# https://python-gitlab.readthedocs.io/en/stable/gl_objects/variables.html\n\n\n# Instance variables (if the token has permissions)\n\nprint(\"Instance variables, if accessible\")\n\ntry:\n    for i_var in gl.variables.list(iterator=True):\n        eval_print_var(i_var)\nexcept:\n    print(\"No permission to fetch global instance variables, continueing without.\")\n    print(\"\\n\")\n\n# group variables (maintainer permissions for groups required)\n\nfor group in groups:\n    print(\"Group {n}, URL: {u}\".format(n=group.full_path, u=group.web_url))\n    for g_var in group.variables.list(iterator=True):\n        eval_print_var(g_var)\n\n    print(\"\\n\")\n\n# Loop over projects and print the settings\n\nfor project in projects:\n    # skip archived projects, they throw 403 errors\n    if project.archived:\n        continue\n\n    print(\"Project {n}, URL: {u}\".format(n=project.path_with_namespace, u=project.web_url))\n    for p_var in project.variables.list(iterator=True):\n        eval_print_var(p_var)\n\n    print(\"\\n\")\n```\n\nDas Skript druckt die Variablenwerte absichtlich nicht aus; dies soll als\nÜbung für sichere Umgebungen dienen. Für die Speicherung von Daten empfiehlt\nsich die Verwendung [externer\nAnbieter](https://docs.gitlab.com/ee/ci/secrets/).\n\n\n### Herunterladen einer Datei aus dem Repository\n\n\nZiel des\n[Skripts](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/get_raw_file_content.py)\nist es, einen Dateipfad von einem angegebenen Verzweigungsnamen\nherunterzuladen und dessen Inhalt in einer neuen Datei zu speichern.\n\n\n```python\n\n# Goal: Try to download README.md from\nhttps://gitlab.com/gitlab-de/use-cases/gitlab-api/gitlab-api-python/-/blob/main/README.md\n\nFILE_NAME = 'README.md'\n\nBRANCH_NAME = 'main'\n\n\n# Search the file in the repository tree and get the raw blob\n\nfor f in project.repository_tree():\n    print(\"File path '{name}' with id '{id}'\".format(name=f['name'], id=f['id']))\n\n    if f['name'] == FILE_NAME:\n        f_content = project.repository_raw_blob(f['id'])\n        print(f_content)\n\n# Alternative approach: Get the raw file from the main branch\n\nraw_content = project.files.raw(file_path=FILE_NAME, ref=BRANCH_NAME)\n\nprint(raw_content)\n\n\n# Store the file on disk\n\nwith open('raw_README.md', 'wb') as f:\n    project.files.raw(file_path=FILE_NAME, ref=BRANCH_NAME, streamed=True, action=f.write)\n```\n\n\n### Hilfe zur Migration: Auflistung aller zertifikatsbasierten\nKubernetes-Cluster\n\n\nDie zertifikatsbasierte Integration von Kubernetes-Clustern in GitLab wurde\n[abgeschafft](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes).\nUm Migrationspläne zu unterstützen, kann die Erfassung bestehender Gruppen\nund Projekte mithilfe der GitLab-API automatisiert werden.\n\n\n```python\n\ngroups = [ ]\n\n\n# get GROUP_ID group\n\ngroups.append(gl.groups.get(GROUP_ID))\n\n\nfor group in groups:\n    for sg in group.subgroups.list(include_subgroups=True, all=True):\n        real_group = gl.groups.get(sg.id)\n        groups.append(real_group)\n\ngroup_clusters = {}\n\nproject_clusters = {}\n\n\nfor group in groups:\n    #Collect group clusters\n    g_clusters = group.clusters.list()\n\n    if len(g_clusters) > 0:\n        group_clusters[group.id] = g_clusters\n\n    # Collect all projects in group and subgroups and their clusters\n    projects = group.projects.list(include_subgroups=True, all=True)\n\n    for project in projects:\n        # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n        manageable_project = gl.projects.get(project.id)\n\n        # skip archived projects\n        if project.archived:\n            continue\n\n        p_clusters = manageable_project.clusters.list()\n\n        if len(p_clusters) > 0:\n            project_clusters[project.id] = p_clusters\n\n# Print summary\n\nprint(\"## Group clusters\\n\\n\")\n\nfor g_id, g_clusters in group_clusters.items():\n    url = gl.groups.get(g_id).web_url\n    print(\"Group ID {g_id}: {u}\\n\\n\".format(g_id=g_id, u=url))\n    print_clusters(g_clusters)\n\nprint(\"## Project clusters\\n\\n\")\n\nfor p_id, p_clusters in project_clusters.items():\n    url = gl.projects.get(p_id).web_url\n    print(\"Project ID {p_id}: {u}\\n\\n\".format(p_id=p_id, u=url))\n    print_clusters(p_clusters)\n```\n\n\nHier findest du das vollständige\n[Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/list_cert_based_kubernetes_clusters.py).\n\n\n### Team-Effizienz: Prüfe, ob bestehende Merge-Requests nach dem Mergen\neiner großen Refactoring-MR neu gebasht werden müssen\n\n\nDas [GitLab-Handbuch-Repository](https://handbook.gitlab.com/handbook/) ist ein großes Monorepo mit\nzahlreichen Merge-Requests, die erstellt, geprüft, genehmigt und\nzusammengeführt werden müssen. Einige Prüfungen dauern länger als andere,\ninsbesondere wenn Zusammenführungsanfragen mehrere Seiten betreffen,\nbeispielsweise wenn ein String umbenannt wird oder Änderungen auf\n[alle](/handbook/about/#count-handbook-pages) Handbuchseiten ausgedehnt\nwerden. Das Marketing-Handbuch wurde umstrukturiert, was zu vielen\nVerschiebungen oder Umbenennungen von Verzeichnissen und Pfaden führte.\n\n\nMit der Zeit nahmen die Issues zu, und es bestand die Sorge, dass andere\nMerge-Anfragen nach dem Zusammenführen der großen Änderungen auf Konflikte\nstoßen könnten. Es wurde festgestellt, dass Python-Gitlab in der Lage ist,\nalle Merge-Requests in einem bestimmten Projekt abzurufen, einschließlich\nDetails über den Git-Zweig, geänderte Quellpfade und vieles mehr.\n\n\nDas daraus resultierende Skript konfiguriert eine Liste von Quellpfaden, die\nvon allen pythongitlab-Merge-Requests berührt werden, und vergleicht die\nDiffs der Merge-Requests mit mr.diffs.list(), um festzustellen, ob ein\nMuster mit dem Wert in old_path. übereinstimmt. Bei einer Übereinstimmung\nprotokolliert das Skript diese und speichert die Zusammenführungsanforderung\nim seen_mr-Wörterbuch für die spätere Zusammenfassung. Zusätzlich werden\nAttribute gesammelt, um eine Markdown-Aufgabenliste mit URLs zum leichteren\nEinfügen in Issue-Beschreibungen zu erstellen.\n\n\n```python\n\nPATH_PATTERNS = [\n    'path/to/handbook/source/page.md',\n]\n\n\n# Only list opened MRs\n\n#\nhttps://python-gitlab.readthedocs.io/en/stable/gl_objects/merge_requests.html#project-merge-requests\n\nmrs = project.mergerequests.list(state='opened', iterator=True)\n\n\nseen_mr = {}\n\n\nfor mr in mrs:\n    # https://docs.gitlab.com/ee/api/merge_requests.html#list-merge-request-diffs\n    real_mr = project.mergerequests.get(mr.get_id())\n    real_mr_id = real_mr.attributes['iid']\n    real_mr_url = real_mr.attributes['web_url']\n\n    for diff in real_mr.diffs.list(iterator=True):\n        real_diff = real_mr.diffs.get(diff.id)\n\n        for d in real_diff.attributes['diffs']:\n            for p in PATH_PATTERNS:\n                if p in d['old_path']:\n                    print(\"MATCH: {p} in MR {mr_id}, status '{s}', title '{t}' - URL: {mr_url}\".format(\n                        p=p,\n                        mr_id=real_mr_id,\n                        s=mr_status,\n                        t=real_mr.attributes['title'],\n                        mr_url=real_mr_url))\n\n                    if not real_mr_id in seen_mr:\n                        seen_mr[real_mr_id] = real_mr\n\nprint(\"\\n# MRs to update\\n\")\n\n\nfor id, real_mr in seen_mr.items():\n    print(\"- [ ] !{mr_id} - {mr_url}+ Status: {s}, Title: {t}\".format(\n        mr_id=id,\n        mr_url=real_mr.attributes['web_url'],\n        s=real_mr.attributes['detailed_merge_status'],\n        t=real_mr.attributes['title']))\n```\n\n\n## DevSecOps-Anwendungsfälle für API-Schreibaktionen\n\n\nDas authentifizierte Zugriffstoken benötigt den vollen Anwendungsbereich der\n[`api`](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-token-scopes).\n\n\nDie folgenden Anwendungsfälle werden diskutiert:\n\n\n- Verschieben von Epics zwischen Gruppen\n\n- Compliance: Sicherstellen, dass Projekteinstellungen nicht überschrieben\nwerden\n\n- Notizen machen, Fälligkeitsübersicht erstellen\n\n\n### Verschieben von Epics zwischen Gruppen\n\n\nManchmal ist es erforderlich, Epics, ähnlich wie Issues, in eine andere\nGruppe zu verschieben. Eine Frage im GitLab-Marketing-Slack-Kanal hat dazu\ngeführt, einen\n[Funktionsvorschlag](https://gitlab.com/gitlab-org/gitlab/-/issues/12689)\nfür die Benutzeroberfläche und die\n[Schnellaktionen](/blog/improve-your-gitlab-productivity-with-these-10-tips/)\nzu prüfen und später über das Schreiben eines API-Skripts nachzudenken, um\ndie Schritte zu automatisieren.\n\n\n### Automatisierung des Verschiebens von Epics\n\n\nDie Idee ist einfach: Ein Epic wird von einer Quellgruppe in eine Zielgruppe\nverschoben, wobei Titel, Beschreibung und Labels kopiert werden. Da Epics es\nerlauben, Themen zu gruppieren, müssen sie auch dem Ziel-Epic neu zugewiesen\nwerden. Parent-Child-Epic-Relationships müssen dabei berücksichtigt werden:\nAlle Child-Epics der Quell-Epics müssen dem Ziel-Epic neu zugewiesen werden.\n\n\nDas folgende Skript sucht zunächst alle\n[Attribute](https://python-gitlab.readthedocs.io/en/stable/gl_objects/epics.html)\ndes Quellepos und erstellt dann ein neues Zielepos mit den minimalen\nAttributen: Titel und Beschreibung. Die Liste der Bezeichnungen wird kopiert\nund die Änderungen werden mit dem save()-Aufruf beibehalten. Die Ausgaben,\ndie dem Epos zugeordnet sind, müssen im Zielepos neu erstellt werden.\n\n\nDer create()-Aufruf erzeugt das Beziehungselement und nicht ein neues\nIssue-Objekt selbst. Das Verschieben von Child-Epics erfordert einen anderen\nAnsatz, da die Beziehung umgekehrt ist: Die parent_id des Child-Epics muss\nmit der ID des Quell-Epics verglichen und bei Übereinstimmung auf die ID des\nZiel-Epics aktualisiert werden. Nachdem alles erfolgreich kopiert wurde,\nmuss das Quell-Epos in den closed-Zustand versetzt werden.\n\n\n```python\n\n#!/usr/bin/env python\n\n\n# Description: Show how epics can be moved between groups, including title,\ndescription, labels, child epics and issues.\n\n# Requirements: python-gitlab Python libraries. GitLab API write access, and\nmaintainer access to all configured groups/projects.\n\n# Author: Michael Friedrich \u003Cmfriedrich@gitlab.com>\n\n# License: MIT, (c) 2023-present GitLab B.V.\n\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\n# https://gitlab.com/gitlab-da/use-cases/gitlab-api\n\nSOURCE_GROUP_ID = os.environ.get('GL_SOURCE_GROUP_ID', 62378643)\n\n# https://gitlab.com/gitlab-da/use-cases/gitlab-api/epic-move-target\n\nTARGET_GROUP_ID = os.environ.get('GL_TARGET_GROUP_ID', 62742177)\n\n# https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1\n\nEPIC_ID = os.environ.get('GL_EPIC_ID', 1)\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n\n# Main\n\n# Goal: Move epic to target group, including title, body, labels, and child\nepics and issues.\n\nsource_group = gl.groups.get(SOURCE_GROUP_ID)\n\ntarget_group = gl.groups.get(TARGET_GROUP_ID)\n\n\n# Create a new target epic and copy all its items, then close the source\nepic.\n\nsource_epic = source_group.epics.get(EPIC_ID)\n\n# print(source_epic) #debug\n\n\nepic_title = source_epic.title\n\nepic_description = source_epic.description\n\nepic_labels = source_epic.labels\n\nepic_issues = source_epic.issues.list()\n\n\n# Create the epic with minimal attributes\n\ntarget_epic = target_group.epics.create({\n    'title': epic_title,\n    'description': epic_description,\n})\n\n\n# Assign the list\n\ntarget_epic.labels = epic_labels\n\n\n# Persist the changes in the new epic\n\ntarget_epic.save()\n\n\n# Epic issues need to be re-assigned in a loop\n\nfor epic_issue in epic_issues:\n    ei = target_epic.issues.create({'issue_id': epic_issue.id})\n\n# Child epics need to update their parent_id to the new epic\n\n# Need to search in all epics, use lazy object loading\n\nfor sge in source_group.epics.list(lazy=True):\n    # this epic has the source epic as parent epic?\n    if sge.parent_id == source_epic.id:\n        # Update the parent id\n        sge.parent_id = target_epic.id\n        sge.save()\n\nprint(\"Copied source epic {source_id} ({source_url}) to target epic\n{target_id} ({target_url})\".format(\n    source_id=source_epic.id, source_url=source_epic.web_url,\n    target_id=target_epic.id, target_url=target_epic.web_url))\n\n# Close the old epic\n\nsource_epic.state_event = 'close'\n\nsource_epic.save()\n\nprint(\"Closed source epic {source_id} ({source_url})\".format(\n    source_id=source_epic.id, source_url=source_epic.web_url))\n\n```\n\n\n```shell\n\n$  python3 move_epic_between_groups.py\n\nCopied source epic 725341\n(https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1) to\ntarget epic 725358\n(https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/epic-move-target/-/epics/6)\n\nClosed source epic 725341\n(https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/-/epics/1)\n\n```\n\n\nDas\n[Ziel-Epic](https://gitlab.com/groups/gitlab-da/use-cases/gitlab-api/epic-move-target/-/epics/5)\nwurde erstellt und zeigt das erwartete Ergebnis: Derselbe Titel, dieselbe\nBeschreibung, dieselben Bezeichnungen, dasselbe untergeordnete Epic und\ndieselben Issues.\n\n\n![Target epic which has all attributes copied from the source epic: title,\ndescription, labels, child epics,\nissues](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_moved_epic_with_all_attributes.png){:\n.shadow}\n\n\n**Übung:** Das Skript kopiert noch keine\n[Kommentare](https://python-gitlab.readthedocs.io/en/stable/gl_objects/notes.html)\nund\n[Diskussionsstränge](https://python-gitlab.readthedocs.io/en/stable/gl_objects/discussions.html).\nRecherchiere und hilf mit, das Skript zu aktualisieren – Merge-Requests\nwillkommen!\n\n\n### Compliance: Sicherstellen, dass Projekteinstellungen nicht überschrieben\nwerden\n\n\nProjekt- und Gruppeneinstellungen können versehentlich von Teammitgliedern\nmit Administratorrechten geändert werden. Die Compliance-Anforderungen\nmüssen erfüllt werden. Ein weiterer Anwendungsfall ist die Verwaltung der\nKonfiguration mit Infrastructure-as-Code-Tools, um sicherzustellen, dass die\nKonfiguration von GitLab-Instanzen, -Gruppen, -Projekten usw. erhalten\nbleibt und immer dieselbe ist. Tools wie Ansible oder Terraform können ein\nAPI-Skript aufrufen oder die Python-GitLab-Bibliothek verwenden, um Aufgaben\nzur Verwaltung von Einstellungen auszuführen.\n\n\nIm folgenden Beispiel ist nur der main-Zweig geschützt.\n\n\n![GitLab project settings for repositories and protected branches, main\nbranch](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_protected_branches_settings_main.png){:\n.shadow}\n\n\nNehmen wir an, dass ein neuer production-Zweig hinzugefügt wurde und\nebenfalls geschützt werden soll. Das folgende\n[Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/enforce_protected_branches.py)\ndefiniert das Wörterbuch der geschützten Zweige und ihre Zugriffsebenen für\nPush-/Merge-Berechtigungen auf Maintainer-Ebene und baut die Vergleichslogik\nauf der Grundlage der\n[python-gitlab-Dokumentation](https://python-gitlab.readthedocs.io/en/stable/gl_objects/protected_branches.html)\nzu geschützten Zweigen auf.\n\n\n```python\n\n#!/usr/bin/env python\n\n\nimport gitlab\n\nimport os\n\nimport sys\n\n\nGITLAB_SERVER = os.environ.get('GL_SERVER', 'https://gitlab.com')\n\n# https://gitlab.com/gitlab-da/use-cases/\n\nGROUP_ID = os.environ.get('GL_GROUP_ID', 16058698)\n\nGITLAB_TOKEN = os.environ.get('GL_TOKEN')\n\n\nPROTECTED_BRANCHES = {\n    'main': {\n        'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n        'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n    },\n    'production': {\n        'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n        'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n    },\n}\n\n\nif not GITLAB_TOKEN:\n    print(\"Please set the GL_TOKEN env variable.\")\n    sys.exit(1)\n\ngl = gitlab.Gitlab(GITLAB_SERVER, private_token=GITLAB_TOKEN)\n\n\n# Main\n\ngroup = gl.groups.get(GROUP_ID)\n\n\n# Collect all projects in group and subgroups\n\nprojects = group.projects.list(include_subgroups=True, all=True)\n\n\nfor project in projects:\n    # Retrieve a full manageable project object\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/groups.html#examples\n    manageable_project = gl.projects.get(project.id)\n\n    # https://python-gitlab.readthedocs.io/en/stable/gl_objects/protected_branches.html\n    protected_branch_names = []\n\n    for pb in manageable_project.protectedbranches.list():\n        manageable_protected_branch = manageable_project.protectedbranches.get(pb.name)\n        print(\"Protected branch name: {n}, merge_access_level: {mal}, push_access_level: {pal}\".format(\n            n=manageable_protected_branch.name,\n            mal=manageable_protected_branch.merge_access_levels,\n            pal=manageable_protected_branch.push_access_levels\n        ))\n\n        protected_branch_names.append(manageable_protected_branch.name)\n\n    for branch_to_protect, levels in PROTECTED_BRANCHES.items():\n        # Fix missing protected branches\n        if branch_to_protect not in protected_branch_names:\n            print(\"Adding branch {n} to protected branches settings\".format(n=branch_to_protect))\n            p_branch = manageable_project.protectedbranches.create({\n                'name': branch_to_protect,\n                'merge_access_level': gitlab.const.AccessLevel.MAINTAINER,\n                'push_access_level': gitlab.const.AccessLevel.MAINTAINER\n            })\n```\n\n\nWenn das Skript ausgeführt wird, werden der bestehende main-Zweig und ein\nHinweis, dass die production aktualisiert wird, ausgegeben. Der Screenshot\naus den Repository-Einstellungen verdeutlicht diese Aktion.\n\n\n```\n\n$ python3\nenforce_protected_branches.py\n─╯\n\nProtected branch name: main, merge_access_level: [{'id': 67294702,\n'access_level': 40, 'access_level_description': 'Maintainers', 'user_id':\nNone, 'group_id': None}], push_access_level: [{'id': 68546039,\n'access_level': 40, 'access_level_description': 'Maintainers', 'user_id':\nNone, 'group_id': None}]\n\nAdding branch production to protected branches settings\n\n```\n\n\n![GitLab project settings for repositories and protected branches, main and\nproduction\nbranch](https://about.gitlab.com/images/blogimages/efficient-devsecops-workflows-python-gitlab-handson/python_gitlab_protected_branches_settings_main_production.png){:\n.shadow}\n\n\n### Notizen machen, Fälligkeitsübersicht erstellen\n\n\nEine Diskussion auf [Hacker\nNews](https://news.ycombinator.com/item?id=32155848) über Tools zum\nErstellen von Notizen hat mich dazu inspiriert, eine Übersicht in Form einer\nMarkdown-Tabelle zu erstellen, die aus Dateien, die Notizen aufnehmen,\ngeholt und nach dem geparsten Fälligkeitsdatum sortiert wird. Das\n[Skript](https://gitlab.com/gitlab-da/use-cases/gitlab-api/gitlab-api-python/-/blob/main/generate_snippets_index_by_due_date.py)\nist hier zu finden und etwas komplexer zu verstehen.\n\n\n\u003C!--\n\n# 2022-07-19 Notes\n\n\nHN topic about taking notes: https://news.ycombinator.com/item?id=32152935\n\n\n-->\n\n\n***Die englischsprachige\n[Originalversion](https://about.gitlab.com/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation/)\ndieses Artikels wurde bereits aktualisiert und erhält einige weitere Tipps,\nwelche wir der deutschen Version beizeiten hinzufügen werden.***\n","engineering",[234,686,9,687],"2025-05-16",{"slug":734,"featured":6,"template":691},"efficient-devsecops-workflows-hands-on-python-gitlab-api-automation","content:de-de:blog:efficient-devsecops-workflows-hands-on-python-gitlab-api-automation.yml","Efficient Devsecops Workflows Hands On Python Gitlab Api Automation","de-de/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation.yml","de-de/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation",{"_path":740,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":741,"content":744,"config":754,"_id":756,"_type":14,"title":757,"_source":16,"_file":758,"_stem":759,"_extension":19},"/de-de/blog/enhance-application-quality-with-ai-powered-test-generation",{"noIndex":6,"title":742,"description":743},"Anwendungsqualität mit KI-gestützter Testgenerierung verbessern","Erfahre, wie GitLab Duo mit Amazon Q den QA-Prozess durch automatische Generierung umfassender Unit-Tests verbessert.",{"title":742,"description":743,"authors":745,"heroImage":747,"date":748,"body":749,"category":683,"tags":750},[746],"Cesar Saavedra","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659604/Blog/Hero%20Images/Screenshot_2024-11-27_at_4.55.28_PM.png","2025-07-03","Du weißt, wie entscheidend die Anwendungsqualität für deine Kund(inn)en und deinen Ruf ist. Allerdings kann es sich wie ein ständiger Kampf anfühlen, diese Qualität durch umfassende Tests sicherzustellen. Du hast es mit zeitaufwendigen manuellen Prozessen zu tun, inkonsistenter Testabdeckung im Team und diesen lästigen Problemen, die irgendwie durchrutschen. Es ist frustrierend, wenn deine Bewertung sinkt, weil die Qualitätssicherung eher zu einem Engpass als zu einem Schutzschild wird.\n\nHier kann [GitLab Duo mit Amazon Q](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), das agentische KI im gesamten Softwareentwicklungslebenszyklus für AWS-Kund(inn)en bereitstellt, deinen QA-Prozess transformieren. Diese KI-gestützte Funktion kann automatisch umfassende Unit-Tests für deinen Code generieren und deinen Qualitätssicherungs-Workflow dramatisch beschleunigen. Anstatt Stunden damit zu verbringen, Tests manuell zu schreiben, kannst du die KI deinen Code analysieren und Tests erstellen lassen, die optimale Abdeckung und konsistente Qualität über deine gesamte Anwendung hinweg gewährleisten.\n\n## Wie GitLab Duo mit Amazon Q funktioniert\n\nWie funktioniert das also? Lass uns gemeinsam durch den Prozess gehen.\nWenn du an einem neuen Feature arbeitest, beginnst du damit, die Java-Klasse auszuwählen, die du über einen Merge Request zu deinem Projekt hinzugefügt hast. Du navigierst einfach zu deinem Merge Request und klickst auf den Tab „Änderungen\", um den neuen Code zu sehen, den du hinzugefügt hast.\n\nAls Nächstes rufst du Amazon Q auf, indem du einen Quick-Action-Befehl eingibst. Alles, was du tun musst, ist `/q test` in das Issue-Kommentarfeld einzugeben. So einfach ist das – nur ein Schrägstrich, der Buchstabe „q\" und das Wort „test\".\n\nSobald du Enter drückst, wird Amazon Q aktiv. Es analysiert deinen ausgewählten Code und versteht dessen Struktur, Logik und Zweck. Die KI untersucht deine Klassenmethoden, Abhängigkeiten und potenzielle Randfälle, um zu bestimmen, welche Tests benötigt werden.\n\nInnerhalb weniger Augenblicke generiert Amazon Q eine umfassende Unit-Test-Abdeckung für deine neue Klasse. Es erstellt Tests, die nicht nur den Happy Path abdecken, sondern auch Randfälle und Fehlerbedingungen, die du möglicherweise übersehen hättest. Die generierten Tests folgen den bestehenden Mustern und Konventionen deines Projekts und stellen sicher, dass sie sich nahtlos in deine Codebasis integrieren.\n\n## Warum GitLab Duo mit Amazon Q verwenden?\n\nHier ist das Fazit: Du hast mit einer kritischen Herausforderung begonnen – hochwertige Anwendungen zu pflegen und dabei mit Zeitbeschränkungen und inkonsistenten Testpraktiken umzugehen. GitLab Duo mit Amazon Q löst dies, indem es den Testgenerierungsprozess automatisiert und optimale Code-Abdeckung sowie konsistente Teststandards gewährleistet. Das Ergebnis? Probleme werden vor der Bereitstellung erkannt, deine Anwendungen behalten ihre Qualität und du kannst Software schneller entwickeln, ohne die Zuverlässigkeit zu opfern.\n\nHauptvorteile dieser Funktion:\n\n* Reduziert die Zeit für das Schreiben von Unit-Tests erheblich\n* Gewährleistet umfassende Testabdeckung über deine gesamte Codebasis\n* Hält konsistente Testqualität über alle Teammitglieder hinweg aufrecht\n* Erkennt Probleme, bevor sie die Produktion erreichen\n* Beschleunigt deine gesamte Entwicklungsgeschwindigkeit\n\nBereit, diese bahnbrechende Funktion in Aktion zu sehen? Sieh dir an, wie GitLab Duo mit Amazon Q deinen Qualitätssicherungsprozess transformieren kann:\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/pxlYJVcHY28?si=MhIz6lnHxc6kFhlL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Starte noch heute mit GitLab Duo mit Amazon Q\n\nMöchtest du mehr über GitLab Duo mit Amazon Q erfahren? Besuche die [GitLab und AWS Partnerseite](https://about.gitlab.com/de-de/partners/technology-partners/aws/) für detaillierte Informationen.\n\n## Agentische KI-Ressourcen\n- [Agentische KI-Leitfäden und Ressourcen](https://about.gitlab.com/de-de/blog/agentic-ai-guides-and-resources/)\n- [Was ist agentische KI?](https://about.gitlab.com/de-de/topics/agentic-ai/)\n- [GitLab Duo mit Amazon Q: Agentische KI optimiert für AWS allgemein verfügbar](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n- [GitLab Duo mit Amazon Q Dokumentation](https://docs.gitlab.com/user/duo_amazon_q/)",[685,751,752,9,686,753],"product","testing","AWS",{"featured":91,"template":691,"slug":755},"enhance-application-quality-with-ai-powered-test-generation","content:de-de:blog:enhance-application-quality-with-ai-powered-test-generation.yml","Enhance Application Quality With Ai Powered Test Generation","de-de/blog/enhance-application-quality-with-ai-powered-test-generation.yml","de-de/blog/enhance-application-quality-with-ai-powered-test-generation",{"_path":761,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":762,"content":768,"config":777,"_id":779,"_type":14,"title":780,"_source":16,"_file":781,"_stem":782,"_extension":19},"/de-de/blog/enhance-application-security-with-gitlab-hackerone",{"title":763,"description":764,"ogTitle":763,"ogDescription":764,"noIndex":6,"ogImage":765,"ogUrl":766,"ogSiteName":673,"ogType":674,"canonicalUrls":766,"schema":767},"Bessere Anwendungssicherheit mit GitLab und HackerOne","Erfahre mehr über die Zusammenarbeit zwischen GitLab und HackerOne und lerne, wie du eine Integration implementierst, die die Sicherheit der Anwendungen in deinem Unternehmen verbessert.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097503/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2810%29_5ET24Q6i8ihqrAOkge7a1R_1750097503214.png","https://about.gitlab.com/blog/enhance-application-security-with-gitlab-hackerone","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Bessere Anwendungssicherheit mit GitLab und HackerOne\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-03\",\n      }",{"title":763,"description":764,"authors":769,"heroImage":765,"date":771,"body":772,"category":773,"tags":774,"updatedDate":776},[770],"Fernando Diaz","2025-04-03","Sicherheit darf im Entwicklungsprozess nicht länger eine Nebensache sein. Unternehmen benötigen robuste Lösungen, mit denen die Sicherheit in den gesamten Software-Entwicklungsprozess integriert wird. Hier kommt die Zusammenarbeit zwischen HackerOne und GitLab ins Spiel, denn sie bietet eine praktische Kombination für moderne Anwendungsentwicklungsteams.\n\n[GitLab](https://about.gitlab.com/de-de/), die umfassende, KI-basierte DevSecOps-Plattform, und HackerOne, die führende Crowd-Sicherheitsplattform, sind eine Partnerschaft eingegangen, die das Beste aus beiden Welten vereint: den optimierten DevSecOps-Workflow von GitLab und die leistungsstarke Sicherheitslückenverwaltung von HackerOne.\n\nIn diesem Tutorial erfährst du, wie du die Produktivität der Entwickler(innen) und deine Sicherheitslage verbessern kannst, indem du die GitLab-Integration von HackerOne implementierst.\n\n## Eine Integration, die Entwickler(innen) befähigt\n\nDie GitLab-Integration von HackerOne ist bemerkenswert einfach und dennoch leistungsstark. Wenn Sicherheitsexpert(inn)en Sicherheitslücken über die Plattform von HackerOne entdecken, werden diese Erkenntnisse automatisch in GitLab-Tickets umgewandelt. Dadurch entsteht ein nahtloser Workflow, der folgendermaßen abläuft:\n\n* Sicherheitsexpert(inn)en identifizieren Sicherheitslücken über die Plattform von HackerOne.\n* Validierte Sicherheitslücken werden automatisch in GitLab-Tickets umgewandelt.\n* Entwicklungsteams können diese Tickets direkt in ihren bestehenden Workflows bearbeiten.\n* Der Lösungsstatus wird zwischen beiden Plattformen synchronisiert.\n\nDu kannst die Vorteile von GitLab und HackerOne nutzen, indem du die [Integration](https://docs.hackerone.com/en/articles/8571227-gitlab-integration) verwendest und GitLab-Tickets als Referenzen auf HackerOne nachverfolgst. Diese Integration bietet eine bidirektionale und nahtlose Datensynchronisierung zwischen deinem HackerOne-Bericht und dem GitLab-Ticket, wodurch die Abstimmung zwischen Entwicklungs- und Sicherheitsteams verbessert und die Behebung von Sicherheitslücken optimiert wird.\n\nFolge den Anweisungen in der [GitLab-Integrationsdokumentation von HackerOne](https://docs.hackerone.com/en/articles/10394699-gitlab-setup), um die GitLab-Integration so zu konfigurieren, dass sie Informationen zwischen deinem HackerOne-Bericht und deinem GitLab-Ticket synchronisiert. Dies umfasst folgende Schritte:\n\n1. [Einrichtung einer OAuth-2.0-Anwendung](https://docs.gitlab.com/ee/integration/oauth_provider.html) für deine GitLab-Instanz mit den bereitgestellten HackerOne-Einstellungen\n2. Verbindung von HackerOne zum neu erstellten OAuth 2.0 auf GitLab\n3. Berechtigung von HackerOne, auf die GitLab-API zuzugreifen\n4. Festlegung des GitLab-Projekts, das du zu HackerOne-Berichten eskalieren möchtest\n5. Auswahl der HackerOne-Felder, die den entsprechenden GitLab-Feldern zugeordnet werden sollen\n6. Ereigniskonfiguration für GitLab zu HackerOne und umgekehrt\n\nSobald die Integration eingerichtet wurde, kannst du Daten bidirektional und nahtlos zwischen GitLab und HackerOne synchronisieren. Dies vereinfacht den Kontextwechsel und ermöglicht es, Sicherheitslücken einfach in beiden Systemen nachzuverfolgen. Die Integration bietet die folgenden Funktionen:\n\n* **Erstellen eines GitLab-Tickets aus HackerOne:** Du kannst neue GitLab-Tickets für Berichte erstellen, die du auf HackerOne erhältst.  \n* **Verknüpfung von HackerOne-Berichten mit bestehenden GitLab-Aufgaben.**   \n* **Synchronisierung von Updates von HackerOne zu GitLab:** Die folgenden Updates eines Berichts werden als Kommentar zu GitLab synchronisiert.\n  * Berichtskommentare  \n  * Staatusänderungen  \n  * Belohnungen  \n  * Änderungen der zuständigen Person  \n  * Öffentlichmachung  \n  * Schließen von GitLab-Tickets  \n* **Synchronisierung von Updates von GitLab zu HackerOne:** Die folgenden Updates in GitLab werden in HackerOne als interner Kommentar zum jeweiligen Bericht angezeigt:  \n  * Kommentare  \n  * Statusänderungen  \n* **Zuordnung von HackerOne-Schweregraden zu GitLab-Labels**: Dadurch kannst du eine benutzerdefinierte Priorität festlegen, wenn du einen Bericht zu GitLab eskalierst.  \n* **Zuordnung von Fälligkeitsdaten:** Damit kannst du basierend auf dem Schweregrad eines Berichts automatisch ein benutzerdefiniertes Fälligkeitsdatum festlegen.\n\n![GitLab und HackerOne fügen Kommentare hinzu oder ändern den Status des Berichts in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/sync_aHR0cHM6_1750097509644.png)\n\nDiese Funktionen vereinfachen die Abstimmung zwischen Entwicklungs- und Sicherheitsteams und optimieren die Behebung von Sicherheitslücken. Weitere Informationen zur Funktionsweise der Integration findest du in der [Integrationsdokumentation](https://docs.hackerone.com/en/articles/8571227-gitlab-integration).\n\n## Ein Blick in die Bug-Bounty-Programme von HackerOne\n\nHackerOne bietet Bug-Bounty-Programme oder Cybersicherheitsinitiativen an, bei denen man Belohnungen bekommt, wenn Sicherheitslücken in den Softwaresystemen, Websites oder Anwendungen von Kund(inn)en entdeckt und gemeldet werden. Bug-Bounty-Programme tragen auf folgende Weise zur Sicherheit einer Anwendung bei:\n\n* Sie helfen, Sicherheitsschwachstellen zu identifizieren, bevor diese missbraucht werden können.\n* Sie ermöglichen es, die vielfältige Expertise einer weltweiten Community aus Sicherheitsexpert(inn)en zu nutzen.\n* Sie sind eine kostengünstige Möglichkeit, die Cybersicherheit zu verbessern.\n* Sie ergänzen interne Sicherheitsmaßnahmen und traditionelle Penetrationstests.\n\nGitLab nutzt das Bug-Bounty-Programm von HackerOne und ermöglicht es Sicherheitsexpert(inn)en, Sicherheitslücken in den Anwendungen oder der Infrastruktur von GitLab zu melden. Dieser Crowdsourcing-Ansatz hilft GitLab, potenzielle Sicherheitsprobleme effektiver zu erkennen und zu beheben.\n\n![Bug-Bounty-Seite für GitLab auf HackerOne](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/hackerone_gitlab_bug_bounty_page_aHR0cHM6_1750097509645.png)\n\nIndem Unternehmen die Plattform und die globale Hacker(innen)-Community von HackerOne nutzen, können sie ihre Sicherheitslage deutlich verbessern, Sicherheitslücken schneller erkennen und potenziellen Bedrohungen immer einen Schritt voraus sein.\n\n## Sichere deine Anwendungen und verbessere die Effizienz mit GitLab\n\nGitLab ist eine umfassende DevSecOps-Plattform mit Funktionen für den gesamten Software-Entwicklungsprozess und enthält unter anderem auch Sicherheits- und Compliance-Tools. GitLab unterstützt die folgenden Arten von Sicherheitsscannern:\n- Statische Anwendungssicherheitstests (SAST)\n- Dynamische Anwendungssicherheitstests (DAST)\n- Container-Scanning\n- Abhängigkeitssuche\n- Infrastructure-as-Code-Scanning\n- Abdeckungsgesteuertes Fuzzing\n- Web-API-Fuzzing\n\nMit GitLab kannst du Sicherheitsscans hinzufügen, indem du einfach eine Vorlage auf deine CI/CD-Pipeline-Definitionsdatei anwendest. Ein SAST kann beispielsweise mit einigen wenigen Zeilen Code in der Datei `.gitlab-ci.yml` hinzugefügt werden:\n\n```yaml\nstage:\n  - test\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\nDadurch wird der SAST in der Testphase ausgeführt und es werden [automatisch die verwendeten Sprachen in deiner Anwendung erkannt](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks). Wenn du dann einen Merge Request erstellst, erkennt der SAST Sicherheitslücken im diff zwischen dem Feature-Branch und dem Zielbranch und stellt relevante Daten für die einzelnen Sicherheitslücken bereit, damit diese behoben werden können.\n\n![NoSQL-Injection-Sicherheitslücke im MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750097509647.png)\n\nDie Ergebnisse des SAST-Scanners können das Zusammenführen von Code blockieren, wenn Sicherheitsrichtlinien eingehalten werden müssen. Native GitLab-Benutzer(innen) können als Genehmiger(innen) festgelegt werden, sodass die erforderlichen Überprüfungen vor dem Zusammenführen von unsicherem Code durchgeführt werden müssen. Dadurch wird sichergestellt, dass alle Sicherheitslücken von den zuständigen Personen überwacht werden.\n\n![Genehmigungsrichtlinie für Merge Requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097510/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750097509649.png)\n\nHackerOne hat GitLab auf verschiedene wichtige Arten in seine Betriebs- und Entwicklungsprozesse integriert, was zu Verbesserungen des Entwicklungsprozesses und einer verbesserten Skalierbarkeit und Zusammenarbeit geführt hat. Zu diesen Verbesserungen gehören schnellere Bereitstellungen und teamübergreifende Planung.\n\n## Hauptvorteile der GitLab-Integration von HackerOne\n\nWerden HackerOne und GitLab zusammen genutzt, erwarten dich folgende Hauptvorteile:\n\n* **Verbesserte Transparenz bei der Sicherheit:** Entwicklungsteams erhalten sofortige Einblicke in Sicherheitslücken, ohne ihre primäre Workflow-Umgebung verlassen zu müssen. Durch diese Erkenntnisse in Echtzeit können Teams Sicherheitsprobleme priorisieren und trotzdem die Entwicklung von Funktionen vorantreiben.\n* **Optimierter Prozess zur Fehlerbehebung:** Indem HackerOne-Berichte direkt in GitLab-Tickets umgewandelt werden, wird die Fehlerbehebung Teil des Standardentwicklungszyklus. Dadurch entfällt der Kontextwechsel zwischen Plattformen und Sicherheitsfixes werden zusammen mit anderen Entwicklungsarbeiten nachverfolgt.  \n* **Raschere Fehlerbehebung:** Die Integration verkürzt die Zeit zwischen der Entdeckung und der Behebung von Sicherheitslücken erheblich. Da HackerOne-Beiträge sofort in GitLab verfügbar sind, können Entwicklungsteams ohne Verzögerung mit der Behebung der Fehler beginnen und so die allgemeine Sicherheitslage verbessern.\n***Verbesserte Zusammenarbeit:** Sicherheitsexpert(inn)en, Sicherheitsteams und Entwickler(innen) können durch diese Integration effektiver kommunizieren. Kommentare und Aktualisierungen werden zwischen beiden Plattformen synchronisiert, wodurch eine kollaborative Umgebung entsteht, bei der die Verbesserung der Sicherheit im Vordergrund steht.\n* **Praktische Auswirkungen:** Unternehmen, die die Integration von HackerOne und GitLab implementiert haben, berichten von folgenden Vorteilen:  \n  * Bis zu 70 % kürzere Zeit von der Entdeckung bis zur Behebung von Sicherheitslücken\n  * Höhere Zufriedenheit der Entwickler(innen), da sie in ihrem bevorzugten Workflow bleiben können\n  * Verbesserte Transparenz hinsichtlich der Sicherheit im gesamten Unternehmen  \n  * Effektivere Zuweisung von Sicherheitsressourcen\n\n> Sieh dir jetzt die [Seite zur Einrichtung der Integration](https://docs.hackerone.com/en/articles/10394699-gitlab-setup) an, um sofort loszulegen.\n\n## Mehr erfahren\n\nWeitere Informationen zu GitLab und HackerOne sowie darüber, wie du deine Sicherheitslage verbessern kannst, findest du in den folgenden Ressourcen:\n* [Nutzung der GitLab-Integration von HackerOne (nur in englischer Sprache verfügbar)](https://docs.hackerone.com/en/articles/8571227-gitlab-integration)  \n* [Bug-Bounty-Programm von GitLab in Zusammenarbeit mit HackerOne (nur in englischer Sprache verfügbar)](https://hackerone.com/gitlab?type=team)\n* [Sicherheits- und Compliance-Lösungen von GitLab](https://about.gitlab.com/de-de/solutions/security-compliance/)  \n* [HackerOne erreicht 5 x schnellere Implementierungen dank der integrierten Sicherheit von GitLab](https://about.gitlab.com/de-de/customers/hackerone/)  \n* [Dokumentation zur Anwendungssicherheit von GitLab](https://docs.gitlab.com/ee/user/application_security/)  \n","security",[773,686,234,285,687,9,775],"bug bounty","2025-05-12",{"slug":778,"featured":6,"template":691},"enhance-application-security-with-gitlab-hackerone","content:de-de:blog:enhance-application-security-with-gitlab-hackerone.yml","Enhance Application Security With Gitlab Hackerone","de-de/blog/enhance-application-security-with-gitlab-hackerone.yml","de-de/blog/enhance-application-security-with-gitlab-hackerone",{"_path":784,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":785,"content":788,"config":797,"_id":799,"_type":14,"title":800,"_source":16,"_file":801,"_stem":802,"_extension":19},"/de-de/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"noIndex":6,"title":786,"description":787,"ogTitle":786,"ogDescription":787},"GitLab Duo Agent Platform: 100+ KI-Agenten für DevSecOps","Delegiere an 100+ KI-Agenten gleichzeitig! GitLab Duo Agent Platform automatisiert Routine-Tasks, während du innovierst. Beta-Zugang jetzt verfügbar.",{"heroImage":789,"title":790,"description":791,"authors":792,"date":794,"body":795,"category":683,"tags":796},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750687578/esmflevxk5bf3eezjhwk.png","Die Zukunft ist da: GitLab Duo lässt dich mit 100+ KI-Agenten arbeiten","Die GitLab Duo Agent Platform ist eine DevSecOps-Orchestrierungsplattform für Menschen und KI-Agenten, die agentische KI für die Zusammenarbeit im SDLC nutzt.",[793],"Bill Staples","2025-06-24","Ich freue mich, die nächste Weiterentwicklung von Duo Workflow vorstellen zu können: die GitLab Duo Agent Platform. Diese innovative Plattform erweitert die agentischen Fähigkeiten auf den gesamten Softwareentwicklungszyklus und ermöglicht es Teams, parallel mit mehreren KI-Agenten zu arbeiten. \n\nStell dir vor, du beginnst deinen Tag so: \n\n* Du weist einen KI-Agenten an, Recherchen zu einem Epic durchzuführen, an dem dein Team arbeitet, die neuesten Updates zu allen Beiträgen der letzten Woche bereitzustellen und einen Veröffentlichungsbeitrag basierend auf den neuesten Funktionserweiterungen vorzuschlagen.   \n* Gleichzeitig beauftragst du mehrere Agenten mit der Analyse einiger Fehler bei der Barrierefreiheit und der Durchführung der erforderlichen Codeänderungen, um diese zu beheben.   \n* In der Zwischenzeit bittest du einen weiteren Agenten, deine komplizierten Codeänderungen zu überprüfen und Feedback zu geben, bevor du sie zur formellen Überprüfung an ein Teammitglied sendest.   \n* Als dich schließlich das Sicherheitsteam über eine neue Sicherheitslücke informiert, die im gesamten Projekt untersucht werden muss, übergibst du diese Rechercheaufgabe an deinen Sicherheitsagenten.\n\nAll das passiert gleichzeitig, während du dich auf Architekturentscheidungen, kreative Problemlösungen und strategische technische Arbeit konzentrieren kannst. Mit der GitLab Duo Agent Platform kannst du Aufgaben an fünf, zehn oder sogar 100 spezialisierte Agenten delegieren. Jeder davon kennt den vollständigen Kontext deines Projekts, nicht nur deinen Code, einschließlich CI-Jobprotokolle, Planungsaufgaben und vieles mehr. Du automatisierst die mühsame Arbeit, die du erledigen musst, damit du dich auf die Arbeit konzentrieren kannst, die dich inspiriert. \n\n**Es geht dabei nicht darum, Entwickler(innen) zu ersetzen. Es geht darum, die menschliche Kreativität und das Fachwissen zu verstärken, indem Routineaufgaben vereinfacht werden.** Das ist die Zukunft, die wir mit der GitLab Duo Agent Platform gestalten.\n\n## Was ist die GitLab Duo Agent Platform?\n\nDie GitLab Duo Agent Platform ermöglicht eine umfassende Zusammenarbeit zwischen Entwickler(inne)n und [KI-Agenten](https://about.gitlab.com/de-de/topics/agentic-ai/) über den gesamten Software-Entwicklungsprozess hinweg, um Teams dabei zu helfen, ihre Produktivität zu steigern und die Bearbeitungszeit drastisch zu verkürzen. \n\nDie GitLab Duo Agent Platform basiert auf der sicheren Grundlage von GitLab und ist anpassbar und erweiterbar. Sie ermöglicht es Entwickler(inne)n, Agenten zu erstellen, die alle Arten von Software-Engineering-Problemen lösen können und dabei den Kontext über den gesamten Software-Entwicklungsprozess hinweg nutzen. \n\nDie GitLab Duo Agent Platform bietet mehr als nur die Erstellung von Code. Mit spezialisierten Agenten und benutzerdefinierten Workflows unterstützt sie eine nahezu unbegrenzte Anzahl von Aktivitäten, darunter:\n\n* Implementierung von Tickets  \n* Groß angelegte Migrationen/Upgrades von Abhängigkeiten  \n* Automatisierte Erstellung von Dokumentationen/Veröffentlichungsbeiträge  \n* Fehlerbehebung bei fehlgeschlagenen CI/CD-Pipelines  \n* Unterstützung bei der Untersuchung von Vorfällen  \n* Detaillierte Recherche zu Status und Informationsbeschaffung zu festgelegten Themen  \n* Verwaltung von Backlogs  \n* Behebung von Sicherheitslücken  \n* Reviews für bestimmte Arten von Code (z. B. Datenbanken)  \n* Schnelle interne Toolerstellung auf Basis vorhandener Build-Blöcke  \n* und vieles mehr! \n\nDu kannst unsere Agenten sofort einsetzen, anpassen und erweitern. Wir testen die GitLab Duo Agent Platform derzeit mit Dutzenden von Kund(inn)en und werden bald mehr Teams den Zugang zur Beta-Version ermöglichen. \n\nSieh dir die GitLab Duo Agent Platform in Aktion an:\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1095679084?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agent Platform Demo Clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Wähle deine Tools, deine Modelle und deine Agenten\n\nDa GitLab eine offene Plattform ist, arbeiten GitLab-Agenten nahtlos mit den von dir gewählten Entwicklertools zur Codeerstellung über das Standard Model Context Protocol (MCP) und das Agent-to-Agent-Framework (A2A) zusammen, unabhängig davon, ob du Cursor, Claude Code, Windsurf, OpenAI Codex oder andere Tools verwendest. \n\nDie Plattform akzeptiert Codebeiträge von jedem Entwicklungstool in deinem Stack, unabhängig davon, ob der Code von einem Menschen geschrieben oder von einem KI-Agenten generiert wurde. Das bedeutet, dass deine vorhandenen Workflows und bevorzugten Tools weiterhin nahtlos funktionieren, wenn du Agentenfunktionen integrierst.\n\nDie GitLab Duo Agent Platform funktioniert mit jedem zugelassenen Sprachmodell, das [unsere Auswahlkriterien erfüllt](https://about.gitlab.com/de-de/ai-transparency-center/#ai-continuity-plan). Für Unternehmen mit strengen Sicherheitsanforderungen unterstützt die Plattform genehmigte, selbst gehostete Modelle, die in vollständig isolierten Umgebungen ausgeführt werden. Deine Infrastrukturanforderungen und Sicherheitsrichtlinien schränken deine Möglichkeiten, von der agentischen Entwicklung zu profitieren, nicht ein.\n\n## Kontext ist alles, und deine GitLab-Duo-Agenten kennen ihn\n\nDer Unterschied zwischen einem hilfreichen KI-Tool und einem wirklich intelligenten Agenten liegt im Kontext. Mit der GitLab Duo Agent Platform arbeiten die Agenten nicht isoliert, sondern sind tief in die Plattform integriert, auf der die Entwicklungsarbeit stattfindet.\n\nJeder Agent kennt automatisch das Gesamtbild deiner Projekte, einschließlich deiner offenen Tickets und deren Verlauf, der Merge Requests, die sie gelöst haben, der Struktur und der Logik hinter deinem Code, deiner CI/CD-Pipeline-Konfigurationen, der Sicherheitserkenntnisse, der Konformitätsanforderungen und der komplexen Beziehungen zwischen all diesen Komponenten.\n\nGenau wie deine menschlichen Teammitglieder verfügen die Agenten über den gesamten Kontext, um dir zu helfen, sichere Software schneller bereitzustellen. Anstatt nur Fragen zum Code zu beantworten, können sie Einblicke geben, wie sich eine vorgeschlagene Änderung auf deine Bereitstellungspipeline auswirken könnte, oder Sicherheitsverbesserungen auf der Grundlage deiner bestehenden Compliance-Regeln vorschlagen. Wir sind der Meinung, dass deine Agenten umso intelligenter werden, je mehr dein Team innerhalb der DevSecOps-Plattform von GitLab arbeitet.\n\n## Behalte die Kontrolle, während die Agenten dein Team skalieren\n\nDer Aufbau von Vertrauen in KI-Agenten unterscheidet sich nicht grundlegend vom Aufbau von Vertrauen in neue Teammitglieder. Du musst ihre Arbeit sehen, ihren Ansatz verstehen und ihre Verantwortung schrittweise erhöhen, wenn sie ihre Kompetenz unter Beweis stellen.\n\nDas ist die Philosophie hinter unserem Workflow zum Agenten-Approval. Bevor ein Agent Änderungen an deinem Code oder deiner Umgebung vornimmt, legt er dir einen klaren Plan vor: Er zeigt auf, was er über das Ticket weiß, welchen Ansatz er verfolgen wird und welche spezifischen Aktionen er ausführen möchte. Du hast dann die Möglichkeit, den Plan zu überprüfen, zu genehmigen oder bei Bedarf anzupassen. Wenn die Agenten konsequent qualitativ hochwertige Arbeit leisten, kannst du ihnen im Laufe der Zeit mehr Autonomie für Routineaufgaben gewähren und gleichzeitig die Kontrolle über komplexe oder kritische Arbeiten behalten.\n\n## Entwickelt für Community und Anpassung\n\nGitLab hat schon immer von den Beiträgen der Community profitiert, und dieses Jahr war ein Meilenstein mit einer rekordverdächtig hohen Zahl an Kundenbeiträgen zu unserer Plattform. Jetzt übertragen wir diese kollaborative Energie durch unseren offenen Framework-Ansatz auf KI-Agenten.\n\nBei der GitLab Duo Agent Platform geht es nicht nur um die Agenten, die wir entwickeln, sondern darum, dich und die breitere Community in die Lage zu versetzen, spezialisierte Agenten zu erstellen, die deine einzigartigen technischen Herausforderungen lösen. Egal, ob du einen Agenten benötigst, der deine spezifischen Programmierstandards versteht, sich in deine benutzerdefinierte Toolchain integrieren lässt oder domänenspezifische Aufgaben erledigt, die Plattform bietet dir die Bausteine, um dies zu erreichen.\n\nDieses auf die Community ausgerichtete Modell schafft einen positiven Kreislauf, der die Stärke der GitLab-Community durch globalen Austausch nutzt, ähnlich wie unser [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/). Vielfältige Anwendungsfälle aus der Praxis treiben Innovationen voran. Feedback von Unternehmen sorgt für Zuverlässigkeit und Sicherheit. Und gemeinsame Lösungen kommen allen zugute. Es ist derselbe kollaborative Ansatz, der GitLab erfolgreich gemacht hat und nun auf die neuesten Entwicklungen im Bereich der Agentenentwicklung angewendet wird.\n\n## Erste Schritte\n\nWenn du mit [GitLab Duo Agentic Chat](https://about.gitlab.com/de-de/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) experimentiert hast, das jetzt in jeder Premium- und Ultimate-GitLab.com-Benutzerlizenz von GitLab 18 enthalten ist, hast du bereits einen Vorgeschmack darauf bekommen, was mit KI-Agenten in deinem Entwicklungsworkflow möglich ist. \n\nWas die GitLab Duo Agent Platform kann und woran wir arbeiten, kannst du dir in den [Demos der Aufzeichnung unseres Release-Events von GitLab 18 Release-Events](https://about.gitlab.com/de-de/eighteen/) ansehen. \n\nMöchtest du zu den Ersten gehören, die es erleben? Dann melde dich für die [Beta-Warteliste für die GitLab Duo Agent Platform (nur in englischer Sprache verfügbar)](https://about.gitlab.com/gitlab-duo/agent-platform/) an. In diesem Sommer werden wir mehr Teams den Zugang ermöglichen und im Laufe des Jahres werden neue Agentenfunktionen in den kommenden Releases von GitLab 18 veröffentlicht. Wir erwarten die allgemeine Verfügbarkeit im Winter.\n\n*Haftungsausschlussklausel: Dieser Blogbeitrag enthält Informationen zu kommenden Produkten, Funktionen und Funktionalitäten. Bitte beachte, dass die Informationen auf dieser Seite 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 hier 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 Inc.*\n\n## Mehr erfahren\n\n* [Vom Vibe Coding zur agentischen KI: Eine Roadmap für technische Führungskräfte (nur in englischer Sprache verfügbar)](https://about.gitlab.com/the-source/ai/from-vibe-coding-to-agentic-ai-a-roadmap-for-technical-leaders/)\n* [Was ist agentische KI?](https://about.gitlab.com/de-de/topics/agentic-ai/)\n* [DevOps-Automatisierung und KI-Agenten (nur in englischer Sprache verfügbar)](https://about.gitlab.com/topics/agentic-ai/devops-automation-ai-agents/)\n* [KI-gestützte Softwareentwicklung: Agentische KI für DevOps (nur in englischer Sprache verfügbar)](https://about.gitlab.com/topics/agentic-ai/ai-augmented-software-development/)\n* [KI-gestützte Codeanalyse: Die neue Grenze der Codesicherheit (nur in englischer Sprache verfügbar)](https://about.gitlab.com/topics/agentic-ai/ai-code-analysis/)",[9],{"featured":91,"template":691,"slug":798},"gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops","content:de-de:blog:gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops.yml","Gitlab Duo Agent Platform What Is Next For Intelligent Devsecops","de-de/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops.yml","de-de/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"_path":804,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":805,"content":811,"config":817,"_id":819,"_type":14,"title":820,"_source":16,"_file":821,"_stem":822,"_extension":19},"/de-de/blog/gitlab-flow-duo",{"title":806,"description":807,"ogTitle":806,"ogDescription":807,"noIndex":6,"ogImage":808,"ogUrl":809,"ogSiteName":673,"ogType":674,"canonicalUrls":809,"schema":810},"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":806,"description":807,"authors":812,"heroImage":808,"date":813,"body":814,"category":683,"tags":815,"updatedDate":816},[746],"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",[109,685,9],"2025-04-21",{"slug":818,"featured":6,"template":691},"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":824,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":825,"content":831,"config":841,"_id":843,"_type":14,"title":844,"_source":16,"_file":845,"_stem":846,"_extension":19},"/de-de/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"ogTitle":826,"schema":827,"ogImage":828,"ogDescription":829,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":830,"title":826,"canonicalUrls":830,"description":829},"GitLab: Leader im Gartner MQ für KI-Programmierassistenten","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab zum Leader im Gartner Magic Quadrant für KI-Programmierassistenten 2024 ernannt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-08-22\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","Im ersten Gartner® Magic Quadrat™ in dieser Kategorie wurde GitLab für seine „Ability to execute sowie die „Completeness of vision“ im Bereich der KI-Programmierassistent-Technologie ausgezeichnet.","https://about.gitlab.com/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"heroImage":828,"body":832,"authors":833,"updatedDate":835,"date":836,"title":837,"tags":838,"description":829,"category":683},"Wir freuen uns, dass GitLab als Leader im [Gartner® Magic Quadrant™ für KI-Programmierassistenten](https://about.gitlab.com/de-de/gartner-mq-ai-code-assistants/) ausgezeichnet wurde – und das im ersten Jahr, in dem diese Kategorie vergeben wird. Wir sind angesichts dieser wichtigen Auszeichnung geehrt und sind überzeugt, dass dies der beste Beweis dafür ist, wie intensiv wir an KI-gestützten Fähigkeiten arbeiten, die die Softwarebereitstellung beschleunigen, die Sicherheit verbessern und Innovationen unserer Kund(inn)en vorantreiben.\n\nKI-Codeassistenten gehen über die reine Codeerstellung und -vervollständigung hinaus. Sie sind unterstützende Partner, die die Effizienz der Entwickler(innen) steigern, indem sie die Codequalität verbessern und kontinuierlich lernen. Durch die Automatisierung von Routineaufgaben und das Bereitstellen intelligenter Vorschläge verschaffen Assistenten wie GitLab Duo – unsere Suite von KI-gestützten Funktionen – den Entwickler(innen) mehr Zeit, um sich auf Problemlösungen auf höherer Ebene zu konzentrieren.\n\n![Bild von Gartner MQ KI-Programmierassistenten](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675964/Blog/Content%20Images/AI_Code_Assistants_MQ_graphic__1_.png)\n\n> Lade den [Bericht des Gartner® Magic Quadrant™ für KI-Programmierassistenten 2024](https://about.gitlab.com/de-de/gartner-mq-ai-code-assistants/) herunter.\n\n## KI-Programmierassistent: Geschwindigkeit, Sicherheit und nahtlose Integration\n\nKI-Programmierassistenten sind für Unternehmen jeder Größe unentbehrlich und helfen DevSecOps-Teams, sichere Software schneller zu entwickeln und bereitzustellen. Der wahre Wert von KI zeigt sich jedoch, wenn sie in den gesamten Lebenszyklus der Softwareentwicklung integriert wird. Anders als punktuelle KI-Lösungen, die zu fragmentierten Toolchains und Datensilos führen können, bettet die umfassende Plattform von GitLab die KI von der Planung bis zur Produktion ein. So bietet die Lösung umfassende Sichtbarkeit sowie Informationen über Metriken und Dashboards.\n\n## Die Stärke von GitLab Duo\n\n[GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) ist eine umfassende Toolbox mit KI-Funktionen, die entwickelt wurde, um das Erlebnis für Entwickler(innen) zu verbessern, die Sicherheit an den Beginn des Entwicklungszyklus zu verlagern und die Zusammenarbeit zwischen den Teams in den Bereichen Dev, Sec und Ops zu stärken. Zu den wichtigsten Funktionen gehören: \n\n* Codevorschläge für die Codeerstellung und Code-Vervollständigung\n* Chat für kontextsensitive In-App-Unterstützung für Codeerläuterung, Code-Refactoring und Testgenerierung\n* Erklärung von Sicherheitslücken, um diese im Code besser zu verstehen\n* Beheben von Sicherheitslücken\n* Grundursachenanalyse zur Behebung von Pipeline-Problemen\n* KI-Impact-Analyse-Dashboard, um Informationen in Echtzeit zu erhalten und den KI-ROI eines Unternehmens zu bewerten\n\n## Maximierung des ROI mit KI \n\nFührungskräfte aus Wirtschaft und Technik benötigen einen Überblick darüber, wie KI im gesamten Lebenszyklus der Softwareentwicklung eingesetzt wird, um den ROI ihrer Technologieinvestitionen zu bewerten. Das [KI-Impact-Analyse-Dashboard](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) von GitLab bietet nicht nur Sichtbarkeit, sondern auch Metriken, um KI-Annahmeraten, Leistungsverbesserungen und noch vieles mehr zu messen.\n\n## Flexibilität, Datenschutz und Transparenz im Fokus\n\nGitLab-Kund(inn)en, die KI-basierte Funktionen entdecken möchten, können mit GitLab Duo die Leistung der KI sicher in einer IDE ihrer Wahl oder in einem GitLab Remote Development Workspace ausprobieren. Dabei erwartet sie eine flexible Preisstruktur sowie eine kostenlose Testversion. Außerdem bietet das [GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/) einen vollständigen Einblick in unsere Governance- und Transparenzpraktiken. \n\nBald können Unternehmen ihre [KI-Erfahrung](https://about.gitlab.com/de-de/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/) durch Modellpersonalisierungen und Bereitstellung über ein selbstgehostetes Modell an ihre strategischen und regulatorischen Anforderungen anpassen. Durch die Modellpersonalisierung können Unternehmen GitLab Duo anpassen und das volle Potenzial der KI ausschöpfen, behalten dabei aber gleichzeitig ihre Geschäftsziele, betrieblichen Anforderungen und Erwartungen der Kund(inn)en im Blick. Die Bereitstellung über ein selbst gehostetes Modell stellt sicher, dass Daten die sichere Umgebung eines Unternehmens nicht verlassen. So kann das Risiko für Verstöße verringert und die Compliance in Branchen mit hohen regulatorischen Anforderungen sichergestellt werden.\n\n## Wir bereiten den Weg in die Zukunft der KI in DevSecOps\n\nGitLab ist dein Partner für KI-gestützte Softwareentwicklung. Wir statten Teams mit den Tools aus, die sie brauchen, um Software schneller zu entwickeln, zu sichern und bereitzustellen. Innovation ist Teil unserer DNA – das heißt, dass unsere Kunden jederzeit von den neuesten Entwicklungen im Bereich der KI profitieren! Wir haben uns nicht weniger vorgenommen, als den Bereich DevSecOps kontinuierlich zu revolutionieren, also bleib dran und entdecke in unserer Roadmap jede Menge spannende Updates.\n\n> [Lade den Bericht des Gartner® Magic Quadrant™ für KI-Programmierassistenten 2024 jetzt herunter](https://about.gitlab.com/de-de/gartner-mq-ai-code-assistants/).\n\n***Quelle: Gartner, Magic Quadrant für KI-Programmierassistenten, Arun Batchu, Haritha Khandabattu, Philip Walsh, Matt Brasier, August 2024***\n\n***GARTNER ist eine eingetragene Marke und Dienstleistungsmarke von Gartner, Inc. und/oder seinen verbundenen Unternehmen in den USA und international, und MAGIC QUADRANT ist eine eingetragene Marke von Gartner, Inc. und/oder seinen verbundenen Unternehmen und wird hierin mit Genehmigung verwendet. Alle Rechte vorbehalten.***\n\n***Gartner empfiehlt keine Anbieter, Produkte oder Dienstleistungen, die in seinen Forschungspublikationen abgebildet sind, und rät Technologiebenutzer(inne)n nicht, nur die Anbieter mit den höchsten Bewertungen oder anderen Bezeichnungen auszuwählen. Gartner-Forschungspublikationen bestehen aus den Meinungen der Forschungsorganisation von Gartner und sollten nicht als Tatsachenbehauptungen ausgelegt werden. Gartner lehnt alle ausdrücklichen oder stillschweigenden Gewährleistungen in Bezug auf diese Studie ab, einschließlich aller Gewährleistungen der Marktgängigkeit oder Eignung für einen bestimmten Zweck.***\n\n***Diese Grafik wurde von Gartner Inc. als Teil eines umfassenderen Berichts veröffentlicht und sollte im Kontext des gesamten Dokuments bewertet werden. Das Gartner-Dokument ist auf Anfrage bei Gartner B.V. erhältlich.***\n",[834],"Dave Steer","2024-09-05","2024-08-22","GitLab zum Leader im Gartner Magic Quadrant für KI-Programmierassistenten 2024 ernannt",[839,685,9,840],"news","research",{"slug":842,"featured":91,"template":691},"gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants","content:de-de:blog:gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants.yml","Gitlab Named A Leader In 2024 Gartner Magic Quadrant For Ai Code Assistants","de-de/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants.yml","de-de/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"_path":848,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":849,"content":855,"config":862,"_id":864,"_type":14,"title":865,"_source":16,"_file":866,"_stem":867,"_extension":19},"/de-de/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"title":850,"description":851,"ogTitle":850,"ogDescription":851,"noIndex":6,"ogImage":852,"ogUrl":853,"ogSiteName":673,"ogType":674,"canonicalUrls":853,"schema":854},"GitLab ist ein Leader im Gartner Magic Quadrant für DevOps-Plattformen 2024","GitLab ist in den Bereichen „Ability to execute“ und „Completeness of vision“ am besten positioniert. Eine Anerkennung für unsere Kund(inn)en und GitLabs DevOps-Innovationen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab ist ein Leader im Gartner Magic Quadrant für DevOps-Plattformen 2024\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2024-09-05\",\n      }\n                  ",{"title":850,"description":851,"authors":856,"heroImage":852,"date":835,"body":858,"category":839,"tags":859,"updatedDate":861},[857],"Ashley Kramer","DevOps war ursprünglich nur ein Konzept – eine Methode, um Software schneller bereitzustellen, indem traditionell getrennte Teams zusammengebracht werden. Es war eine Antwort auf alle Probleme, die durch die Trennung zwischen denen, die Software entwickelten, und denen, die sie einsetzten, verursacht wurden. \n\nBei GitLab haben wir dieses Konzept weiterentwickelt: Anstatt Tools zu einer komplexen DevOps-Toolchain zusammenzufügen, würde eine [einheitliche DevOps-Plattform](https://about.gitlab.com/de-de/platform/) eine engere Zusammenarbeit, eine stärkere Automatisierung sowie skalierbare und standardisierte Prozesse ermöglichen. \n\nWir glauben, dass diese Strategie, die auf den Erfolg unserer Kund(inn)en ausgerichtet ist, die richtige Wahl war. In der zweiten Iteration des [Gartner Magic Quadrant für DevOps-Plattformen](https://about.gitlab.com/de-de/gartner-magic-quadrant/) sind wir erneut Leader. Diesmal sind wir auf beiden Achsen „Ability to Execute“ und „Completeness of vision“ am besten positioniert.\n\n![Bild von Gartner MQ für DevOps-Plattformen 2024](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674334/Blog/Content%20Images/figure1.png)\n\n> Lade den [Bericht des Gartner® Magic Quadrant™ für DevOps-Plattformen 2024](https://about.gitlab.com/gartner-magic-quadrant/) herunter.\n\nDie Softwareunternehmen von heute müssen sich mit zunehmenden Sicherheitsbedrohungen, komplexen Compliance-Anforderungen und der vorsichtigen Einführung neuer Technologien wie generativer KI auseinandersetzen. Außerdem müssen sie ihr Versprechen von skalierbaren Dienstleistungen und kontinuierlicher Innovation gegenüber ihren eigenen Kund(inn)en einhalten.\n\nMit GitLab können unseren Kund(inn)en sich diesen Herausforderungen stellen und in ihren Branchen führend werden. Dank unserer KI-basierten DevSecOps-Plattform wird die Sicherheit früher im SDLC berücksichtigt, Transparenz im gesamten Entwicklungslebenszyklus geschaffen und alle Beteiligten zusammengebracht, um die Software zu entwickeln, die unsere Welt antreibt.\n\n## Die DevOps-Vision fördern\n\nUnsere Arbeit hier ist noch nicht erledigt. Wir werden die DevOps-Vision weiter vorantreiben und unsere DevSecOps-Plattform auf zwei Arten weiterentwickeln.\n\nZum einen wollen wir noch mehr Teams dazu einladen, auf einer gemeinsamen Plattform zusammenzuarbeiten, und zwar mit speziellen Funktionen für diejenigen, die sich mit [Agile Planning](https://about.gitlab.com/de-de/blog/categories/agile-planning/), [Data Science](https://about.gitlab.com/de-de/topics/devops/the-role-of-ai-in-devops/) und [Beobachtbarkeit und Anwendungsüberwachung](https://docs.gitlab.com/operations/observability/) (englischsprachige Seite) beschäftigen.\n\nZum anderen wollen wir die Optionen für die Einführung und Bereitstellung unserer Plattform noch flexibler gestalten, um die unterschiedlichen Bedürfnisse unserer Kund(inn)en zu erfüllen. Dazu gehört auch die Investition in [GitLab Dedicated](https://about.gitlab.com/de-de/dedicated/), unsere gehostete Single-Tenant-Option, mit der Unternehmen in stark regulierten Branchen die Einfachheit von SaaS und die Leistungsfähigkeit der neuesten Funktionen und Möglichkeiten nutzen und gleichzeitig die Compliance-Anforderungen einer isolierten Infrastruktur erfüllen können.\n\n## Unterstützung von Unternehmen bei der Entwicklung sicherer Software\n\nNeben der Entwicklung einer besseren Plattform für die Zusammenarbeit bei der Bereitstellung von Software gehört es zu den wichtigsten Aufgaben von GitLab, Unternehmen bei der Entwicklung sicherer und gesetzeskonformer Software zu unterstützen. Unsere Vision unterscheidet uns hier von anderen, denn GitLab integriert [Sicherheitsscans](https://about.gitlab.com/de-de/solutions/security-compliance/) bereits bei der Übergabe des Codes und nicht erst, wenn die Anwendungen zur Veröffentlichung bereit sind. Das hilft den Teams, Sicherheitslücken früher zu erkennen, was zu schnelleren Release-Zyklen führt. GitLab erleichtert außerdem die Einhaltung von Richtlinien durch Leitlinien und die automatische Erstellung [einer Software-Stückliste](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/).\n\nWir wissen, dass unsere Kund(inn)en mit immer mehr Sicherheitsbedrohungen konfrontiert sind, wenn die Angriffsfläche für ihre eigene Software wächst. Deshalb planen wir, in den nächsten 12 Monaten unsere SAST-Scanner weiter zu verbessern, zusätzliche Richtlinienkontrollen hinzuzufügen und [einen neuen nativen Geheimnismanager](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/) (englischsprachiger Artikel) zu erstellen.\n\n## Führend mit KI im gesamten SDLC\n\nUnsere Vision ist es, auch im Bereich KI führend zu sein – und zwar nicht nur, wenn es darum geht, unseren Kund(inn)en zu ermöglichen, innovative Software mit KI zu entwickeln, sondern auch, wenn es darum geht, dies mit datenschutzorientierter KI-Technologie zu tun. Die künstliche Intelligenz bedeutet einen gewaltigen Sprung nach vorn und bietet unglaublich viele Möglichkeiten, wenn sie in den gesamten Software-Entwicklungsprozess integriert wird. Wir entwickeln Innovationen verantwortungsbewusst. Wir haben die Bedenken unserer Kund(inn)en gehört: Sie wollen [KI mit Leitlinien](https://about.gitlab.com/the-source/ai/velocity-with-guardrails-ai-automation/) (englischsprachiger Artikel), [KI, die transparent ist](https://about.gitlab.com/de-de/ai-transparency-center/) und KI, die ihren Code und ihr geistiges Eigentum respektiert.\n\n[GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/), eine Suite von KI-gestützten Funktionen für unsere DevSecOps-Plattform, soll die folgenden Kriterien erfüllen: sie soll umfassend, datenschutzorientiert und den gesamten Lebenszyklus der Softwareentwicklung unterstützen.\n\nWir glauben, dass dieses Engagement und unsere GitLab-Duo-Funktionen der Grund dafür sind, dass [Gartner® uns kürzlich auch in seinem ersten Magic Quadrant™ für KI-Programmierassistenten zum Leader ernannt hat](https://about.gitlab.com/de-de/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants/).\n\nWir sind stolz auf diese Auszeichnung und sehen sie als Signal, weiterhin auf euch – unsere Kund(inn)en – zu hören, denn das treibt unsere Vision, unsere Produkt-Roadmap und unser Engagement an, die beste DevSecOps-Plattform zu liefern.\n\n> Lade den [Bericht des Gartner® Magic Quadrant™ für DevOps-Plattformen 2024](https://about.gitlab.com/de-de/gartner-magic-quadrant/) herunter.\n\n***Quelle: Gartner, Magic Quadrant für DevOps-Plattformen, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, August 2024***\n\n***GARTNER ist eine eingetragene Marke und Dienstleistungsmarke von Gartner, Inc. und/oder seinen verbundenen Unternehmen in den USA und international, und MAGIC QUADRANT ist eine\neingetragene Marke von Gartner, Inc. und/oder seinen verbundenen Unternehmen und wird hierin mit Genehmigung verwendet. Alle Rechte vorbehalten.***\n\n***Gartner empfiehlt keine Anbieter, Produkte oder Dienstleistungen, die in seinen Forschungspublikationen abgebildet sind, und rät Technologiebenutzer(inne)n nicht, nur die Anbieter mit den höchsten Bewertungen oder anderen Bezeichnungen auszuwählen. Gartner-Forschungspublikationen stellen die Meinungen der Forschungsorganisation von Gartner dar und sollten nicht als Tatsachenbehauptungen ausgelegt werden. Gartner lehnt alle ausdrücklichen oder stillschweigenden Gewährleistungen in Bezug auf diese Studie ab, einschließlich aller Gewährleistungen der Marktgängigkeit oder Eignung für einen bestimmten Zweck.***\n\n***Diese Grafik wurde von Gartner Inc. als Teil eines umfassenderen Berichts veröffentlicht und sollte im Kontext des gesamten Dokuments bewertet werden. Das Gartner-Dokument ist auf Anfrage bei Gartner erhältlich.***",[839,840,687,860,9],"DevOps","2025-04-28",{"slug":863,"featured":91,"template":691},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","content:de-de:blog:gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","Gitlab Named A Leader In The 2024 Gartner Magic Quadrant For Devops","de-de/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","de-de/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"_path":869,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":870,"content":873,"config":882,"_id":884,"_type":14,"title":885,"_source":16,"_file":886,"_stem":887,"_extension":19},"/de-de/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":871,"title":872},"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":874,"body":875,"authors":876,"updatedDate":879,"date":880,"title":872,"tags":881,"description":871,"category":751},"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/).",[877,878],"Mike Flouton","Andy Bradfield","2025-06-23","2025-06-20",[285,751,109,9],{"featured":91,"template":691,"slug":883},"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":889,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":890,"content":896,"config":904,"_id":906,"_type":14,"title":907,"_source":16,"_file":908,"_stem":909,"_extension":19},"/de-de/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"ogTitle":891,"schema":892,"ogImage":893,"ogDescription":894,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":895,"title":891,"canonicalUrls":895,"description":894},"GitLab Duo: So testen wir KI-generierten Code","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Entwicklung von GitLab Duo: Sicheres und gründliches Testen von KI-generiertem Code\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-05-30\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097183/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750097183481.png","Erfahre Schritt für Schritt, wie du die Zuverlässigkeit und Sicherheit von KI-generiertem Code mithilfe von GitLab Duo und GitLab Pages (einschließlich Codebeispielen und Prompts) verbessern kannst.","https://about.gitlab.com/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"heroImage":893,"body":897,"authors":898,"updatedDate":900,"date":901,"title":902,"tags":903,"description":894,"category":683},"***Generative KI bedeutet einen monumentalen Wandel in der\nSoftwareentwicklungsbranche, da sie die Entwicklung, die Sicherheit und den\nBetrieb von Software vereinfacht. Die neue Blog-Reihe unserer Produkt- und\nEntwicklungsteams zeigt, wie wir die KI-Funktionen erstellen, testen und\nbereitstellen, die in Unternehmen benötigt werden. Lerne neue Funktionen\ninnerhalb von GitLab Duo kennen und erfahre, wie diese DevSecOps-Teams dabei\nhelfen, bessere Ergebnisse für ihre Kund(inn)en zu erzielen.***\n\n\n## Inhaltsverzeichnis\n\n\n* [Herausforderungen bei der Verwendung von KI-generiertem Code](#herausforderungen-bei-der-verwendung-von-ki-generiertem-code)\n\n* [Der Ansatz von GitLab für die Sicherheit und das Testen von KI](#der-ansatz-von-gitlab-für-die-sicherheit-und-das-testen-von-ki)\n\n  * [1. Ein neues Projekt auf GitLab.com erstellen](#1.-ein-neues-projekt-auf-gitlab.com-erstellen)\n  * [2. GitLab Duo-Codevorschläge aktivieren](#2.-gitlab-duo-codevorschläge-aktivieren)\n  * [3. Einen Flask Webserver erstellen](#3.-einen-flask-webserver-erstellen)\n  * [4. Tests mit GitLab Duo generieren](#4.-tests-mit-gitlab-duo-generieren)\n  * [5. Probleme mit KI-generiertem Code mithilfe von GitLab Duo Chat identifizieren](#5.-probleme-mit-ki-generiertem-code-mithilfe-von-gitlab-duo-chat-identifizieren)\n  * [6. Testberichte erstellen](#6.-testberichte-erstellen)\n  * [7. Den Testbericht mit GitLab Pages bereitstellen](#7.-den-testbericht-mit-gitlab-pages-bereitstellen)\n  * [8. Testberichte in MR-Widgets einbetten](#8.-testberichte-in-mr-widgets-einbetten)\n* [Fallstudie: Zuverlässigkeit von KI mit Sicherheitsrichtlinien und Scannern](#fallstudie-zuverlässigkeit-von-ki-mit-sicherheitsrichtlinien-und-scannern)\n\n* [Lege noch heute los](#lege-noch-heute-los)\n\n* [Lies mehr über die Reihe „Entwicklung von GitLab Duo\"](#lies-mehr-über-die-reihe-„entwicklung-von-gitlab-duo“)\n\n\nDa KI zunehmend Bestandteil der Softwareentwicklung wird, ist die Gewährleistung der Sicherheit und das gründliche Testen von KI-generiertem Code von größter Bedeutung. Dieser Artikel ist eine Schritt-für-Schritt-Anleitung zur Kombination von [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/), unserer Suite von KI-Funktionen zur Unterstützung des DevSecOps-Workflows, und [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/), um KI-generierten Code zu sichern und gründlich zu testen. Du erfährst, wie du typische Risiken minimieren kannst und wie du automatisch Tests generierst, Code testest und Testberichte erstellst, um die Zuverlässigkeit deines KI-generierten Codes zu verbessern.\n\n\n## Herausforderungen bei der Verwendung von KI-generiertem Code\n\n\nKI-generierter Code steht häufig vor folgenden Problemen:\n\n\n* Nicht übereinstimmende Algorithmen: Es können falsche oder suboptimale Algorithmen generiert werden.\n\n* Probleme mit Abhängigkeiten: KI-generierter Code kann Abhängigkeiten enthalten, die veraltet oder inkompatibel sind.\n\n* Sicherheitslücken: KI kann Code mit potenziellen Sicherheitsschwachstellen generieren.\n\n\nKI-generierter Code hat oft mit Problemen wie nicht übereinstimmenden Algorithmen, Abhängigkeitsproblemen und Sicherheitslücken zu kämpfen. Eine [kürzlich von der Association of Computing Machinery veröffentlichte Studie](https://dl.acm.org/doi/pdf/10.1145/3613904.3642596) zu den Antworten von ChatGPT auf Programmierfragen ergab, dass 52 % der Antworten falsche Informationen enthielten und 77 % zu ausführlich waren. Trotz dieser Mängel bevorzugten die Benutzer(innen) in 35 % der Fälle die umfassenden und gut formulierten Antworten von ChatGPT, wobei sie in 39 % der Fälle sogar Fehlinformationen übersahen. Die Bewältigung dieser Herausforderungen erfordert den Einsatz fortschrittlicher Tools und Frameworks.\n\n\n## Der Ansatz von GitLab für die Sicherheit und das Testen von KI\n\n\nGitLab hat eine umfassende Inhaltsstrategie, die sich auf die Integration von Sicherheitsmaßnahmen in den Entwicklungsworkflow konzentriert. Durch die Nutzung von GitLab Duo für die KI-gestützte Codegenerierung und GitLab Pages für die Einbettung von Testberichten können Entwickler(innen) sicherstellen, dass ihr KI-generierter Code sowohl sicher als auch zuverlässig ist.\n\n\nHier ist eine Schritt-für-Schritt-Anleitung für die Kombination von GitLab Duo und GitLab Pages, um durch die Implementierung eines [Flask-Webservers](https://flask.palletsprojects.com/en/3.0.x/) sicheren und gründlich getesteten KI-generierten Code zu gewährleisten.\n\n\n### 1. Ein neues Projekt auf GitLab.com erstellen\n\n\n* Gehe zu [GitLab.com](http://GitLab.com).\n\n* Klicke auf die Schaltfläche „Neues Projekt“.\n\n* Wähle „Leeres Projekt erstellen“ aus.\n\n* Gib einen Projektnamen ein (z. B. AI_Code_Security).\n\n* Lege die Sichtbarkeitsebene fest (öffentlich, intern oder privat).\n\n* Klicke auf „Projekt erstellen“.\n\n\n### 2. GitLab Duo-Codevorschläge aktivieren\n\n\n* Navigiere zu deinem Projekt.\n\n* Klicke auf die Schaltfläche „Web IDE“, um die Web IDE zu öffnen.\n\n* Stelle sicher, dass GitLab Duo-Funktionen wie Codevorschläge und Duo-Chat aktiviert sind. \n\n* Beginne mit der Programmierung in der [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/). Während du tippst, liefert GitLab Duo Codevorschläge, die dir helfen, effizienter zu programmieren.\n\n\n### 3. Einen Flask Webserver erstellen\n\n\nDu kannst mithilfe des Kommentars im Screenshot unten (grün hervorgehoben) einen Flask Webserver erstellen.\n\n\n![DGD-Testing – Bild 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097192520.png)\n\n\n### 4. Tests mit GitLab Duo generieren\n\n\nUnit-Tests sind für die Validierung der Funktionalität des generierten Codes unerlässlich. Verwende den Befehl `/tests` von GitLab Duo, um [Testvorschläge direkt in der Web IDE zu generieren](https://docs.gitlab.com/ee/user/gitlab_duo_chat_examples.html#write-tests-in-the-ide). Dieser Befehl kann mit zusätzlichen Anweisungen angepasst werden, um einen Fokus auf bestimmte Aspekte wie Leistung, Regression oder die Verwendung bestimmter Frameworks zu erreichen.\n\n\n#### Beispiel für die Verwendung in Web IDE:\n\n\n* Wähle den Code aus, für den du Tests generieren möchtest.\n\n* Verwende den Befehl `/tests` und füge bei Bedarf zusätzliche Anweisungen hinzu.\n\n\n![DGD-Testing – Bild 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097192521.png)\n\n\n### 5. Probleme mit KI-generiertem Code mithilfe von GitLab Duo Chat identifizieren\n\n\nVerwende GitLab Duo Chat, um KI-generierten Code zu überprüfen und zu optimieren. Wir können zum Beispiel den Code für unseren Flask Webserver auf Sicherheitslücken überprüfen:\n\n\n```unset\n\nPrompt: Überprüfe diesen Code auf potenzielle Sicherheitslücken und Abhängigkeitsprobleme.\n\n```\n\n\n![DGD-Testing – Bild 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097192523.png)\n\n\nGitLab Duo Chat kann helfen, die Sicherheitslücken im oben gezeigten Code zu identifizieren.\n\n\n### 6. Testberichte erstellen\n\n\nNachdem du deine Tests durchgeführt hast, erstellst du einen Testbericht, der mit GitLab Pages bereitgestellt wird.\n\n\n```unset\n\nPrompt: Schreibe mir ein Python-Skript, das einen Testbericht erstellt, der mit GitLab Pages bereitgestellt wird.\n\n```\n\n\n![DGD-Testing – Bild 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097192/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097192525.png)\n\n\nWas passiert hier?\n\n\n* Das Skript stellt sicher, dass das Verzeichnis test_reports existiert.\n\n* Es führt die Datei `test_server.py` mit `subprocess.run()` aus und erfasst die Ausgabe.\n\n* Die Rohausgabe wird in `test_reports/test_output.txt` gespeichert.\n  Es wird ein HTML-Bericht erstellt, der die Testausgabe aus Gründen der Lesbarkeit in die `\u003Cpre>`-Tags einbettet und als `test_reports/index.html` gespeichert wird.\n\n### 7. Den Testbericht mit GitLab Pages bereitstellen\n\n\nVerwende [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/), um den Testbericht zu hosten und anzuzeigen. Hier ist die Konfiguration für unsere Datei `.gitlab-ci.yml`, um den Testbericht bereitzustellen.\n\n\n```python\n\nstages:\n  - test\n  - deploy\ntest_job:\n  stage: test\n  script:\n    - python generate_test_report.py\n  artifacts:\n    paths:\n      - test_reports/\npages:\n  stage: deploy\n  script:\n    - mv test_reports public\n  artifacts:\n    paths:\n      - public\n```\n\n\nBei dieser Konfiguration führt die Phase `test_job` das Python-Skript aus, um den Testbericht zu erstellen. Die Phase `pages` verschiebt das Verzeichnis `test_reports` in den Pfad `public`, wo GitLab Pages den Inhalt bereitstellt.\n\n\n### 8. Testberichte in MR-Widgets einbetten\n\n\nDie Einbettung der [Testberichte in MR-Widgets](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html) bietet einen sofortigen Einblick in die Testergebnisse und gewährleistet Transparenz und Zuverlässigkeit. Dazu kannst du den Testbericht als Artefakt in die Konfiguration deiner CI/CD-Pipeline aufnehmen:\n\n\n```python\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the project...\"\n    - # Your build commands here\n\ntest_job:\n  stage: test\n  script:\n    - mkdir -p test-reports\n    - python test_server.py > test-reports/results.xml\n  artifacts:\n    when: always\n    reports:\n      junit: test-reports/results.xml\n    paths:\n      - test-reports/results.xml\n\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - mv test-reports .public/\n  artifacts:\n    paths:\n      - .public\n```\n\n\nIndem du den Testbericht als Artefakt einfügst und ihn im Abschnitt „reports“ angibst, zeigt GitLab die Testergebnisse automatisch in den MR-Widgets an, was einen sofortigen Einblick in die Testergebnisse ermöglicht und die Transparenz und Zuverlässigkeit erhöht.\n\n\n## Fallstudie: Zuverlässigkeit von KI mit Sicherheitsrichtlinien und Scannern\n\n\nStell dir ein Szenario vor, in dem ein KI-generierter Codeschnipsel eine Abhängigkeit verwendet, die bekannte Sicherheitslücken aufweist. Durch die Verwendung von GitLab Duo und den integrierten Sicherheitsrichtlinien würde diese Abhängigkeit bei der Codeerstellung gekennzeichnet. Das folgende Beispiel wurde von der KI erstellt:\n\n\n```python\n\nimport os\n\nfrom flask import Flask, request\n\n\napp = Flask(__name__)\n\n\n@app.route('/search')\n\ndef search():\n    query = request.args.get('query')\n    execute_os_command(query)\n    return 'You searched for: ' + query\n\ndef execute_os_command(command):\n    os.system(command)\n\nif __name__ == '__main__':\n    app.run()\n```\n\n\nDer Suchendpunkt in diesem Beispiel ist anfällig für OS Command Injection. Durch den Einsatz der GitLab-Komponente Statische Anwendungssicherheitstests ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)) würde diese Sicherheitslücke bereits in der CI/CD-Pipeline entdeckt werden.\n\n\n#### SAST-Scans integrieren, um Sicherheitslücken zu erkennen\n\n\nGitLab SAST analysiert deinen Code automatisch auf Sicherheitslücken. So kannst du es in deine `.gitlab-ci.yml`-Datei integrieren, um nach Problemen zu suchen:\n\n\n```python\n\nstages:\n  - build\n  - test\n  - sast\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the project...\"\n    - # Your build commands here\n\ntest_job:\n  stage: test\n  script:\n    - python test_server.py > test-reports/results.xml\n  artifacts:\n    when: always\n    reports:\n      junit: test-reports/results.xml\n    paths:\n      - test-reports/results.xml\n\nsast_job:\n  stage: sast\n  script:\n    - echo \"Running SAST...\"\n  artifacts:\n    reports:\n      sast: gl-sast-report.json\n  only:\n    - branches\n\npages:\n  stage: deploy\n  script:\n    - mv test-reports public\n  artifacts:\n    paths:\n      - public\n```\n\n\nIn dieser Konfiguration wird SAST in der Phase `sast_job` ausgeführt, um Sicherheitslücken im Code zu erkennen, und einen Bericht (`gl-sast-report.json`) zu erstellen, der in die Pipeline-Artefakte aufgenommen wird. Durch die Integration von Sicherheitsrichtlinien und robusten Test-Frameworks hilft GitLab Duo Kund(inn)en dabei, sicherzustellen, dass ihr KI-generierter Code sowohl effizient als auch sicher ist.\n\n\n## Lege noch heute los\n\n\nDie Integration von KI in die Softwareentwicklung bringt erhebliche Vorteile, aber auch neue Herausforderungen mit sich. Durch die Verwendung von Tools wie GitLab Duo und GitLab Pages können Entwickler(innen) sicherstellen, dass ihr KI-generierter Code sicher, gut getestet und zuverlässig ist. Erkunde diese Tools noch heute und beteilige dich an der Diskussion über die Verbesserung der Sicherheit und des Testens von KI.\n\n\n>  [Starte noch heute eine Testversion von GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial), um GitLab Duo und GitLab Pages auszuprobieren.\n\n\n## Lies mehr über die Reihe „Entwicklung von GitLab Duo“\n\n\n* [Entwicklung von GitLab Duo: Wie wir KI-Modelle im großen Maßstab validieren und testen](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n\n* [Entwicklung von GitLab Duo: 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\n* [Entwicklung von GitLab Duo: Dogfooding unserer KI-Funktionen](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n",[899],"David O'Regan","2025-05-29","2024-05-30","Entwicklung von GitLab Duo: Sicheres und gründliches Testen von KI-generiertem Code",[685,9,686,773],{"slug":905,"featured":6,"template":691},"how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code","content:de-de:blog:how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code.yml","How Gitlab Duo Helps Secure And Thoroughly Test Ai Generated Code","de-de/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code.yml","de-de/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"_path":911,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":912,"content":918,"config":925,"_id":927,"_type":14,"title":928,"_source":16,"_file":929,"_stem":930,"_extension":19},"/de-de/blog/introducing-the-source-insights-for-the-future-of-software-development",{"title":913,"description":914,"ogTitle":913,"ogDescription":914,"noIndex":6,"ogImage":915,"ogUrl":916,"ogSiteName":673,"ogType":674,"canonicalUrls":916,"schema":917},"Einführung in The Source: Einblicke in die Zukunft der Softwareentwicklung","In unserer neuen Publikation findest du transformative Softwareentwicklungsstrategien und Ratschläge von Expert(inn)en zu neuen Technologien.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674616/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","https://about.gitlab.com/blog/introducing-the-source-insights-for-the-future-of-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Einführung in The Source: Einblicke in die Zukunft der Softwareentwicklung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chandler Gibbons\"}],\n        \"datePublished\": \"2024-10-29\",\n      }",{"title":913,"description":914,"authors":919,"heroImage":915,"date":921,"body":922,"category":839,"tags":923,"updatedDate":924},[920],"Chandler Gibbons","2024-10-29","Die moderne Softwareentwicklung verändert die Art und Weise, wie Unternehmen geschäftlichen Mehrwert schaffen, liefern und skalieren. Die Teams müssen in der Lage sein, schnell und effizient Lösungen zu entwickeln und gleichzeitig mit den zunehmenden Sicherheitsbedrohungen, neuen Technologien und immer komplexeren Compliance-Anforderungen umzugehen.\n\nHeute bringt GitLab [The Source](https://about.gitlab.com/the-source/) auf den Markt, eine neue Publikation, die sich mit der Entwicklung der Softwareentwicklung als Motor für den Geschäftserfolg beschäftigt. Wir bieten regelmäßig Einblicke in die Zukunft der Softwareentwicklung, gestützt auf eigene Forschung und Analysen unserer Fachleute und Vordenker(innen).\n\nAuf The Source findest du zum Beispiel Antworten auf folgende Fragen:  \n* Wie können Führungskräfte den ROI von KI über den gesamten Software-Entwicklungsprozess hinweg messen?    \n* Wie lassen sich Sicherheit und Compliance in der gesamten Software-Lieferkette am besten gewährleisten?\n* Welche Arten von Effizienzgewinnen können Teams durch die Konsolidierung von Plattformen und Toolchains erzielen?\n\nHier ein aktueller Auszug von The Source:\n\n**4 Schritte zur Messung der Auswirkungen von KI**\n\n„Die Bewertung der Produktivität von KI-gestütztem Coding erfordert einen differenzierteren Ansatz als herkömmliche Kennzahlen wie Codezeilen, Code Commits oder die Erledigung von Aufgaben. Es ist notwendig, den Fokus auf reale Geschäftsergebnisse zu verlagern, die ein Gleichgewicht zwischen Entwicklungsgeschwindigkeit, Softwarequalität und Sicherheit herstellen.“  \n- [Erfahre mehr über die 4 nötigen Schritte vom KI-Experten Taylor McCaslin (nur in englischer Sprache)](https://about.gitlab.com/the-source/ai/4-steps-for-measuring-the-impact-of-ai/)\n\n**Behebung der Grundursache für häufigen Frust, der durch umständliche Sicherheitsanforderungen verursacht wird**\n\n„DevSecOps verspricht eine bessere Integration zwischen Engineering und Sicherheit, aber es ist klar, dass Frustrationen und Fehlausrichtungen bestehen bleiben. Das liegt daran, dass diese Herausforderungen Symptome eines größeren Problems sind, wie Unternehmen Sicherheit sehen, wie Teams zusammenarbeiten und wie sie Zeit für Sicherheit aufwenden.“\n- [Löse dieses Problem mit fachkundigem Rat des CISO von GitLab, Josh Lemos (nur in englischer Sprache).](https://about.gitlab.com/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/)\n\n**Bessere Geschäftsergebnisse durch Platform Engineering**\n\n„Platform Engineering zielt darauf ab, die Workflows von Entwickler(inne)n zu normalisieren und zu standardisieren, indem es Entwickler(inne)n optimierte „Golden Paths“ für die meisten ihrer Workloads und Flexibilität bei der Definition von Ausnahmen für den Rest bietet.“\n- [Entdecke die Best Practices für den Erfolg des Platform Engineerings von Brian Wald, Field CTO von GitLab (nur in englischer Sprache).](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/)\n\n## Lass dir von The Source bei deinen Entscheidungen helfen\n\nAuf [The Source (nur in englischer Sprache)](https://about.gitlab.com/the-source/), findest du die neuesten Erkenntnisse, Antworten auf deine Fragen zu Führungsthemen und kannst immer etwas Neues lernen, das du mit deinen Teams teilen kannst. Du kannst auch unseren Newsletter abonnieren, um regelmäßige Updates direkt in deinem Posteingang zu erhalten. Werde Teil unserer Community zukunftsorientierter Technologie-Leader und gestalte die Zukunft der Softwareentwicklung mit.",[685,773,839,9],"2024-11-14",{"slug":926,"featured":91,"template":691},"introducing-the-source-insights-for-the-future-of-software-development","content:de-de:blog:introducing-the-source-insights-for-the-future-of-software-development.yml","Introducing The Source Insights For The Future Of Software Development","de-de/blog/introducing-the-source-insights-for-the-future-of-software-development.yml","de-de/blog/introducing-the-source-insights-for-the-future-of-software-development",{"_path":932,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":933,"content":939,"config":945,"_id":947,"_type":14,"title":948,"_source":16,"_file":949,"_stem":950,"_extension":19},"/de-de/blog/jenkins-to-gitlab-migration-made-easy",{"title":934,"description":935,"ogTitle":934,"ogDescription":935,"noIndex":6,"ogImage":936,"ogUrl":937,"ogSiteName":673,"ogType":674,"canonicalUrls":937,"schema":938},"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":934,"description":935,"authors":940,"heroImage":936,"date":941,"body":942,"category":10,"tags":943,"updatedDate":944},[770],"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",[109,9],"2025-02-13",{"slug":946,"featured":91,"template":691},"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":952,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":953,"content":959,"config":967,"_id":969,"_type":14,"title":970,"_source":16,"_file":971,"_stem":972,"_extension":19},"/de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"ogTitle":954,"schema":955,"ogImage":956,"ogDescription":957,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":958,"title":954,"canonicalUrls":958,"description":957},"GitLab: Ein Jahr Secure by Design – unser Update","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Letztes Jahr haben wir das Secure by Design-Versprechen unterzeichnet – hier ist unser Fortschritt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2025-06-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659684/Blog/Hero%20Images/AdobeStock_479904468__1_.jpg","Ein Jahr Secure by Design: GitLabs Fortschritte bei MFA, Passwort-Sicherheit, Patches und Schwachstellen-Management. CISA-konform.","https://about.gitlab.com/de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"title":960,"description":961,"authors":962,"heroImage":956,"date":964,"body":965,"category":773,"tags":966},"Letztes Jahr haben wir das Secure by Design-Versprechen unterzeichnet – hier ist unser Fortschritt","Erfahre mehr über GitLabs CISA-konforme Erweiterungen und Verbesserungen bei MFA, Reduzierung von Standardpasswörtern, Patches und Offenlegung von Schwachstellen.",[963],"Joseph Longo","2025-06-09","Vor etwas mehr als einem Jahr hat GitLab [CISAs Secure by Design Pledge](https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17/) unterzeichnet, eine Richtlinie für Technologieanbieter, Sicherheit von Beginn der Entwicklung an ins Herz ihrer Produkte zu integrieren. Seitdem haben wir erhebliche Fortschritte bei der Verbesserung unserer Sicherheitslage gemacht und ein sichereres Ökosystem für unsere Kund(inn)en geschaffen, um sichere Software schneller zu entwickeln.\n\n## Die Sicherheitsziele erreichen\n\nSchauen wir uns die Erweiterungen und Verbesserungen an, die wir vorgenommen haben, um die Sicherheit über den gesamten Entwicklungslebenszyklus hinweg weiter zu verbessern.\n\n### Multi-Faktor-Authentifizierung (MFA)\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens nachweisbare Maßnahmen zur messbaren Erhöhung der Nutzung von Multi-Faktor-Authentifizierung in den Produkten des Herstellers demonstrieren.***\n\nGitLab bietet derzeit mehrere [MFA](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html)-Optionen für Nutzer(innen), um ihre Konten zu sichern. Wir bieten auch SSO-Funktionalität an, damit [GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/)-, [Self-Managed](https://docs.gitlab.com/integration/saml/)- und [GitLab Dedicated](https://docs.gitlab.com/integration/saml/)-Kund(inn)en ihre Authentifizierungsprozesse und internen MFA-Anforderungen optimieren können.\n\nUm die Widerstandsfähigkeit der Plattform weiter zu verbessern und eine sicherere Grundlage für unsere Kund(inn)en zu schaffen, führt GitLab eine schrittweise MFA-by-Default-Einführung durch.\n\nIn den kommenden Monaten werden wir Änderungen implementieren, die alle Kund(inn)en verpflichten, MFA für ihre Konten zu aktivieren.\n\nFür Kund(inn)en, die bereits MFA aktiviert haben oder sich über die Single-Sign-On-Methode (SSO) ihrer Organisation bei GitLab authentifizieren, sind keine Änderungen erforderlich. Kund(inn)en, die noch keine MFA aktiviert haben und sich nicht über die SSO-Methode ihrer Organisation bei GitLab authentifizieren, müssen MFA aktivieren und sich für eine oder mehrere der verfügbaren MFA-Methoden registrieren.\n\nDie MFA-Einführung erfolgt in Phasen, um eine reibungslose und konsistente Annahme bei allen Kund(inn)en zu gewährleisten. Weitere Details zu GitLabs MFA-by-Default-Einführung werden in naher Zukunft geteilt.\n\n### Standardpasswörter\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens messbaren Fortschritt bei der Reduzierung von Standardpasswörtern in den Produkten des Herstellers demonstrieren.***\n\nUm die Verwendung von Standardpasswörtern zu reduzieren, nutzt GitLab zufällig generierte Root-Passwörter für seine verschiedenen Installationsmethoden. GitLabs [Installationsanweisungen](https://docs.gitlab.com/ee/install/install_methods.html) für mehrere Methoden enthalten auch Anleitungen, wie das zufällig generierte Root-Passwort für jede Installation geändert werden kann.\n\nBei einigen Installationsmethoden, wie der Installation von GitLab in einem Docker-Container, wird die Passwortdatei mit dem initialen Root-Passwort beim ersten Container-Neustart nach 24 Stunden gelöscht, um die GitLab-Instanz weiter zu härten.\n\n### Reduzierung ganzer Klassen von Schwachstellen\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, die eine signifikante messbare Reduzierung der Verbreitung einer oder mehrerer Schwachstellenklassen in den Produkten des Herstellers ermöglichen.***\n\nGitLab hat [Richtlinien für sicheres Programmieren](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#sast-coverage) auf seiner Dokumentationsseite veröffentlicht, die Beschreibungen und Richtlinien zur Behebung von Sicherheitsschwachstellen enthalten, die häufig in der GitLab-Codebasis identifiziert werden.\n\nDie Richtlinien sind „darauf ausgelegt, Entwickler(inne)n zu helfen, potenzielle Sicherheitsschwachstellen frühzeitig zu identifizieren, mit dem Ziel, die Anzahl der im Laufe der Zeit veröffentlichten Schwachstellen zu reduzieren.\"\n\nGitLab verbessert kontinuierlich seine [SAST-Regelabdeckung](https://docs.gitlab.com/development/secure_coding_guidelines#sast-coverage), um umfassendere Sicherheitsschwachstellen für sich selbst und seine Kund(inn)en zu adressieren.\n\n### Sicherheitspatches\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, um die Installation von Sicherheitspatches durch Kund(inn)en messbar zu erhöhen.***\n\nGitLab übernimmt alle Updates im Zusammenhang mit seinen GitLab.com- und GitLab Dedicated-Serviceangeboten. Zusätzlich veröffentlicht GitLab eine [Wartungsrichtlinie](https://docs.gitlab.com/ee/policy/maintenance.html), die den Ansatz für die Veröffentlichung von Updates, Rückportierungen, Upgrade-Empfehlungen und unterstützende Dokumentation usw. darlegt.\n\nDie GitLab-Dokumentation bietet umfassende Anleitungen zum [Upgrade](https://docs.gitlab.com/ee/update/?tab=Self-compiled+%28source%29#upgrade-based-on-installation-method) von Self-Managed-Instanzen basierend auf ihrem Bereitstellungsmodell. Dies umfasst Omnibus-, Helm-Chart-, Docker- und selbstkompilierte GitLab-Installationen.\n\nGitLab bietet auch einen detaillierten [Upgrade-Plan](https://docs.gitlab.com/ee/update/plan_your_upgrade.html), um ordnungsgemäße Tests und Fehlerbehebung sowie bei Bedarf Rollback-Pläne zu gewährleisten.\n\nJe nach Versions-Upgrade werden spezifische Änderungen ([Beispiel für GitLab 17](https://docs.gitlab.com/ee/update/versions/gitlab_17_changes.html)) für jede Version hervorgehoben, um einen reibungslosen Upgrade-Prozess zu gewährleisten und die Nichtverfügbarkeit von Diensten zu begrenzen.\n\n### Richtlinie zur Offenlegung von Schwachstellen\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine Richtlinie zur Offenlegung von Schwachstellen (VDP) veröffentlichen.***\n\nGitLab unterhält ein starkes Bug-Bounty-Programm über [HackerOne](https://hackerone.com/gitlab?type=team), eine [security.txt](https://gitlab.com/.well-known/security.txt)-Datei, die GitLabs bevorzugte und zusätzliche Offenlegungsprozesse hervorhebt, sowie [Release-Posts](https://about.gitlab.com/de-de/releases/categories/releases/), die Sicherheitsfixes hervorheben.\n\nKund(inn)en und die Öffentlichkeit können sich anmelden, um GitLabs Release-Posts direkt in ihrem E-Mail-Posteingang zu erhalten.\n\n### Common Vulnerability Enumerations\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Transparenz in der Schwachstellenberichterstattung demonstrieren***\n\nGitLab fügt das Common Weakness Enumeration (CWE)-Feld in alle Common Vulnerability Enumeration (CVE)-Datensätze ein, die es veröffentlicht. Im vergangenen Jahr hat GitLab iterativ auch das Common Platform Enumeration (CPE)-Feld in CVE-Datensätzen aufgenommen.\n\nDas GitLab [CVE-Zuweisungsprojekt](https://gitlab.com/gitlab-org/cves) speichert eine Kopie aller CVE-Identifikatoren, die von GitLab in seiner Rolle als CVE Numbering Authority zugewiesen und veröffentlicht wurden.\n\n> Schau dir [GitLabs CVE-Einreichungsvorlage](https://gitlab.com/gitlab-org/cves/-/blob/master/.gitlab/issue_templates/Internal%20GitLab%20Submission.md?ref_type=heads) an.\n\n### Beweise für Eindringlinge\n\n***Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine messbare Erhöhung der Fähigkeit von Kund(inn)en demonstrieren, Beweise für Cybersicherheitseindringlinge zu sammeln, die die Produkte des Herstellers betreffen.***\n\nGitLab hat einen [Leitfaden zur Vorfallreaktion](https://docs.gitlab.com/ee/security/responding_to_security_incidents.html) veröffentlicht, um Kund(inn)en bei der Reaktion auf Vorfälle mit GitLab-Instanzen zu helfen. Zusätzlich hat GitLab Open-Source-Versionen seiner [GUARD Detection-as-Code](https://about.gitlab.com/blog/unveiling-the-guard-framework-to-automate-security-detections-at-gitlab/)- und TLDR-Bedrohungserkennungs-Frameworks veröffentlicht. Die Repositories für diese Open-Source-Frameworks finden sich im [GitLab Open Source Security Center](https://about.gitlab.com/de-de/security/open-source-resources/).\n\nIn ähnlicher Weise fügt GitLab Funktionalität zu seinem [GitLab.com](http://gitLab.com)-Serviceangebot hinzu, um [kompromittierte Passwörter zu erkennen](https://about.gitlab.com/blog/introducing-compromised-password-detection-for-gitlab-com/) für alle Anmeldungen, die GitLabs native Benutzername- und Passwort-Authentifizierungsmethode verwenden.\n\n## Was kommt als Nächstes\n\nDie [Mission der GitLab Security Division](https://gitlab.com/gitlab-com/gl-security) ist es, allen zu ermöglichen, auf einer sicheren, geschützten und vertrauenswürdigen DevSecOps-Plattform zu innovieren und erfolgreich zu sein.\n\nGitLabs Sicherheitsverbesserungen im vergangenen Jahr haben es uns ermöglicht, unser Engagement für CISAs Secure by Design Pledge zu demonstrieren, und sie haben unsere Plattform gestärkt und Kund(inn)en eine zuverlässigere und sicherere Grundlage zum Aufbauen gegeben.\n\nUnser Engagement für Iteration bedeutet, dass wir uns bereits auf die nächste Reihe von Innovationen konzentrieren, die uns voranbringen werden.\n\n> Um mehr über GitLabs Sicherheitsverbesserungen zu erfahren, setze ein Lesezeichen für unsere [Sicherheitsseite im GitLab Blog](https://about.gitlab.com/de-de/blog/categories/security/).\n\n## Mehr lesen\n\n* [Secure by Design-Prinzipien treffen auf DevSecOps-Innovation in GitLab 17 (Englisch)](https://about.gitlab.com/blog/secure-by-design-principles-meet-devsecops-innovation-in-gitlab-17/)\n* [Happy Birthday, Secure by Design! (Englisch)](https://about.gitlab.com/blog/happy-birthday-secure-by-design/)\n* [Stärke deine Cybersicherheitsstrategie mit Secure by Design](https://about.gitlab.com/de-de/the-source/security/strengthen-your-cybersecurity-strategy-with-secure-by-design/)",[9,687,773,187],{"slug":968,"featured":91,"template":691},"last-year-we-signed-the-secure-by-design-pledge-heres-our-progress","content:de-de:blog:last-year-we-signed-the-secure-by-design-pledge-heres-our-progress.yml","Last Year We Signed The Secure By Design Pledge Heres Our Progress","de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress.yml","de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"_path":974,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":975,"content":981,"config":989,"_id":991,"_type":14,"title":992,"_source":16,"_file":993,"_stem":994,"_extension":19},"/de-de/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions",{"title":976,"description":977,"ogTitle":976,"ogDescription":977,"noIndex":6,"ogImage":978,"ogUrl":979,"ogSiteName":673,"ogType":674,"canonicalUrls":979,"schema":980},"Lerne fortschrittliche Rust-Programmierung mit KI-Unterstützung","In diesem Tutorial vertiefst du mithilfe der KI-basierten Codevorschläge von GitLab Duo deine Kenntnisse in der fortgeschrittenen Rust-Programmierung.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662439/Blog/Hero%20Images/codewithheart.png","https://about.gitlab.com/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Lerne fortschrittliche Rust-Programmierung mit KI-Unterstützung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2023-10-12\",\n      }",{"title":976,"description":977,"authors":982,"heroImage":978,"date":983,"body":984,"category":683,"tags":985,"updatedDate":988},[680],"2023-10-12","Vor mehr als 20 Jahren musste ich für eine Programmiersprache die MSDN-Bibliothek von Visual Studio 6 mit 6 CD-ROMs installieren. Algorithmen mit Stift und Papier, Bücher für Entwurfsmuster und MSDN-Abfragen waren oft zeitaufwendig. Das Erlernen neuer Programmiersprachen hat sich mit Remote-Zusammenarbeit und KI stark gewandelt. Jetzt kannst du einen [Remote Development Workspace](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/) nutzen, deinen Bildschirm freigeben und zusammen programmieren. Mit [GitLab Duo Codevorschläge](/gitlab-duo/) hast du immer einen intelligenten Partner. Codevorschläge lernt von deinem Programmierstil und deiner Erfahrung. Es werden nur Input und Kontext benötigt.\n\nWir bauen auf den [Blogbeitrag „Erste Schritte“](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/) auf und erstellen eine einfache Feed-Reader-Anwendung.\n\n- [Vorbereitungen](#preparations)\n    - [Codevorschläge](#code-suggestions)\n- [Rust vertiefen](#continue-learning-rust)\n    - [Hallo, Reader-App](#hello-reader-app)\n    - [Projekt initialisieren](#initialize-project)\n    - [RSS-Feed-URLs definieren](#define-rss-feed-urls)\n- [Module](#modules)\n    - [Modulfunktion im main() aufrufen](#call-the-module-function-in-main)\n- [Crates](#crates)\n    - [feed-rs: XML-Feed parsen](#feed-rs-parse-xml-feed)\n- [Laufzeit-Konfiguration: Programmargumente](#runtime-configuration-program-arguments)\n    - [Umgang mit Benutzereingabefehlern](#user-input-error-handling)\n- [Persistenz und Datenspeicherung](#persistence-and-data-storage)\n- [Optimierung](#optimization)\n    - [Asynchrone Ausführung](#asynchronous-execution)\n    - [Threads spawnen](#spawning-threads)\n    - [Funktionsumfänge, Threads und Abschlüsse](#function-scopes-threads-and-closures)\n- [Feed-XML in Objekte parsen](#parse-feed-xml-into-object-types)\n    - [Generische Feed-Datentypen zuordnen](#map-generic-feed-data-types)\n    - [Fehlerbehebung mit Option::unwrap()](#error-handling-with-option-unwrap)\n- [Benchmarks](#benchmarks)\n    - [Benchmarks für sequentielle/parallele Ausführung](#sequential-vs-parallel-execution-benchmark)\n    - [CI/CD mit Rust-Caching](#cicd-with-rust-caching)\n- [Wie geht es weiter?](#what-is-next)\n    - [Asynchrone Lernübungen](#async-learning-exercises)\n    - [Teile dein Feedback](#share-your-feedback)\n\n## Vorbereitung\nRichte [VS Code](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/#vs-code) und [deine Entwicklungsumgebung mit Rust](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/#development-environment-for-rust) ein.\n\n### Codevorschläge\nMache dich vorher damit vertraut. GitLab Duo Codevorschläge werden angezeigt, während du tippst. Drücke `tab`, um einen Codevorschlag anzunehmen. Das Schreiben von neuem Code funktioniert zuverlässiger als das Refactoring von bestehendem Code. Der gleiche Codevorschlag wird ggf. nicht erneut angezeigt, wenn du einen Codevorschlag löschst. Codevorschläge sind gerade in der Betaphase und wir verbessern die Genauigkeit der generierten Inhalte. Sieh dir die [bekannten Einschränkungen](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#known-limitations) an.\n\n**Tipp:** Die neueste Version von Codevorschläge unterstützt mehrzeilige Anweisungen. Passe die Spezifikationen an deine Bedürfnisse an, um bessere Vorschläge zu erhalten.\n\n\n```rust\n    // Create a function that iterates over the source array\n    // and fetches the data using HTTP from the RSS feed items. // Store the results in a new hash map.\n    // Print the hash map to the terminal.\n```\n\nDie VS-Code-Erweiterung wird angezeigt, wenn ein Vorschlag angeboten wird. Mit `tab` kannst du die vorgeschlagene(n) Zeile(n) oder mit `cmd cursor right` ein Wort annehmen. Über das Menü mit den drei Punkten kannst du immer die Symbolleiste anzeigen.\n\n![VS Code überlagert GitLab Duo Codevorschläge mit Anweisungen](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_code_suggestions_options_overlay_keep_toolbar.png){: .shadow}\n\n## Rust vertiefen\nVertiefen wir nun Rust, eine der [unterstützten Sprachen in Codevorschläge](https://docs.gitlab.com/ee/user/project/repository/code_suggestions.html#supported-languages). [Rust by Example](https://doc.rust-lang.org/rust-by-example/) und das offizielle [Rust-Buch](https://doc.rust-lang.org/book/) bieten einen guten Einstieg. Auf beide Ressourcen wird hier verwiesen.\n\n### Hallo, Reader-App\nEs gibt viele Möglichkeiten, eine Anwendung zu erstellen und Rust zu lernen. Einige beinhalten die Nutzung bestehender Rust-Bibliotheken, der `Crates`. Wir verwenden sie weiter unten. Du kannst eine App mit einer Befehlszeile erstellen, die Bilder verarbeitet und die Ergebnisse in eine Datei schreibt. Es macht Spaß, ein Labyrinth zu lösen oder ein Sudoku-Lösungsprogramm zu schreiben. Spieleentwicklung ist auch gut. Das Buch [Hands-on Rust](https://hands-on-rust.com/) bietet einen Lernpfad für ein Dungeon-Crawler-Spiel. Fatima Sarah Khalid hat [Dragon Realm in C++ mit ein wenig KI-Unterstützung](/blog/building-a-text-adventure-using-cplusplus-and-code-suggestions/) gestartet.\n\nEin echter Anwendungsfall: Wichtige Infos sollen in einem RSS-Feed für (Sicherheits-)Releases, Blogbeiträge und Diskussionen in Foren wie Hacker News gesammelt werden. Oft möchten wir nach Keywords oder Versionen filtern. Mit diesen Anforderungen können wir eine Anforderungsliste erstellen:\n\n1. Daten von verschiedenen Quellen abrufen (HTTP-Websites, REST API, RSS-Feeds). RSS-Feeds in der ersten Iteration.\n1. Die Daten parsen.\n1. Die Daten den Benutzer(innen) präsentieren oder auf die Festplatte schreiben.\n1. Die Leistung optimieren.\n\nDiese Anwendungsausgabe ist nach den Lernschritten verfügbar: \n\n![VS-Code-Terminal, Cargo-Run mit formatierter Feedelement-Ausgabe](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_run_formatted_output_final.png)\n\nDie Anwendung sollte modular und die Grundlage für weitere Datentypen, Filter und Hooks sein, um später Aktionen auszulösen.\n\n### Projekt initialisieren\nZur Erinnerung: `cargo init` im Projekt-Root erstellt die Dateistruktur, darunter den Eingangspunkt `main()`. Daher lernen wir nun, wie wir Rust-Module erstellen und verwenden.\n\nErstelle ein neues Verzeichnis `learn-rust-ai-app-reader`, wechsle dorthin und führe `cargo init` aus. Dieser Befehl führt implizit `git init` aus, um ein neues Git-Repository lokal zu initialisieren. Zuletzt wird der Git-Remote-Repository-Pfad konfiguriert, z. B. `https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader`. Passe den Pfad an. Durch das Pushen des Git-Repositorys [wird automatisch ein neues privates Projekt in GitLab erstellt](https://docs.gitlab.com/ee/user/project/#create-a-new-project-with-git-push).\n\n```shell\nmkdir learn-rust-ai-app-reader\ncd learn-rust-ai-app-reader\n\ncargo init\n\ngit remote add origin https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader.git\ngit push --set-upstream origin main\n```\n\nÖffne VS Code aus dem neu erstellten Verzeichnis. Die CLI `code` öffnet ein neues VS-Code-Fenster auf macOS.\n\n```shell\ncode .\n```\n\n### RSS-Feed-URLs definieren\nFüge eine neue Hashmap hinzu, um die RSS-Feed-URLs in der Datei `src/main.rs` in der Funktion `main()` zu speichern. Du kannst mit GitLab Duo Codevorschläge über einen mehrzeiligen Kommentar ein [`HashMap`](https://doc.rust-lang.org/stable/std/collections/struct.HashMap.html)-Objekt erstellen und mit Standardwerten für Hacker News und TechCrunch initialisieren. Hinweis: Stelle sicher, dass die URLs korrekt sind, wenn du Vorschläge erhältst.\n\n```rust\nfn main() {\n    // Define RSS feed URLs in the variable rss_feeds\n    // Use a HashMap\n    // Add Hacker News and TechCrunch\n    // Ensure to use String as type\n\n}\n```\n\nAnweisungen sind enthalten für:\n:\n\n1. Den Variablennamen `rss_feeds`.\n2. Den Typ `HashMap`.\n3. Initiale Seed-Schlüssel-/Wertpaare.\n4. Den String als Typ (sichtbar mit `to_string()`-Aufrufen).\n\nEin möglicher vorgeschlagener Pfad:\n\n```rust\nuse std::collections::HashMap;\n\nfn main() {\n    // Define RSS feed URLs in the variable rss_feeds\n    // Use a HashMap\n    // Add Hacker News and TechCrunch\n    // Ensure to use String as type\n    let rss_feeds = HashMap::from([\n        (\"Hacker News\".to_string(), \"https://news.ycombinator.com/rss\".to_string()),\n        (\"TechCrunch\".to_string(), \"https://techcrunch.com/feed/\".to_string()),\n    ]);\n\n}\n```\n\n![VS Code mit Codevorschlägen für RSS-Feed-URLs für Hacker News und TechCrunch](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_main_array_rss_feed_urls_suggested.png)\n\nÖffne ein neues Terminal in VS Code (cmd Umschalt p – suche nach `terminal`). Führe `cargo build` aus, um die Änderungen zu erstellen. Die Fehlermeldung weist dich an, den Import von `use std::collections::HashMap;` hinzuzufügen.\n\nDer nächste Schritt betrifft die RSS-Feed-URLs. [Im letzten Blogbeitrag](/blog/learning-rust-with-a-little-help-from-ai-code-suggestions-getting-started/) haben wir Code in Funktionen aufgeteilt. Wir möchten den Code für unsere Reader-Anwendung modular mit Rust-Modulen strukturieren.\n\n## Module\n[Module](https://doc.rust-lang.org/rust-by-example/mod.html) organisieren Code. Mit ihnen können auch Funktionen im Modulbereich ausgeblendet und der Zugriff darauf vom Bereich main() aus beschränkt werden. In unserer Reader-Anwendung möchten wir den RSS-Feed abrufen/XML-Antwort parsen. Der Caller `main()` sollte nur auf die Funktion `get_feeds()` zugreifen können, andere Funktionen sind nur im Modul verfügbar.\n\nErstelle eine neue Datei `feed_reader.rs` im Verzeichnis `src/`. Weise Codevorschläge an, ein öffentliches Modul `feed_reader` und eine öffentliche Funktion `get_feeds()` mit einer String-HashMap als Eingabe zu erstellen. Wichtig: Die Datei- und Modulnamen müssen gemäß der [Rust-Modulstruktur](https://doc.rust-lang.org/book/ch07-02-defining-modules-to-control-scope-and-privacy.html) identisch sein.\n\n![Codevorschläge: öffentliches Modul mit Funktions- und Eingabetypen erstellen](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_public_module_function_input.png){: .shadow}\n\nWenn du Codevorschläge mit Namen/Typ der Eingabevariablen anweist, wird auch das Modul `std::collections::HashMap` importiert. Tipp: Experimentiere mit Kommentaren und verfeinere die Variablentypen. Die Übergabe von Funktionsparametern als Objektreferenzen gilt in Rust als Best Practice.\n\n```rust\n// Create public module feed_reader\n// Define get_feeds() function which takes rss_feeds as String HashMap reference as input\npub mod feed_reader {\n    use std::collections::HashMap;\n\n    pub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n        // Do something with the RSS feeds\n    }\n}\n```\n\n![Codevorschläge: öffentliches Modul mit Funktion `get_feeds()` und vorgeschlagener Eingabevariable](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_public_module_function_input.png){: .shadow}\n\nWeise Codevorschläge innerhalb der Funktion weiter an:\n\n1. `// Iterate over the RSS feed URLs`\n2. `// Fetch URL content`\n3. `// Parse XML body`\n4. `// Print the result`\n\n![Codevorschläge: öffentliches Modul mit Funktion `get_feeds()`, Schritt 1: iterieren](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_01_iterate.png){: .shadow}\n\n![Codevorschläge: öffentliches Modul mit Funktion `get_feeds()`, Schritt 2: URL-Inhalt abrufen](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_02_fetch_content.png){: .shadow}\n\n![Codevorschläge: öffentliches Modul mit Funktion`get_feeds()`, Schritt 3: XML-Body parsen](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_03_parse_body.png){: .shadow}\n\n![Codevorschläge: öffentliches Modul mit Funktion`get_feeds()`, Schritt 4: Ergebnisse drucken](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_04_print_result.png){: .shadow}\n\nCodevorschlag:\n\n```rust\n// Create public module feed_reader\n// Define get_feeds() function which takes rss_feeds as String HashMap reference as input\npub mod feed_reader {\n    use std::collections::HashMap;\n\n    pub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n        // Iterate over the RSS feed URLs\n        for (name, url) in rss_feeds {\n            println!(\"{}: {}\", name, url);\n\n            // Fetch URL content\n            let body = reqwest::blocking::get(url).unwrap().text().unwrap();\n\n            // Parse XML body\n            let parsed_body = roxmltree::Document::parse(&body).unwrap();\n\n            // Print the result\n            println!(\"{:#?}\", parsed_body);\n        }\n    }\n}\n```\n\nDu siehst ein neues Keyword: [`unwrap()`](https://doc.rust-lang.org/rust-by-example/error/option_unwrap.html). Rust unterstützt keine `null`-Werte und verwendet immer den [Typ `Option`](https://doc.rust-lang.org/rust-by-example/std/option.html). Wenn du einen bestimmten wrapped-Typ verwenden willst, z. B. `Text` oder `String`, rufe die Methode `unwrap()` auf, um den Wert zu erhalten. Methode `unwrap()` gerät bei Wert `None` in Panik.\n\n**Hinweis** Codevorschläge bezogen sich auf Funktion `reqwest:: blocking::get` für Kommentaranweisung `// Fetch URL content`. [Crate `reqwest`](https://docs.rs/reqwest/latest/reqwest/) ist kein Tippfehler. Sie bietet einen praktischen, übergeordneten HTTP-Client für asynchrone und blockierende Anfragen.\n\nParsen des XML-Textes ist schwierig. Du erhältst ggf. unterschiedliche Ergebnisse, das Schema ist nicht für jede RSS-Feed-URL gleich. Rufen wir die Funktion `get_feeds()` auf und verbessern den Code.\n\n### Modulfunktion in main() aufrufen\n\nFunktion main() kennt Funktion `get_feeds()` noch nicht, wir müssen ihr Modul importieren. Evtl. kennst du schon die Keywords `include` oder `import`. Das Rust-Modulsystem ist anders.\n\nModule sind in Pfadverzeichnissen organisiert. Hier liegen beide Quelldateien auf derselben Verzeichnisebene vor. `feed_reader.rs` wird als Crate interpretiert, die ein Modul `feed_reader` enthält, das Funktion `get_feeds()` definiert.\n\n```\nsrc/\n  main.rs\n  feed_reader.rs\n```\n\nUm auf `get_feeds()` aus Datei `feed_reader.rs` zuzugreifen, müssen wir den [Modulpfad](https://doc.rust-lang.org/book/ch07-04-bringing-paths-into-scope-with-the-use-keyword.html) in den Bereich `main.rs` bringen, dann den vollständigen Funktionspfad aufrufen.\n\n```rust\nmod feed_reader;\n\nfn main() {\n\n    feed_reader::feed_reader::get_feeds(&rss_feeds);\n\n```\n\nAlternativ können wir den vollständigen Funktionspfad mit Keyword `use` importieren und später den kurzen Funktionsnamen verwenden.\n\n```rust\nmod feed_reader;\nuse feed_reader::feed_reader::get_feeds;\n\nfn main() {\n\n    get_feeds(&rss_feeds);\n\n```\n\n**Tipp:** Lies den Blogbeitrag [Erklärung des Rust-Modulsystems](https://www.sheshbabu.com/posts/rust-module-system/) für ein besseres visuelles Verständnis.\n\n```diff\n\nfn main() {\n    // ...\n\n    // Print feed_reader get_feeds() output\n    println!(\"{}\", feed_reader::get_feeds(&rss_feeds));\n```\n\n```rust\nuse std::collections::HashMap;\n\nmod feed_reader;\n// Alternative: Import full function path\n//use feed_reader::feed_reader::get_feeds;\n\nfn main() {\n    // Define RSS feed URLs in the variable rss_feeds\n    // Use a HashMap\n    // Add Hacker News and TechCrunch\n    // Ensure to use String as type\n    let rss_feeds = HashMap::from([\n        (\"Hacker News\".to_string(), \"https://news.ycombinator.com/rss\".to_string()),\n        (\"TechCrunch\".to_string(), \"https://techcrunch.com/feed/\".to_string()),\n    ]);\n\n    // Call get_feeds() from feed_reader module\n    feed_reader::feed_reader::get_feeds(&rss_feeds);\n    // Alternative: Imported full path, use short path here.\n    //get_feeds(&rss_feeds);\n}\n```\n\nFühre `cargo build` erneut im Terminal aus, um den Code zu erstellen.\n\n```shell\ncargo build\n```\n\nPotenzielle Build-Fehler, wenn sich Codevorschläge auf allgemeinen Code und Bibliotheken für HTTP-Anfragen und XML-Parsing beziehen:\n\n1. Fehler: `could not find blocking in reqwest`. Lösung: Aktiviere Funktion `blocking` für Crate in `Config.toml`: `reqwest = { version = \"0.11.20\", features = [\"blocking\"] }`.\n2. Fehler: `failed to resolve: use of undeclared crate or module reqwest`. Lösung: Füge Crate `reqwest` hinzu.\n3. Fehler: `failed to resolve: use of undeclared crate or module roxmltree`. Lösung: Füge Crate `roxmltree` hinzu.\n\n```shell\nvim Config.toml\n\nreqwest = { version = \"0.11.20\", features = [\"blocking\"] }\n```\n\n```shell\ncargo add reqwest\ncargo add roxmltree\n```\n\n**Tipp:** Kopiere den Fehlermeldungs-String mit einem führenden `Rust \u003Cerror message>` in einen Browser, um zu sehen, ob eine fehlende Crate verfügbar ist. Allgemein führt diese Suche zu einem Ergebnis auf crates.io und du kannst die fehlenden Abhängigkeiten hinzufügen.\n\nWenn der Build erfolgreich ist, führe den Code mit `cargo run` aus und überprüfe die RSS-Feed-Ausgabe von Hacker News.\n\n![VS-Code-Terminal, cargo run zum Abrufen des XML-Feeds von Hacker News](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_fetch_rss_feed_output_hacker_news.png){: .shadow}\n\nWie kann der XML-Body in ein für Menschen lesbares Format geparst werden? Als Nächstes lernen wir über bestehende Lösungen und Rust-Crates.\n\n## Crates\n\nRSS-Feeds haben gemeinsame Protokolle und Spezifikationen. Es fühlt sich an, als würde man das Rad neu erfinden, wenn man XML-Elemente parsen und die untere Objektstruktur verstehen will. Empfehlung: Schau nach, ob es dieses Problem samt Code schon gibt.\n\nDer wiederverwendbare Bibliothekscode in Rust ist in [`Crates`](https://doc.rust-lang.org/rust-by-example/crates.html) organisiert und in Paketen/der Paket-Registry auf crates.io verfügbar. Füge diese Abhängigkeiten hinzu, indem du die Datei `Config.toml` im Abschnitt `[dependencies]` bearbeitest oder `cargo add \u003Cname>` verwendest.\n\nFür die Reader-App verwenden wir [Feed-rs-Crate](https://crates.io/crates/feed-rs). Öffne ein neues Terminal, führe folgenden Befehl aus:\n\n```shell\ncargo add feed-rs\n```\n\n![VS-Code-Terminal: Crate hinzufügen, in Config.toml überprüfen](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_rust_crate_add_feed-rs_explained.png)\n\n### feed-rs: XML-Feed parsen\nGehe zu `src/feed_reader.rs`, ändere den Teil, in dem wir den XML-Body parsen. Codevorschläge versteht, wie Crate `feed-rs` mit Funktion `parser::parse` aufgerufen wird, aber `feed-rs` [erwartet die String-Eingabe als Rohbytes](https://docs.rs/feed-rs/latest/feed_rs/parser/fn.parse_with_uri.html), um die Codierung selbst zu bestimmen. Wir können im Kommentar Anweisungen geben, um das erwartete Ergebnis zu erhalten.\n\n```rust\n            // Parse XML body with feed_rs parser, input in bytes\n            let parsed_body = feed_rs::parser::parse(body.as_bytes()).unwrap();\n```\n\n![Codevorschläge: öffentliches Modul mit Funktion `get_feeds()`, Schritt 5: XML-Parser in feed-rs ändern](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_module_function_05_use_feed_rs_to_parse.png){: .shadow}\n\nDen Vorteil von `feed-rs` siehst du im Ausdruck mit `cargo run`: Alle Schlüssel/Werte werden ihren jeweiligen Rust-Objekttypen zugeordnet und können für weitere Operationen verwendet werden.\n\n![VS-Code-Terminal, cargo run zum Abrufen des XML-Feeds von Hacker News](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_fetch_rss_feed_output_hacker_news_feed_rs.png){: .shadow}\n\n## Laufzeit-Konfiguration: Programmargumente\nBisher haben wir das Programm mit hardcoded RSS-Feed-Werten ausgeführt, die in die Binärdatei kompiliert wurden. Jetzt wird der RSS-Feed zur Laufzeit konfiguriert.\n\nRust stellt in der Standard-Misc-Bibliothek [Programmargumente](https://doc.rust-lang.org/rust-by-example/std_misc/arg.html) bereit. [Argumente parsen](https://doc.rust-lang.org/rust-by-example/std_misc/arg/matching.html) ist besser und schneller als das Zielen auf erweiterte Programmargument-Parser (z. B. die Crate [clap](https://docs.rs/clap/latest/clap/)) oder das Verschieben der Programmparameter in eine Konfigurationsdatei/ein Format ([TOML](https://toml.io/en/), YAML). Vor diesem Blog habe ich Verschiedenes für die beste Lernerfahrung ausprobiert und versagt. Du kannst trotzdem versuchen, RSS-Feeds anders zu konfigurieren.\n\nAls langweilige Lösung können Befehlsparameter als `\"name,url\"` String-Wert-Paare übergeben und durch das `,`-Zeichen getrennt werden, um den Namen und die URL-Werte zu extrahieren. Der Kommentar weist Codevorschläge an, diese Vorgänge auszuführen und die HashMap `rss_feeds` um die neuen Werte zu erweitern. Die Variable ist möglicherweise nicht veränderbar und muss in `let mut rss_feeds` geändert werden.\n\nGehe zu `src/main.rs` und füge der Funktion `main()` nach der Variable `rss_feeds` diesen Code hinzu. Beginne mit einem Kommentar, um die Programmargumente zu definieren, überprüfe die vorgeschlagenen Codeschnipsel.\n\n```rust\n    // Program args, format \"name,url\"\n    // Split value by , into name, url and add to rss_feeds\n```\n\n![Codevorschläge für Programmargumente und Aufteilung von name,URL-Werten für die Variable rss_feeds](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_program_args_boring_solution.png){: .shadow}\n\nVollständiges Codebeispiel:\n\n```rust\nfn main() {\n    // Define RSS feed URLs in the variable rss_feeds\n    // Use a HashMap\n    // Add Hacker News and TechCrunch\n    // Ensure to use String as type\n    let mut rss_feeds = HashMap::from([\n        (\"Hacker News\".to_string(), \"https://news.ycombinator.com/rss\".to_string()),\n        (\"TechCrunch\".to_string(), \"https://techcrunch.com/feed/\".to_string()),\n    ]);\n\n    // Program args, format \"name,url\"\n    // Split value by , into name, url and add to rss_feeds\n    for arg in std::env::args().skip(1) {\n        let mut split = arg.split(\",\");\n        let name = split.next().unwrap();\n        let url = split.next().unwrap();\n        rss_feeds.insert(name.to_string(), url.to_string());\n    }\n\n    // Call get_feeds() from feed_reader module\n    feed_reader::feed_reader::get_feeds(&rss_feeds);\n    // Alternative: Imported full path, use short path here.\n    //get_feeds(&rss_feeds);\n}\n```\n\nDu kannst Programmargumente direkt an den Befehl `cargo run` übergeben, wobei den Argumenten `--` vorgestellt ist.\n `--`. Füge alle Argumente mit doppelten Anführungszeichen und den Namen gefolgt von einem Komma und den RSS-Feed-URL als Argument ein. Trenne alle Argumente mit Leerzeichen.\n\n```\ncargo build\n\ncargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\n![VS-Code-Terminal, Beispiel einer RSS-Feed-Ausgabe für den GitLab-Blog](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_gitlab_blog_rss_feed_example.png){: .shadow}\n\n### Fehlerbehandlung bei Benutzereingaben\nWenn die Benutzereingabe nicht der Programmerwartung entspricht, müssen wir [einen Fehler ausgeben](https://doc.rust-lang.org/rust-by-example/error.html) und dem Caller helfen, die Programmargumente zu beheben. Die Übergabe eines fehlerhaften URL-Formats sollte als Laufzeitfehler behandelt werden. Weise Codevorschläge an, einen Fehler auszugeben, wenn die URL nicht gültig ist.\n\n```rust\n    // Ensure that URL contains a valid format, otherwise throw an error\n```\n\nMögliche Lösung: Beginnt die Variable `url` mit `http://` oder `https://`? Wenn nicht, gib einen Fehler mit dem Makro [Panic! ](https://doc.rust-lang.org/rust-by-example/std/panic.html) aus. Vollständiges Codebeispiel:\n\n```rust\n    // Program args, format \"name,url\"\n    // Split value by , into name, url and add to rss_feeds\n    for arg in std::env::args().skip(1) {\n        let mut split = arg.split(\",\");\n        let name = split.next().unwrap();\n        let url = split.next().unwrap();\n\n        // Ensure that URL contains a valid format, otherwise throw an error\n        if !url.starts_with(\"http://\") && !url.starts_with(\"https://\") {\n            panic!(\"Invalid URL format: {}\", url);\n        }\n\n        rss_feeds.insert(name.to_string(), url.to_string());\n    }\n```\n\nTeste, was passiert, wenn du ein `:` in einem URL-String entfernst. Füge die Umgebungsvariable `RUST_BACKTRACE=full` hinzu, um beim Aufruf von `panic()` eine ausführlichere Ausgabe zu erhalten.\n\n```\nRUST_BACKTRACE=full cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https//www.cncf.io/feed/\"\n```\n\n![VS-Code-Terminal mit falschem URL-Format, panic-Fehler-Backtrace](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_url_format_error_panic_backtrace.png){: .shadow}\n\n## Persistenz und Datenspeicherung\nBei der langweiligen Lösung zum Speichern der Feed-Daten wird der geparste Body in eine neue Datei kopiert. Weise Codevorschläge an, ein Muster zu verwenden, das den RSS-Feed-Namen und das aktuelle ISO-Datum enthält.\n\n```rust\n    // Parse XML body with feed_rs parser, input in bytes\n    let parsed_body = feed_rs::parser::parse(body.as_bytes()).unwrap();\n\n    // Print the result\n    println!(\"{:#?}\", parsed_body);\n\n    // Dump the parsed body to a file, as name-current-iso-date.xml\n    let now = chrono::offset::Local::now();\n    let filename = format!(\"{}-{}.xml\", name, now.format(\"%Y-%m-%d\"));\n    let mut file = std::fs::File::create(filename).unwrap();\n    file.write_all(body.as_bytes()).unwrap();\n```\nEin möglicher Vorschlag ist die Verwendung der [Crate chrono](https://crates.io/crates/chrono). Füge sie mit `cargo add chrono` hinzu, rufe wieder `cargo build` und `cargo run` auf.\n\nDie Dateien werden in das gleiche Verzeichnis geschrieben, in dem `cargo run` ausgeführt wurde. Wenn du die Binärdatei direkt im Verzeichnis `target/debug/` ausführst, werden alle Dateien dort abgelegt.\n\n![VS-Code mit CNCF-RSS-Feed-Inhaltsdatei, auf Festplatte gespeichert](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_cncf_rss_feed_saved_on_disk.png)\n\n## Optimierung\nDie Einträge in der Variable `rss_feeds` werden nacheinander ausgeführt. Bei einer Liste mit über 100 konfigurierten URLs kann das Abrufen und Verarbeiten lange dauern. Was wäre, wenn Abrufanforderungen parallel ausgeführt würden?\n\n### Asynchrone Ausführung\nRust stellt [Threads](https://doc.rust-lang.org/book/ch16-01-threads.html) für die asynchrone Ausführung bereit.\n\nBei der einfachsten Lösung wird für jede RSS-Feed-URL ein Thread erstellt. Wir sprechen später über Optimierungsstrategien. Vor der parallelen Ausführung musst du die Ausführungszeit des sequentiellen Codes mit dem Befehl `cargo run` vor `time` messen.\n\n\n```\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n\n0.21s user 0.08s system 10% cpu 2.898 total\n```\n\nBeachte, dass diese Übung mehr manuelle Codearbeit erfordern könnte. Empfehlung: Den sequentiellen Arbeitszustand in einem neuen Git-Commit und einem neuen Git-Branch `sequential-exec` beibehalten, um die Auswirkungen der parallelen Ausführung besser zu vergleichen.\n\n```shell\ngit commit -avm \"Sequential execution working\"\ngit checkout -b sequential-exec\ngit push -u origin sequential-exec\n\ngit checkout main\n```\n\n### Threads spawnen\nÖffne `src/feed_reader.rs` und refaktorisiere die Funktion `get_feeds()`. Beginne mit einem Git-Commit für den aktuellen Status und lösche dann den Inhalt des Funktionsbereichs. Füge die folgenden Codekommentare hinzu:\n\n1. `// Store threads in vector`: Speichere die Thread-Alias in einem Vektor, damit wir warten können, bis sie am Ende des Funktionsaufrufs abgeschlossen sind.\n2. `// Loop over rss_feeds and spawn threads`: Erstelle Boilerplate-Code für die Iteration über alle RSS-Feeds und einen neuen Thread.\n\nFüge die folgenden `use`-Anweisungen hinzu, um mit den Modulen `thread` und `time` zu arbeiten.\n\n```rust\n    use std::thread;\n    use std::time::Duration;\n```\n\nSchreibe den Code weiter, schließe die for-Schleife. Codevorschläge schlägt dann automatisch vor, das Thread-Alias in der Vektorvariable `threads` hinzuzufügen und bietet an, den Threads am Ende der Funktion beizutreten.\n\n```rust\n    pub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n\n        // Store threads in vector\n        let mut threads: Vec\u003Cthread::JoinHandle\u003C()>> = Vec::new();\n\n        // Loop over rss_feeds and spawn threads\n        for (name, url) in rss_feeds {\n            let thread_name = name.clone();\n            let thread_url = url.clone();\n            let thread = thread::spawn(move || {\n\n            });\n            threads.push(thread);\n        }\n\n        // Join threads\n        for thread in threads {\n            thread.join().unwrap();\n        }\n    }\n```\n\nFüge die Crate `thread` hinzu, erstelle den Code, führe ihn erneut aus.\n\n```shell\ncargo add thread\n\ncargo build\n\ncargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\nZu diesem Zeitpunkt werden keine Daten verarbeitet oder gedruckt. Bevor wir die Funktion erneut hinzufügen, informieren wir uns über die neu eingeführten Keywords.\n\n### Funktionsumfänge, Threads und Closures\nMit dem vorgeschlagenen Code gilt es neue Keywords und Designmuster zu erlernen. Der Thread-Alias hat den Typ `thread:: JoinHandle`, wir können also warten, bis die Threads ([join()](https://doc.rust-lang.org/book/ch16-01-threads.html#waiting-for-all-threads-to-finish-using-join-handles)) beendet haben.\n\n`thread::spawn()` erstellt einen neuen Thread, in dem wir ein Funktionsobjekt übergeben können. In diesem Fall wird der Ausdruck [closure](https://doc.rust-lang.org/book/ch13-01-closures.html) als anonyme Funktion übergeben. Closure-Eingaben werden mit der Syntax `||` übergeben. Du erkennst den [Closure `move`](https://doc.rust-lang.org/book/ch16-01-threads.html#using-move-closures-with-threads), der die Variablen des Funktionsbereichs in den Thread-Bereich verschiebt. Dadurch wird die manuelle Angabe vermieden, welche Variablen in den neuen Funktions-/Closure-Bereich übergeben werden müssen.\n\nEinschränkung: `rss_feeds` ist eine Referenz `&`, die vom Funktions-Caller `get_feeds()` als Parameter übergeben wird. Die Variable ist nur im Funktionsbereich gültig. Provoziere diesen Fehler mit diesem Codeausschnitt:\n\n```rust\npub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n\n    // Store threads in vector\n    let mut threads: Vec\u003Cthread::JoinHandle\u003C()>> = Vec::new();\n\n    // Loop over rss_feeds and spawn threads\n    for (key, value) in rss_feeds {\n        let thread = thread::spawn(move || {\n            println!(\"{}\", key);\n        });\n    }\n}\n```\n\n![VS-Code-Terminal, Fehler im Variablenbereich mit Referenzen und Thread-Verschiebungs-Closure](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_build_error_function_threads_variable_scopes.png){: .shadow}\n\nObwohl die Variable `key` im Funktionsbereich erstellt wurde, verweist sie auf die Variable `rss_feeds` und kann nicht in den Thread-Bereich verschoben werden. Werte, auf die über den Funktionsparameter `rss_feeds` zugegriffen wird, erfordern eine lokale Kopie mit `clone()`.\n\n![VS-Code-Terminal, Thread-Spawn mit Klon](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_rust_thread_spawn_clone.png){: .shadow}\n\n```rust\npub fn get_feeds(rss_feeds: &HashMap\u003CString, String>) {\n\n    // Store threads in vector\n    let mut threads: Vec\u003Cthread::JoinHandle\u003C()>> = Vec::new();\n\n    // Loop over rss_feeds and spawn threads\n    for (name, url) in rss_feeds {\n        let thread_name = name.clone();\n        let thread_url = url.clone();\n        let thread = thread::spawn(move || {\n            // Use thread_name and thread_url as values, see next chapter for instructions.\n```\n\n## Feed-XML in Objekttypen parsen\nAls Nächstes werden die Schritte für das Parsen des RSS-Feeds im Thread-Closure wiederholt. Füge folgende Codekommentare hinzu:\n\n1. `// Parse XML body with feed_rs parser, input in bytes`. Damit rufst du den Inhalt der RSS-Feed-URL ab und parst ihn mit den Crate-Funktionen `feed_rs`.\n2. `// Check feed_type attribute feed_rs::model::FeedType::RSS2 or Atom and print its name`: Extrahiere den Feed-Typ, indem du das Attribut `feed_type` mit dem [`feed_rs::model::FeedType`](https://docs.rs/feed-rs/latest/feed_rs/model/enum.FeedType.html) vergleichst. Dazu braucht Codevorschläge Anweisungen, in denen die genauen ENUM-Werte für den Abgleich angegeben werden.\n\n![Weise Codevorschläge an, mit bestimmten Feed-Typen abzugleichen](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_feed_rs_type_condition.png){: .shadow}\n\n```rust\n            // Parse XML body with feed_rs parser, input in bytes\n            let body = reqwest::blocking::get(thread_url).unwrap().bytes().unwrap();\n            let feed = feed_rs::parser::parse(body.as_ref()).unwrap();\n\n            // Check feed_type attribute feed_rs::model::FeedType::RSS2 or Atom and print its name\n            if feed.feed_type == feed_rs::model::FeedType::RSS2 {\n                println!(\"{} is an RSS2 feed\", thread_name);\n            } else if feed.feed_type == feed_rs::model::FeedType::Atom {\n                println!(\"{} is an Atom feed\", thread_name);\n            }\n```\n\nErstelle das Programm und führe es erneut aus. Überprüfe die Ausgabe.\n\n```\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n\nCNCF is an RSS2 feed\nTechCrunch is an RSS2 feed\nGitLab Blog is an Atom feed\nHacker News is an RSS2 feed\n```\n\nWir überprüfen diese Ausgabe: Öffne die Feed-URLs im Browser oder sieh die heruntergeladenen Dateien an.\n\nHacker News unterstützt RSS-Version 2.0 mit `channel(title,link,description,item(title,link,pubDate,comments))`. TechCrunch und der CNCF-Blog haben eine ähnliche Struktur.\n```xml\n\u003Crss version=\"2.0\">\u003Cchannel>\u003Ctitle>Hacker News\u003C/title>\u003Clink>https://news.ycombinator.com/\u003C/link>\u003Cdescription>Links for the intellectually curious, ranked by readers.\u003C/description>\u003Citem>\u003Ctitle>Writing a debugger from scratch: Breakpoints\u003C/title>\u003Clink>https://www.timdbg.com/posts/writing-a-debugger-from-scratch-part-5/\u003C/link>\u003CpubDate>Wed, 27 Sep 2023 06:31:25 +0000\u003C/pubDate>\u003Ccomments>https://news.ycombinator.com/item?id=37670938\u003C/comments>\u003Cdescription>\u003C![CDATA[\u003Ca href=\"https://news.ycombinator.com/item?id=37670938\">Comments\u003C/a>]]>\u003C/description>\u003C/item>\u003Citem>\n```\n\nIm GitLab-Blog wird das [Atom](https://datatracker.ietf.org/doc/html/rfc4287)-Feed-Format verwendet, das RSS zwar ähnlich ist, aber eine andere Parsing-Logik erfordert.\n```xml\n\u003C?xml version='1.0' encoding='utf-8' ?>\n\u003Cfeed xmlns='http://www.w3.org/2005/Atom'>\n\u003C!-- / Get release posts -->\n\u003C!-- / Get blog posts -->\n\u003Ctitle>GitLab\u003C/title>\n\u003Cid>https://about.gitlab.com/blog\u003C/id>\n\u003Clink href='https://about.gitlab.com/blog/' />\n\u003Cupdated>2023-09-26T00:00:00+00:00\u003C/updated>\n\u003Cauthor>\n\u003Cname>The GitLab Team\u003C/name>\n\u003C/author>\n\u003Centry>\n\u003Ctitle>Atlassian Server ending: Goodbye disjointed toolchain, hello DevSecOps platform\u003C/title>\n\u003Clink href='https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/' rel='alternate' />\n\u003Cid>https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/\u003C/id>\n\u003Cpublished>2023-09-26T00:00:00+00:00\u003C/published>\n\u003Cupdated>2023-09-26T00:00:00+00:00\u003C/updated>\n\u003Cauthor>\n\u003Cname>Dave Steer, Justin Farris\u003C/name>\n\u003C/author>\n```\n\n### Generische Feed-Datentypen zuordnen\nMit [`roxmltree::Document::parse`](https://docs.rs/roxmltree/latest/roxmltree/struct.Document.html) müssten wir den XML-Knotenbaum und dessen spezifische Tag-Namen verstehen. Glücklicherweise bietet [feed_rs::model::Feed](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html) ein kombiniertes Modell für RSS- und Atom-Feeds. Wir verwenden daher die Crate `feed_rs` weiter.\n\n1. Atom: Feed->Feed, Eintrag->Eintrag\n2. RSS: Kanal->Feed, Element->Eintrag\n\nZusätzlich zur obigen Zuordnung müssen wir die erforderlichen Attribute extrahieren und deren Datentypen zuordnen. Es ist hilfreich, [die Dokumentation für feed_rs::model](https://docs.rs/feed-rs/latest/feed_rs/model/index.html) zu öffnen, um die Strukturen und ihre Felder sowie Implementierungen zu verstehen. Andernfalls würden einige Vorschläge zu Fehlern bei der Typkonvertierung und Kompilierungsfehlern führen, die für die Implementierung von `feed_rs` spezifisch sind.\n\nEine [`Feed`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html)-Struktur liefert den `title`, Typ `Option\u003CText>` (entweder ist ein Wert festgelegt oder nichts). Eine [`Entry`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Entry.html)-Struktur bietet:\n\n1. `title`: `Option\u003CText>`mit [`Text`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html) und dem Feld `content` als `String`.\n2. `updated`: `Option\u003CDateTime\u003CUtc>>` mit [`DateTime`](https://docs.rs/chrono/latest/chrono/struct.DateTime.html) mit der [`format()`-Methode](https://docs.rs/chrono/latest/chrono/struct.DateTime.html#method.format).\n3. `summary`: `Option\u003CText>` [`Text`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html) und das Feld `content` als `String`.\n4. `links`: `Vec\u003CLink>`, Vektor mit [`Link`](https://docs.rs/feed-rs/latest/feed_rs/model/struct.Link.html)-Elementen. Das Attribut `href` liefert die rohe URL-Zeichenfolge.\n\nNutze dieses Wissen, um die erforderlichen Daten aus den Feed-Einträgen zu extrahieren. Zur Erinnerung: Alle `Option`-Typen müssen `unwrap()` aufrufen und erfordert weitere rohe Anweisungen für Codevorschläge.\n\n```rust\n                // https://docs.rs/feed-rs/latest/feed_rs/model/struct.Feed.html\n                // https://docs.rs/feed-rs/latest/feed_rs/model/struct.Entry.html\n                // Loop over all entries, and print\n                // title.unwrap().content\n                // published.unwrap().format\n                // summary.unwrap().content\n                // links href as joined string\n                for entry in feed.entries {\n                    println!(\"Title: {}\", entry.title.unwrap().content);\n                    println!(\"Published: {}\", entry.published.unwrap().format(\"%Y-%m-%d %H:%M:%S\"));\n                    println!(\"Summary: {}\", entry.summary.unwrap().content);\n                    println!(\"Links: {:?}\", entry.links.iter().map(|link| link.href.clone()).collect::\u003CVec\u003CString>>().join(\", \"));\n                    println!();\n                }\n```\n\n![Codevorschläge zum Drucken von Feed-Eintragstypen mit spezifischen Anforderungen](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_print_feed_entries_fields_with_rust_type_specifics.png){: .shadow}\n\n### Fehlerbehandlung mit der Option unwrap()\nWiederhole die mehrzeiligen Anweisungen, nachdem du das Programm erstellt und erneut ausgeführt hast. Spoiler: `unwrap()` ruft das Makro `panic!` auf und lässt das Programm abstürzen, wenn es auf leere Werte stößt. Dies kann passieren, wenn ein Feld wie `summary` in den Feed-Daten nicht festgelegt ist.\n\n```shell\nGitLab Blog is an Atom feed\nTitle: How the Colmena project uses GitLab to support citizen journalists\nPublished: 2023-09-27 00:00:00\nthread '\u003Cunnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/feed_reader.rs:40:59\n```\nMögliche Lösung: [`std::Option::unwrap_or_else`](https://doc.rust-lang.org/std/option/enum.Option.html#method.unwrap_or_else) verwenden und einen leeren String als Standardwert festlegen. Die Syntax erfordert einen Closure, der eine leere `Text`-Strukturinstanziierung zurückgibt.\n\nEs waren viele Versuche nötig, um die richtige Initialisierung zu finden. Das Übergeben nur einer leeren Zeichenfolge funktionierte nicht mit benutzerdefinierten Typen. Ich zeige dir, was ich versucht habe.\n\n```rust\n// Problem: The `summary` attribute is not always initialized. unwrap() will panic! then.\n// Requires use mime; and use feed_rs::model::Text;\n/*\n// 1st attempt: Use unwrap() to extraxt Text from Option\u003CText> type.\nprintln!(\"Summary: {}\", entry.summary.unwrap().content);\n// 2nd attempt. Learned about unwrap_or_else, passing an empty string.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| \"\").content);\n// 3rd attempt. summary is of the Text type, pass a new struct instantiation.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{}).content);\n// 4th attempt. Struct instantiation requires 3 field values.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{\"\", \"\", \"\"}).content);\n// 5th attempt. Struct instantation with public fields requires key: value syntax\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: \"\", src: \"\", content: \"\"}).content);\n// 6th attempt. Reviewed expected Text types in https://docs.rs/feed-rs/latest/feed_rs/model/struct.Text.html and created Mime and String objects\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: String::new(), content: String::new()}).content);\n// 7th attempt: String and Option\u003CString> cannot be casted automagically. Compiler suggested using `Option::Some()`.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: Option::Some(), content: String::new()}).content);\n*/\n\n// xth attempt: Solution. Option::Some() requires a new String object.\nprintln!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: Option::Some(String::new()), content: String::new()}).content);\n```\n\nDies war nicht zufriedenstellend, da die Codezeile kompliziert ist und manuelle Arbeit ohne Codevorschläge erforderte. Ich ging also einen Schritt zurück: Wenn `Option` `none` ist, gibt `unwrap()` einen Fehler  aus. Ich fragte Codevorschläge in einem neuen Kommentar:\n\n```\n                // xth attempt: Solution. Option::Some() requires a new String object.\n                println!(\"Summary: {}\", entry.summary.unwrap_or_else(|| Text{content_type: mime::TEXT_PLAIN, src: Option::Some(String::new()), content: String::new()}).content);\n\n                // Alternatively, use Option.is_none()\n```\n\n![Codevorschläge hat nach Alternativen gefragt, wenn Options.is_none](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/code_suggestions_after_complex_unwrap_or_else_ask_for_alternative_option.png){: .shadow}\n\nErgebnis: erhöhte Lesbarkeit, weniger CPU-Zyklen, die mit `unwrap()` verschwendet wurden, und eine Lernkurve .\n\nDenke daran: Füge das Speichern der XML-Daten auf der Festplatte erneut hinzu, um die Reader-App erneut abzuschließen.\n\n```rust\n                // Dump the parsed body to a file, as name-current-iso-date.xml\n                let file_name = format!(\"{}-{}.xml\", thread_name, chrono::Local::now().format(\"%Y-%m-%d-%H-%M-%S\"));\n                let mut file = std::fs::File::create(file_name).unwrap();\n                file.write_all(body.as_ref()).unwrap();\n```\n\nErstelle das Programm, führe es aus, um die Ausgabe zu überprüfen.\n\n```shell\ncargo build\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\n![VS-Code-Terminal, cargo run mit formatierter Ausgabe von Feed-Einträgen](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/vs_code_terminal_cargo_run_formatted_output_final.png)\n\n## Benchmarks\n\n### Benchmarks für sequentielle vs. parallele Ausführung\nVergleiche die Ausführungszeit-Benchmarks, indem du jeweils fünf Samples erstellst.\n\n1. Sequentielle Ausführung. [Beispiel-Quellcode MR](https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader/-/merge_requests/1)\n2. Parallele Ausführung. [Beispiel-Quellcode MR](https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader/-/merge_requests/3)\n\n```shell\n# Sequential\ngit checkout sequential-exec\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n\n0.21s user 0.08s system 10% cpu 2.898 total\n0.21s user 0.08s system 11% cpu 2.585 total\n0.21s user 0.09s system 10% cpu 2.946 total\n0.19s user 0.08s system 10% cpu 2.714 total\n0.20s user 0.10s system 10% cpu 2.808 total\n```\n\n```shell\n# Parallel\ngit checkout parallel-exec\n\ntime cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n\n0.19s user 0.08s system 17% cpu 1.515 total\n0.18s user 0.08s system 16% cpu 1.561 total\n0.18s user 0.07s system 17% cpu 1.414 total\n0.19s user 0.08s system 18% cpu 1.447 total\n0.17s user 0.08s system 16% cpu 1.453 total\n```\n\nDie CPU-Nutzung ist bei der parallelen Ausführung von vier RSS-Feed-Threads gestiegen, hat aber die Gesamtzeit fast halbiert. Wenn wir dies beachten, können wir unsere Kenntnisse von Rust vertiefen und den Code und die Funktionalität optimieren.\n\nBeachte, dass wir den Debug-Build über Cargo ausführen und noch nicht über die optimierten veröffentlichten Builds. Einschränkungen bei der parallelen Ausführung: Einige HTTP-Endpunkte haben Ratenbegrenzungen eingeführt.\n\nDas System, das mehrere Threads parallel ausführt, könnte ebenfalls überlastet werden – Threads erfordern einen Kontextwechsel im Kernel und weisen jedem Thread Ressourcen zu. Während ein Thread Rechenressourcen erhält, werden andere Threads in den Ruhezustand versetzt. Wenn zu viele Threads gespawned werden, kann dies das System verlangsamen, anstatt den Vorgang zu beschleunigen. Lösungen umfassen Entwurfsmuster wie [Arbeitswarteschlangen](https://docs.rs/work-queue/latest/work_queue/), bei denen der Caller eine Aufgabe in eine Warteschlange einfügt und eine definierte Anzahl von Worker-Threads die Aufgaben für die asynchrone Ausführung aufnimmt.\n\nRust bietet auch eine Datensynchronisation zwischen Threads, sogenannten [Channels](https://doc.rust-lang.org/rust-by-example/std_misc/channels.html). Um einen gleichzeitigen Datenzugriff zu gewährleisten, stehen [mutexes](https://doc.rust-lang.org/std/sync/struct.Mutex.html) zur Verfügung, die sichere Sperren bieten.\n\n### CI/CD mit Rust-Caching\nFüge die folgende CI/CD-Konfiguration in die Datei `.gitlab-ci.yml` ein. Der Job `run-latest` ruft `cargo run` mit URL-Beispielen für RSS-Feeds auf und misst die Ausführungszeit kontinuierlich.\n\n```\nstages:\n  - build\n  - test\n  - run\n\ndefault:\n  image: rust:latest\n  cache:\n    key: ${CI_COMMIT_REF_SLUG}\n    paths:\n      - .cargo/bin\n      - .cargo/registry/index\n      - .cargo/registry/cache\n      - target/debug/deps\n      - target/debug/build\n    policy: pull-push\n\n# Cargo data needs to be in the project directory for being cached.\nvariables:\n  CARGO_HOME:${CI_PROJECT_DIR}/.cargo\n\nbuild-latest:\n  stage: build\n  script:\n    - cargo build --verbose\n\ntest-latest:\n  stage: build\n  script:\n    - cargo test --verbose\n\nrun-latest:\n  stage: run\n  script:\n    - time cargo run -- \"GitLab Blog,https://about.gitlab.com/atom.xml\" \"CNCF,https://www.cncf.io/feed/\"\n```\n\n![GitLab-CI/CD-Pipelines für Rust, Cargo-Run-Ausgabe](https://about.gitlab.com/images/blogimages/learn-rust-with-ai-code-suggestions-advanced-programming/gitlab_cicd_pipeline_rust_cargo_run_output.png){: .shadow}\n\n## Wie geht es weiter?\nDieser Blogbeitrag war schwierig zu erstellen, da ich sowohl selbst fortgeschrittene Rust-Programmiertechniken erlernte als auch eine gute Lernkurve mit Codevorschlägen fand. Letzteres hilft bei der schnellen Generierung von Code, nicht nur von Textbausteinen. Nach dem Lesen dieses Blogbeitrags kennst du einige Herausforderungen und Turnarounds. Der Beispiel-Lösungscode für die Reader-App ist im Projekt [learn-rust-ai-app-reader](https://gitlab.com/gitlab-de/use-cases/ai/learn-with-ai/learn-rust-ai-app-reader) verfügbar.\n\nDas Parsen von RSS-Feeds ist herausfordernd, da es sich um Datenstrukturen mit externen HTTP-Anforderungen und parallelen Optimierungen handelt. Als erfahrene(r) Rust-Benutzer(in) hast du dich vielleicht gefragt: `Warum verwendet er nicht die Crate std::rss?` -- Sie ist für die erweiterte asynchrone Ausführung optimiert und erlaubt es nicht, die verschiedenen Rust-Funktionen, die in diesem Blogbeitrag erläutert werden, zu zeigen und zu erklären. Versuche als Übung den Code mit der [Crate `rss`](https://docs.rs/rss/latest/rss/) neu zu schreiben.\n\n### Asynchrone Lernübungen\nWas du in diesem Blogbeitrag gelernt hast, bildet die Grundlage für zukünftige Projekte mit persistenter Speicherung und Präsentation der Daten. Hier sind ein paar Ideen, mit denen du deine Kenntnisse von Rust vertiefen und die Reader-App optimieren kannst:\n\n1. Datenspeicherung: Verwende eine Datenbank wie sqlite und RSS-Feed-Update-Tracking.\n2. Benachrichtigungen: Spawne untergeordnete Prozesse, um Benachrichtigungen in Telegram usw. auszulösen.\n3. Funktionalität: Erweitere die Reader-Typen zu REST-APIs\n4. Konfiguration: Füge Unterstützung für Konfigurationsdateien für RSS-Feeds, APIs usw. hinzu.\n5. Effizienz: Füge Unterstützung für Filter und abonnierte Tags hinzu.\n6. Bereitstellungen: Verwende einen Webserver, sammle Prometheus-Metriken und stelle auf Kubernetes bereit.\n\nIn einem zukünftigen Blogbeitrag werden wir einige dieser Ideen besprechen und zeigen, wie wir sie umsetzen können. Tauche in vorhandene RSS-Feed-Implementierungen ein und erfahre, wie du den vorhandenen Code in Rust-Bibliotheken (`crates`) nutzen kannst.\n\n### Teile dein Feedback\nWenn du [GitLab Duo](/gitlab-duo/) Codevorschläge verwendest, [teile deine Meinung im Feedback-Ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/405152).\n",[9,986,686,987,685],"careers","workflow","2025-01-29",{"slug":990,"featured":6,"template":691},"learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions","content:de-de:blog:learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions.yml","Learn Advanced Rust Programming With A Little Help From Ai Code Suggestions","de-de/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions.yml","de-de/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions",{"_path":996,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":997,"content":1003,"config":1010,"_id":1012,"_type":14,"title":1013,"_source":16,"_file":1014,"_stem":1015,"_extension":19},"/de-de/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"ogTitle":998,"schema":999,"ogImage":1000,"ogDescription":1001,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":1002,"title":998,"canonicalUrls":1002,"description":1001},"GitLab Duo – die Zukunft der KI-gestützten Entwicklung","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Lerne GitLab Duo Workflow kennen – die Zukunft der KI-gestützten Entwicklung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2024-06-27\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658912/Blog/Hero%20Images/blog-image-template-1800x945__20_.png","Workflow, unser autonomer KI-Agent, wird die Art und Weise verändern mit der Teams Software entwickeln und ausliefern – unser erster kühner Schritt in Richtung KI-gestützte DevSecOps.","https://about.gitlab.com/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"title":1004,"description":1001,"authors":1005,"heroImage":1000,"date":1007,"body":1008,"category":683,"tags":1009},"Lerne GitLab Duo Workflow kennen – die Zukunft der KI-gestützten Entwicklung",[1006],"David DeSanto, Chief Product Officer, GitLab","2024-06-27","Stell dir vor, Software würde sich selbst schreiben. Das hört sich jetzt zunächst einmal nach Zukunftsmusik an, aber mit den kontinuierlichen Fortschritten bei LLMs und den Neuerungen, die GitLab in einer einzigen DevSecOps Plattform zusammen gefasst hat, rückt diese Zukunft in greifbare Nähe. Während unseres [GitLab 17 Launch-Event](https://about.gitlab.com/de-de/seventeen/) haben wir GitLab Duo Workflow angekündigt, einen autonomen KI-Agenten, der die Art und Weise verändern wird, wie Teams Software entwickeln, sichern, bereitstellen und überwachen.\n\nGitLab Duo Workflow geht über die derzeitigen reaktiven, prompt-basierten KI-Assistenten hinaus. Es ist ein autonomes Teammitglied, das aktiv dazu beiträgt, jeden Aspekt deines SDLC zu optimieren. Workflow zeichnet sich durch die Nutzung des einheitlichen Datenspeichers von GitLab aus, der alle relevanten Daten, Projekte, Repositories und Dokumentationen nahtlos miteinander verknüpft. Dadurch wird Workflow zu einem intelligenten, immer verfügbaren Agenten, der deine Projekte ständig überwacht, potenzielle Probleme in der Produktivumgebung vorhersieht, Sicherheitslücken automatisch identifiziert und behebt, deine Anwendungen für Spitzenleistungen optimiert und die Einarbeitung neuer Teammitglieder durch den schnellen Aufbau individueller Remote-Entwicklungsumgebungen vereinfacht.\n\nKI verändert wie sichere Software erstellt, gepflegt, aktualisiert, bereitgestellt und überwacht wird, und ermöglicht es Unternehmen, mehr Software als je zuvor zu entwickeln. GitLab Duo Workflow ist unser erster mutiger Schritt in Richtung KI-gestützter DevSecOps. Unser Ziel ist es, Entwickler(innen) dazu zu befähigen, sich auf Problemlösungen, Innovationen und Wertschöpfung auf höchster Ebene zu konzentrieren, während [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) repetitive Aufgaben und Optimierungen im Hintergrund erledigt.\n\n## Die Vision für GitLab Duo Workflow\nMit GitLab Duo Workflow arbeiten wir hochkonzentriert an mehreren wichtigen Anwendungsfällen, um den Prozess der Softwareentwicklung von Anfang bis Ende zu automatisieren und zu optimieren.\n### 1. Automatisierte Entwicklung\n\nDirekt in der IDE ermöglicht GitLab Duo Workflow die Planung und Priorisierung von Aufgaben, die auf einzelne Projekte und definierte Unternehmensprozesse zugeschnitten sind. Anhand der Anforderungen eines bestimmten Workitems (sei es ein Epic, ein Issue oder ein Task) erstellt Workflow einen Implementierungsplan, den die Entwickler(innen) überprüfen und individuell anpassen können. Dann arbeitet sich Workflow durch den Plan und generiert oder schreibt den Code um, um die definierten Anforderungen zu erreichen und zu erfüllen. Workflow bedient sich bei der Umsetzung eines [GitLab Remote Development Workspaces](https://about.gitlab.com/blog/quick-start-guide-for-gitlab-workspaces/), der es ermöglicht, Codeänderungen sicher zu bewerten, zu schreiben und zu testen. Das bedeutet auch, dass genau der Code produziert wird, der sowohl die Anforderungen erfüllt als auch alle Tests der CI-Pipeline, einschließlich Sicherheitsscans, besteht. Wenn die Pipeline fehlschlägt, kümmert sich Workflow automatisch um die Behebung der Probleme und stellt sicher, dass nur qualitativ hochwertiger Code, der den Standards deines Unternehmens entspricht, erstellt und für deine Projekte verwendet wird.\n\nSobald die Pipeline fertig ist, erstellt Workflow automatisch einen Merge Request mit den Codeänderungen und durchläuft die Approvalprozesse für Merge Requests, einschließlich der Kommunikation mit Code-Prüfer(inne)n oder -Verantwortlichen. Du kannst Workflow sogar damit beauftragen, deinen Code zu überprüfen und deine Merge Requests zu kommentieren, so wie es auch menschliche Code-Prüfer(innen) tun würden. Das Beste ist, dass Workflow diese Vorschläge sogar für dich umsetzt, wenn du das möchtest. Und das ist erst der Anfang.\n\n### 2. Intelligente kontinuierliche Verbesserung\nGitLab Duo Workflow analysiert deine Codebase in Echtzeit und schlägt dir architektonische Optimierungen für mehr Effizienz, Leistung und Kosteneinsparungen vor. Außerdem identifiziert es proaktiv Möglichkeiten für Code-Refactoring, um die Skalierbarkeit zu verbessern und technical debt zu beseitigen, indem es den Entwickler(inne)n Änderungen vorschlägt oder sie automatisch in einer Sandbox-Umgebung implementiert. Darüber hinaus verwaltet Workflow die Cloud-Ressourcen dynamisch, um eine Überbelegung zu verhindern und sicherzustellen, dass deine Anwendungen stets ihre Leistungsziele erreichen.\n\n### 3. Proaktive Sicherheit und Konformität\nSicherheit und Compliance Konformität sind für jedes Unternehmen von höchster Priorität. GitLab Duo Workflow fordert Entwickler(innen) automatisch und in Echtzeit auf, Patches anzuwenden, unsicheren Code zu überarbeiten und sich an neue Bedrohungen anzupassen. Es bewertet außerdem kontinuierlich die Sicherheitsrisiken deiner Anwendungen und Produktionsumgebungen und unterstützt dich bei der Implementierung von Maßnahmen zur Risikominderung.\n\n### 4. Selbstoptimierende Leistung\nGitLab Duo Workflow verfügt über ausgeklügelte Feedbackschleifen für kontinuierliches Lernen und Verbesserung. Durch die Analyse von Daten aus Überwachungstools, Benutzerinteraktionen und Geschäftsergebnissen wird die Sicht auf deine Codebase kontinuierlich verbessert, um sicherzustellen, dass deine Anwendungsarchitekturen immer auf deine Geschäftsanforderungen abgestimmt sind. Wie alle KI-Systeme wird sich auch Workflow ständig verbessern, indem es seine eigenen Fehler erkennt und korrigiert, während es lernt, ein Partner für dein Unternehmen zu sein.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://player.vimeo.com/video/967982166?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allowfullscreen=\"true\" title=\"GitLab Duo Workflow the future of AI-driven DevSecOps\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Die Zukunft der KI ist jetzt\nGitLab Duo Workflow ist ein großer Schritt nach vorn: weg von der KI, die ständig von Menschen gesteuert werden muss, hin zu einer KI, die eigenständig Entwicklungsworkflows und -prozesse vorantreibt und bei Bedarf menschliche Hilfe in Anspruch nimmt. Mit der einheitlichen, KI-gestützten Schnittstelle von GitLab, die den DevSecOps-Lebenszyklus abdeckt, können Unternehmen eine neue Generation von KI-gestützten Anwendungen mit beispielloser Geschwindigkeit, Effizienz und Innovation erstellen und dabei die höchsten Sicherheits- und Compliance-Standards einhalten. Ohne Kompromisse.\n\nBegleite uns, während wir die Grenzen dessen, was mit KI in der Softwareentwicklung möglich ist, immer weiter verschieben. Lasst uns gemeinsam die Zukunft der KI-gestützten DevSecOps angehen und das volle Potenzial eurer Teams und Unternehmen ausschöpfen.\n\n> Wenn du neugierig auf KI-gestützte DevSecOps bist und diese Entwicklung miterleben möchtest, [melde dich für unsere GitLab Duo Workflow-Warteliste an](https://forms.gle/5ppRuNVb8LwSPNVJA) und erhalte Zugang zum Pre-Release-Programm.",[685,687,9,839,987],{"slug":1011,"featured":91,"template":691},"meet-gitlab-duo-workflow-the-future-of-ai-driven-development","content:de-de:blog:meet-gitlab-duo-workflow-the-future-of-ai-driven-development.yml","Meet Gitlab Duo Workflow The Future Of Ai Driven Development","de-de/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development.yml","de-de/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"_path":1017,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1018,"content":1024,"config":1030,"_id":1032,"_type":14,"title":1033,"_source":16,"_file":1034,"_stem":1035,"_extension":19},"/de-de/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo",{"title":1019,"description":1020,"ogTitle":1019,"ogDescription":1020,"noIndex":6,"ogImage":1021,"ogUrl":1022,"ogSiteName":673,"ogType":674,"canonicalUrls":1022,"schema":1023},"Code mit KI-gestütztem GitLab Duo in moderne Sprachen refaktorisieren ","In diesem detaillierten Tutorial erfahren Entwickler(innen), wie sie Code mithilfe von KI modernisieren können, indem sie zu einer neuen Programmiersprache wechseln und mehr über neue Funktionen in dieser Sprache lernen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662465/Blog/Hero%20Images/GitLab_Duo_Workflow_Unified_Data_Store__1_.png","https://about.gitlab.com/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Code mit KI-gestütztem GitLab Duo in moderne Sprachen refaktorisieren \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-08-26\",\n      }\n                  ",{"title":1019,"description":1020,"authors":1025,"heroImage":1021,"date":1026,"body":1027,"category":683,"tags":1028,"updatedDate":1029},[680],"2024-08-26","Egal, ob es deine Aufgabe ist, die Codebase oder das Framework zu modernisieren, indem du zu einer neuen Programmiersprache wechselst, oder ob du mehr über neue Funktionen in dieser Sprache erfahren möchtest: das KI-gestützte [GitLab Duo](https://about.gitlab.com/gitlab-duo/) kann dir dabei helfen. Hier erfährst du anhand von Beispielen aus meiner 20-jährigen Berufserfahrung als Programmier(in), wie du Herausforderungen beim Code-Refactoring am besten meisterst.\n\nDie Prompts und Beispiele in diesem Artikel werden in verschiedenen IDEs gezeigt: VS Code und JetBrains (IntelliJ IDEA, PyCharm und CLion) mit den jeweiligen installierten (GitLab-Duo-Erweiterungen/Plugins]https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html). Die Entwicklungsumgebung nutzt GitLab.com, darunter Updates auf Anthropic Claude 3.5 als großes Sprachmodell (LLM) für [Codevorschläge](https://docs.gitlab.com/ee/user/gitlab_duo/#code-suggestions) und den [Chat](https://docs.gitlab.com/ee/user/gitlab_duo/#gitlab-duo-chat) von GitLab Duo. Spoiler: Sie sind noch leistungsstärker und effizienter.\n\nDu kannst zu den einzelnen Abschnitten dieses Artikels springen oder ihn von Anfang bis Ende lesen. Der Quellcode und die Herausforderungen mit den jeweiligen Übungen sind zum Selbststudium geeignet.\n\n- [Code in moderne Programmiersprachen-Standards refaktorieren](#refactor-code-to-modern-programming-language-standards)\n    - [Java 7 generieren und zu Java 8 refaktorisieren](#generate-java-7-and-refactor-to-java-8)\n    - [Über C++-Standards refaktorisieren](#refactor-across-c%2B%2B-standards)\n        - [Migration: C++03 zu C++14 refaktorisieren](#migration-refactor-c%2B%2B03-into-c%2B%2B14)\n        - [Downgrade: C++23 zu C++11 refaktorisieren](#downgrade-refactor-c%2B%2B23-to-c%2B%2B11)\n    - [COBOL erklären und refaktorisieren](#explain-and-refactor-cobol)\n- [Eine Sprache in eine andere refaktorisieren](#refactor-a-language-into-another-language)\n    - [C zu Rust refaktorisieren](#refactor-c-to-rust)\n    - [Perl zu Python refaktorisieren](#refactor-perl-to-python)\n- [Weitere Tipps zum Refaktorisieren](#more-refactoring-hands-on)\n    - [JavaScript refaktorisieren](#refactor-javascript)\n    - [Bash zu ZSH oder SH refaktorisieren](#refactor-bash-to-zsh-or-sh)\n    - [Weitere Anwendungsfälle und Tutorials](#more-use-cases-and-tutorials)\n- [Wichtige Erkenntnisse](#key-takeaways)\n\n## Code in moderne Programmiersprachen-Standards refaktorisieren\n\nIm nächsten Abschnitt erfährst du, wie du die sprachspezifischen Unterschiede einer Programmiersprache refaktorisierst, erklärst und verstehst. \n\n### Java 7 generieren und auf Java 8 refaktorisieren \n\nEin Kunde wollte wissen, ob GitLab Duo Java 7 unterstützt. Beim Testen von Codevorschlägen und Chat-Prompts, um spezifischen Code für Java 7 zu erstellen, dachte ich auch über Hilfe bei der Migration nach. Anthropic Claude 3.5 kann die sprachspezifischen Unterschiede verstehen, ebenso wie GitLab Duo.\n\nDas folgende Beispiel zeigt eine Aufforderung zum Generieren von Java-7-Code mit Codevorschlägen.\n\n```java\n// Generate a new class for a File Manager. Use Java 7 features only.\nimport java.io.*;\nimport java.nio.file.*;\nimport java.util.*;\n\npublic class FileManager {\n    private Path rootDirectory;\n\n    public FileManager(String rootPath) throws IOException {\n        this.rootDirectory = Paths.get(rootPath);\n        if (!Files.exists(rootDirectory)) {\n            Files.createDirectories(rootDirectory);\n        }\n    }\n\n    public void createFile(String fileName, String content) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        Files.write(filePath, content.getBytes(), StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING);\n    }\n\n    public String readFile(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        return new String(Files.readAllBytes(filePath));\n    }\n\n    public void deleteFile(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        Files.delete(filePath);\n    }\n\n    public List\u003CString> listFiles() throws IOException {\n        List\u003CString> fileList = new ArrayList\u003C>();\n        try (DirectoryStream\u003CPath> stream = Files.newDirectoryStream(rootDirectory)) {\n            for (Path file : stream) {\n                fileList.add(file.getFileName().toString());\n            }\n        }\n        return fileList;\n    }\n\n    public void copyFile(String sourceFileName, String destinationFileName) throws IOException {\n        Path sourcePath = rootDirectory.resolve(sourceFileName);\n        Path destinationPath = rootDirectory.resolve(destinationFileName);\n        Files.copy(sourcePath, destinationPath, StandardCopyOption.REPLACE_EXISTING);\n    }\n\n    public void moveFile(String sourceFileName, String destinationFileName) throws IOException {\n        Path sourcePath = rootDirectory.resolve(sourceFileName);\n        Path destinationPath = rootDirectory.resolve(destinationFileName);\n        Files.move(sourcePath, destinationPath, StandardCopyOption.REPLACE_EXISTING);\n    }\n\n    public long getFileSize(String fileName) throws IOException {\n        Path filePath = rootDirectory.resolve(fileName);\n        return Files.size(filePath);\n    }\n\n    public boolean fileExists(String fileName) {\n        Path filePath = rootDirectory.resolve(fileName);\n        return Files.exists(filePath);\n    }\n}\n```\n\nDu kannst mit folgenden Schritten in deinem IDE fortfahren:\n\n1. Lerne und verstehe den generierten Code: Wähle den Code im Editor aus (im Screenshot blau), wechsle zum GitLab-Duo-Chat und sende den Slash-Befehl `/explain` als Prompt.\n\n![Validiere den generierten Code mit dem Slash-Befehl `/explain` im GitLab-Duo-Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/intellij_java7_generate_refactor.png)\n\n2. Wandle den Java-7-Code in Java 8 um: Wähle den Code im Editor aus, wechsle zum Chat und sende `/refactor using Java 8 features` als detaillierteren Prompt.\n3. Übe eine Alternative zum Refactoring: Erstelle die neue Datei `java8.java` und generiere Java-8-spezifischen Code mit Codevorschlägen mit dem Prompt `// Generate a new class for a File Manager. Use Java 8 features only.`.\n4. Schreibe weiter Java-8-Code im gleichen Kontext mit KI-basierter Code-Vervollständigung.\n\nDu kannst dir alle Schritte in dieser Aufnahme ansehen.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/XKRv6uBkD2I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nDer Quellcode ist in der [GitLab-Duo-Challenge – Java 7 generieren und auf Java 8 refaktorisieren](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-generate-refactor-java-7-to-8) verfügbar.\n\n### Über C++-Standards refaktorisieren\n\nDer C++-Standard hat eine lange Geschichte und gilt als stabil und ausgereift. Je nach Zielarchitektur und Plattformen hängt der unterstützte Standard vom Compiler des Host-Betriebssystems ab.\n\nIn meiner Karriere musste ich bereits 25 verschiedene Linux- und Windows-Distributionen in Open-Source-Projekten supporten und habe unterschiedlichsten Compiler-Support für neuere Sprachfunktionen und C++-Standards erlebt. Im Jahr 2015 haben wir uns für C++11-Funktionen entschieden und später C++14 oder C++17 nie mehr angerührt. \n\nDie Refaktorisierung von Funktionen und Algorithmen zu einem neuen C++-Standard wäre zu aufwändig gewesen und es wäre Hilfe beim Erklären der Unterschiede nötig gewesen. Damals haben wir in Büchern, über Online-Suche, Stack Overflow und manchmal Tools Hilfe zum Refactoring gesucht.Mit KI-basierten Assistenten und GitLab Duo hat sich das alles geändert: Du kannst Codevorschläge und den Chat nutzen, um Quellcode in einem bestimmten C++-Standard bereitzustellen. Dann ist es auch möglich, die verschiedenen Ausgaben zu vergleichen. \n\nDas folgende Beispiel verwendet einen Prompt, um speziell Quellcode für den C++03-Standard zu generieren. Es implementiert einen einfachen Konfigurations-Parser für das Konfigurationsformat `.ini`.\n\n```c++\n/* Create a config parser which can parse an ini format\nUse C++03 standard only\n */\n\n#include \u003Ciostream>\n#include \u003Cfstream>\n#include \u003Cstring>\n#include \u003Cmap>\n#include \u003Csstream>\n\nclass ConfigParser {\nprivate:\n    std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> > config;\n\npublic:\n    ConfigParser() {}\n\n    bool parse(const std::string& filename) {\n        std::ifstream file(filename.c_str());\n        if (!file.is_open()) {\n            return false;\n        }\n\n        std::string line;\n        std::string currentSection;\n\n        while (std::getline(file, line)) {\n            // Trim whitespace\n            size_t first = line.find_first_not_of(\" \\t\");\n            size_t last = line.find_last_not_of(\" \\t\");\n            if (first == std::string::npos) continue; // Skip empty lines\n            line = line.substr(first, (last - first + 1));\n\n            if (line[0] == '[' && line[line.length() - 1] == ']') {\n                // This is a section\n                currentSection = line.substr(1, line.length() - 2);\n            } else {\n                // This is a key-value pair\n                size_t delimiterPos = line.find('=');\n                if (delimiterPos != std::string::npos) {\n                    std::string key = line.substr(0, delimiterPos);\n                    std::string value = line.substr(delimiterPos + 1);\n                    config[currentSection][key] = value;\n                }\n            }\n        }\n\n        file.close();\n        return true;\n    }\n\n    std::string getValue(const std::string& section, const std::string& key) const {\n        std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> >::const_iterator sectionIt = config.find(section);\n        if (sectionIt != config.end()) {\n            std::map\u003Cstd::string, std::string>::const_iterator keyIt = sectionIt->second.find(key);\n            if (keyIt != sectionIt->second.end()) {\n                return keyIt->second;\n            }\n        }\n        return \"\";\n    }\n\n    void printConfig() const {\n        std::map\u003Cstd::string, std::map\u003Cstd::string, std::string> >::const_iterator sectionIt;\n        for (sectionIt = config.begin(); sectionIt != config.end(); ++sectionIt) {\n            std::cout \u003C\u003C \"[\" \u003C\u003C sectionIt->first \u003C\u003C \"]\" \u003C\u003C std::endl;\n            std::map\u003Cstd::string, std::string>::const_iterator keyIt;\n            for (keyIt = sectionIt->second.begin(); keyIt != sectionIt->second.end(); ++keyIt) {\n                std::cout \u003C\u003C keyIt->first \u003C\u003C \" = \" \u003C\u003C keyIt->second \u003C\u003C std::endl;\n            }\n            std::cout \u003C\u003C std::endl;\n        }\n    }\n};\n\nint main() {\n    ConfigParser parser;\n    if (parser.parse(\"config.ini\")) {\n        std::cout \u003C\u003C \"Config file parsed successfully.\" \u003C\u003C std::endl;\n        parser.printConfig();\n\n        std::cout \u003C\u003C \"Value of 'key1' in 'section1': \" \u003C\u003C parser.getValue(\"section1\", \"key1\") \u003C\u003C std::endl;\n    } else {\n        std::cout \u003C\u003C \"Failed to parse config file.\" \u003C\u003C std::endl;\n    }\n    return 0;\n}\n```\n\nThe same prompts can be applied to [explaining code](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide), [generating tests](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#write-tests-in-the-ide), and even [refactoring code](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide): `/explain focus on C++03 features`, `/tests for C++03 features`, `/refactor into C++03`. \n\nDie folgenden C+ -Standards wurden für die Arbeit mit GitLab Duo Codevorschläge getestet:\n\n- C++03\n- C++11\n- C++14\n- C++17\n- C++20\n- C++23\n\nDen Quellcode findest du in der [Challenge –  Cpp-Standards Konfigurations-Parser refaktorisieren](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser). \n\nEs gibt viele verschiedene Kombinationen, um den Quellcode zwischen den C++-Standards zu refaktorisieren. Die folgenden Beispiele zeigen eine Modernisierung des C++-Codes mit Versionsupgrades, testen aber auch ein Downgrade, als ambitionierte Entwickler(innen) C++20 verwenden wollten, aber C++11 verwenden mussten, um den Umgebungen ihrer Geschäftskund(inn)en zu entsprechen.#### Migration: C++03 in C++14 refaktorisieren \n\nDas Ziel ist es, den Code zu modernisieren und die Veränderungen zwischen C++03 und C++14 zu verstehen. Öffne den [03.cpp](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser/-/blob/main/03.cpp?ref_type=heads)-Quellcode in der IDE, wähle ihn aus und gib den folgenden Chat-Prompt ein: \n\n```markdown\n/refactor into C++14 and explain the changes\n```\n\nPotentielle Antwort des Chats: \n\n```markdown\n…\n\nExplanations of the changes:\n\n1. Default constructor: Changed `ConfigParser() {}` to `ConfigParser() = default;` to use the default constructor.\n2. File opening: Removed `.c_str()` when opening the file, as C++11 and later support `std::string` directly.\n3. Lambda functions: Introduced a lambda function trim to handle string trimming, making the code more readable and reusable.\n4. Auto keyword: Used `auto` for type deduction in various places, improving code readability.\n5. Range-based for loops: In the `printConfig` method, replaced traditional for loops with range-based for loops, which are more concise and less error-prone.\n6. Structured bindings: Used structured bindings in the range-based for loops to directly access key-value pairs.\n7. If statements with initializers: In the `getValue` method, used if statements with initializers to combine the find operation and the check in a single line.\n8. String member functions: Used `front()` and `back()` instead of array-style access for the first and last characters of strings.\n9. Uniform initialization: Used uniform initialization `{}` instead of parentheses `()` for object creation.\n10. Removed `std::endl`: Replaced `std::endl` with `'\\n'` for better performance, as `std::endl` forces a flush of the output buffer.\n\nThese changes make the code more modern, concise, and potentially more efficient while maintaining the same functionality.\n\n```\n\n![Änderungen im Code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp03_to_14_01.png)\n\n![Änderungen im Code 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675060/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp03_to_14_02.png)\n\n#### Downgrade: C++23 zu C++11 refaktorisieren\n\nManchmal starten Entwickler(innen) einen neuen Proof of Concept in einem modernen C++-Standard wie C++20. Die aktuell unterstützten Versionen für Geschäftskundenumgebungen erfordern ältere Compiler mit C++11-Unterstützung. Ein Downgrade der Versionen ist mit Kosten verbunden und erfordert eine Bewertung, welche Sprachfunktionen noch unterstützt werden und welche anderen Nachteile auftreten könnten.\n\nÖffne den [23.cpp](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-cpp-standards-config-parser/-/blob/main/23.cpp?ref_type=heads)-Quellcode in der IDE, wähle ihn aus und gib den folgenden Chat-Prompt ein: \n\n```markdown\n/refactor into C++11, explain the necessary changes and potential problems\n```\n\nPotenzielle Antwort des Duo Chat: \n\n```markdown\nThe main changes required to make this code compatible with C++11 are:\n\n1. Remove the C++23 standard comment, as it's no longer applicable.\n2. Replace `std::string::find_first_not_of` and `std::string::find_last_not_of` with C++11 compatible alternatives in the trim function.\n3. Use `const auto&` instead of `auto` for loop variables to avoid unnecessary copying.\n\nPotential problems in the original code:\n\n1. The original code used C++23 features, which might not be widely supported yet.\n2. The `trim` function used `std::string::find_first_not_of` and `std::string::find_last_not_of`, which are not available in C++11.\n3. The use of `auto` instead of `const auto&` in some loops could lead to unnecessary copying of complex objects.\n\nThese issues have been addressed in the refactored version. The `trim` function now uses `std::find_if_not` with lambda functions to achieve the same result in a C++11 compatible way. The use of `const auto&` ensures that no unnecessary copying occurs when iterating over the config map.\n```\n\n![The `trim` function now uses `std::find_if_not` with lambda functions to achieve the same result in a C++11 compatible way](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp23_to_11_01.png)\n\n![The use of `const auto&` ensures that no unnecessary copying occurs when iterating over the config map](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/duo_refactor_cpp_clion_chat_cpp23_to_11_02.png)\n\n**Asynchronisierungsübung**: Teste weitere Refactoring-Szenarios.\n\n### COBOL erklären und umgestalten\n\nDu kannst GitLab Duo verwenden, um den Quellcode zu erklären, zu analysieren, zu reparieren und für COBOL-Programme zu refaktorisieren. Ich habe COBOL nie geschrieben oder gelernt und fand diesen [COBOL-Programmierkurs](https://github.com/openmainframeproject/cobol-programming-course) mit vielen Beispielen hilfreich.\n\nIch habe dann den Chat gefragt, wie man mit COBOL beginnt, ein COBOL-Programm erstellt und ein COBOL-Programm auf macOS kompiliert.\n\n```markdown\nPlease explain what COBOL is and its syntax\n\nPlease create a COBOL program that shows the first steps\n\nTell me more about the COBOL compiler. Which system do I need? Can I do it on my macOS?\n\n```\n\n![Bitte an GitLab Duo Chat, die Sprache und ihre Syntax zu erklären](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/vscode_chat_cobol_generate_example.png)\n\nÖffne ein COBOL-Programm, wähle den Quellcode aus, gehe zum Duo Chat und sende den Prompt `/explain`, um Zweck und Funktion des Codes zu erklären. \n\nDu kannst die Prompts auch verfeinern, um allgemeinere Zusammenfassungen zu erhalten, zum Beispiel:\n\n```markdown\n/explain like I am five\n```\n\n> Tipp: Programmiersprachen haben ähnliche Algorithmen und Funktionen. Für COBOL bot der Chat an, es mit Python zu erklären. Deshalb habe ich die folgenden Prompts angepasst, um in Python nach einer Erklärung zu fragen.\n\n```markdown\n/explain in a different programming language\n```\n\nDu kannst auch den Slash-Befehl `/refactor` im Chat verwenden, um die Codequalität zu verbessern, potenzielle Probleme zu beheben und zu versuchen, COBOL in Python zu refaktorisieren.\n\n```markdown\n/refactor fix the environment error\n\n/refactor fix potential problems\n\n/refactor into Python\n```\n\nDie Aufzeichnung [GitLab Duo Coffee Chat – Herausforderung: COBOL-Programme erklären und refaktorisieren](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-explain-refactor-cobol-program) zeigt die Schritte, die ich oben erklärt habe, anhand eines praktischen Beispiels. Hier siehst du auch, wie man einen fehlenden Punkt finden kann: \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/pwlDmLQMMPo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Eine Sprache in eine andere Sprache refaktorisieren\n\nModernisierung und Verbesserungen der Codequalität erfordern manchmal den Wechsel einer Programmiersprache. Ähnliche Refactoring-Prompts mit GitLab Duo können den Migrationsprozess beschleunigen. Das COBOL-Beispiel mit Python ist nur eine von vielen Anforderungen in Unternehmensumgebungen. Sehen wir uns nun weitere Anwendungsfälle an.\n\n### C in Rust refaktorisieren\n\nAnfang 2024 wurden mehrere Programmiersprachen, darunter C, als nicht speichersicher bezeichnet. Die Empfehlungen für zukünftige Projekte umfassen [speichersichere Sprachen](https://about.gitlab.com/blog/memory-safe-vs-unsafe/) wie Rust. Aber wie startet man eine Migration und welche Herausforderungen gibt es dabei?\n\nVersuchen wir es mit einem einfachen Beispiel in C. Der Code wurde mithilfe von Codevorschlägen generiert und sollte die grundlegenden Betriebssysteminformationen wie Name, Version und Plattform ausdrucken. Der C-Code kompiliert plattformübergreifend unter Windows, Linux und macOS.\n\n```c\n// Read OS files to identify the platform, name, versions\n// Print them on the terminal\n#include \u003Cstdio.h>\n#include \u003Cstdlib.h>\n#include \u003Cstring.h>\n\n#ifdef _WIN32\n    #include \u003Cwindows.h>\n#elif __APPLE__\n    #include \u003Csys/utsname.h>\n#else\n    #include \u003Csys/utsname.h>\n#endif\n\nvoid get_os_info() {\n    #ifdef _WIN32\n        OSVERSIONINFOEX info;\n        ZeroMemory(&info, sizeof(OSVERSIONINFOEX));\n        info.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);\n        GetVersionEx((OSVERSIONINFO*)&info);\n\n        printf(\"Platform: Windows\\n\");\n        printf(\"Version: %d.%d\\n\", info.dwMajorVersion, info.dwMinorVersion);\n        printf(\"Build: %d\\n\", info.dwBuildNumber);\n    #elif __APPLE__\n        struct utsname sys_info;\n        uname(&sys_info);\n\n        printf(\"Platform: macOS\\n\");\n        printf(\"Name: %s\\n\", sys_info.sysname);\n        printf(\"Version: %s\\n\", sys_info.release);\n    #else\n        struct utsname sys_info;\n        uname(&sys_info);\n\n        printf(\"Platform: %s\\n\", sys_info.sysname);\n        printf(\"Name: %s\\n\", sys_info.nodename);\n        printf(\"Version: %s\\n\", sys_info.release);\n    #endif\n}\n\nint main() {\n    get_os_info();\n    return 0;\n}\n```\n\nÖffne den Quellcode in [`os.c`](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-c-to-rust/-/blob/897bf57a14bb7be07d842e7f044f93a61456d611/c/os.c), beispielsweise in JetBrains CLion. Wähle den Quellcode aus und gib den Chat-Prompt `/explain` ein, um Zweck und Funktion erklären zu lassen. Gib als Nächstes `/refactor` in den Chat ein, um den C-Code zu refaktorisieren, und gehe dann einen Schritt weiter: `/refactor into Rust`. \n\nInitialisiere ein neues Rust-Projekt (Tipp: Frage den Duo Chat) und kopiere den generierten Quellcode in die Datei `src/main.rs`. Führe `cargo build` aus, um den Code zu kompilieren.\n\n![Initialisiere ein neues Rust-Projekt und kopiere den generierten Quellcode in die Datei `src/main.rs`. Führe `cargo build` aus, um den Code zu kompilieren.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/jetbrains_clion_c_rust.png)\n\nIn der Aufzeichnung von [GitLab Duo Coffee Chat: Herausforderung – C zu Rust refaktorisieren](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-c-to-rust) lernst du alle Schritte kennen und siehst außerdem einen Kompilierungsfehler, der mithilfe des Chats und des Slash-Vefehls `/refactor` behoben wird. Die Aufzeichnung zeigt auch, wie man die Wartbarkeit des neuen Rust-Codes verbessern kann, indem man mehr Fehlerbehandlung hinzufügt. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/nf8g2ucqvkI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Perl zu Python refaktorisieren \n\nDieses eine Skript, das auf Produktionsservern läuft, seinen Job macht und dessen Autor(in) schon seit zehn Jahren nicht mehr im Unternehmen arbeitet – und das niemand anfassen will. Dieses Problem kann es auch für mehrere Skripte oder sogar für eine ganze Anwendung geben. Dann wird beschlossen, alles auf das moderne Python 3 zu migrieren, mit dem Ziel, den Code zu modernisieren und die Veränderungen zwischen Perl und Python zu verstehen.\n\nEin(e) Kund(in) hat kürzlich in einem GitLab-Duo-Workshop gefragt, ob eine direkte Migration mit GitLab Duo möglich ist. Die kurze Antwort: Ja, das ist es. Die längere Antwort: Du kannst mithilfe verfeinerter Chat-Prompts Perl-Code in Python refaktorisieren, ähnlich wie bei anderen Beispielen in diesem Artikel.\n\nÖffne den Quellcode `script.pl` in der IDE, wähle ihn aus und öffne den Chat.\n\n```perl\n#!/usr/bin/perl\nuse strict;\nuse warnings;\n\nopen my $md_fh, '\u003C', 'file.md' or die \"Could not open file.md: $!\";\n\nmy $l = 0;\nmy $e = 0;\nmy $h = 0;\n\nwhile (my $line = \u003C$md_fh>) {\n  $l++;\n  if ($line =~ /^\\s*$/) {\n    $e++;\n    next;\n  }\n  if ($line =~ /^#+\\s*(.+)/) {\n    print \"$1\\n\";\n    $h++; \n  }\n}\n\nprint \"\\nS:\\n\"; \nprint \"L: $l\\n\";\nprint \"E: $e\\n\"; \nprint \"H: $h\\n\";\n```\n\nYou can use the following prompts to:\n\n1. `/explain` its purpose, and `/refactor` to improve the code.\n2. `/refactor into Python`, um ein funktionierendes Python-Skript zu erhalten.\n\n![Refaktorisierung in Python](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/pycharm_duo_refactor_perl_python.png)\n\n> Tipp: Du kannst Perl-Code in mehrere Zielsprachen refaktorisieren. Die Aufzeichnung von [GitLab Duo Coffee Chat: Herausforderung – Perl zu Python refaktorisieren](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-perl-python) zeigt Refaktorisierungen zu PHP, Ruby, Rust, Go, Java, VB.NET, C# und mehr.\n> \n> Wenn du Perl-Skripts weiterhin verwenden möchtest, kannst du [Perl als zusätzliche Sprache](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/supported_extensions.html#add-support-for-more-languages) in Duo Codevorschläge konfigurieren. Der Chat versteht bereits Perl und kann bei Fragen und Slash-Befehlen helfen, wie du in der folgenden Aufnahme sehen kannst.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/03HGhxXg9lw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Weitere Tipps zum Refaktorisieren \n\n### JavaScript refaktorisieren \n\nEddie Jaoude zeigt in einem praktischen Beispiel, wie er JavaScript refaktorisiert, um die Codequalität zu verbessern oder Funktionen hinzuzufügen. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mHn8KOzpPNY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Bash zu ZSH oder SH refaktorisieren\n\nIch benutze Bash seit 20 Jahren als Shell und bin zuletzt auf macOS auf ZSH umgestiegen. Dies führte dazu, dass das Skript nicht funktionierte oder unbekannte Fehler in meinem Terminal auftraten. Ein weiterer Anwendungsfall für das Refactoring sind Shell-Einschränkungen – einige Betriebssysteme oder Linux-/Unix-Distributionen bieten kein Bash, sondern nur SH, z. B. Alpine.\n\n![Shell-Skripte refaktorisieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675059/Blog/Content%20Images/intellj_refactor_shell_scripts.png)\n\nDer [GitLab Duo Coffee Chat: Herausforderung – Shell-Skripte refaktorisieren](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-challenges/code-challenges/challenge-refactor-shell-scripts) zeigt ein Beispiel mit einem C-Programm, das Syslog-Dateien bearbeiten kann, und einem in Bash geschriebenen Build-Skript. Während der gesamten Challenge wird der Chat mit den Prompts `/explain` und `/refactor` abgefragt, um den Code zu verbessern. Es ist auch möglich, Bash in POSIX-konformes SH oder ZSH zu refaktorisieren. Die Sitzung endet mit der Bitte an den Chat, fünf verschiedene Shell-Skriptimplementierungen bereitzustellen und die wichtigsten Zusammenfassungen zu erläutern. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/mssqYjlKGzU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Weitere Anwendungsfälle und Tutorials\n\n- [Dokumentation: GitLab-Duo-Anwendungsfälle](https://docs.gitlab.com/ee/user/gitlab_duo/use_cases.html)\n- [Tutorial: Top-Tipps für effiziente KI-basierte Codevorschläge mit GitLab Duo](https://about.gitlab.com/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo/)\n- [Tutorial: 10 Best Practices für den Einsatz des KI-basierten GitLab Duo Chat](https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat/)\n\n## Wichtigste Erkenntnisse \n\n1. GitLab Duo bietet effiziente Hilfe beim Erklären und Refaktorisieren von Code. \n1. Du kannst Code zwischen den Sprachstandards refaktorisieren und im Chat weitere Fragen stellen.\n1. Prompts für Codevorschläge können bestimmte Sprachstandards generieren, und die Code-Vervollständigung geht auf den aktuellen Codekontext ein. \n1. Das Refaktorisieren von Code in neue Programmiersprachen hilft bei längerfristigen Migrations- und Modernisierungsvorhaben.\n1. Code kann auf die unterstützten Sprachstandards älterer Systeme „herabgestuft“ werden.\n1. GitLab Duo kann komplexe Code- und Programmiersprachen mit Beispielen in verschiedenen Programmiersprachen erklären.\n1. Das Update auf Anthropic Claude 3.5 auf GitLab.com hat die Qualität und Geschwindigkeit der Codevorschläge und des Chats noch einmal verbessert (Self-Managed-Upgrade auf 17.3 empfohlen).\n1. Es gibt keine Grenzen, außer deiner Vorstellungskraft und deinen Produktionsschwierigkeiten.\n\nErfahre mehr über effiziente Codevorschläge und Chat-Workflows und beginne jetzt deine KI-basierte Code-Refactoring-Reise mit GitLab Duo!\n\n> [Starte deine kostenlose Testversion von GitLab Duo!](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro_)\n",[685,686,9],"2024-11-13",{"slug":1031,"featured":6,"template":691},"refactor-code-into-modern-languages-with-ai-powered-gitlab-duo","content:de-de:blog:refactor-code-into-modern-languages-with-ai-powered-gitlab-duo.yml","Refactor Code Into Modern Languages With Ai Powered Gitlab Duo","de-de/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo.yml","de-de/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo",{"_path":1037,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1038,"content":1044,"config":1054,"_id":1056,"_type":14,"title":1057,"_source":16,"_file":1058,"_stem":1059,"_extension":19},"/de-de/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"ogTitle":1039,"schema":1040,"ogImage":1041,"ogDescription":1042,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":1043,"title":1039,"canonicalUrls":1043,"description":1042},"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      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","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":1041,"body":1045,"authors":1046,"updatedDate":794,"date":1048,"title":1049,"tags":1050,"description":1052,"category":1053},"[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",[1047],"Maximilien Belinga","2024-10-10","Von Jira zu GitLab wechseln: Der komplette Migrationsleitfaden 2025",[1051,109,9,688,751],"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":1055,"featured":91,"template":691},"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":1061,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1062,"content":1068,"config":1076,"_id":1078,"_type":14,"title":1079,"_source":16,"_file":1080,"_stem":1081,"_extension":19},"/de-de/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":1063,"description":1064,"ogTitle":1063,"ogDescription":1064,"noIndex":6,"ogImage":1065,"ogUrl":1066,"ogSiteName":673,"ogType":674,"canonicalUrls":1066,"schema":1067},"Strukturierung der GitLab-Paket-Registry für Unternehmen","Wie du projektbasierte Modelle zur Veröffentlichung von Softwarepaketen von GitLab mit Nutzung auf Root-Gruppen-Ebene kombinierst, um eine Strategie für Paketverwaltung aufzubauen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662332/Blog/Hero%20Images/blog-image-template-1800x945__23_.png","https://about.gitlab.com/blog/structuring-the-gitlab-package-registry-for-enterprise-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Strukturierung der GitLab-Paket-Registry für Unternehmen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":1063,"description":1064,"authors":1069,"heroImage":1065,"date":1071,"body":1072,"category":751,"tags":1073,"updatedDate":1075},[1070],"Tim Rizzi","2025-02-19","Je größer Unternehmen werden, desto komplexer wird es, interne Pakete zu verwalten. Während herkömmliche Paketmanager wie JFrog Artifactory und Sonatype Nexus ein zentralisiertes Repository nutzen, geht [GitLab](https://about.gitlab.com/de-de/) einen anderen Weg, der der Arbeitsweise moderner Entwicklungsteams besser entspricht. In diesem Beitrag erfährst du, wie du deine GitLab-Paket-Registry auf Unternehmensniveau effektiv strukturierst. Dabie ziehen wir Maven- und npm-Pakete als Beispiele heran.\n\n## Das Modell der GitLab-Paket-Registry verstehen\n\nWenn du bisher einen herkömmlichen Paketmanager verwendet hast, mutet der Ansatz von GitLab vielleicht erst einmal ungewohnt an. Anstatt eines einzigen, zentralisierten Repositorys integriert GitLab die Paketverwaltung direkt in deine bestehende Projekt- und Gruppenstruktur. Das bedeutet Folgendes:\n\n- Teams veröffentlichen Pakete in bestimmten Projekten, in denen sich der Code befindet\n- Teams verwenden Pakete von Root-Gruppen-Registries, die alle untergeordneten Pakete aggregieren\n- Die Zugriffskontrolle wird durch deine bestehenden GitLab-Berechtigungen festgelegt\n\nDieses Modell bietet mehrere Vorteile:\n\n- Klare Inhaberschaft von Paketen neben deren Quellcode\n- Granulare Zugriffskontrolle ohne zusätzliche Konfiguration\n- Vereinfachte CI/CD-Integration\n- Natürliche Anpassung an die Teamstrukturen\n- Eine einzige URL für alle Pakete des Unternehmens durch Root-Gruppen-Nutzung\n\n### Die Vorteile der Paket-Registry auf Root-Gruppen-Ebene\n\nGitLab unterstützt zwar die Paketnutzung auf verschiedenen Gruppenebenen, aber die Root-Gruppen-Ebene hat sich bei unseren Benutzer(inne)n als bewährte Vorgehensweise etabliert. Das liegt an folgenden Gründen:\n\n- **Einziger Zugriffspunkt:** Eine URL bietet Zugriff auf alle privaten Pakete im gesamten Unternehmen\n- **Konsistente Benennung von Paketen:** Mit Endpunkten auf Gruppenebene können Teams ihre bevorzugten Benennungskonventionen ohne Konflikte weiter nutzen\n- **Vereinfachte Konfiguration:** Alle Entwickler(innen) können dieselbe Konfiguration nutzen, um auf Pakete zuzugreifen\n- **Sicheres Zugriffsmanagement:** Kombiniert mit Bereitstellungstokens für einfache Rotation und Zugriffskontrolle\n- **Hierarchische Organisation**: Bildet deine Unternehmensstrukturen natürlich ab und bietet gleichzeitig vereinheitlichten Zugriff\n\n## Praxisbeispiel: Unternehmensstruktur\n\nSehen wir uns am Beispiel eines größeren Unternehmens an, wie das Ganze in der Praxis aussehen kann:\n\n```\ncompany/ (root group)\n├── retail-division/\n│   ├── shared-libraries/     # Division-specific shared code\n│   └── teams/\n│       ├── checkout/        # Team publishes packages here\n│       └── inventory/       # Team publishes packages here\n├── banking-division/\n│   ├── shared-libraries/    # Division-specific shared code\n│   └── teams/\n│       ├── payments/       # Team publishes packages here\n│       └── fraud/         # Team publishes packages here\n└── shared-platform/        # Enterprise-wide shared code\n    ├── java-commons/      # Shared Java libraries\n    └── ui-components/     # Shared UI components\n```\n\n### Veröffentlichungskonfiguration\n\nTeams veröffentlichen Pakete in ihre jeweiligen Projekt-Registries und behalten dabei eine klare Inhaberschaft bei:\n\n1. Beispiel: Maven\n\n```xml\n\u003C!-- checkout/pom.xml -->\n\u003CdistributionManagement>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/distributionManagement>\n```\n\n2. Beispiel: npm\n\n```json\n// ui-components/package.json\n{\n  \"name\": \"@company/ui-components\",\n  \"publishConfig\": {\n    \"registry\": \"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/npm/\"\n  }\n}\n```\n\n### Nutzungskonfiguration\n\nHier zeigt sich wirklich, wie vorteilhaft die Nutzung in der Root-Gruppe ist. Alle Teams konfigurieren einen einzigen Endpunkt für den Paketzugriff:\n\n1. Beispiel: Maven\n\n```xml\n\u003C!-- Any project's pom.xml -->\n\u003Crepositories>\n    \u003Crepository>\n        \u003Cid>gitlab-maven\u003C/id>\n        \u003Curl>https://gitlab.example.com/api/v4/groups/company/-/packages/maven\u003C/url>\n    \u003C/repository>\n\u003C/repositories>\n```\n\n2. Beispiel: npm\n\n```\n# Any project's .npmrc\n@company:registry=https://gitlab.example.com/api/v4/groups/company/-/packages/npm/\n```\n\nDiese Konfiguration bietet automatisch Zugriff auf alle Pakete in deine Unternehmen und gleichzeitig alle Vorteile der projektbasierten Veröffentlichung.\n\n## Authentifizierung und Zugriffskontrolle\n\nDas Modell von GitLab vereinfacht die Authentifizierung durch Bereitstellungstoken und CI/CD-Integration.\n\n### Für CI/CD-Pipelines\n\nGitLab übernimmt automatisch die Authentifizierung mit `CI_JOB_TOKEN`:\n\n```yaml\n# .gitlab-ci.yml\npublish:\n  script:\n    - mvn deploy  # or npm publish\n  # CI_JOB_TOKEN provides automatic authentication\n```\n\n### Für die Entwicklung\n\nNutze Gruppen-Bereitstellungstoken für die Paketnutzung:\n\n- Erstelle auf Root-Gruppen-Ebene Bereitstellungstoken mit Lesezugriff\n- Rotiere Tokens aus Sicherheitsgründen in regelmäßigen Abständen\n- Teile eine einzige Konfiguration für alle Entwickler(innen)\n\n## Vorteile eines Root-Gruppen-Paket-Registrys:\n\n1. Vereinfachte Konfiguration\n   - Eine URL für den gesamten Paketzugriff\n   - Konsistente Einrichtung für alle Teams\n   - Einfache Rotation von Tokens\n2. Klare Inhaberschaft\n   - Pakete bleiben bei ihrem Quellcode\n   - Teams haben Kontrolle über die Veröffentlichung\n   - Der Versionsverlauf korreliert mit der Projektaktivität\n3. Natürliche Organisation\n   - Entspricht deiner Unternehmensstruktur\n   - Fördert die Autonomie der Teams\n   - Ermöglicht teamübergreifende Zusammenarbeit\n\n## Erste Schritte\n\n1. Richte deine Root-Gruppe ein\n   - Erstelle eine klare Gruppenstruktur\n   - Konfiguriere die entsprechenden Zugriffskontrollen\n   - Erstelle Gruppen-Bereitstellungstoken\n2. Konfiguriere Teamprojekte\n   - Richte die Veröffentlichung auf Projektebene ein\n   - Implementiere CI/CD-Pipelines\n   - Dokumentiere die Benennungskonventionen für Pakete\n3. Standardisiere die Nutzung\n   - Konfiguriere den Registry-Zugriff für die Root-Gruppe\n   - Teile Bereitstellungstoken auf sichere Art und Weise\n   - Dokumentiere den Entdeckungsprozess der Pakete\n\n## Zusammenfassung\n\nDas Paket-Registry-Modell von GitLab ist – insbesondere dann, wenn es auf Root-Gruppen-Ebene genutzt wird – eine leistungsstarke Lösung für die Paketverwaltung im Unternehmen. Durch die Kombination aus projektbasierter Veröffentlichung mit Nutzung auf Root-Gruppen-Ebene erhalten Unternehmen das Beste aus beiden Welten: klare Inhaberschaft und vereinfachten Zugriff. Dieser Ansatz lässt sich natürlich mit deinem Unternehmen skalieren, ohne dass Sicherheit und Benutzerfreundlichkeit vernachlässigt werden.\n\nDu kannst dieses Modell zunächst in einzelnen Teams oder Abteilungen einführen und dann ausweiten, wenn dich die Vorteile dieses integrierten Ansatzes überzeugt haben. Auch wenn wir uns in diesem Beitrag auf Maven und npm konzentriert haben, gelten dieselben Prinzipien für alle Pakettypen, die von GitLab unterstützt werden.\n\n> Lege jetzt mit Paket-Registries los! Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) an.\n",[9,686,1074],"solutions architecture","2025-05-13",{"slug":1077,"featured":91,"template":691},"structuring-the-gitlab-package-registry-for-enterprise-scale","content:de-de:blog:structuring-the-gitlab-package-registry-for-enterprise-scale.yml","Structuring The Gitlab Package Registry For Enterprise Scale","de-de/blog/structuring-the-gitlab-package-registry-for-enterprise-scale.yml","de-de/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"_path":1083,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1084,"content":1090,"config":1100,"_id":1102,"_type":14,"title":1103,"_source":16,"_file":1104,"_stem":1105,"_extension":19},"/de-de/blog/the-ultimate-guide-to-sboms",{"ogTitle":1085,"schema":1086,"ogImage":1087,"ogDescription":1088,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":1089,"title":1085,"canonicalUrls":1089,"description":1088},"Der ultimative Leitfaden zu SBOM","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der ultimative Leitfaden zu SBOM\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2022-10-25\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664571/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","Unser Leitfaden erklärt die Software Bill of Materials (SBOM) einfach und praxisnah. ✓ Definition ✓ Bedeutung ✓ Arten ✓ Vorteile ✓ GitLab-SBOM ➤ Lesen!","https://about.gitlab.com/blog/the-ultimate-guide-to-sboms",{"heroImage":1087,"body":1091,"authors":1092,"updatedDate":1094,"date":1095,"title":1085,"tags":1096,"description":1099,"category":773},"In der heutigen digitalen Landschaft ist der Fokus auf Anwendungssicherheit innerhalb der Softwarebereitstellungskette kritischer denn je. Die Integration von Abhängigkeiten in Software erfordert Transparenz und Sicherheitsmaßnahmen, die oft komplex in der Implementierung und Verwaltung sind. Hier wird eine Software Bill of Materials (SBOM) unverzichtbar.\n\nUnser Leitfaden taucht tief in die Welt der SBOMs ein, beleuchtet ihre zentrale Rolle in einer multifunktionalen [DevSecOps-Strategie](https://about.gitlab.com/de-de/topics/devsecops/) und zeigt auf, wie du die SBOM-Gesundheit deiner Anwendung verbessern kannst – mit dem Ziel, die Cybersecurity deines Unternehmens zu stärken.\n\n## Inhalt - Der ultimative Guide zu SBOMs\n\n- [Was ist eine SBOM?](#was-ist-eine-software-bill-of-materials%3F)\n- [Warum sind SBOMs wichtig?](#warum-sind-sboms-wichtig%3F)\n- [Arten von SBOM-Datenaustauschstandards](#arten-von-sbom-datenaustauschstandards)\n- [Vorteile der Kombination von SBOMs und Software-Vulnerability-Management](#vorteile-der-kombination-von-sboms-und-software-vulnerability-management)\n- [Dynamische GitLab SBOMs](#dynamische-gitlab-sboms)\n- [SBOM-Generierung und -Verwaltung skalieren](#sbom-generierung-und-sbom-verwaltung-skalieren)\n- [SBOMs einlesen und zusammenführen](#sboms-einlesen-und-zusammenführen)\n- [Schwachstellen schneller beheben](#schwachstellen-schneller-beheben)\n- [Kontinuierliche SBOM-Analyse](#kontinuierliche-sbom-analyse)\n- [Vertrauen in SBOMs aufbauen](#vertrauen-in-sboms-aufbauen)\n- [Die Zukunft der SBOM-Funktionalität von GitLab](#die-zukunft-der-sbom-funktionalität-von-gitlab)\n- [Erste Schritte mit SBOMs](#erste-schritte-mit-sboms)\n- [SBOM-FAQ](#sbom-faq)\n\n## Was ist eine Software Bill of Materials?\n\nEine SBOM dient als umfassende [Liste der Komponenten](https://www.cisa.gov/sbom#), die Software ausmachen. Sie beleuchtet das Netzwerk von Bibliotheken, Tools und Prozessen, die im gesamten Entwicklungslebenszyklus verwendet werden. In Kombination mit Tools zum Management von Sicherheitslücken offenbart eine SBOM nicht nur genau diese potenziellen Sicherheitslücken in Softwareprodukten, sondern ebnet auch den Weg für strategische Risikominderung. \n\nEine SBOM ist ein verschachteltes Inventar oder eine Liste von Punkten, die Softwarekomponenten ausmachen. Zusätzlich zu den Komponenten selbst enthalten SBOMs wichtige Informationen über die Bibliotheken, Tools und Prozesse, die zur Entwicklung, zum Aufbau und zur Bereitstellung eines Software-Artefakts verwendet werden.\n\nDas Konzept des SBOM existiert seit mehr als einem Jahrzehnt. Im Rahmen der Bemühungen, die im Jahr 2023 veröffentlichte Nationale Cyber-Strategie umzusetzen, hilft CISA Secure by Design-Softwareherstellern, Sicherheitsprinzipien zu übernehmen und Cybersicherheit in ihre Produkte zu integrieren. Die [deutsche Regierung](https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/TR-03183-2-SBOM-Anforderungen.html) hat bewährte Verfahren herausgegeben, die Softwareentwickler(innen) im öffentlichen Sektor dazu bewegen, SBOMs in ihre Softwarepakete aufzunehmen. Auch auf dem privaten Sektor sindSBOMs immer mehr auf dem Vormarsch.\n\nObwohl SBOMs oft mit eigenständiger Software erstellt werden, integrieren Plattformen wie GitLab die SBOM-Generierung schon früh in den DevSecOps-Workflow.\n\n![supply chain security sdlc](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/supply_chain_security_sdlc.png)\n\n## Warum sind SBOMs wichtig?\n\nModerne Softwareentwicklung ist darauf fokussiert, Anwendungen schneller und effizienter zu liefern. Das führt oft dazu, dass Entwickler(innen) Code aus Open-Source-Repositories oder proprietären Paketen in ihre Anwendungen einbauen. Laut dem [Open Source Security and Risk Analysis-Bericht 2024 von Synopsys](https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2024.pdf), der über 1.000 kommerzielle Codebasen aus 17 Branchen im Jahr 2023 untersuchte, enthielten 96 % der gesamten Codebasen Open Source und 84 % der bewerteten Codebasen zeigten deutlicheSicherheitslücken.\n\nDie Einbindung von Code aus unbekannten Repositories erhöht das Risiko von Schwachstellen, die von Hackern ausgenutzt werden können. Tatsächlich wurde der [Angriff auf SolarWinds im Jahr 2020](https://www.spektrum.de/news/solarwinds-ein-hackerangriff-der-um-die-welt-geht/1819187) durch die Aktivierung einer bösartigen Code-Injektion in einem Paket ausgelöst, das von SolarWinds Orion-Produkt verwendet wurde. Kunden entlang der gesamten Softwarebereitstellungskette waren erheblich davon betroffen. Andere Angriffe, einschließlich der log4j-Schwachstelle, die mehrere kommerzielle Softwareanbieter traf, unterstrichen die Notwendigkeit einer genauen Untersuchung von Anwendungsabhängigkeiten, um Risiken in der gesamten [Softwarebereitstellungskette](https://about.gitlab.com/de-de/solutions/supply-chain/) zu bewerten.\n\nDarüber hinaus stellt das Auffinden und Beheben einer Sicherheitslücke einen Kostenfaktor dar –was die Bedeutung von SBOMs weiter unterstreicht. SBOMs ermöglichen Transparenz in Bezug auf Abhängigkeiten und können dazu genutzt werden, Schwachstellen sowie Lizenzen zu identifizieren, die nicht den internen Vorgaben entsprechen.\n\n## Arten von SBOM-Datenaustauschstandards   \n\nSBOMs sind am effektivsten, wenn die Generierung und Verarbeitung von Informationen wie Name, Version, Packager und weiteren Daten automatisiert erfolgen kann. Dies wird optimal erreicht, wenn alle Beteiligten ein standardisiertes Format für den Datenaustausch verwenden.\n\nEs gibt zwei wesentliche Standards für den SBOM-Datenaustausch:\n\n- [OWASP CycloneDX](https://cyclonedx.org/capabilities/sbom/)\n- [SPDX](https://spdx.dev/)\n\nGitLab setzt für die SBOM-Generierung auf CycloneDX, da dieser Standard präzise und benutzerfreundlich ist, komplexe Abhängigkeiten vereinfacht und durch seine Erweiterbarkeit auch spezialisierte sowie zukünftige Anwendungsfälle abdeckt.\n\n## Vorteile der Kombination von SBOMs und Software-Vulnerability-Management\n\nSBOMs sind für DevSecOps-Teams und Software-Nutzer(innen) aus mehreren Gründen äußerst vorteilhaft:\nSie ermöglichen einen Standardansatz, um zu verstehen, welche zusätzlichen Softwarekomponenten in einer Anwendung enthalten sind und wo sie deklariert sind.\nSie bieten einen kontinuierlichen Einblick in den Entstehungsprozess einer Anwendung, einschließlich Details über die Herkunft des Codes von Drittanbietern und Host-Repositories.\nSie bieten ein hohes Maß an Sicherheitstransparenz, sowohl für den von Erstanbietern entwickelten Code als auch für die übernommene Open-Source-Software.\nDie Details, die SBOMs bieten, ermöglichen es einem [DevOps-Team](https://about.gitlab.com/de-de/topics/devops/), Schwachstellen zu identifizieren, die potenziellen Risiken zu bewerten und sie dann zu entschärfen.\nSBOMs können die Transparenz liefern, die die Käufer von Anwendungen heute verlangen.\n\n## Dynamische GitLab-SBOMs \n\nDamit SBOMs ihr volles Potenzial entfalten können, müssen sie automatisch generiert, mit Anwendungssicherheitsscans verbunden, in Dashboards integriert und kontinuierlich aktualisiert werden. GitLab unterstützt all diese Ziele und bietet dabei umfassende Funktionen zur Sicherung der Softwarebereitstellungskette.\n\n![Dynamic SBOM management](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673653/Blog/Content%20Images/Screenshot_2024-05-03_at_10.53.28_AM.png)\n\n### SBOM-Generierung und SBOM-Verwaltung skalieren\n\nZur Einhaltung interner Richtlinien und Vorschriften ist es wichtig, über genaue und umfassende SBOMs zu verfügen, die Open-Source-, Drittanbieter- und unternehmenseigene Software abdecken. Um SBOMs für jede Komponente und Produktversion effektiv zu verwalten, ist ein rationalisierter Prozess für die Erstellung, Zusammenführung, Validierung und Genehmigung von SBOMs erforderlich. Die Abhängigkeitslistenfunktion von GitLab fasst bekannte Schwachstellen- und Lizenzdaten in einer einzigen Ansicht auf der GitLab-Benutzeroberfläche zusammen. Die Informationen des Abhängigkeitsdiagramms werden auch als Teil des Abhängigkeits-Scanberichts generiert. Dadurch erhalten Benutzer(innen) einen umfassenden Einblick in Abhängigkeiten und Risiken innerhalb ihrer Projekte oder in Projektgruppen. Darüber hinaus kann in der CI-Pipeline ein JSON-Artefakt im CycloneDX-Format erzeugt werden. Diese API bietet einen differenzierteren und anpassbaren Ansatz für die SBOM-Erstellung. SBOMs können über die Benutzeroberfläche, eine bestimmte Pipeline oder ein Projekt oder über die GitLab-API exportiert werden.\n\n### SBOMs einlesen und zusammenführen\n\nGitLab kann SBOMs von Drittanbietern einlesen und bietet eine umfängliche Sicherheitstransparenz sowohl für Drittanbieter-Code als auch für eingebundene Open-Source-Software. Mit GitLab kannst du einen CI/CD-Job verwenden, um mehrere CycloneDX-SBOMs nahtlos in eine einzige SBOM zusammenzuführen. Durch die Verwendung implementierungsspezifischer Details in den CycloneDX-Metadaten jeder SBOM, wie etwa die Position von Build- und Sperrdateien, werden doppelte Informationen aus der resultierenden Datei entfernt. Diese Daten werden auch automatisch mit Lizenz- und Schwachstelleninformationen für die in der SBOM enthaltenen Komponenten angereichert.\n\n### Schwachstellen schneller beheben\n\nDie schnellere Entwicklung hochwertiger Produkte erfordert aussagekräftige Sicherheitsergebnisse, damit Entwickler(innen) die kritischsten Schwachstellen beheben können. GitLab hilft bei der Sicherung deiner Bereitstellungskette, indem es nach Schwachstellen im Quellcode, in Containern, Abhängigkeiten und laufenden Anwendungen sucht. GitLab bietet einen umfassenden Sicherheitsscanner mit Funktionen für statische Anwendungssicherheitstests (SAST), dynamische Anwendungssicherheitstests (DAST), Containerscans und Softwarekompositionsanalysen (SCA), um dich umfassend vor neuen Bedrohungen zu schützen. Um Entwickler(innen) und Sicherheitsingenieur(innen) zu helfen, Schwachstellen besser zu verstehen und effizienter zu beheben, bietet GitLab Duo Vulnerability Explanation, eine KI-gestützte Funktion. Sie erläutert eine bestimmte Schwachstelle, wie sie ausgenutzt werden kann und empfiehlt vor allem, wie die Schwachstelle zu beheben ist. In Kombination mit GitLab Duo Vulnerability Resolution können DevSecOps-Teams Schwachstellen mit nur wenigen Klicks intelligent identifizieren, analysieren und beheben.\n\nDie Plattform unterstützt auch die Erstellung neuer Richtlinien (und die Durchsetzung der Compliance), die auf neu entdeckten Schwachstellen basieren.\n\n### Kontinuierliche SBOM-Analyse\n\nGitLab Continuous Vulnerability Scanning löst Scans in allen Projekten aus, bei denen entweder Container-Scans, Abhängigkeits-Scans oder beide aktiviert sind, unabhängig von einer Pipeline. Wenn neue Common Vulnerabilities and Exposures (CVEs) in der National Vulnerability Database (NVD) gemeldet werden, müssen die Benutzer(innen) ihre Pipelines nicht neu starten, um die neuesten Feeds zu erhalten. GitLabs Vulnerability Research Team fügt diese CVEs zur GitLab Advisory Database hinzu – und diese Hinweise werden automatisch als Schwachstellen in GitLab gemeldet. Dadurch wird GitLabs SBOM dynamisch.\n\n### Vertrauen in SBOMs aufbauen\n\nOrganisationen, die [Compliance-Funktionen](https://about.gitlab.com/de-de/solutions/compliance/) benötigen, können GitLab verwenden, um Bestätigungen für alle Build-Artefakte zu erstellen, die vom [GitLab Runner](https://docs.gitlab.com/runner/) produziert werden. Der Prozess ist sicher, da er vom GitLab Runner selbst durchgeführt wird, ohne dass Daten an einen externen Dienst übergeben werden müssen.\n\n### Die Zukunft der SBOM-Funktionalität von GitLab\n\nDie Sicherheit der [Softwarebereitstellungskette](https://about.gitlab.com/direction/supply-chain/) bleibt aufgrund der häufigen Angriffe auf große Softwareanbieter und der gezielten Bemühungen von Angreifern im Open-Source-Ökosystem ein kritisches Thema in der Cybersecurity- und Softwareindustrie. Auch wenn sich die SBOM-Branche schnell weiterentwickelt, gibt es weiterhin Bedenken, wie SBOMs generiert werden, wie häufig diese Generierung erfolgt, wo sie gespeichert werden, wie man mehrere SBOMs für komplexe Anwendungen kombiniert, wie man sie analysiert und wie man sie für Anwendungen nutzt.\n\nGitLab hat SBOMs zu einem integralen Bestandteil seiner Softwarebereitstellungskettenstrategie gemacht und verbessert kontinuierlich seine SBOM-Fähigkeiten innerhalb der DevSecOps-Plattform, einschließlich der Planung neuer Funktionen und Funktionalitäten. Zu den jüngsten Verbesserungen gehören die Automatisierung der Bestätigungserstellung, die digitale Signierung von Build-Artefakten und die Unterstützung extern generierter SBOMs. \n\nDarüber hinaus hat GitLab innerhalb der Plattform ein solides [SBOM Maturity Model](https://handbook.gitlab.com/handbook/security/security-assurance/dedicated-compliance/sbom-plan/) , etabliert, das Schritte wie die automatische SBOM-Generierung, das Sourcing von SBOMs aus der Entwicklungsumgebung, die Analyse von SBOMs für Artefakte und die Förderung der digitalen Signierung von SBOMs umfasst. GitLab plant auch die Einführung der automatischen digitalen Signatur von Build-Artefakten in zukünftigen Versionen.\n\n### Erste Schritte mit SBOMs\n\nDie Nachfrage nach SBOMs ist bereits hoch. Behörden empfehlen oder verlangen zunehmend die Erstellung von SBOMs von Softwareanbietern, Entwickler(innen) von Bundessoftware und sogar Open-Source-Communities. \n\nInformiere dich über die SBOM-Funktionen für GitLab Ultimate in der DevSecOps-Plattform von GitLab, um diese Anforderungen zu erfüllen.\n\n## SBOM-FAQ\n### Was ist eine SBOM?\n\nEine SBOM (Software Bill of Materials) ist eine detaillierte Liste aller Komponenten, Bibliotheken und Abhängigkeiten, die in einer Software verwendet werden. Sie bietet Transparenz über die verwendeten Elemente, um Sicherheitslücken zu identifizieren und die Software-Compliance sicherzustellen. SBOMs helfen, Schwachstellen zu erkennen und Software-Supply-Chain-Risiken zu minimieren.\n\n### Warum sind SBOMs wichtig?  \n\nSBOMs sind aus mehreren Gründen entscheidend:\nEinblick in Abhängigkeiten: Das Verständnis der Bestandteile deiner Software hilft, Risiken in Verbindung mit Drittanbieter-Komponenten zu identifizieren und zu mindern.\nErhöhte Sicherheit: Mit detaillierten Einblicken in die Komponenten einer Anwendung können Organisationen Schwachstellen schnell identifizieren und beheben.\nRegulatorische Compliance: Zunehmend fordern Vorschriften und Best Practices eine SBOM für Softwarepakete, insbesondere im öffentlichen Sektor.\nEffiziente Entwicklung: Entwickler(innen) können auf eine SBOM zurückgreifen, um Einblicke in verwendete Bibliotheken und Komponenten zu erhalten, was Zeit spart und Fehler im Entwicklungszyklus reduziert.\n\n### Welche Standards werden für den SBOM-Datenaustausch verwendet?\n\nEs gibt zwei vorherrschende Standards:\n\n- CycloneDX: CycloneDX ist für seine benutzerfreundliche Herangehensweise bekannt, die es ermöglicht, komplexe Beziehungen zwischen Softwarekomponenten zu vereinfachen und spezielle Anwendungsfälle zu unterstützen. Der Standard ist erweiterbar und eignet sich gut für zukünftige Anforderungen.\n- SPDX: Ein weiteres weit verbreitetes Framework für den SBOM-Datenaustausch, das detaillierte Informationen über die in der Softwareumgebung enthaltenen Komponenten bereitstellt.\n\nGitLab verwendet speziell CycloneDX für die SBOM-Generierung, da es aufgrund seiner Präskriptivität und Erweiterbarkeit gut für zukünftige Anforderungen geeignet ist.\n\n### Wie geht GitLab mit SBOMs um?\n\nGitLab legt besonderen Wert auf die Erstellung dynamischer SBOMs, die:\nAutomatisch generiert werden: So wird sichergestellt, dass stets aktuelle Informationen über die Softwarezusammensetzung vorliegen.\nIn Tools integriert sind: SBOMs werden mit Sicherheits-Scanning-Tools verbunden, um umfassende Risikobewertungen zu ermöglichen.\nEinfach zu verwalten sind: GitLab unterstützt die Einlesung und das Zusammenführen von SBOMs für eine umfassende Analyse.\nKontinuierlich analysiert werden: Die Plattform bietet fortlaufende Scans von Projekten, um neu auftretende Schwachstellen frühzeitig zu erkennen.\n\n### Wie kann ich SBOMs in meinem Unternehmen implementieren?\n\nDie steigende Nachfrage nach SBOMs spiegelt die zunehmende Bedeutung von Softwaresicherheit und Integrität der Lieferkette wider. Für Unternehmen, die bereit sind, SBOMs einzuführen, bietet das Ultimate-Paket von GitLab eine robuste Plattform zur Erstellung und Verwaltung von SBOMs innerhalb eines DevSecOps-Workflows. Durch den Einsatz der GitLab-Tools können Teams die Einhaltung von Vorschriften gewährleisten, die Sicherheit verbessern und Entwicklungsverfahren optimieren.\n\n[\nTeste GitLab Ultimate kostenlos.](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/de-de/blog/&glm_content=default-saas-trial)\n\n---\n\nDisclaimer \n*Dieser Blog enthält Informationen zu zukünftigen Produkten, Features und Funktionen. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Sie sollten nicht als Grundlage für Kauf- oder Planungsentscheidungen verwendet werden. Wie bei allen Projekten unterliegen die in diesem Blog erwähnten Elemente und verlinkten Seiten Änderungen oder Verzögerungen. Die Entwicklung, Veröffentlichung und das Timing von Produkten, Features oder Funktionen liegen im alleinigen Ermessen von GitLab.*\n",[1093],"Sandra Gittlen","2025-04-01","2022-10-25",[773,9,1097,1098,187],"performance","open source","Erfahre, was eine Software Bill of Materials (SBOM) ist und warum sie zu einem integralen Bestandteil der modernen Softwareentwicklung geworden ist.",{"slug":1101,"featured":6,"template":691},"the-ultimate-guide-to-sboms","content:de-de:blog:the-ultimate-guide-to-sboms.yml","The Ultimate Guide To Sboms","de-de/blog/the-ultimate-guide-to-sboms.yml","de-de/blog/the-ultimate-guide-to-sboms",{"_path":1107,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1108,"content":1115,"config":1125,"_id":1127,"_type":14,"title":1128,"_source":16,"_file":1129,"_stem":1130,"_extension":19},"/de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":1109,"description":1110,"ogTitle":1109,"ogDescription":1110,"noIndex":6,"ogImage":1111,"ogUrl":1112,"ogSiteName":673,"ogType":1113,"canonicalUrls":1112,"schema":1114},"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":1109,"description":1110,"authors":1116,"heroImage":1111,"date":1118,"body":1119,"category":751,"tags":1120,"updatedDate":1124},[1117],"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",[1121,1122,109,860,9,1123],"Tutorial","CI","Git","2025-06-05",{"slug":1126,"featured":6,"template":691},"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":1132,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1133,"content":1139,"config":1145,"_id":1147,"_type":14,"title":1148,"_source":16,"_file":1149,"_stem":1150,"_extension":19},"/de-de/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":1134,"description":1135,"ogTitle":1134,"ogDescription":1135,"noIndex":6,"ogImage":1136,"ogUrl":1137,"ogSiteName":673,"ogType":674,"canonicalUrls":1137,"schema":1138},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","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":1134,"description":1135,"authors":1140,"heroImage":1136,"date":1141,"body":1142,"category":10,"tags":1143,"updatedDate":1144},[1093],"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.",[109,9,687,686,773,751],"2025-05-08",{"slug":1146,"featured":91,"template":691},"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":1152,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1153,"content":1159,"config":1166,"_id":1168,"_type":14,"title":1169,"_source":16,"_file":1170,"_stem":1171,"_extension":19},"/de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management",{"title":1154,"description":1155,"ogTitle":1154,"ogDescription":1155,"noIndex":6,"ogImage":1156,"ogUrl":1157,"ogSiteName":673,"ogType":674,"canonicalUrls":1157,"schema":1158},"Agile Exzellenz entfesseln: GitLab Epics für nahtloses Portfolio-Management","Erfahre, wie die mehrstufigen Epics von GitLab das agile Portfoliomanagement revolutionieren, indem sie einen strukturierten und dennoch flexiblen Ansatz für die strategische Planung und effiziente Ausführung bieten.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098713/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098713577.png","https://about.gitlab.com/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Agile Exzellenz entfesseln: GitLab Epics für nahtloses Portfolio-Management\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"},{\"@type\":\"Person\",\"name\":\"Melissa Ushakov\"}],\n        \"datePublished\": \"2024-02-06\",\n      }",{"title":1154,"description":1155,"authors":1160,"heroImage":1156,"date":1163,"body":1164,"category":1053,"tags":1165},[1161,1162],"Amanda Rueda","Melissa Ushakov","2024-02-06","Ein effektives Portfoliomanagement ist entscheidend für den Erfolg von Organisationen in der sich ständig weiterentwickelnden Landschaft der Softwareentwicklung. Um deine Geschäftsstrategie effektiv umzusetzen, musst du auf die richtigen Dinge setzen, deine Ressourcen optimal einsetzen und die Risiken minimieren.\n\nDie Portfolio-Management-Funktionen von GitLab bieten einen strukturierten und dennoch flexiblen Ansatz, um die Strategie mit der Umsetzung zu verbinden. In diesem Blogbeitrag werden wir die Vorteile der mehrstufigen Epics von GitLab und ihre zentrale Rolle im agilen Portfoliomanagement untersuchen.\n\n## Mehrstufige Epics von GitLab verstehen\n\nMit den mehrstufigen Epics von GitLab können Organisationen ihre Arbeit in einer hierarchischen Struktur organisieren, die einen klaren und detaillierten Überblick über die Projekte und ihre Abhängigkeiten bietet, damit Teams fundierte Entscheidungen treffen, potenzielle Herausforderungen vorhersehen und ihre Arbeitsabläufe optimieren können, um die Effizienz zu steigern und Projekte erfolgreich abzuschließen. Im Gegensatz zu anderen Tools erlaubt GitLab die Verschachtelung von Epics auf bis zu sieben Ebenen über verschiedene Gruppen und Projekte hinweg und ermöglicht so eine effiziente funktionsübergreifende Koordination.\n\n![epics portfolio management - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098727863.png)\n\n## Vorteile von mehrstufigen Epics im Portfolio-Management\n\nHier findest du vier Vorteile von mehrstufigen Epics im Portfolio-Management:\n\n### 1. Flexible Kompatibilität mit agilen Frameworks\n\nEpics passen sich nahtlos an verschiedene Scaled Agile Framework an, so dass Teams GitLab an ihre bevorzugte Arbeitsweise anpassen können. Mehrstufige Epics bieten ein flexibles Konstrukt zur Darstellung verschiedener übergeordneter Planungsaufgaben mit minimalem Konfigurationsaufwand. Diese Anpassungsfähigkeit bedeutet, dass Teams GitLab effizient für Produktplanungs-Workflows nutzen können, ohne dass sie umfangreiche Einstellungen vornehmen müssen, sodass sie sich mehr auf die strategische Planung und weniger auf die Konfiguration von Tools konzentrieren können.\n\n### 2. Granulare Aufschlüsselung der Arbeit\n\nMit den mehrstufigen Epics von GitLab können Organisationen komplexe Projekte in kleinere, überschaubare Komponenten aufteilen, so dass die Teams kleinere Iterationen identifizieren können, die eine schnellere und häufigere Bereitstellung von greifbarem Mehrwert für die Benutzer(innen) ermöglichen. Übergeordnete Epics bieten einen strategischen Überblick, der sich über mehrere Jahre erstrecken kann, während Epics, die näher an den Entwicklungsergebnissen liegen, in der Regel in wenigen Sprints abgeschlossen werden können. Epics können in Issues und Tasks unterteilt werden, um strategische Ziele mit taktischeren Ergebnissen zu verbinden.\n\n![epics portfolio management - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098727864.png)\n\n### 3. Echtzeit-Transparenz und Zusammenarbeit\n\nGitLab-Epics bieten Transparenz über den Fortschritt in Echtzeit und fördern die effektive Zusammenarbeit im Team. GitLab bietet eine beispiellose Rückverfolgbarkeit mit automatischen Fortschrittsaktualisierungen für Epics auf der Grundlage nachgelagerter DevSecOps-Aktivitäten für verknüpfte Workitems, sodass die Beteiligten fundierte Entscheidungen anhand der aktuellsten Informationen treffen, Ressourcen effektiv zuweisen und einen proaktiven Ansatz für die Verwaltung von Produktzeitplänen verfolgen können.\n\n![epics portfolio management - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098727866.png)\n\n### 4. Teamübergreifende Planung\n\nMehrstufige Epics erleichtern die effiziente Planung über mehrere Teams hinweg, indem sie eine zentrale Übersicht über die Arbeitsaufteilung und die Abhängigkeiten der Teams in der gesamten Organisation bieten und so eine kohärente Zusammenarbeit und Abstimmung der Bemühungen gewährleisten. Alle Informationen für die agilen Planungsprozesse und die Ausführung der Arbeit in deiner Organisation sind in einem einzigen Tool zusammengefasst, das den gemeinsamen Kontext der Arbeit eines Teams mit der übergeordneten Strategie darstellt.\n\n![epics portfolio management - image 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098728/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098727871.png)\n\nDie Portfolio-Management-Tools von GitLab, einschließlich der mehrstufigen Epics, stellen sicher, dass die strategische Planung nahtlos mit der Ausführung von Projekten übereinstimmt, sodass die Teams die Komplexität der Softwareentwicklung mit Präzision, Effizienz und einem klaren Fokus auf die übergreifenden Geschäftsziele steuern können.\n\nBist du bereit, das volle Potenzial der mehrstufigen Epics von GitLab zu nutzen und dein Portfolio-Management zu verbessern? Sieh dir unsere Abonnementoptionen auf unserer [Preisseite](https://about.gitlab.com/de-de/pricing/) an und schalte eine Vielzahl leistungsstarker Funktionen frei, die die Zusammenarbeit fördern, die Transparenz verbessern und deine Projekte zum Erfolg führen.\n",[1051,9,687],{"slug":1167,"featured":91,"template":691},"unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management","content:de-de:blog:unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management.yml","Unlocking Agile Excellence Gitlab Epics For Seamless Portfolio Management","de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management.yml","de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management",{"_path":1173,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1174,"content":1180,"config":1186,"_id":1188,"_type":14,"title":1189,"_source":16,"_file":1190,"_stem":1191,"_extension":19},"/de-de/blog/what-is-a-rest-api-guide-and-functions",{"title":1175,"description":1176,"ogTitle":1175,"ogDescription":1176,"noIndex":6,"ogImage":1177,"ogUrl":1178,"ogSiteName":673,"ogType":674,"canonicalUrls":1178,"schema":1179},"Was ist eine REST-API? Guide & Funktionen","REST-APIs sind der de-facto-Standard für die Kommunikation zwischen Server und Client. Erfahren Sie hier alles Wissenswerte zum Thema!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg","https://about.gitlab.com/blog/what-is-a-rest-api-guide-and-functions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist eine REST-API? Guide & Funktionen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-10-16\",\n      }",{"title":1175,"description":1176,"authors":1181,"heroImage":1177,"date":1183,"body":1184,"category":10,"tags":1185},[1182],"GitLab Germany Team","2024-10-16","REST-APIs sind seit über zwei Jahrzehnten ein zentraler Baustein des Internets. Bei ihnen handelt es sich um Programmierschnittstellen (APIs), die den Austausch von Daten zwischen Client und Server regeln. REST-APIs unterliegen einem Satz von Bedingungen, welche der Wissenschaftler Roy Fielding im Jahr 2000 entwickelt und unter der Abkürzung REST (representational state transfer) [festgelegt hat](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 \"festgelegt hat\").\n\nREST legt die genaue technische Umsetzung dieser Schnittstellen nicht fest. Fielding hat REST vielmehr als einen „Architektur-Stil“ [bezeichnet](https://www.youtube.com/watch?v=6oFAmQUM8ws \"bezeichnet\"), der eine Vielzahl praktischer Lösungen erlaubt. Jede API, die sich innerhalb der Grenzen dieser Architektur bewegt, entspricht dem REST-Standard.\n\nIn diesem Artikel zeigen wir Ihnen, warum sich REST seit seiner Einführung zum dominanten Modell entwickelt hat und welche Vorteile sich für Web-Development-Teams daraus ergeben. \n\n## Constraints: Die Grundbausteine der REST-Architektur\n\nREST baut auf insgesamt sechs sogenannten „Constraints“ (Einschränkungen) auf. \n\nAus ihnen ergibt sich eine Architektur, die einfach und anpassungsfähig ist und auch in einem rasch wandelnden Geschäftsumfeld langfristig Bestand haben kann.\n\n## Definition: Was ist eine Rest-API?\n\nREST-APIs sind praktische Softwarelösungen, die auf der REST-Dokumentation aufbauen und gemäß der folgenden sechs REST-Prinzipien für ein Client-Server-Modell erstellt werden: \n\n- Unabhängigkeit zwischen Client und Server,\n- Zustandslosigkeit,\n- ein mehrschichtiges Systemmodell, \n- eine einheitliche Schnittstelle,\n- Cache-Fähigkeit und\n- ein optionales Constraint: Code on Demand.\n\nIn den folgenden Abschnitten betrachten wir diese Constraints genauer. \n\n### Unabhängigkeit zwischen Client und Server\n\nREST findet wie erwähnt für APIs Anwendung, die den Austausch von Ressourcen zwischen einem Client und einem Server ermöglichen. Entscheidend ist, dass Client und Server vollkommen unabhängig voneinander bleiben. \n\nSo kann beispielsweise der Code des Servers verändert werden, ohne dass der Client ebenfalls Änderungen vornehmen muss, um weiterhin Informationen anfragen und erhalten zu können. \n\n### Zustandslosigkeit\n\nDie Einschränkung der Zustandslosigkeit hat der REST-Architektur ihren Namen verliehen. Für APIs soll gemäß dieser Vorgabe gelten, dass für die korrekte Beantwortung einer Anfrage die übermittelten Informationen der aktuellen Sitzung ausreichen.\n\nDas bedeutet: Es ist keine dauerhafte Verbindung zwischen Client und Server erforderlich und Client-Anfragen müssen auf der Server-Seite auch nicht zwischengespeichert werden. \n\nZustandslosigkeit führt zu höherer Daten- und Ausfallsicherheit. Gleichzeitig gilt aber auch: Benötigen Nutzer(innen) dieselben Informationen ein zweites Mal, müssen sämtliche Informationen der vorigen Sitzung erneut eingeben werden. \n\n### Mehrschichtiges Systemmodell\n\nFür jedes Unternehmen ist eine andere Server-Struktur optimal. Werden Informationen beispielsweise in verschiedenen Schichten gespeichert, gestaltet sich die Abfrage mehr oder weniger komplex. Das aber sollte für eine Anfrage unerheblich bleiben, solange die Daten korrekt übermittelt werden.  \n\nDie Einschränkung des mehrschichtigen Systemmodells ist somit das Gegenstück zur Zustandslosigkeit. Während letztere besagt, dass der Server vom Client nichts weiter benötigt als die Anfrageinformationen, verlangt das mehrschichtige Modell, dass dem Client nicht bekannt zu sein braucht, wie der Server die angeforderten Daten bereitstellt. \n\nDer Server kann also mit einer Vielzahl verschiedener Architekturen arbeiten, ohne dass die REST-API-Schnittstelle beeinflusst wird. \n\n### Einheitliche Schnittstelle\n\nDiese Einschränkung ist etwas komplexer und wiederum aus vier Unterpunkten aufgebaut. Für Roy Fielding war sie die womöglich wichtigste der gesamten REST-API-Architektur. \n\nDie einheitliche Schnittstelle fordert:\n\n- dass jeder Datensatz über eine einzige URI eindeutig gekennzeichnet ist,\n- dass Veränderungen oder auch Löschungen der Daten nur mittels der grundlegenden Netzwerkprotokollbefehle, wie GET, POST, PUT/PATCH und DELETE, vorgenommen werden können,\n- dass jede Nachricht, die versandt wird, mittels Metadaten sämtliche Informationen bereithält, die für die Bearbeitung der Daten erforderlich ist und\n- dass, sofern erforderlich, Hyperlinks (HATEOAS) bereitgestellt werden, um weitere benötigte Informationen einzuholen.\n\nDie einheitliche Schnittstelle sorgt für maximale Klarheit und eine einfache, standardisierte Client-Server-Kommunikation. \n\n### Cache-Fähigkeit\n\nZwar findet bei REST-APIs der Ressourcenaustausch zustandslos statt, zugleich aber sollten einmal angeforderte Daten aus einer Sitzung auf demselben Endgerät weiterverwendet werden können.\n\nIndem REST das Cachen dieser Informationen ermöglicht, sorgt es für eine höhere Effizienz und beschleunigt viele Prozesse bedeutend.\n\n### Code on Demand\n\nFür die meisten Anwendungen reicht die Bereitstellung der Daten in der Form von XML or JSON vollkommen aus. In bestimmten Fällen aber kann es von Vorteil sein, dem Client darüber hinaus –      oder stattdessen – eine Anwendung bereitzustellen. Denken Sie dabei an Java Applets oder JavaScript.\n\nCode on Demand stellt eine sinnvolle Erweiterung der REST-Architektur dar, aber sie ist als einzige der sechs Einschränkungen optional. \n\n## Wofür eignen sich REST-APIs?\n\nFlexibilität ist eines der Hauptmerkmale von REST-APIs. So sind sehr viele praktische Anwendungen denkbar:\n\n- Ganz grundsätzlich das Abrufen und Bereitstellen von Daten. Social-Media-Seiten wie Instagram oder Facebook nutzen REST-APIs beispielsweise um Updates zu posten.\n- Gerade weil sie zustandslos sind, eignen sich REST-APIs für Cloud-Services: Auch wenn die Verbindung abbricht, können die Daten weiter genutzt werden. \n- [Microservices](https://microservices.io/ \"Microservices\") gewinnen rasch an Beliebtheit und Bedeutung. Mit ihnen geht ein umfassender Perspektivenwechsel einher: Applikationen werden nicht mehr als riesige, in sich geschlossene Systeme gedacht, sondern als modular und aus kleineren, schlanken Elementen zusammengesetzt. REST-APIs bilden die ideale Schnittstelle zur nahtlosen Integration dieser verschiedenen Bausteine.\n\nIm Laufe der letzten 20 Jahre sind Alternativen zu REST-APIs verfügbar geworden. Dennoch hat sich keine davon auf breiter Basis durchsetzen können. Ganz offensichtlich ist REST auch aktuell der beste Ansatz zum Datenaustausch im Netz. \n\n## Was sind die Vorteile einer Rest-     API?\n\nIn den frühen Tagen des Internets war SOAP (Simple object access protocol) die dominante Form des Datenaustauschs. \n\nDass sich REST seitdem durchgesetzt hat und fast ein Vierteljahrhundert lang relevant geblieben ist, lässt sich recht einfach aus seinen inhärenten Vorteilen erklären:\n\n- SOAP vs REST: SOAP ist ein Protokoll, das Regeln und auch technische Realisierungen im Gegensatz zu REST sehr präzise vorschreibt. Daraus ergibt sich unmittelbar, dass APIs, die auf diesen Anforderungen aufbauen, weitaus komplexer als REST-APIs sind.\n- Die APIs, die gemäß der REST-Richtlinien programmiert wurden, basieren auf dem HTTP-Standard. Sie sind schnell und effizient und in nahezu jedem Kontext einsetzbar. Aus genau diesen Gründen eignen sich REST-APIs auch besonders gut für mobile Anwendungen.\n- Der Begriff der Skalierbarkeit ist bereits gefallen und er ist auch einer der maßgeblichen Argumente für die Verwendung von REST-APIs. Darunter ist zu verstehen, dass bei Erweiterungen der Server-Architektur nicht die darunter liegende Datenaustausch-Technologie verändert werden muss. \n- Einige Unternehmen setzen aus Sicherheitserwägungen immer noch auf SOAP. Allerdings sind REST-APIs keineswegs grundsätzlich unsicher. Entscheidend ist, einige grundlegende Best Practices anzuwenden – darunter die Verwendung von HTTPS sowie Autorisierung und Authentifizierung. \n\n## Gibt es eine REST-API von GitLab?\n\nAuch bei GitLab sind wir von den Vorzügen der REST-Architektur überzeugt. Aus diesem Grund stellen wir unseren Nutzer(inne)n eine [GitLab-REST-API](https://docs.gitlab.com/ee/api/rest/ \"GitLab-REST-API\") zur Verfügung. \n\nBei GitLab handelt es sich um den führenden Anbieter von DevSecOps-Lösungen. Anwender(innen) nutzen die Plattform, um sicher, fehlerfrei und kollaborativ an Entwicklungsprojekten zu arbeiten. \n\nDie GitLab-API kann sowohl genutzt werden, um öffentlich sichtbare, als auch nicht öffentliche Daten (nach erfolgter Authentifizierung und Autorisierung) abzurufen. Weil die API unmittelbar auf GitLab abgestimmt ist, erfolgt der Austausch sicher, schnell und effizient. \n\n## REST-API FAQs\n\n### Ist REST ein Standard?\n\nREST ist ein Satz aus sechs Einschränkungen, die den Datenaustausch in einer Client-Server-Beziehung regeln. Alle API-Schnittstellen, die diesen Vorgaben entsprechen, sind „RESTful“. \nEs ist somit nicht falsch, REST als einen Standard zu bezeichnen. Allerdings gilt dies weniger im Sinne eines Protokolls oder konkreter Anweisungen. REST gibt vielmehr Leitlinien und Anforderungen vor, deren Umsetzung zu gewünschten Ergebnissen führen, unabhängig davon, wie diese technisch realisiert werden.\n\nAus diesem Grund wird REST zumeist als ein „Architektur-Stil“ definiert. \n\n### Muss ich alle sechs REST-Einschränkungen befolgen?\n\nRoy Fielding hat hierzu persönlich im Laufe der Jahre mehrfach [Stellung bezogen](https://www.infoq.com/articles/roy-fielding-on-versioning/ \"Stellung bezogen\"). Seine Ansichten zu dieser Frage sind eindeutig: REST ist nicht in allen Fällen zwangsläufig die beste Option. Wenn man aber eine REST-konforme Architektur wünscht, müssen sämtliche Constraints ausnahmslos umgesetzt werden. \n\nEine API beispielsweise, die alle Einschränkungen umsetzt, bei der aber keine Daten gecached werden können, ist nicht RESTful. \n\nDie einzige Ausnahme ist Code on Demand. Diese Einschränkung ist optional und muss somit nicht umgesetzt werden, damit eine REST-API die Kriterien erfüllt. \n\n### Wie passen Cache-Fähigkeit und Zustandslosigkeit zusammen?\n\nZwischen den Einschränkungen der Cache-Fähigkeit und Zustandslosigkeit scheint ein Spannungsverhältnis zu bestehen. Wenn bei jeder Anfrage die Daten neu übermittelt werden müssen, widerspricht das Zwischenspeichern von Daten im Cache dann nicht dieser Forderung? \n\nIn Wahrheit fordert Zustandslosigkeit lediglich, dass der Server jede Anfrage so behandelt, als wäre sie die erste. Es besteht keine Zuordnung der Daten im Cache zu einer aktuellen Anfrage. \n\nDas Cachen der Daten dient lediglich einer höheren Effizienz und sorgt für Stabilität. \n\n### Was bedeutet der Begriff Idempotenz im Zusammenhang mit REST-APIs?\n\nWenn ein Client dieselbe Anfrage mehrfach nacheinander stellt, spricht man von Idempotenz. Das kann entweder passieren, weil die Verbindung instabil oder der Code fehlerhaft ist. \n\nEntscheidend ist, dass eine solche idempotente Anfrage nicht zu einem Fehler bei der Beantwortung der Anfrage führt. \n\nDie Einschränkung der Cache-Fähigkeit sorgt dafür, dass idempotente Anfragen als solche erkannt und fehlerfrei bearbeitet werden können. \n\n### Wie lassen sich Rest-APIs sichern?\n\nREST-APIs können sehr effektiv gesichert werden. \n\nÜbliche und sehr effiziente Methoden sind die Verwendung von HTTPS und API-Schlüsseln, die Durchführung von Authentifizierungen und Autorisierungen sowie die Durchführung einer Input-Validation und eines Audit-Loggings. \n\nAuch die Begrenzung der Anfragen in einem bestimmten Zeitfenster im Sinne eines Rate-Limiting empfiehlt sich.",[860,9],{"slug":1187,"featured":6,"template":691},"what-is-a-rest-api-guide-and-functions","content:de-de:blog:what-is-a-rest-api-guide-and-functions.yml","What Is A Rest Api Guide And Functions","de-de/blog/what-is-a-rest-api-guide-and-functions.yml","de-de/blog/what-is-a-rest-api-guide-and-functions",{"_path":1193,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1194,"content":1200,"config":1210,"_id":1212,"_type":14,"title":1213,"_source":16,"_file":1214,"_stem":1215,"_extension":19},"/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"ogTitle":1195,"schema":1196,"ogImage":1197,"ogDescription":1198,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":1199,"title":1195,"canonicalUrls":1199,"description":1198},"Was ist Git? | Einfach erklärt | Praxis-Tutorial","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist Git? Der ultimative Leitfaden zur Rolle und Funktionalität von Git\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-11-14\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673991/Blog/Hero%20Images/Git.jpg","Wir zeigen dir, was hinter Git steckt und wie du das Tool optimal nutzt. ✓ Definition ✓ Bedeutung ✓ Funktionen ✓ Vorteile ✓ Befehle ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"heroImage":1197,"body":1201,"authors":1202,"updatedDate":1204,"date":924,"title":1205,"tags":1206,"description":1208,"category":1209},"Git ist ein unverzichtbares Tool in der modernen Softwareentwicklung. In diesem umfassenden Leitfaden erklären wir detailliert, was das Git-Tool ist, welche Rolle es bei der Versionsverwaltung von Quellcode spielt und wie es funktioniert. Egal, ob du Anfänger(in) oder Expert(in) bist: Dieser Leitfaden vermittelt dir ein tiefes Verständnis von Git und seinen vielen Funktionen.\n\n## Inhalt - Alles über Git\n\n- [Was ist Git?](#was-ist-git%3F)\n- [Was ist Versionskontrolle?](#was-ist-versionskontrolle%3F)\n- [Was sind die Funktionen von Git?](#was-sind-die-funktionen-von-git%3F)\n- [Visualisierung deines Projektverlaufs](#visualisierung-deines-projektverlaufs)\n- [Mehr Autonomie für Teams](#mehr-autonomie-f%C3%BCr-teams)\n- [Optimierung von Entwicklungs-Workflows](#optimierung-von-entwicklungs-workflows)\n- [Was sind die Vorteile von Git?](#was-sind-die-vorteile-von-git%3F)\n- [Was sind die Hauptbefehle von Git?](#was-sind-die-hauptbefehle-von-git%3F)\n- [Git und GitLab](#git-und-gitlab)\n- [FAQ zu Git](#faq-zu-git)\n\n## Was ist Git?\n\nGit ist ein Tool zur Versionskontrolle, das sich in der Welt der Softwareentwicklung schnell zu einem Muss entwickelt hat. Da mit Git Änderungen an Projekten genauestens verfolgt werden können, ist es ein unverzichtbares Tool für Entwickler(innen), um ihre Projekte effizient zu verwalten. Damit es für alle, die in der Softwareentwicklung weiterkommen möchten, unverzichtbar, Git zu beherrschen.\n\n### Was ist Versionskontrolle?\n\n[Versionskontrolle](https://about.gitlab.com/de-de/topics/version-control/) ermöglicht es dir, Änderungen am Quellcode einer Software zu verfolgen. Daher besteht jede gelieferte Softwareversion aus einer Reihe bestimmter Versionen jeder ihrer Komponenten und Quellcodedateien. Ein Icon wurde beispielsweise nur zwei Mal geändert, während eine Codedatei im Laufe der Zeit dutzende Änderungen durchgemacht hat.\n\n## Was sind die Funktionen von Git?\n\nIn der Entwicklung ist es wichtig, Änderungen am Quellcode einer Software rigoros zu verwalten. Ohne diese kann unmöglich sichergestellt werden, dass Entwicklungsteams konsistent und zuverlässig arbeiten können. Ein fein abgestimmtes Änderungsmanagement kann es auch einfacher machen, die Ursache eines Problems zu identifizieren. Außerdem verringert es das Risiko von Konflikten und das Überschreiben von Dateien. In der Tat erleichtert und rationalisiert Git die Versionsverwaltung von Software genau zu diesem Zweck.\n\nUm Git und seine Funktionsweise besser zu verstehen, haben wir hier einige Hauptfunktionen angeführt, mit denen die Quellcodeverwaltung sowie de Zusammenarbeit zwischen Teams auf einfache Weise optimiert werden kann.\n\n### Visualisierung deines Projektverlaufs\n\nIn der Welt der Softwareentwicklung ist der [Commit-Verlauf](https://about.gitlab.com/blog/keeping-git-commit-history-clean/) ein Grundpfeiler, um den Projektfortschritt auf Git zu verfolgen. Daher bietet Git Entwickler(inne)n einen detaillierten Gesamtverlauf aller Änderungen am Quellcode.\n\nFür jeden neuen Commit wird Folgendes erfasst:\n\n* Spezifische Änderungen an Projektdateien\n* Eine erläuternde Nachricht des Entwicklerteams, das die Änderung vorgenommen hat\n\nDiese Elemente tragen dazu bei, die Kommunikation und den Auftrag des Entwicklungsteams zu verbessern, sodass es die Einzelheiten jeder Codeänderung schneller verstehen kann.\n\nMit diesem Verlauf kannst du nicht nur die Entwicklung des Projekts überwachen, sondern auch zurückgehen und Teile der Änderung rückgängig machen oder auch nur einen Teil der Änderungen von einem Branch zu einem anderen übertragen. Diese Funktion ist daher entscheidend, um die Transparenz, Konsistenz und Qualität des Quellcodes eines Projekts in Git zu wahren. Außerdem wird dadurch die Zusammenarbeit im Entwicklungsteam gefördert und die betriebliche Effizienz bei der Problembehebung gesteigert.\n\nSieh dir in unserem Tutorial an, [wie du deinen ersten Git-Commit erstellst](https://docs.gitlab.com/ee/tutorials/make_first_git_commit/).\n\n### Mehr Autonomie für Teams\n\nEin weiteres wesentliches Merkmal des Git-Tools ist die [verteilte Entwicklung](https://git-scm.com/about/distributed). Dank seiner dezentralen Struktur ermöglicht es Git den Teams, gleichzeitig am selben Projekt zu arbeiten. Jedes Teammitglied hat seine eigene Kopie des Projekts, in der Änderungen versioniert werden können. Dadurch können sie autonom an bestimmten Funktionen arbeiten, ohne dass es zu Konflikten oder Überschreibungen kommt. Dieser Ansatz bietet den Entwickler(inne)n große Flexibilität, denn so können sie verschiedene Ideen ausarbeiten oder mit neuen Funktionen experimentieren, ohne die Arbeit ihrer Kolleg(inn)en zu stören.\n\nDie verteilte Entwicklung verbessert auch die Resilienz gegenüber Serverausfällen. So hat jede Person im Falle eine Ausfalls eine Kopie, mit der sie offline weiterarbeiten kann. Die Änderungen können dann synchronisiert werden, sobald der Server wieder verfügbar ist. Dadurch wird verhindert, dass die Arbeit des Entwicklungsteams unterbrochen wird und es zu Einschränkungen der Betriebsteams kommt.\n\n### Optimierung von Entwicklungs-Workflows\n\nEine der leistungsstärksten Funktionen von Git ist die Möglichkeit, [Branches und ihre Zusammenführer zu verwalten (Branching und Zusammenführen)](https://git-scm.com/about/branching-and-merging). Dadurch können Teams parallel auf kooperative und organisierte Weise arbeiten. Jede neue Ergänzung am Code und jeder Bugfix kann unabhängig getestet und entwickelt werden, um sicherzustellen, dass er zuverlässig ist. Die Entwickler(innen) können die Änderungen dann einfach in den Haupt-Branch des Projekts zusammenführen.\n\nDurch diesen Ansatz können Teams die Entwicklung des Codes nachverfolgen, einfach und effizient zusammenarbeiten, Konflikte zwischen verschiedenen Versionen reduzieren und die kontinuierliche Integration der entwickelten Funktionen sicherstellen.\n\nMit diesen beiden Funktionen können Teams kontinuierlich und im Sinne der Agile-Methodik Projekte entwickeln und regelmäßig neue Codeversionen bereitstellen. Diese Vorgehensweise erleichtert das Change Management deutlich und senkt gleichzeitig das Fehlerrisiko.\n\n## Was sind die Vorteile von Git?\n\nUm Git wirklich zu verstehen, musst du all die Vorteile kennen, die es deinen Entwicklungsteams bietet:\n\n* **Dezentralisierte Versionsverwaltung:** Mit Git haben alle Entwickler(innen) eine vollständige Kopie des Projektverlaufs und können dadurch unabhängig arbeiten.\n* **Ein Tool für Sicherheit:** Anders als andere Tools zur Versionskontrolle wurde Git mit dem Gedanken entwickelt, die Integrität aller Elemente im Repository mit einem kryptografischen Secure Hash Algorithm (aktuell SHA1 und [SHA-256](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/)) sicherzustellen. Dieser Algorithmus soll den Code und den Verlauf des Projekts vor Änderungen – egal, ob böswillig oder nicht – schützen. Darüber hinaus kann jeder Commit (also jede Erstellung einer neuen Version) automatisch signiert werden (GPG), um die Nachvollziehbarkeit zu gewährleisten. Dies macht Git zu einem besonders sicheren Tool, das die Integrität und Authentizität deines Quellcodes und seines Verlaufs sicherstellt.\n* **Ein schnelles und effektives Tool:** Das Git-Tool wurde entwickelt, um die Effizienz bei der Entwicklung zu maximieren. Dank seiner Geschwindigkeit können Entwickler(innen) komplexe Vorgänge wie Commits, Branching und das Zusammenführen äußerst rasch durchführen, und das sogar in großen Codebases. Es sorgt auch für einen minimalen Fingerabdruck auf der Festplatte und beim Netzwerkaustausch. Diese Effizienz führt zu kürzeren Reaktionszeiten bei Backups, Beratungen und Änderungen am Projektverlauf.\n* **Mehr Flexibilität beim Arbeiten:** Git unterstützt eine Vielzahl an Entwicklungs-Workflows. Egal, ob du zentralisierte Entwicklungsmodelle oder eher einen linearen Ansatz bevorzugst: Git lässt sich einfach anpassen. Diese Fähigkeit, verschiedene Workflows zu verwalten, bietet Teams zahlreiche Optionen für ihre Arbeitsweise.\n* **Einfache Integration:** Git zeichnet sich dadurch aus, dass es sich in eine ganze Reihe bestehender Entwicklungstools und -plattformen integrieren lässt. Durch diese breite Kompatibilität können Teams die besten DevSecOps-Tools und -Praktiken nutzen und dadurch ihre Projekte effizienter verwalten.\n* **Ein weithin anerkanntes Open-Source-Projekt:** Ein weiterer bedeutender Vorteil von Git ist, dass es ein Open-Source-Projekt ist und von einer dynamischen, engagierten Community unterstützt wird, wodurch die kontinuierliche Weiterentwicklung sichergestellt wird. Durch diese aktive Beteiligung von Einzelpersonen und Unternehmen in der Git-Community kommen im Rahmen kontinuierlicher Updates regelmäßig neue Funktionen und Verbesserungen hinzu.\n\n## Was sind die Hauptbefehle von Git?\n\nDas Open-Source-Projekt Git bietet eine Vielzahl an Befehlen, um die Teamarbeit zu erleichtern.  \nHier sind einige der am häufigsten verwendeten Befehle.\n\n* **git init:** Ein neues Git-Repository initialisieren.  \n* **git clone \\[url\\]:** Ein vorhandenes Repository klonen.  \n* **git add \\[file\\]:** Eine Datei zum Index hinzufügen.  \n* **git commit:** Die vorgenommenen Änderungen validieren.  \n* **git commit \\-m \"message\":** Änderungen mit einer Nachricht validieren.  \n* **Git-Status:** Den Status der Dateien im Arbeitsverzeichnis anzeigen.  \n* **git push:** Änderungen an das Remote-Repository senden.  \n* **git pull:** Änderungen aus dem Remote-Repository abrufen und sie mit dem lokalen Repository zusammenführen. Alles über git pull erfährst du in diesem umfangreichen Artikel [git fetch vs. git pull](https://about.gitlab.com/de-de/blog/git-pull-vs-git-fetch-whats-the-difference/).\n\nDiese Befehle sind zwar unerlässlich, um mit Git loszulegen – es gibt aber noch viele andere Befehle. Du findest sie in der [Liste der Git-Befehle](https://git-scm.com/docs).\n\n## Git und GitLab\n\nGitLab ist eine kollaborative Open-Source-Entwicklungsplattform, die alle Phasen des DevSecOps-Lebenszyklus abdeckt und einen Git-Server für eine effiziente Teamzusammenarbeit bietet.\n\nNeben der Quellcodeverwaltung bietet GitLab ein umfassendes Programmpaket für kontinuierliche Integration und Verteilung, Verwaltung von Ergebnissen, Sicherheits- und Vorfallmanagement sowie Nachvollziehbarkeit, Aufgabenplanung und -nachverfolgung in Echtzeit, Bereitstellungsüberwachung, Software-Versionsverwaltung und die zugehörigen Dokumente.\n## FAQ zu Git\n\n### Warum sollte man Git verwenden?\n\nBei Git dreht sich alles um Effizienz. Durch das dezentrale System von Git, das auf Branching und Funktionen zum Zusammenführen basiert, können Entwicklungsteams am selben Projekt arbeiten, ohne sich gegenseitig zu stören und (was noch wichtiger ist) ohne Versionskonflikte zu erschaffen.\n\n### Ist Git Software?\n\nGit ist ein Open-Source-Projekt. Daher ist es kostenlos und für alle offen. Du musst jedoch [Git](https://docs.gitlab.com/ee/topics/git/how_to_install_git/) auf deinem Gerät installieren, bevor du mit der Arbeit beginnen kannst.\n\n### Was ist ein Branch in Git?\n\nIn Git ist ein Branch ein Zeiger auf einen Änderungsverlauf. Somit verweist jeder Haupt-Branch auf den letzten Commit, der auf ihm ausgeführt wurde. Es ist daher möglich, viele parallele Branches zu haben, die alle ihren eigenen Verlauf, jedoch die gleiche Wurzel haben.\n\n### Was ist ein Commit?\n\nIn Git ist ein Commit ein Datensatz von Änderungen am Quellcode einer Software. Jeder Commit wird von einer erläuternden Nachricht begleitet, die den Gesamtverlauf aller Änderungen dokumentiert. Dies erleichtert die Nachverfolgung von Projekten. Außerdem gibt es immer die Möglichkeit, bei Problemen zu früheren, funktionierenden Versionen zurückzukehren.\n\n### Was sind die Vorteile von Branches in Git?\n\nDurch die Entwicklung von Funktionen in Branches können Entwickler(innen) gleichzeitig an mehreren unterschiedlichen Funktionen arbeiten. Darüber hinaus wird dadurch vermieden, dass der Haupt-Branch mit instabilem Code kompromittiert wird. Außerdem ist die Implementierung von Branches in Git deutlich leichter als in anderen Versionskontrollsystemen.",[1203],"GitLab","2025-07-10","Was ist Git? Der ultimative Leitfaden",[1207,9,1098],"git","Möchtest du deine Projekte mit Git umsetzen? Entdecke alle Vorteile und Funktionen von Git in unserem umfassenden Guide.","open-source",{"slug":1211,"featured":6,"template":691},"what-is-git-the-ultimate-guide-to-gits-role-and-functionality","content:de-de:blog:what-is-git-the-ultimate-guide-to-gits-role-and-functionality.yml","What Is Git The Ultimate Guide To Gits Role And Functionality","de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality.yml","de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"_path":1217,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1218,"content":1224,"config":1232,"_id":1234,"_type":14,"title":1235,"_source":16,"_file":1236,"_stem":1237,"_extension":19},"/de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"ogTitle":1219,"schema":1220,"ogImage":1221,"ogDescription":1222,"ogSiteName":673,"noIndex":6,"ogType":674,"ogUrl":1223,"title":1219,"canonicalUrls":1223,"description":1222},"Einheitliche DevSecOps-Plattform: Vorteile für Unternehmen","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2025-06-02\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","Erfahre mehr über GitLabs einheitliche DevSecOps-Plattform: Tool-Integration, verbesserte Sicherheit und KI für effiziente Entwicklung.","https://about.gitlab.com/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"heroImage":1221,"body":1225,"authors":1226,"updatedDate":879,"date":1228,"title":1229,"tags":1230,"description":1231,"category":10},"In der modernen Softwareentwicklung von heute migrieren viele Unternehmen in die Cloud und führen DevSecOps-Prozesse ein. Durch die Vielzahl von Tools und Legacy-Systemen, die nicht für die moderne Entwicklung ausgelegt sind, stellt diese Umstellung jedoch eine große Herausforderung dar. \n\nUm diese Systeme an DevSecOps anzupassen, müssen Unternehmen mehrere Tools für Aufgabenmanagement, CI/CD, Sicherheit, Überwachung und vieles mehr miteinander verknüpfen. Das Ergebnis? Komplexe Betriebsabläufe, hohe Wartungskosten und eine erschwerte Zusammenarbeit zwischen Entwicklungs- und Betriebsteams. Darüber hinaus sind Entwickler(innen) frustriert, da sie ständig zwischen verschiedenen Tools wechseln müssen, um einen einzigen Flow – von der Planung bis zur Produktion – abzuschließen.\n\n![Die Komplexität und die Betriebskosten der Integration mehrerer Tools in einen DevSecOps-Prozess](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>Wie komplex es sein kann, mehrere Tools in einen DevSecOps-Prozess zu integrieren\u003C/i>\u003C/center> \n\n\u003Cbr>\u003C/br>\n\nDie gute Nachricht ist, es gibt eine Lösung: Eine umfassende DevSecOps-Plattform, die einen einheitlichen Ansatz für die Softwareentwicklung bietet.\n\nDiese Plattformen sind für Unternehmen konzipiert, die in cloudbasierten und DevSecOps-Umgebungen arbeiten. Sie konsolidieren alle Phasen der Softwareentwicklung – von der Codeverwaltung, über CI/CD-Prozesse, Aufgabenmanagement und Sicherheit bis hin zur KI-gestützten Automatisierung – auf einer einzigen Plattform. Die Zentralisierung aller Softwareentwicklungs-Workflows in einer einheitlichen Oberfläche ermöglicht es den Entwicklungs- und Betriebsteams, effizienter zu arbeiten, die Kommunikation zu vereinfachen und die Komplexität der Vorgänge und Störungen zu minimieren. \n\nDarüber hinaus verbessert sich die Entwicklererfahrung erheblich – sie arbeiten viel lieber mit einem Produkt, das speziell für moderne Entwicklungsanforderungen konzipiert wurde.\n\nIn den folgenden Abschnitten erfahren wir, wie GitLab Teams bei der Bewältigung gängiger Herausforderungen hilft – sei es bei der Verwaltung von Projekten und Aufgaben, der Gewährleistung von Sicherheit und Compliance oder der Einführung von KI-basierten Entwicklungstools – und das alles auf einer einzigen, einheitlichen Plattform.\n\n## Integriertes Agile-Projektmanagement\n\n[GitLab](https://about.gitlab.com/de-de/) bietet eine ganzheitliche Lösung, bei der das Projekt- und Aufgabenmanagement über alle Phasen des Softwareentwicklungszyklus hinweg vollständig integriert ist, wie z. B. CI/CD, wodurch der Entwicklungsfortschritt in Echtzeit verfolgt werden kann. Tickets und Epics sind direkt mit den Automatisierungsprozessen verknüpft und ermöglichen einen nahtlosen Flow von der Planung bis zur Bereitstellung in der Produktion. Dieser Ansatz erhöht die Transparenz zwischen den Teams, verringert Verzögerungen und stellt sicher, dass alle Beteiligten einen klaren Überblick über den Entwicklungsstatus in Echtzeit haben.\n\n![Tickets und Epics sind direkt mit Automatisierungsprozessen verknüpft und ermöglichen einen nahtlosen Übergang von der Planung bis zur Bereitstellung in der Produktion.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## Integrierte Sicherheit\n\nGitLab legt großen Wert auf die Integration von umfassenden Sicherheitsfunktionen („security first“). Die Plattform integriert eine breite Palette automatisierter Sicherheitsscanner, darunter (Dokumentation nur in englischer Sprache verfügbar):\n\n* [Abhängigkeitssuche](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n* [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/user/application_security/sast/)\n* [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/user/application_security/dast/)\n* [Erkennung von Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/)\n* [Container-Scanning](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![Sicherheitsscanning-Funktionen, die in verschiedenen Entwicklungsphasen in den CI/CD-Prozess integriert sind](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>Sicherheitsscanning-Funktionen, die in verschiedenen Entwicklungsphasen in den CI/CD-Prozess integriert sind\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nDiese Sicherheitsprüfungen werden direkt in jede Phase des Softwareentwicklungszyklus eingebaut, einschließlich der CI/CD-Pipeline, um den Entwickler(inne)n schon früh im Entwicklungszyklus ein unmittelbares Feedback zu potenziellen Sicherheitsproblemen zu geben.\n\n## Compliance und regulatorische Anforderungen\n\nNeben Effizienz und Benutzerfreundlichkeit müssen viele Unternehmen – insbesondere in regulierten Branchen wie Finanzinstituten oder Großunternehmen – sicherstellen, dass ihre Prozesse strengen Sicherheits- und Compliance-Standards entsprechen. Sie müssen in der Lage sein, Richtlinien für verschiedene Projekte durchzusetzen, z. B. einen Sicherheitsscanner vorzuschreiben, wenn eine CI/CD-Pipeline auf bestimmten Code-Branches (Main- oder geschützte Branches) ausgeführt wird, oder bestimmte Genehmigungen zu verlangen, bevor Code in den Main-Branch zusammengeführt wird.\n\nMit GitLab wird dies durch [Compliance-Frameworks (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) erleichtert, eine Funktion, mit der Unternehmen strukturierte Richtlinien für ausgewählte Projekte definieren und durchsetzen können. So wird die Einhaltung automatischer gesetzlicher und sicherheitstechnischer Anforderungen gewährleistet und gleichzeitig ein nahtloser und effizienter Workflow für Entwickler(innen) sichergestellt.\n\n## KI-basierte Entwicklung\n\n[GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) unterstützt dich in allen Entwicklungsphasen mit KI, sodass du nicht mehr auf externe Tools zurückgreifen musst. Jede KI-unterstützte Anforderung wird im gesamten Kontext des Projekts und der Codebase bearbeitet, was eine intelligentere und effizientere Arbeit ermöglicht.\n\nDie KI kann zum Beispiel folgende Aufgaben übernehmen:\n\n* automatische Erstellung von Aufgabenbeschreibungen\n* intelligente Zusammenfassung von Diskussionen zu Tickets, was Entwickler(inne)n wertvolle Zeit spart\n* erweiterte Code-Review-Funktionen\n* Vorschläge zur Codeverbesserung und -optimierung\n* automatisierte Testgenerierung\n* Erkennung und Behebung von Sicherheitslücken\n* Fehlerbehebung bei der Grundursachenanalyse für CI-Pipeline-Fehler\n* Datenschutz und Datensicherheit\n\nGitLab kennt die Bedürfnisse von regulierten Unternehmen, insbesondere im öffentlichen und im Finanzsektor, und bietet eine einzigartige Lösung für den Einsatz von KI-Modellen in einer sicheren Umgebung. GitLab Duo Self-Hosted ermöglicht es Unternehmen, die volle Kontrolle über Datenschutz, Sicherheit und die Bereitstellung großer Sprachmodelle [(LLMs; nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) in ihrer eigenen Infrastruktur zu behalten. Dabei wird Folgendes gewährleistet:\n\n* Datenschutz\n* Einhaltung gesetzlicher Anforderungen\n* maximale Sicherheit\n* KI-Vorteile ohne externe Netzwerkabhängigkeiten oder -risiken\n\n## Zusammenfassung\n\nUnternehmen brauchen eine umfassende DevSecOps-Plattform, um Prozesse zu rationalisieren, die Sicherheit zu verbessern und Innovationen zu beschleunigen. GitLab bietet genau das – eine einzige Anwendung, die alle wichtigen Entwicklungs-, Sicherheits- und Betriebswerkzeuge mit integrierter Sicherheitsintegration und KI-basierter Automatisierung vereint.\n\nWillst du GitLab in Aktion sehen? Entdecke interaktive (englischsprachige) Demos für:\n\n* [GitLab Premium und Ultimate mit Duo](https://gitlab.navattic.com/gitlab-premium-with-duo): Erlebe KI-Unterstützung bei der Entwicklung,\n* [Sicherheit in der CI/CD-Pipeline](https://gitlab.navattic.com/gitlab-scans): Sieh dir an, wie integriertes Sicherheitsscanning deine Software schützt.\n* [Compliance-Frameworks](https://gitlab.navattic.com/compliance): Erfahre, wie GitLab Richtlinien projektübergreifend durchsetzt, um eine bessere Governance zu gewährleisten.\n\n> Nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über die Zukunft der DevSecOps-Plattform zu erfahren, einschließlich der Rolle der agentischen KI. [Registriere dich noch heute!](https://about.gitlab.com/de-de/eighteen/)",[1227],"Itzik Gan Baruch","2025-06-02","Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?",[9,687,751],"Erfahre mehr über die einheitliche DevSecOps-Plattform von GitLab, die Tools integriert, Sicherheit verbessert und KI für eine effiziente Softwareentwicklung nutzt.",{"slug":1233,"featured":6,"template":691},"why-are-organizations-moving-to-a-unified-devsecops-platform","content:de-de:blog:why-are-organizations-moving-to-a-unified-devsecops-platform.yml","Why Are Organizations Moving To A Unified Devsecops Platform","de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform.yml","de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"_path":1239,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":1240,"content":1246,"config":1253,"_id":1255,"_type":14,"title":1256,"_source":16,"_file":1257,"_stem":1258,"_extension":19},"/de-de/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"title":1241,"description":1242,"ogTitle":1241,"ogDescription":1242,"noIndex":6,"ogImage":1243,"ogUrl":1244,"ogSiteName":673,"ogType":674,"canonicalUrls":1244,"schema":1245},"Drei überraschende Ergebnisse unserer Globalen DevSecOps-Umfrage 2024","Unsere Umfrage in diesem Jahr hat gezeigt, dass sich die Investitionsprioritäten der Unternehmen im Schatten der KI verändert haben – und wie KI die Arbeitsweise von Teams beeinflusst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751993603/Blog/Hero%20Images/fy25-global-devsecops-report-blog-image.png","https://about.gitlab.com/blog/3-surprising-findings-from-our-2024-global-devsecops-survey","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Drei überraschende Ergebnisse unserer Globalen DevSecOps-Umfrage 2024\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-06-25\",\n      }\n                  ",{"title":1241,"description":1242,"authors":1247,"heroImage":1243,"date":1248,"body":1249,"category":1250,"tags":1251},[834],"2024-06-25","Die diesjährige [Umfrage unter mehr als 5.000 DevSecOps-Fachleuten weltweit](https://about.gitlab.com/de-de/developer-survey/) zeigt, dass Unternehmen mit der Einführung neuer Technologien wie KI ihre Investitionsprioritäten neu bewerten und kritischer prüfen, wie sie das Entwicklererlebnis verbessern können. Wir werfen einen Blick auf drei der überraschendsten Ergebnisse der aktuellen Umfrage und was sie für Softwareentwicklungs-, Betriebs- und Sicherheitsteams im Jahr 2024 und darüber hinaus bedeuten könnten.\n\n## 1. KI deckt umständliche Toolchains auf\n\nIn diesem Jahr haben wir uns besonders damit beschäftigt, wie sich KI auf die Einstellung von DevSecOps-Teams zu ihren bestehenden Toolchains auswirken könnte. Die Ergebnisse waren etwas überraschend. Wir wissen, dass KI Teams helfen kann, die Softwareentwicklung zu vereinfachen, aber unsere Umfrage hat gezeigt, dass die Befragten, die derzeit KI einsetzen, mit ihren Toolchains möglicherweise weniger zufrieden sind als diejenigen, die keine KI einsetzen.\n\nFast drei Viertel (74 %) der Befragten, deren Unternehmen derzeit KI für die Softwareentwicklung einsetzen, gaben an, dass sie ihre Toolchain konsolidieren möchten, verglichen mit 57 % derjenigen, die keine KI einsetzen. Allerdings gab es hinsichtlich der Anzahl der Tools, die die Befragten laut ihren Angaben verwenden, keinen signifikanten Unterschied zwischen den beiden Gruppen. Mit anderen Worten: Die Befragten, die derzeit KI einsetzen, verwenden nicht mehr Tools, haben aber dennoch ein stärkeres Bedürfnis, ihre Toolchain zu konsolidieren.\n\nWarum könnte der Einsatz von KI den Wunsch nach Konsolidierung beschleunigen? Eine mögliche Erklärung könnte sein, dass verschiedene punktuelle Lösungen mit unterschiedlichen KI-Modellen ein unüberschaubares (und nicht messbares) Chaos im Lebenszyklus der Softwareentwicklung verursachen – und das wirft ein neues Licht auf die ohnehin schon schwerfälligen und kontraproduktiven Toolchains der Unternehmen. Je mehr Unternehmen in KI investieren, desto größer wird die Notwendigkeit, die Effizienz durch die Konsolidierung und Vereinfachung der ausufernden Toolchain zu verbessern. Teams profitieren mehr von KI, wenn die Toolchains kleiner sind, da so die Integration von KI in den gesamten Lebenszyklus der Softwareentwicklung einfacher ist.\n\nEin(e) Umfrageteilnehmer(in) nannte „zu viele Tools (einschließlich KI-Tools) und Kontextwechsel“ als die größten Herausforderungen bei der Softwareentwicklung im Jahr 2024, während ein(e) andere(r) auf die „Komplexität der fragmentierten Landschaft von Tools in allen Bereichen“ verwies. \n\nEin(e) weitere(r) Befragte(r) betonte die Möglichkeiten, die KI bietet, um Teams bei der Bewältigung von Herausforderungen in der Toolchain zu unterstützen: „KI entwickelt sich rasant, und unsere aktuelle Toolchain kann durch KI-Integrationen massiv verbessert werden. Wir müssen Teammitglieder besser schulen, damit sie wissen, wie sie KI effektiv in ihrer täglichen Arbeit einsetzen können.“\n\n## 2. KI beschleunigt das Onboarding von Entwickler(inne)n – aber Unternehmen haben immer noch Bedenken\n\nNeben der steigenden Anzahl von Tools, die Teams nutzen, haben wir in der diesjährigen Umfrage auch einen deutlichen Anstieg der Einarbeitungszeiten für Entwickler(innen) festgestellt. 2024 gaben 70 % der Befragten an, dass Entwickler(innen) in ihrem Unternehmen für die Einarbeitung und die Aufnahme der Arbeit mehr als einen Monat benötigen. 2023 waren es noch 66 %.\n\nEs ist zwar nicht überraschend, dass KI-gestützte [Chat-Assistenten](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/) und [Codevorschläge](https://about.gitlab.com/blog/top-tips-for-efficient-ai-powered-code-suggestions-with-gitlab-duo/) Entwickler(inne)n helfen können, sich schneller einzuarbeiten, aber der Effekt, den wir in unserer Umfrage beobachtet haben, war dramatisch: Die Befragten, die KI für die Softwareentwicklung nutzen, gaben viel häufiger an, dass das Onboarding von Entwickler(inne)n in der Regel weniger als einen Monat dauert. \n\nTrotz der eindeutigen Vorteile, die KI für Entwickler(innen) bietet, äußerten die Befragten einige Bedenken hinsichtlich ihrer schnellen Einführung. Mehr als die Hälfte (55 %) der Befragten gab an, dass die Einführung von KI in den Lebenszyklus der Softwareentwicklung riskant ist, und 49 % befürchten, dass KI sie in ihrer derzeitigen Rolle innerhalb der nächsten fünf Jahre ersetzen wird.\n\nRachel Stephens, leitende Analystin beim Branchenanalysten RedMonk, teilte ihre Sicht auf diese Ergebnisse: „Es gibt eine Komponente der psychologischen Sicherheit und der Teamkultur, die sich darauf auswirkt, wie Menschen über KI denken. Die Menschen sind vielleicht besorgt über die Auswirkungen von KI auf die Sicherheit oder den Datenschutz, aber ihr Gefühl der Unvorbereitetheit kann auch von dem Gefühl herrühren, dass KI ein persönliches Risiko für ihren Lebensunterhalt darstellt.“\n\nUnserer Meinung nach liegt der Wert der KI in ihrer Fähigkeit, sich wiederholende Aufgaben und Optimierungen im Hintergrund zu automatisieren, so dass sich die Teams auf anspruchsvolle Problemlösungen, Innovationen und Wertschöpfung konzentrieren können. Es geht darum, das menschliche Element der Softwareentwicklung zu ergänzen – nicht zu ersetzen. Ein(e) Umfrageteilnehmer(in) fasste dies wie folgt zusammen: „Kreativität zu fördern und zu erhalten, während wir uns auf KI stützen, ist eine Herausforderung, der wir uns stellen müssen. Wir dürfen nicht vergessen, dass KI nur ein Werkzeug ist, das kreative Menschen nutzen, um alles auszublenden, was die Produktivität beeinträchtigen würde. Sie ersetzt nicht die menschliche Kreativität.“\n\n## 3. Die Cloud wird zum Grundpfeiler\n\nIn unserer Umfrage wurde Cloud Computing in den letzten Jahren immer wieder als eine der wichtigsten IT-Investitionsprioritäten genannt. 2022 lag Cloud Computing nach Sicherheit auf Platz zwei und 2023 auf Platz eins. Das ist nicht überraschend, wenn man bedenkt, dass der Druck auf die Unternehmen wächst, sich einer [digitalen Transformation](https://about.gitlab.com/blog/lockheed-martin-aws-gitlab/) zu unterziehen.\n\nIm Jahr 2024 ging die Bedeutung von Cloud Computing jedoch stark zurück und es landete nur noch auf Platz fünf. Gleichzeitig ist aber auch klar, dass die Cloud weiterhin wichtig ist. Die Zahl der Befragten, die angaben, dass sie 50 % oder mehr ihrer Anwendungen in der Cloud ausführen, ist sogar deutlich gestiegen. Das deutet darauf hin, dass die Cloud für viele Unternehmen zwar immer noch geschäftskritisch ist, aber inzwischen zum Standard gehört – und im gleichen Zug, dass die Prioritätenliste für technische Teams und IT- Führungskräfte immer länger wird.\n\nStephens von RedMonk meint: „Wir befinden uns in einer finanziell angespannten Situation und müssen Prioritäten bei den Technologieinvestitionen setzen. Das bedeutet, dass Unternehmen einen Teil, aber nicht das gesamte Budget für die digitale Transformation in Dinge wie KI umschichten können.“\n\n## Der diesjährige Bericht\n\nLies den vollständigen [Globalen DevSecOps-Bericht 2024](https://about.gitlab.com/de-de/developer-survey/), um mehr über KI, Sicherheit, Entwicklererfahrung und weiterführende Themen zu erfahren.","insights",[1252,9,685,773,839],"developer survey",{"slug":1254,"featured":6,"template":691},"3-surprising-findings-from-our-2024-global-devsecops-survey","content:de-de:blog:3-surprising-findings-from-our-2024-global-devsecops-survey.yml","3 Surprising Findings From Our 2024 Global Devsecops Survey","de-de/blog/3-surprising-findings-from-our-2024-global-devsecops-survey.yml","de-de/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",3,[666,696,718,739,760,783,803,823,847],1756472578412]