[{"data":1,"prerenderedAt":1194},["ShallowReactive",2],{"/de-de/blog/":3,"navigation-de-de":21,"banner-de-de":440,"footer-de-de":452,"blogCategories-de-de":662,"relatedBlogPosts-de-de":780,"maineFeaturedPost-de-de":1158,"recentFeaturedPosts-de-de":1163,"recentPosts-de-de":1179},{"_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","/de-de/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/de-de/solutions/continuous-integration/",{"text":113,"config":114},"KI-unterstützte Entwicklung",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Quellcodeverwaltung",{"href":119,"dataGaLocation":28,"dataGaName":120},"/de-de/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Automatisierte Softwarebereitstellung",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"Sicherheit und Compliance",{"href":130,"dataGaLocation":28,"dataGaName":137},"Security & Compliance",{"text":139,"config":140},"Schutz der Software-Lieferkette",{"href":141,"dataGaLocation":28,"dataGaName":142},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Compliance und Governance",{"href":146,"dataGaLocation":28,"dataGaName":147},"/de-de/solutions/continuous-software-compliance/","Compliance and governance",{"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},"/de-de/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":290,"config":291},"the source promo card",{"src":292},"/images/navigation/the-source-promo-card.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},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":420,"config":425},{"src":426,"dataGaName":423,"dataGaLocation":418},"/images/brand/gitlab-logo-type.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":447,"_id":449,"_type":16,"_source":17,"_file":450,"_stem":451,"_extension":20},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":68,"config":444},{"href":445,"dataGaName":446,"dataGaLocation":28},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":448},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":453,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":454,"_id":658,"_type":16,"title":659,"_source":17,"_file":660,"_stem":661,"_extension":20},"/shared/de-de/main-footer",{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":650},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":457,"config":458},"Quelltext der Seite anzeigen",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Diese Seite bearbeiten",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Beteilige dich",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,556,586,620],{"title":46,"links":479,"subMenu":484},[480],{"text":481,"config":482},"DevSecOps-Plattform",{"href":55,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":189,"links":486},[487,491,496],{"text":488,"config":489},"Tarife anzeigen",{"href":191,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Vorteile von Premium",{"href":494,"dataGaName":495,"dataGaLocation":461},"/de-de/pricing/premium/","why premium",{"text":497,"config":498},"Vorteile von Ultimate",{"href":499,"dataGaName":500,"dataGaLocation":461},"/de-de/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Lösungen",[504,509,512,514,519,524,528,531,534,539,541,543,546,551],{"text":505,"config":506},"Digitale Transformation",{"href":507,"dataGaName":508,"dataGaLocation":461},"/de-de/topics/digital-transformation/","digital transformation",{"text":135,"config":510},{"href":130,"dataGaName":511,"dataGaLocation":461},"security & compliance",{"text":122,"config":513},{"href":105,"dataGaName":106,"dataGaLocation":461},{"text":515,"config":516},"Agile Entwicklung",{"href":517,"dataGaName":518,"dataGaLocation":461},"/de-de/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Cloud-Transformation",{"href":522,"dataGaName":523,"dataGaLocation":461},"/de-de/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":119,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":109,"config":529},{"href":111,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":161,"config":532},{"href":163,"dataGaName":533,"dataGaLocation":461},"value stream management",{"text":535,"config":536},"GitOps",{"href":537,"dataGaName":538,"dataGaLocation":461},"/de-de/solutions/gitops/","gitops",{"text":174,"config":540},{"href":176,"dataGaName":177,"dataGaLocation":461},{"text":179,"config":542},{"href":181,"dataGaName":182,"dataGaLocation":461},{"text":544,"config":545},"Öffentlicher Sektor",{"href":186,"dataGaName":187,"dataGaLocation":461},{"text":547,"config":548},"Bildungswesen",{"href":549,"dataGaName":550,"dataGaLocation":461},"/de-de/solutions/education/","education",{"text":552,"config":553},"Finanzdienstleistungen",{"href":554,"dataGaName":555,"dataGaLocation":461},"/de-de/solutions/finance/","financial services",{"title":194,"links":557},[558,560,562,564,567,569,572,574,576,578,580,582,584],{"text":206,"config":559},{"href":208,"dataGaName":209,"dataGaLocation":461},{"text":211,"config":561},{"href":213,"dataGaName":214,"dataGaLocation":461},{"text":216,"config":563},{"href":218,"dataGaName":219,"dataGaLocation":461},{"text":221,"config":565},{"href":223,"dataGaName":566,"dataGaLocation":461},"docs",{"text":9,"config":568},{"href":245,"dataGaName":246,"dataGaLocation":461},{"text":239,"config":570},{"href":571,"dataGaName":242,"dataGaLocation":461},"/customers/",{"text":248,"config":573},{"href":250,"dataGaName":251,"dataGaLocation":461},{"text":261,"config":575},{"href":263,"dataGaName":264,"dataGaLocation":461},{"text":253,"config":577},{"href":255,"dataGaName":256,"dataGaLocation":461},{"text":266,"config":579},{"href":268,"dataGaName":269,"dataGaLocation":461},{"text":271,"config":581},{"href":273,"dataGaName":274,"dataGaLocation":461},{"text":276,"config":583},{"href":278,"dataGaName":279,"dataGaLocation":461},{"text":281,"config":585},{"href":283,"dataGaName":284,"dataGaLocation":461},{"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":461},{"text":311,"config":591},{"href":313,"dataGaName":314,"dataGaLocation":461},{"text":319,"config":593},{"href":321,"dataGaName":322,"dataGaLocation":461},{"text":324,"config":595},{"href":326,"dataGaName":327,"dataGaLocation":461},{"text":329,"config":597},{"href":331,"dataGaName":332,"dataGaLocation":461},{"text":334,"config":599},{"href":336,"dataGaName":337,"dataGaLocation":461},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":461},"/sustainability/",{"text":605,"config":606},"Vielfalt, Inklusion und Zugehörigkeit",{"href":607,"dataGaName":608,"dataGaLocation":461},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":610},{"href":341,"dataGaName":342,"dataGaLocation":461},{"text":349,"config":612},{"href":351,"dataGaName":352,"dataGaLocation":461},{"text":354,"config":614},{"href":356,"dataGaName":357,"dataGaLocation":461},{"text":616,"config":617},"Transparenzerklärung zu moderner Sklaverei",{"href":618,"dataGaName":619,"dataGaLocation":461},"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":461},{"text":368,"config":627},{"href":370,"dataGaName":371,"dataGaLocation":461},{"text":373,"config":629},{"href":375,"dataGaName":376,"dataGaLocation":461},{"text":631,"config":632},"Status",{"href":633,"dataGaName":634,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":636,"config":637},"Nutzungsbedingungen",{"href":638,"dataGaName":639,"dataGaLocation":461},"/terms/","terms of use",{"text":641,"config":642},"Datenschutzerklärung",{"href":643,"dataGaName":644,"dataGaLocation":461},"/de-de/privacy/","privacy statement",{"text":646,"config":647},"Cookie-Einstellungen",{"dataGaName":648,"dataGaLocation":461,"id":649,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":651},[652,654,656],{"text":636,"config":653},{"href":638,"dataGaName":639,"dataGaLocation":461},{"text":641,"config":655},{"href":643,"dataGaName":644,"dataGaLocation":461},{"text":646,"config":657},{"dataGaName":648,"dataGaLocation":461,"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,825,865,880,927,967,1005,1046,1086,1123],{"category":667,"slug":672,"posts":782},[783,797,813],{"content":784,"config":794},{"heroImage":785,"body":786,"authors":787,"updatedDate":789,"date":789,"title":790,"tags":791,"description":793,"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.*",[788],"GitLab Germany Team","2025-05-20","So schreibst du eine User Story in Scrum",[792],"agile","Der große User-Story-Guide für Scrum: Beispiele, Aufbau, Akzeptanzkriterien, Formulierung. Jetzt hier klicken und durchlesen!",{"slug":795,"featured":6,"template":796},"how-to-write-a-user-story-in-scrum","BlogPost",{"content":798,"config":811},{"title":799,"description":800,"authors":801,"heroImage":803,"date":804,"body":805,"category":672,"tags":806,"updatedDate":810},"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.",[802],"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",[792,807,808,764,809],"DevSecOps platform","features","tutorial","2025-05-12",{"slug":812,"featured":91,"template":796},"safe-without-silos-in-gitlab",{"content":814,"config":823},{"title":815,"description":816,"authors":817,"heroImage":818,"date":819,"body":820,"category":672,"tags":821,"updatedDate":819},"Wie OKRs deine Software-Entwicklung voranbringen","Die weltweit größten Unternehmen vertrauen auf OKR. Hier bekommst du den besten Einstieg im Netz.",[788],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663217/Blog/Hero%20Images/AdobeStock_790549874.jpg","2025-04-02","# Wie OKRs deine Softwareentwicklung voranbringen\n\nObjectives & Key Results – Ziele und Schlüsselergebnisse. Das klingt zunächst einmal recht einfach. Und nahezu alle, die mit OKRs arbeiten, können bestätigen, dass die Methode denkbar unkompliziert ist.\n\nDennoch wurden einige der wertvollsten Unternehmen der Gegenwart auf dieser rasch erlernbaren Methode aufgebaut. Von Google über Intel bis hin zu Apple – OKRs haben die Welt der Planung und Organisation im Sturm erobert.\n\nIn der Softwareentwicklung lassen sich OKRs organisch in agiles Management und in die unterschiedlichsten Strukturen einbinden. OKR ist ein Managementansatz, der schnell und ohne hohen finanziellen Aufwand umgesetzt werden kann. Das macht ihn geradezu ideal für kleine und mittelständische Unternehmen.\n\nIn diesem Artikel zeigen wir dir, wie du OKRs für das Formulieren und Erreichen deiner Entwicklungsziele einsetzen kannst und was es dabei zu beachten und zu vermeiden gilt.\n\n## Was sind OKRs?  \n\nOKR ist ein Ansatz, der das Erreichen qualitativer betrieblicher Ziele an empirisch messbare Ergebnisse bindet.  \n\nDer Begriff beinhaltet zwei Teile:\n\n**Objectives** – hierbei handelt es sich um die zu erreichenden Ziele.\n\n**Key Results** – dies sind die Kennziffern, mit denen du überprüfen kannst, ob das Ziel erreicht wurde.\n\nWenn du mit OKR arbeitest, setzt du dir somit klare, am Kundennutzen ausgerichtete Ziele, und prüfst während ihrer Umsetzung kontinuierlich und anhand eindeutig quantifizierbarer Werte, ob du Fortschritte machst.\n\n## OKR-Methode: Ein Beispiel  \n\nWie sieht dieser Prozess beispielsweise in der Entwicklungspraxis aus?\n\nNehmen wir an, aus Feedback-E-Mails sei hervorgegangen, dass deine international aktiven Kunden nicht zufrieden sind mit der Funktionalität deiner Buchhaltungssoftware. Du möchtest deswegen ein neues Feature entwickeln, das internationalen Geschäften automatisch die korrekten und erforderlichen Informationen, Vorlagen und Umsatzsteuereinstellungen bereitstellt. Nutzer(innen) brauchen nur noch das Land einzustellen und die Software kümmert sich um die korrekte Abwicklung.\n\nAls Ziel gibst du deinem Team vor, die Software so zu erweitern, dass sie euren bestehenden Kunden die Rechnungsstellung und Buchung grenzüberschreitender Transaktionen spürbar erleichtert.\n\nFolgende Key Results sollen den Erfolg des Projekts ermitteln:\n\nDie Anzahl der Beschwerde-E-Mails zu diesem Thema soll auf Null reduziert werden.\nDas Rating der Software auf Bewertungsportalen soll um mindestens 0,5/5 Punkte gesteigert werden.\n\nDie Aktion soll zu mindestens 500 Neukunden führen.\n\nDieses Beispiel macht klar, wie einfach OKRs umzusetzen sind. Und auch, wenn solche OKR-Beispiele trivial klingen mögen - in der betrieblichen Praxis ist es das keineswegs.\n\n## Fokus: Warum OKRs ein Gamechanger sind\n\nAuch, wenn OKRs keine revolutionäre neue Methode darstellen, so bieten sie doch eine neue Weise, über Management zu denken.\n\nDank OKRs können Ziele zum einen nicht mehr von Ergebnissen getrennt werden.\n\nDas Formulieren von Zielen bringt dein Unternehmen nur dann nach vorne, wenn du sie überprüfen kannst. Und die Arbeit an einem Projekt war nur dann erfolgreich, wenn du nachweisen kannst, dass die angestrebten Ziele erreicht wurden.\n\nZweitens legt OKRs großen Wert auf objektivierbare Ergebnisse. Gerade in Unternehmen, die noch mit traditionellen Top-Down-Hierarchien arbeiten, liegt es oftmals im Ermessen der oberen Managementebenen, die Ergebnisse aufgrund „heuristischer” Verfahren oder schlicht persönlicher Einschätzung zu beurteilen. Das führt zu Verzerrungen und Fehleinschätzungen.\n\nDie Key Results in OKRs hingegen sind unzweideutig. Entweder ein Schlüsselergebnis wurde erreicht oder nicht.\n\nOKRs bieten ein einfaches System mit einer komplexen Wirkung. Es reduziert den gesamten Planungsprozess auf nur zwei Komponenten. Gerade innerhalb einer zunehmend komplexen Wirtschaft ist das ein deutlicher Vorteil gegenüber anderen Ansätzen.\n\nDieses Prinzip wird oft auch unter dem Punkt „Fokus” zusammengefasst, also der scharfen Ausrichtung ihrer Planung auf klar umrissene Ziele und Ergebnisse. Fokus ist eine der fünf sogenannten “Superkräfte” der OKRs.\n\n## Warum OKRs Outcome statt Output betonen\n\nDer Unterschied zwischen Outcome und Output scheint rein semantischer Natur zu sein. In OKRs jedoch trennen die beiden Begriffe Welten.\n\nEinfach gesagt ist ein Output eine Leistung, die du für deinen/deine Kunden(in) erbringst. Das kann beispielsweise ein neues Software-Feature sein. Ein Outcome orientiert sich darüber hinaus noch dafür, welchen Nutzen dieses Feature dem/der Kunden(in) konkret bietet.\n\nOKRs sollten immer so formuliert werden, dass sie den Outcome in den Mittelpunkt stellen. Das bedeutet zugleich, dass sich Milestones – Meilensteine in der Produktentwicklung – in diesem Rahmen nicht eignen, da sie in der Regel Output-orientiert sind.\n\nOKRs sind keine Aufgabenliste, die du abarbeitest. Sie orientieren sich stets daran, dem/der Kunden(in) größtmöglichen Nutzen zu bieten.\n\n## Es gibt drei verschiedene Arten von Objectives\n\nEin weiterer wichtiger Aspekt, der die OKR-Methode deutlich interessanter macht, als sie auf den ersten Blick erscheinen mag, ist die Unterteilung der Ziele in drei Typen: Committed, Aspirational und Learning.\n\n**Committed Objectives** sind Ziele, für deren Umsetzung du dich fest verbürgst. Es gibt hier keinen Spielraum: Es gilt, ein Objective umzusetzen und entweder es wird zu 100 % umgesetzt oder gar nicht.\n\n**Aspirational Objectives**, auch gelegentlich als „Stretch objectives” bezeichnet, gehen einen Schritt weiter. Diese Ziele haben den Charakter von Idealen oder, um ein beliebtes Wort zu gebrauchen, „Visionen”. Sie stehen für Ansprüche, die du an dich und dein Unternehmen stellst, aber vielleicht zu diesem Zeitpunkt noch nicht erfüllen kannst.\n\n**Learning Objectives** kommen immer dann zum Tragen, wenn es vor allem darum geht, mit der Arbeit an bestimmten Zielen den eigenen Horizont zu erweitern oder mehr Daten zu sammeln, um die eigentlichen Ziele klarer erfassen zu können.\n\n## Die besondere Bedeutung von Stretch Goals\n\nMan kann OKRs auch ohne Stretch Goals einsetzen. Dennoch sind es gerade diese ambitionierten Ziele, die diese Managementmethode so beliebt gemacht haben. Der durchschlagende Erfolg, den OKRs in den frühen Jahren von Google und bei Intel verzeichneten und der beide Unternehmen gegenüber der Konkurrenz entscheidend nach vorne gebracht hat, beruht zu einem wesentlichen Teil auf ihnen.\n\nAuch aus diesem Grund ist „Stretching” einer der Kernaspekte der OKR-Methode und eine der fünf OKR-Superkräfte.\n\nStretch Objectives sind nicht erreichbar. Aber genau wie ein Muskel nur wachsen kann, wenn er immer wieder über seine aktuelle Belastbarkeit hinaus beansprucht wird, kann auch eine Organisation nur Fortschritte machen, wenn sie ihre Grenzen erforscht. Aspirational Goals sind der Baustein der OKR-Methode, der genau dies anstrebt.\n\nDas besondere: Stretch Objectives sind keine langfristigen Leitbilder, sondern sie sind durchaus praktisch angelegt. Sie können sowohl auf niedriger als auch auf hoher Hierarchieebene Anwendung finden und stehen neben „Committed Objectives”, die zu 100 % erfüllt werden sollen.\n\nDie Idee dahinter: Auch, wenn du vielleicht nur 70 % eines epischen Ziels erreichst – und im eigentlichen Sinne an deiner Aufgabe gescheitert bist, kann das, was am Ende dabei herausgekommen ist, dennoch bemerkenswert sein.  \n\n## Google Chrome: Stretching in der Praxis\n\nDie Energien, die beim Stretching freigesetzt werden, sind in der Praxis oftmals erstaunlich. Eines der meistzitierten Beispiele für OKRs  ist, wie Google den Markt für Webbrowser mit Chrome geradezu überrollte.\n\nDas erklärte Ziel (Objective) des Unternehmens lautete 2006, den besten Browser der Welt zu entwickeln. Als Key Result wählte man schlicht die globalen Nutzerzahlen: Man wollte nach Abschluss des ersten Jahres nach Einführung von Chrome die Zahl von 20 Millionen Usern erreichen.\n\nDieses Ziel verfehlte der mit der Leitung des Projekts beauftragte Sundar Pichai deutlich – es waren nur 10 Millionen. Statt den Kopf hängen zu lassen, betrachtete er das Ergebnis aus der Perspektive des Stretchings: 10 Millionen User aus dem Stand heraus war eine geradezu astronomisch hohe Zahl und belegte, dass man auf dem besten Weg war.\n\nNiemand wollte den Erfolg mehr als Pichai, der laut einem Business-Insider-Portrait zu Sundar Pichai sogar maßgeblich daran beteiligt war, die Google-Gründer von dem Chrome-Projekt zu überzeugen. Und so gab er für das nächste Jahr das Key Result von 50 Millionen vor. Es wurden 37 Millionen. Im letzten Jahr der Offensive schließlich lautete die Vorgabe 100 Millionen Benutzer. Diese überbot Pindar sogar um 11 Millionen. 2011 hatte Chrome den langjährigen Marktführer, Microsofts Internet Explorer, überholt und war zum meistgenutzten Browser geworden. Eine schöne Übersicht zu dieser Erfolgs-Story gibt es bei Digitalcoach.\n\nHieraus wird ersichtlich, dass Stretching, wenn es konsequent und auf das richtige Produkt angewandt wird, ein enormer Motivations-Booster sein kann.\n\nWie fügen sich diese Prinzipien zu einem kohärenten Framework zusammen? Durch Alignment, Commitment und Tracking.\n\n## Alignment: Alle machen mit\n\nDas OKR-Framework ist auf eine natürliche Art und Weise mit dem Agile-Framework verbunden. Ein wesentlicher Punkt ist, dass Objectives and Key Results Teil der Arbeitsorganisation auf jeder Ebene deines Unternehmens werden müssen.\n\nDas bedeutet, dass die oberen Ebenen OKRs nach unten delegieren, aber untere Ebenen auch OKRs nach oben weiterleiten. Es findet ein ständiger Austausch statt. Anstatt sich nur darauf zu konzentrieren, starr Ziele umzusetzen, wird den Teams viel Spielraum zur Entfaltung gewährt.\n\nSich aktiv an der OKR-Planung und den Rückmeldungsschleifen zu beteiligen, ist ein integraler Teil der Philosophie.\n\nMan bezeichnet diesen Prozess auch als “Alignment”, also die kontinuierliche Ausrichtung und Abstimmung zwischen verschiedenen Teams und Hierarchien. Daten fließen stets sowohl von unten nach oben und von oben nach unten und auf einer horizontalen Ebene in alle Richtungen.\n\nOKRs verschmelzen zudem Planung und Ausführung und überbrücken damit eine der traditionell größten Lücken in der Planerfüllung.\n\n## Commitment: Motivation\n\nEng verbunden mit dem Alignment ist das Commitment, also der Wunsch, dass sich alle Mitarbeiter(innen) einer Organisation voll und ganz mit einem Ziel identifizieren und sich dessen Erreichung verschreiben. Je mehr es für den/die Einzelnen(e) erkennbar wird, wie er/sie zum Erreichen beiträgt, desto höher wird seine/ihre Motivation sein, produktiv dazu beizutragen.\n\nEs war dieser Aspekt in Kombination mit einer flachen Hierarchie, der OKRs bei Intel und Google so effektiv machte. Von Anfang an war allen Beteiligten klar, dass man in einem Boot saß und dass jeder(e) seinen/ihren Beitrag leisten konnte.\n\nAlignment und Commitment sind zwei weitere Superkräfte des OKR. Sie werden ganz unmittelbar durch das Tracking unterstützt.\n\n## Tracking: Ergebnisse fassbar machen\n\nTracking bezeichnet den praktischen Prozess der Erfassung der Key Results.  Erst durch Tracking wird die OKR-Planung agil und aus einer Reihe von Vorgaben ein System zur Zielerreichung. Wegen dieser zentralen Rolle ist Tracking die letzte der fünf Superkräfte der OKRs.\n\nOKRs sind aufgrund der ständigen Kontrolle und des Fokus auf Objektivierbarkeit eng mit der agilen Methodologie verbunden. Ziele werden ständig auf ihre Erreichbarkeit hin getestet und gegebenenfalls neu formuliert.\n\nSolange die Key Results sinnvoll gesetzt sind, sollte das Tracking nicht kompliziert sein. Komplexer und umstrittener gestaltet sich hingegen die Frage, wie die Ergebnisse anschließend bewertet werden sollen.\n\nEigentlich geben OKRs vor, dass Ziele zu 100 % erreicht werden sollen. Für manche Unternehmen aber ist dieses Denken, so nützlich es sich in der Praxis oftmals auch erweist, zu Schwarzweiß. Sie bevorzugen es, innerhalb eines Systems zu arbeiten, bei dem Ergebnisse abgestuft bewertet werden, so dass auch ein Nichterreichen nicht sofort als ein „Scheitern” eingestuft werden muss.\n\nGrading ist die Antwort auf diesen Wunsch.\n\n## Was ist Grading in OKRs? \n\nBeim Grading werden die Key Results entweder prozentual oder mit farblichen oder symbolischen Abstufungen bewertet, die es ermöglichen, das weitere Vorgehen genauer zu bestimmen.\n\nWar der angesetzte Zeitraum zu kurz? Das Ziel zu hoch gesteckt? Oder konnte das Ziel zu diesem Zeitpunkt grundsätzlich nicht erreicht werden? Diese Fragen werden im Grading beantwortet, um anschließend neue OKRs zu setzen.\n\nAuch bei Stretch Objectives kann Grading zur Anwendung kommen. Waren die 10 Millionen Chrome-Nutzer nach Ende des ersten Geschäftsjahres ein Triumph trotz Zielverfehlung - oder eben doch ein Misserfolg? Grading kann helfen, hier zu zufriedenstellenden Einschätzungen zu gelangen.\n\n## OKRs: Eine Vorlage\n\nUm mit OKRs zu arbeiten, brauchst du keinen Kurs zu belegen. Die Methode ist so intuitiv, dass du im Grunde genommen sofort damit anfangen kannst.\n\nDas Festlegen von OKR-Zielen wird den Meisten dabei noch recht leicht von der Hand gehen.\n\nEs hilft, als OKR Vorlage folgende Formulierung zu wählen:\n\n**„Wir werden [Ziel], gemessen in [Schlüsselergebnisse]”**\n\nDas mutet noch etwas abstrakt an. Anhand eines OKR-Beispiels wird dir aber recht schnell klar werden, wie so ein Satz konkret aussehen kann. Erinner dich daran, wie wir vorher beschrieben haben, wie Google den Chrome-Browser zum meistbenutzten der Welt machte. Sundair Pindai gab damals schlicht das folgende Objective aus:\n\n„Wir werden Chrome zum besten Browser machen ...”\n\nUnd das dazugehörige Key Result:\n\n„... gemessen an 20 Millionen Nutzern.”\n\n### Sind alle OKR-Ziele Stretch Objectives?\n\nGanz gewiss muss nicht bei jedem Objective gestretcht werden. Man kann sogar mit Recht behaupten, dass zu viel Stretching im wahrsten Sinne des Wortes die Organisation auf die Zerreißprobe stellen kann.\n\nWohl aber empfiehlt es sich, die OKR-Ziele so zu setzen, dass sie nicht „alltäglich” sind. Sie sollen eine Herausforderung darstellen und Zweifel an ihrer Erreichbarkeit immer gegeben sein.\n\nDiese Spannung ist ein wichtiger Aspekt dabei, dass OKRs Innovation und Motivation in deinem Unternehmen erhöhen. Sie fördern ein gesundes, mitarbeitergetriebenes Wachstum.\n\n## OKRs tracken\n\nAus diesem Beispiel geht hervor, dass die Key Results die eigentliche Herausforderung darstellen. Um beim Chrome-Beispiel zu bleiben: Dass die Nutzerzahlen wirklich der Maßstab für Qualität sind („der beste Browser”), ist nicht direkt ersichtlich.\n\nIm Zweifelsfall ergibt es Sinn, sich für solche unmittelbar fassbaren und einfach zu trackenden Werte zu entscheiden. Wenn sich auf dem Weg zum Ziel bessere Key Results offenbaren, ist es einfacher, diese anzupassen, als das ursprüngliche Ziel aufzugeben.\n\nSicher spielte für Sundar Pinchai eine Rolle, dass die Google-Geschäftsleitung nach seiner Überzeugungsarbeit den Browser-Krieg zur Chefsache gemacht und den „Sieg” zu einer strategischen Priorität erklärt hatte.\n\nDas eigentlich Entscheidende aber ist, dass Key Results auf Erfahrungswerten aufbauen und von den Teammitgliedern gesetzt werden, die eine kompetente Aussage über ihre Erreichbarkeit (oder Nichterreichbarkeit) machen können. Nur, wer die Key Results auf Daten aufbaut, kann erwarten, dass die Ergebnisse den Key Results entsprechen.\n\n## Wer ist für die Umsetzung der OKRs verantwortlich?\n\nBei Objectives and Key Results sind alle Teams sowohl für sich als auch kollektiv verantwortlich für das Erreichen oder Verfehlen der Ziele. Eine strenge „Kontrollinstanz” würde dem intrinsischen Charakter widersprechen.\n\nDennoch empfiehlt es sich, eine oder sogar zwei Personen in deiner Organisation damit zu beauftragen, den OKR-Prozess am Laufen und auf Kurs zu halten und gegebenenfalls sanft gegenzusteuern oder mit den Teams an allgemeinen Verbesserungen zu arbeiten.\n\nDies ist die Aufgabe des/der OKR Masters, gelegentlich auch „OKR Champion\" oder „OKR Coach\" genannt.\n\nDie Agile Heroes definieren in ihrem Artikel zum Thema OKR Master den/die OKR Master als „die Person im Unternehmen, die die Mitarbeiter(innen) dabei unterstützt, OKR bestmöglich zu verstehen und umzusetzen.”\n\nOKR Master sind in der Regel vor allem an der Erarbeitung und Kommunikation der OKRs beteiligt. Sie stoßen den Prozess an, halten sich aber danach zumeist eher im Hintergrund. Im Idealfall scheiden sie kurz nach Beginn des Projekts aus dem aktiven OKR-Prozess aus.\n\nGelegentlich wird noch der/die OKR-Botschafter(in) unterschieden (OKR Ambassador), die üblicherweise mit dem/der Teammanager(in) zusammenfällt. Sein/ihre Aufgabe besteht in der Koordination und Begleitung der praktischen Arbeit, der Beantwortung von Fragen und der Erstellung der abschließenden Auswertung. \n\n## Wie OKRs eine Eigendynamik entwickeln\n\nObjectives and Key Results ist keine Methode, die deiner derzeitigen Organisation gewaltsam übergestülpt wird. Sie ist auch kein Gegenmodell zu KPIs. Während KPIs sich auf die Leistungsbewertung konzentrieren, setzen OKRs einen Schritt vorher, bei der Zielsetzung selbst, an.\n\nDas Besondere an OKRs besteht darin, dass die Vorteile sich selbst verstärken und sich so zunehmend auf das gesamte Unternehmen und alle Prozesse auswirken:\n\nWeil OKRs Teams zu mehr Eigenengagement zwingen, entwickeln diese wiederum die Kompetenzen, um aus Eigeninitiative heraus selbst Ziele vorzuschlagen und umzusetzen.\nWeil OKRs die Zusammenarbeit zwischen Teams erfordern, stärken sie den inneren Zusammenhalt der Organisation. Dies wiederum erleichtert die zukünftige Zusammenarbeit.\nEine höhere intrinsische Arbeitsmotivation erlaubt die Umsetzung komplexerer, anspruchsvollerer OKR-Ziele, die wiederum eine höhere Motivation und Zufriedenheit bieten.\nWenn Tracking konsequent nur als Maßstab zur Zielerreichung genutzt wird und nicht zur Leistungsbeurteilung, spornt es alle Mitarbeiter(innen) zu vollem Einsatz an.\nTracking kann auch offenbaren, wo Optimierungsbedarf besteht, was wiederum die Arbeit mit OKRs erleichtert.\nErfolgreich absolvierte Objectives oder auch annähernd erreichte Stretch Objectives können als Erfolg aller Mitarbeiter eines Projekts, nicht nur der unmittelbar Verantwortlichen, gefeiert werden.\n\n## OKRs: FAQs\n\n### Sind OKRs Teil des agilen Managements?\n\nObjectives and Key Results sind auf jeden Fall eng mit den Prinzipien agilen Managements verbunden.\n\nHierfür spricht unter anderem, dass OKRs stets objektiv messbar sein müssen und bei dieser Methode großer Wert auf Feedback-Schleifen, regelmäßige Meetings und Teamarbeit gelegt wird.\n\nAus diesem Grund finden OKRs in ähnlichen Branchen und Unternehmen Anwendung wie agiles Management – unter anderem auch im IT-Bereich sowie in der Softwareentwicklung.\n\n### Kann ich OKRs mit Gitlab nutzen?\n\nBei GitLab sind wir von den Konzepten und Erfolgen von OKRs überzeugt. Deswegen arbeiten wir daran, dass du mit OKRs auch in GitLab arbeiten kannst.\n\nDas Projekt befindet sich aktuell noch in einer experimentellen Phase, ist aber durchaus praktisch anwendbar.\n\nMehr Informationen dazu findest du in unserem ausführlichen Artikel zu GitLab und OKRs (Englisch), in dem wir alle Schritte zur Umsetzung genau erklären.\n\n### Sind OKR dasselbe wie Management by Objectives?\n\nZwischen OKR und MBO (Management by Objectives) besteht ein enger Zusammenhang. Historisch sind Objectives & Key Results, wie die ähnliche Begrifflichkeit bereits nahelegt, aus MBO hervorgegangen.\n\nSo kann man Objectives and Key Results als Erweiterung und Neuausrichtung des in den 1950ern entwickelten Management by Objectives betrachten. Während MBO den Prozess genau vorgibt, tendenziell in langen Zyklen denkt, Outputs vorgibt und streng von einer Top-Down-Hierarchie ausgeht, fordert und fördert der OKR-Prozess kürzere Zyklen, Outcome statt Output und die Nutzung sowohl von Top-Down- als auch Bottom-Up-Flüssen.\n\nKurz gesagt: OKR ist die Umsetzung von MBO in einem Agile-Management-Framework.\n\n### Ist für die Einführung von OKRs ein Training erforderlich?\n\nEs wird gelegentlich gefordert, dass die Einführung von OKRs in einem Unternehmen über einen Sponsor und unter Begleitung von Trainern stattfindet.\n\nWir meinen: Tatsächlich empfiehlt sich die Unterstützung des OKR-Prozesses durch eine erfahrene Coaching-Persönlichkeit. Dies sollte sich aber nicht auf die Ersteinführung beschränken.\n\nEin OKR-Coach – auch OKR Master genannt – kann genau diese Aspekte begleiten und dazu beitragen, dass die verschiedenen Hierarchieebenen aufeinander abgestimmt werden und die Kommunikation der OKRs im Unternehmen stets offen, transparent und frei funktioniert.\n\nEin separates Training kann unter Umständen hilfreich sein, aber auch den Eindruck erwecken, dass OKRs ein komplexes Regelwerk beinhalten – was definitiv nicht der Fall ist.\n\n### Wie verhalten sich Objectives and Key Results zu Scrum oder Kanban?\n\nOKRs bilden eine Brücke zwischen verschiedenen agilen Management-Methoden.\n\nKPIs sind grundlegende, quantifizierbare Werte, welche ein Unternehmen selbst vorgibt. OKRs verbinden dieses Denken mit der praktischen Zielsetzungsebene und der Ausführung.\n\nAgile Führung mit OKRs kann sehr unkompliziert in einem Kanban-Board dargestellt werden. Weil Scrum selbst deutlich spezialisierter ist als Kanban, fallen die Unterschiede hier größer aus.\n\nWie die Computerwoche bemerkt, wird Scrum „meist in der Produktentwicklung eingesetzt, OKR dagegen findet überwiegend im gesamten Unternehmen Anwendung, die Produktentwicklung eingeschlossen.” Vielleicht gerade deswegen ergänzen sich die beiden geradezu optimal:\n\n„Zur Umsetzung von Zielen bedarf es mit rasch verändernden Anforderungen und Rahmenbedingungen einer iterativen und agilen Vorgehensweise. Hier kommt Scrum (oder ggf. Kanban) ins Spiel und ergänzt damit OKR ideal. Scrum (bzw. Kanban) unterstützt die operative Ausführung der Aufgaben, hilft bei der iterativen Umsetzung von Projekten und Aufgaben und trägt damit zum Fortschritt der Key Results bei.”\n\n### Erfordern OKRs eine ausführliche Dokumentation?\n\nNein. Viele Unternehmen verlangen, dass im Rahmen von Objectives and Key Results ausführlich der gesamte Prozess beobachtet wird und am Ende eines jeden Zyklus die Ergebnisse in einem Report zusammengefasst und analysiert werden.\n\nDies steht aber eher im Widerspruch zu der agilen Philosophie hinter dem Konzept.\n\nRichtig ist vielmehr: OKRs legen großen Wert auf Empirismus und Daten – aber nur die Daten, die zu Anfang als Key Results definiert wurden. Alles, was darüber hinausgeht, macht den OKR-Prozess weniger effizient und sollte deswegen auf ein Minimum beschränkt werden.\n\n### Sollen die Objectives bei OKRs gar nicht erreicht werden?\n\nDies ist ein durchaus beliebtes Missverständnis. Tatsächlich meinen viele, OKRs gäben vor, dass die Ziele so formuliert und die Key Results so gesetzt würden, dass sie innerhalb eines Zyklus überhaupt nicht erreicht werden könnten.\n\nEs stimmt, dass Objectives and Key Results Stretching als Motivationsmittel und ganz generell Zielvorgaben empfehlen, die über das zu Erwartende hinausgehen. Die meisten OKR-Ziele aber sind „lediglich” committed und sollen sehr wohl erfüllt werden – und zwar zu 100 %.\n\nStretching ist keine Anleitung dazu, das Unmögliche zu fordern, sondern ein Instrument, alle Mitarbeiter(innen) zu Höchstleistungen zu inspirieren und sich anschließend auch dann an dem Geleisteten zu erfreuen, wenn das Ziel knapp verfehlt wurde.\n\nDies betont erneut, wie wichtig es ist, dass die Key Results auf praktischen Erfahrungen beruhen und kein theoretisches Konstrukt bleiben.\n",[822],"collaboration",{"slug":824,"featured":6,"template":796},"what-are-okrs",{"category":679,"slug":683,"posts":826},[827,840,853],{"content":828,"config":838},{"tags":829,"category":683,"date":831,"heroImage":832,"authors":833,"description":835,"title":836,"body":837},[830,764,808,742],"AI/ML","2025-07-17","https://res.cloudinary.com/about-gitlab-com/image/upload/v1752678395/impw8no5tbskr6k2afgu.jpg",[834],"Bill Staples","Entwicklerteams und KI-Agenten arbeiten erstmals Hand in Hand – parallel, intelligent, orchestriert.","GitLab Duo Agent Platform jetzt in Public Beta: KI-Orchestrierung der nächsten Generation","**Das ist die Zukunft der Software-Entwicklung.**\n\nBei GitLab [gestalten wir die Zukunft der Software-Entwicklung neu](https://about.gitlab.com/de-de/blog/gitlab-duo-agent-platform-what-is-next-for-intelligent-devsecops/) als Zusammenarbeit zwischen Menschen und KI. Entwickler(innen) konzentrieren sich auf die Lösung technischer, komplexer Probleme und treiben Innovationen voran, während KI-Agenten die routinemäßigen, sich wiederholenden Aufgaben übernehmen, die den Fortschritt verlangsamen. Entwickler(innen) sind frei, neue Ideen im Code zu deutlich geringeren Kosten zu erkunden, Bug-Backlogs gehören der Vergangenheit an, und die Nutzer(innen) der von dir erstellten Software genießen eine benutzerfreundlichere, zuverlässigere und sicherere Erfahrung. Das ist kein ferner Traum. Wir bauen diese Realität schon heute. Sie heißt GitLab Duo Agent Platform.\n\n## Was ist GitLab Duo Agent Platform?\n\nGitLab Duo Agent Platform ist unsere DevSecOps-Orchestrierungsplattform der nächsten Generation, welche entwickelt wurde, um die asynchrone Zusammenarbeit zwischen Entwickler(innen) und KI-Agenten zu ermöglichen. Sie wird deinen Entwicklungsworkflow von isolierten linearen Prozessen in eine dynamische Zusammenarbeit verwandeln, bei der spezialisierte KI-Agenten in jeder Phase des Software-Entwicklungslebenszyklus an deiner Seite und mit deinem Team arbeiten. Es wird so sein, als hättest du ein unbegrenztes Team von Kolleg(inn)en zur Verfügung.\n\nStell dir vor, du delegierst eine komplexe Refaktorierungsaufgabe an einen Software-Entwickler-Agenten, während gleichzeitig ein Sicherheitsanalyse-Agent nach Schwachstellen sucht und ein Deep-Research-Agent den Fortschritt über deine Repository-Historie hinweg analysiert. All dies geschieht parallel, nahtlos orchestriert innerhalb von GitLab.\n\nHeute kündigen wir die Einführung der [ersten Public Beta von GitLab Duo Agent Platform](https://about.gitlab.com/de-de/gitlab-duo/agent-platform/) für GitLab.com und selbstverwaltete GitLab Premium- und Ultimate-Kund(inn)en an. Dies ist nur die erste einer Reihe von Updates, die verbessern werden, wie Software geplant, erstellt, verifiziert und bereitgestellt wird, während wir menschlichen Einfallsreichtum durch intelligente Automatisierung verstärken.\n\nDiese erste Beta konzentriert sich auf die Freischaltung der IDE-Erfahrung über die GitLab VS Code-Erweiterung und das JetBrains IDEs-Plugin; nächsten Monat planen wir, die Duo Agent Platform-Erfahrung in die GitLab-Anwendung zu bringen und unsere IDE-Unterstützung zu erweitern. \n\nLass mich ein wenig mehr über unsere Vision für die Roadmap von heute bis zur allgemeinen Verfügbarkeit, die für später in diesem Jahr geplant ist, berichten. Details zur ersten Beta findest du unten.\n\nSchau dir dieses Video an oder lies weiter, um zu erfahren, was jetzt verfügbar ist und was demnächst kommen wird. Wenn du dann bereit bist, mit Duo Agent Platform zu arbeiten, [erfährst du hier, wie das mit der Public Beta geht](#get-started-now).\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101993507?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Agent Platform Beta Launch_071625_MP_v2\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## GitLabs einzigartige Position als Orchestrierungsplattform\n\nGitLab steht im Mittelpunkt des Entwicklungslebenszyklus als System of Record für Engineering-Teams und orchestriert die gesamte Reise vom Konzept zur Produktion für über 50 Millionen registrierte Nutzer(innen), einschließlich der Hälfte der Fortune 500 über alle Geografien hinweg. Dies umfasst über 10.000 zahlende Kund(inn)en in allen Segmenten und Branchen, einschließlich öffentlicher Institutionen.\n\nDies gibt GitLab etwas, was kein Wettbewerber bieten kann: ein umfassendes Verständnis von allem, was es braucht, um Software zu liefern. Wir bringen deine Projektpläne, Code, Testläufe, Sicherheitsscans, Compliance-Prüfungen und CI/CD-Konfigurationen zusammen, um nicht nur dein Team zu unterstützen, sondern auch die Zusammenarbeit mit KI-Agenten zu orchestrieren, die du kontrollierst.\n\nAls intelligente, einheitliche DevSecOps-Plattform speichert GitLab den gesamten Kontext deiner Software-Engineering-Praxis an einem Ort. Wir werden diese einheitlichen Daten über unseren Knowledge Graph KI-Agenten zugänglich machen. Jeder Agent, den wir erstellen, hat automatischen Zugriff auf diesen SDLC-verbundenen Datensatz und bietet einen reichhaltigen Kontext, sodass Agenten fundierte Empfehlungen abgeben und Maßnahmen ergreifen können, die deinen organisatorischen Standards entsprechen.\n\n**Hier ist ein Beispiel für diesen Vorteil in Aktion.** Hast du jemals versucht herauszufinden, wie genau ein Projekt über Dutzende, wenn nicht Hunderte von Stories und Issues verläuft, die von allen beteiligten Entwickler(inne)n bearbeitet werden? Unser Deep Research Agent nutzt den GitLab Knowledge Graph und semantische Suchfunktionen, um dein Epic und alle damit verbundenen Issues zu durchsuchen, die zugehörige Codebasis und den umgebenden Kontext zu erkunden. Er korreliert schnell Informationen über deine Repositories, Merge Requests und Deployment-Historie hinweg. Dies liefert kritische Einblicke, die eigenständige Tools nicht bieten können und die menschliche Entwickler(innen) Stunden kosten würden, um sie zu entdecken.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101998114?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Deep Research Demo_071625_MP_v1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n## Unsere strategische Entwicklung von KI-Features zur Agenten-Orchestrierung\n\nGitLab Duo begann als Add-on, das generative KI zu Entwickler(inne)n über Duo Pro und Enterprise brachte. Mit GitLab 18.0 ist es jetzt in die Plattform integriert. Wir haben [Duo Agentic Chat](https://about.gitlab.com/de-de/blog/gitlab-duo-chat-gets-agentic-ai-makeover/) und Code Suggestions für alle Premium- und Ultimate-Nutzer(innen) freigeschaltet, und jetzt bieten wir sofortigen Zugang zu Duo Agent Platform.\n\nWir haben die Engineering-Investitionen erhöht und beschleunigen die Bereitstellung, wobei jeden Monat leistungsstarke neue KI-Features landen. Aber wir bauen nicht nur einen weiteren Coding-Assistenten. GitLab Duo wird zu einer Agenten-Orchestrierungsplattform, auf der du KI-Agenten erstellen, anpassen und bereitstellen kannst, die an deiner Seite arbeiten und problemlos mit anderen Systemen interoperieren, was die Produktivität dramatisch steigert.\n\n> **„GitLab Duo Agent Platform verbessert unseren Entwicklungsworkflow mit KI, die unsere Codebasis und unsere Organisation wirklich versteht. GitLab Duo KI-Agenten in unserem System of Record für Code, Tests, CI/CD und den gesamten Software-Entwicklungslebenszyklus eingebettet zu haben, steigert Produktivität, Geschwindigkeit und Effizienz. Die Agenten sind zu echten Mitarbeitern unserer Teams geworden, und ihre Fähigkeit, Absichten zu verstehen, Probleme zu zerlegen und Maßnahmen zu ergreifen, befreit unsere Entwickler(innen), sich den aufregenden, innovativen Arbeiten zu widmen, die sie lieben.\"** - Bal Kang, Engineering Platform Lead bei NatWest\n\n### Agenten, die sofort funktionieren\n\nWir führen Agenten ein, die vertraute Teamrollen widerspiegeln. Diese Agenten können in GitLab suchen, lesen, erstellen und vorhandene Artefakte ändern. Denk an diese als Agenten, mit denen du einzeln interagieren kannst, die auch als Bausteine fungieren, die du anpassen kannst, um deine eigenen Agenten zu erstellen. Wie deine Teammitglieder haben Agenten definierte Spezialisierungen, wie Softwareentwicklung, Testen oder technisches Schreiben. Als Spezialisten nutzen sie den richtigen Kontext und die richtigen Tools, um konsequent die gleichen Arten von Aufgaben zu erledigen, wo immer sie eingesetzt werden.\n\nHier sind einige der Agenten, die wir heute bauen:\n\n* **Chat-Agent (jetzt in Beta):** Nimmt Anfragen in natürlicher Sprache entgegen, um dem Nutzer Informationen und Kontext bereitzustellen. Kann allgemeine Entwicklungsaufgaben ausführen, wie das Lesen von Issues oder Code-Diffs. Als Beispiel kannst du Chat bitten, einen fehlgeschlagenen Job zu debuggen, indem du die Job-URL bereitstellst.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953504?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-in-web-ui-demo_Update V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n* **Software-Entwickler-Agent (jetzt in Beta):** Arbeitet an zugewiesenen Elementen, indem er Code-Änderungen in virtuellen Entwicklungsumgebungen erstellt und Merge Requests zur Überprüfung öffnet.\n* **Produktplanungs-Agent:** Priorisiert Produkt-Backlogs, weist Arbeitselemente menschlichen und agentischen Teammitgliedern zu und liefert Projekt-Updates über festgelegte Zeiträume.\n* **Software-Test-Ingenieur-Agent:** Testet neue Code-Beiträge auf Bugs und validiert, ob gemeldete Probleme gelöst wurden.\n* **Code-Review-Agent:** Führt Code-Reviews nach Teamstandards durch, identifiziert Qualitäts- und Sicherheitsprobleme und kann Code mergen, wenn er bereit ist.\n* **Plattform-Ingenieur-Agent:** Überwacht GitLab-Deployments, einschließlich GitLab Runners, verfolgt die CI/CD-Pipeline-Gesundheit und meldet Performance-Probleme an menschliche Plattform-Engineering-Teams.\n* **Sicherheitsanalyse-Agent:** Findet Schwachstellen in Codebasen und bereitgestellten Anwendungen und implementiert Code- und Konfigurationsänderungen, um Sicherheitsschwächen zu beheben.\n* **Deployment-Ingenieur-Agent:** Stellt Updates in der Produktion bereit, überwacht ungewöhnliches Verhalten und macht Änderungen rückgängig, die sich auf die Anwendungsleistung oder -sicherheit auswirken.\n* **Deep-Research-Agent:** Führt umfassende, quellenübergreifende Analysen über dein gesamtes Entwicklungsökosystem durch.\n\nWas diese Agenten leistungsstark macht, ist ihr nativer Zugriff auf GitLabs umfassendes Toolkit. Heute haben wir über 25 Tools, von Issues und Epics bis zu Merge Requests und Dokumentation, mit mehr in Sicht. Im Gegensatz zu externen KI-Tools, die mit begrenztem Kontext arbeiten, arbeiten unsere Agenten als echte Teammitglieder mit vollständigen Plattformberechtigungen unter deiner Aufsicht.\n\nIn den kommenden Monaten wirst du auch in der Lage sein, diese Agenten zu modifizieren, um den Bedürfnissen deiner Organisation gerecht zu werden. Zum Beispiel wirst du spezifizieren können, dass ein Software-Test-Ingenieur-Agent Best Practices für ein bestimmtes Framework oder eine bestimmte Methodik befolgt, seine Spezialisierung vertieft und ihn zu einem noch wertvolleren Teammitglied macht.\n\n## Flows orchestrieren komplexe Agenten-Aufgaben\n\nZusätzlich zu einzelnen Agenten führen wir Agenten-Flows ein. Betrachte diese als komplexere Workflows, die mehrere Agenten mit vorgefertigten Anweisungen, Schritten und Aktionen für eine bestimmte Aufgabe umfassen können, die autonom ausgeführt werden kann.\n\nWährend du Flows für grundlegende Aufgaben erstellen kannst, die für Einzelpersonen üblich sind, brillieren sie wirklich, wenn sie auf komplexe, spezialisierte Aufgaben angewendet werden, die normalerweise Stunden an Koordination und Aufwand erfordern würden. Flows helfen dir, komplexe Aufgaben schneller zu erledigen und in vielen Fällen asynchron ohne menschliche Intervention.\n\nFlows haben spezifische Trigger für die Ausführung. Jeder Flow enthält eine Reihe von Schritten, und jeder Schritt hat detaillierte Anweisungen, die einem spezialisierten Agenten sagen, was zu tun ist. Dieser granulare Ansatz ermöglicht es dir, den Agenten im Flow präzise Anweisungen zu geben. Durch die Definition von Anweisungen mit mehr Details und die Einrichtung strukturierter Entscheidungspunkte können Flows helfen, die inhärente Variabilität in KI-Antworten zu lösen und gleichzeitig die Notwendigkeit zu eliminieren, wiederholt die gleichen Anforderungen zu spezifizieren, was konsistentere und vorhersagbarere Ergebnisse ohne Benutzerkonfiguration freischaltet.\n\nHier sind einige Beispiele für sofort einsatzbereite Flows, die wir bauen:\n\n**Software-Entwicklungs-Flow (jetzt in Beta):** Orchestriert mehrere Agenten, um Code-Änderungen End-to-End zu planen, zu implementieren und zu testen, und hilft dabei zu transformieren, wie Teams Features vom Konzept zur Produktion liefern.\n\n**Issue-to-MR-Flow:** Konvertiert automatisch Issues in umsetzbare Merge Requests, indem Agenten koordiniert werden, um Anforderungen zu analysieren, umfassende Implementierungspläne vorzubereiten und Code zu generieren.\n\n**CI-Datei-Konvertierungs-Flow:** Vereinfacht Migrations-Workflows, indem Agenten bestehende CI/CD-Konfigurationen analysieren und sie intelligent in das GitLab CI-Format mit vollständiger Pipeline-Kompatibilität konvertieren.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101941425?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jenkins-to-gitlab-cicd-for-blog\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cp>\u003C/p>\n\n**Such- und Ersetzungs-Flow:** Entdeckt und transformiert Code-Muster über Codebasen hinweg, indem Projektstrukturen systematisch analysiert, Optimierungsmöglichkeiten identifiziert und präzise Ersetzungen ausgeführt werden.\n\n**Incident-Response- und Root-Cause-Analyse-Flow:** Orchestriert die Incident-Response durch Korrelation von Systemdaten, Koordination spezialisierter Agenten für die Root-Cause-Analyse und Ausführung genehmigter Abhilfemaßnahmen, während menschliche Stakeholder während des gesamten Lösungsprozesses informiert bleiben.\n\nHier verfolgt GitLab Duo Agent Platform einen wirklich einzigartigen Ansatz im Vergleich zu anderen KI-Lösungen. Wir geben dir nicht nur vorgefertigte Agenten. Wir geben dir auch die Möglichkeit, Agenten-Flows zu erstellen, anzupassen und zu teilen, die perfekt zu deinen individuellen und organisatorischen Bedürfnissen passen. Und mit Flows kannst du dann Agenten einen spezifischen Ausführungsplan für allgemeine und komplexe Aufgaben geben.\n\nWir glauben, dass dieser Ansatz leistungsstärker ist als spezialisierte Agenten zu bauen, wie es unsere Wettbewerber tun, denn jede Organisation hat unterschiedliche Workflows, Codierungsstandards, Sicherheitsanforderungen und Geschäftslogik. Generische KI-Tools können deinen spezifischen Kontext nicht verstehen, aber GitLab Duo Agent Platform wird so angepasst werden können, dass sie genau so funktioniert, wie dein Team arbeitet.\n\n## Warum Agenten und Agenten-Flows in GitLab Duo Agent Platform bauen?\n\n**Es geht schnell.** Du kannst Agenten und komplexe Agenten-Flows in Duo Agent Platform schnell und einfach mit einem schnellen, deklarativen Erweiterbarkeitsmodell und UI-Unterstützung erstellen.\n\n**Integrierte Rechenleistung.** Mit Duo Agent Platform musst du dich nicht mehr um den Aufwand kümmern, deine eigene Infrastruktur für Agenten aufzubauen: Rechenleistung, Netzwerk und Speicher sind alle integriert.\n\n**SDLC-Events.** Deine Agenten können automatisch bei gängigen Ereignissen aufgerufen werden: defekte Pipeline, fehlgeschlagenes Deployment, erstelltes Issue usw.\n\n**Sofortiger Zugriff.** Du kannst mit deinen Agenten überall in GitLab oder unserem IDE-Plugin interagieren: weise ihnen Issues zu, @erwähne sie in Kommentaren und chatte mit ihnen überall, wo Duo Chat verfügbar ist.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1102029239?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"assigning an agent an issue\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script> \u003Cp>\u003C/p>\n\n**Unterstützung integrierter und benutzerdefinierter Modelle.** Deine Agenten haben automatischen Zugriff auf alle von uns unterstützten Modelle, und Nutzer(innen) können spezifische Modelle für spezifische Aufgaben auswählen. Wenn du Duo Agent Platform mit deinem eigenen selbst gehosteten Modell verbinden möchtest, kannst du das auch tun!\n\n**Model Context Protocol (MCP) Endpunkte.** Jeder Agent und Flow kann über native MCP-Endpunkte aufgerufen oder ausgelöst werden, sodass du dich von überall aus mit deinen Agenten und Flows verbinden und zusammenarbeiten kannst, einschließlich beliebter Tools wie Claude Code, Cursor, Copilot und Windsurf.\n\n**Observability und Sicherheit.** Schließlich bieten wir integrierte Observability und Nutzungs-Dashboards, damit du genau sehen kannst, wer, wo, was und wann Agenten in deinem Namen Aktionen durchgeführt haben.\n\n## Eine von der Community getriebene Zukunft\n\nCommunity-Beiträge haben lange Zeit GitLabs Innovation und Softwareentwicklung angetrieben. Wir freuen uns, mit unserer Community bei der Einführung des KI-Katalogs zusammenzuarbeiten. Der KI-Katalog ermöglicht es dir, Agenten und Flows innerhalb deiner Organisation und im gesamten GitLab-Ökosystem in unserer kommenden Beta zu erstellen und zu teilen.\n\nWir glauben, dass die wertvollsten KI-Anwendungen wahrscheinlich von dir, unserer Community, entstehen werden, dank deiner täglichen Anwendung von GitLab Duo Agent Platform zur Lösung zahlreicher realer Anwendungsfälle. Durch die Ermöglichung des nahtlosen Teilens von Agenten und Flows schaffen wir einen Netzwerkeffekt, bei dem jeder Beitrag die kollektive Intelligenz und den Wert der Plattform erhöht. Im Laufe der Zeit glauben wir, dass die wertvollsten Anwendungsfälle von Agent Platform aus unserer florierenden GitLab-Community kommen werden.\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685501/awdwx08udwrxgvcpmssb.png \"AI Catalog\")\n\n## Heute verfügbar in GitLab Duo Agent Platform in Public Beta\n\nDie Public Beta von GitLab Duo Agent Platform ist jetzt für Premium- und Ultimate-Kund(inn)en mit diesen Funktionen verfügbar:\n\n**Software-Entwicklungs-Flow:** Unser erster Flow orchestriert Agenten beim Sammeln umfassenden Kontexts, beim Klären von Unklarheiten mit menschlichen Entwickler(inne)n und beim Ausführen strategischer Pläne, um präzise Änderungen an deiner Codebasis und deinem Repository vorzunehmen. Er nutzt dein gesamtes Projekt, einschließlich seiner Struktur, Codebasis und Historie, zusammen mit zusätzlichem Kontext wie GitLab-Issues oder Merge Requests, um die Produktivität der Entwickler(innen) zu steigern.\n\n**Neue verfügbare Agenten-Tools:** Agenten haben jetzt Zugriff auf mehrere Tools, um ihre Arbeit zu erledigen, darunter:\n\n* Dateisystem (Lesen, Erstellen, Bearbeiten, Dateien finden, Auflisten, Grep)\n* Befehlszeile ausführen*\n* Issues (Auflisten, Abrufen, Kommentare abrufen, Bearbeiten*, Erstellen*, Kommentare hinzufügen/aktualisieren*)\n* Epics (Abrufen, Kommentare abrufen)\n* MR (Abrufen, Kommentare abrufen, Diff abrufen, Erstellen, Aktualisieren)\n* Pipeline (Job-Logs, Pipeline-Fehler)\n* Projekt (Abrufen, Datei abrufen)\n* Commits (Abrufen, Auflisten, Kommentare abrufen, Diff abrufen)\n* Suche (Issue-Suche)\n* Secure (Schwachstellen auflisten)\n* Dokumentationssuche\n  *=Erfordert Benutzergenehmigung\n\n**GitLab Duo Agentic Chat in der IDE:** Duo Agentic Chat verwandelt die Chat-Erfahrung von einem passiven Q&A-Tool in einen aktiven Entwicklungspartner direkt in deiner IDE.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101953477?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-ai-launch-video_Updated V1\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Iteratives Feedback und Chat-Verlauf:** Duo Agentic Chat unterstützt jetzt Chat-Verlauf und iteratives Feedback und verwandelt den Agenten in einen zustandsbehafteten, gesprächsfähigen Partner. Dies fördert Vertrauen und ermöglicht es Entwickler(inne)n, komplexere Aufgaben zu delegieren und korrigierende Anleitung zu bieten.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"agentic-chat-history\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Optimierte Delegation mit Slash-Befehlen:** Erweiterte, leistungsstärkere Slash-Befehle wie /explain, /tests und /include erstellen eine „Delegationssprache\" für schnelle und präzise Absichten. Der /include-Befehl ermöglicht die explizite Injektion von Kontext aus bestimmten Dateien, offenen Issues, Merge Requests oder Abhängigkeiten direkt in den Arbeitsspeicher des Agenten, macht den Agenten leistungsfähiger und lehrt Nutzer(innen), wie sie optimalen Kontext für qualitativ hochwertige Antworten bereitstellen.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743187?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"include-agentic-chat-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Personalisierung durch benutzerdefinierte Regeln:** Neue benutzerdefinierte Regeln ermöglichen es Entwickler(inne)n, das Agentenverhalten an individuelle und Teampräferenzen anzupassen, indem sie natürliche Sprache verwenden, zum Beispiel Entwicklungs-Styleguides. Dieser grundlegende Mechanismus formt die Persönlichkeit des Agenten zu einem personalisierten Assistenten und entwickelt sich zu spezialisierten Agenten basierend auf benutzerdefinierten Präferenzen und organisatorischen Richtlinien.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743179?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"custom-rules-with-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **Unterstützung für GitLab Duo Agentic Chat in JetBrains IDE:** Um Entwickler(innen) dort zu treffen, wo sie arbeiten, haben wir die Unterstützung von Duo Agentic Chat auf die JetBrains-Familie von IDEs erweitert, einschließlich IntelliJ, PyCharm, GoLand und Webstorm. Dies ergänzt unsere bestehende Unterstützung für VS Code. Bestehende Nutzer(innen) erhalten automatisch agentische Funktionen, während neue Nutzer(innen) das Plugin vom JetBrains Marketplace installieren können.\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743193?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"jetbrains-support-jc-voiceover\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **MCP-Client-Unterstützung:** Duo Agentic Chat kann jetzt als MCP-Client fungieren und sich mit remote und lokal laufenden MCP-Servern verbinden.\n\nDiese Fähigkeit ermöglicht es dem Agenten, sich mit Systemen jenseits von GitLab wie Jira, ServiceNow und ZenDesk zu verbinden, um Kontext zu sammeln oder Aktionen durchzuführen. Jeder Service, der sich über MCP exponiert, kann jetzt Teil des Skillsets des Agenten werden. Der offizielle GitLab MCP-Server kommt bald!\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1101743202?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"McpDemo\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n* **GitLab Duo Agentic Chat in der GitLab Web-UI.** Duo Agentic Chat ist jetzt auch direkt in der GitLab Web-UI verfügbar. Dieser entscheidende Schritt entwickelt den Agenten von einem Coding-Assistenten zu einem echten DevSecOps-Agenten, da er Zugriff auf reichhaltigen Nicht-Code-Kontext erhält, wie Issues und Merge-Request-Diskussionen, was es ihm ermöglicht, das „Warum\" hinter der Arbeit zu verstehen. Über das Verständnis des Kontexts hinaus kann der Agent Änderungen direkt aus der Web-UI vornehmen, wie z.B. automatisch Issue-Status aktualisieren oder Merge-Request-Beschreibungen bearbeiten.\n\n## Bald verfügbar in GitLab Duo Agent Platform\n\nIn den kommenden Wochen werden wir neue Funktionen für Duo Agent Platform veröffentlichen, einschließlich weiterer sofort einsatzbereiter Agenten und Flows. Diese werden die Plattform in die GitLab-Erfahrung bringen, die du heute liebst, und noch größere Anpassung und Erweiterbarkeit ermöglichen, was die Produktivität für unsere Kund(inn)en verstärkt:\n\n![GitLab Duo Agent Platform public beta roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685275/hjbe9iiu2ydp9slibsc2.png \"GitLab Duo Agent Platform public beta roadmap\")\n\n* **Integrierte GitLab-Erfahrung:** Aufbauend auf den in 18.2 verfügbaren IDE-Erweiterungen erweitern wir Agenten und Flows innerhalb der GitLab-Plattform. Diese tiefere Integration wird die Möglichkeiten erweitern, wie du synchron und asynchron mit Agenten zusammenarbeiten kannst. Du wirst in der Lage sein, Issues direkt an Agenten zuzuweisen, sie in GitLab Duo Chat zu @erwähnen und sie nahtlos von überall in der Anwendung aufzurufen, während die MCP-Konnektivität von deinem bevorzugten Entwicklungstool beibehalten wird. Diese native Integration verwandelt Agenten in echte Entwicklungsteammitglieder, die in ganz GitLab zugänglich sind.\n* **Agenten-Observability:** Da Agenten autonomer werden, bauen wir umfassende Sichtbarkeit in ihre Aktivität auf, während sie durch Flows fortschreiten, was es dir ermöglicht, ihre Entscheidungsprozesse zu überwachen, Ausführungsschritte zu verfolgen und zu verstehen, wie sie deine Entwicklungsherausforderungen interpretieren und darauf reagieren. Diese Transparenz im Agentenverhalten schafft Vertrauen und Zuversicht, während es dir ermöglicht, Workflows zu optimieren, Engpässe zu identifizieren und sicherzustellen, dass Agenten genau wie beabsichtigt funktionieren.\n* **KI-Katalog:** In Anerkennung der Tatsache, dass großartige Lösungen aus Community-Innovation entstehen, werden wir bald die Public Beta unseres KI-Katalogs einführen - ein Marktplatz, der es dir ermöglicht, Duo Agent Platform mit spezialisierten Agenten und Flows zu erweitern, die von GitLab und im Laufe der Zeit von der breiteren Community stammen. Du wirst in der Lage sein, diese Lösungen schnell in GitLab bereitzustellen und dabei den Kontext über deine Projekte und Codebasis hinweg zu nutzen.\n* **Knowledge Graph:** Unter Nutzung von GitLabs einzigartigem Vorteil als System of Record für Quellcode und seinen umgebenden Kontext bauen wir einen umfassenden Knowledge Graph auf, der nicht nur Dateien und Abhängigkeiten über die Codebasis hinweg abbildet, sondern diese Karte auch für Nutzer(innen) navigierbar macht, während KI-Abfragezeiten beschleunigt und die Genauigkeit erhöht wird. Diese Grundlage ermöglicht es GitLab Duo-Agenten, Beziehungen über deine gesamte Entwicklungsumgebung hinweg schnell zu verstehen, von Code-Abhängigkeiten bis zu Deployment-Mustern, und ermöglicht schnellere und präzisere Antworten auf komplexe Fragen.\n\n![GitLab Duo Agent Platform Knowledge Graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752685367/n0tvfgorchuhrronic3j.png \"GitLab Duo Agent Platform Knowledge Graph\")\n\n* **Agenten und Flows erstellen und bearbeiten:** Im Verständnis, dass jede Organisation einzigartige Workflows und Anforderungen hat, entwickeln wir leistungsstarke Funktionen zur Erstellung und Bearbeitung von Agenten und Flows, die eingeführt werden, wenn der KI-Katalog reift. Du wirst in der Lage sein, Agenten und Flows zu erstellen und zu modifizieren, damit sie genau so funktionieren, wie deine Organisation arbeitet, und eine tiefe Anpassung über Duo Agent Platform hinweg liefern, die qualitativ hochwertigere Ergebnisse und erhöhte Produktivität ermöglicht.\n\n![AI Catalog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752684938/fruwqcqvvrx8gmkz5u0v.png \"AI Catalog\")\n\n* **Offizieller GitLab MCP-Server:** In der Erkenntnis, dass Entwickler(innen) über mehrere Tools und Umgebungen hinweg arbeiten, bauen wir einen offiziellen GitLab MCP-Server, der es dir ermöglicht, über MCP auf alle deine Agenten und Flows zuzugreifen. Du wirst in der Lage sein, dich mit deinen Agenten und Flows von überall aus zu verbinden und zusammenzuarbeiten, wo MCP unterstützt wird, einschließlich beliebter Tools wie Claude Code, Cursor, Copilot und Windsurf, was eine nahtlose KI-Zusammenarbeit unabhängig von deiner bevorzugten Entwicklungsumgebung ermöglicht.\n* **GitLab Duo Agent Platform CLI:** Unsere kommende CLI ermöglicht es dir, Agenten aufzurufen und Flows auf der Befehlszeile auszulösen, wobei GitLabs reichhaltiger Kontext über den gesamten Software-Entwicklungslebenszyklus genutzt wird - von Code-Repositories und Merge Requests bis zu CI/CD-Pipelines und Issue-Tracking.\n\n## Jetzt loslegen\n\n* **GitLab Premium- und Ultimate-Kund(inn)en** in GitLab.com- und selbstverwalteten Umgebungen, die GitLab 18.2 verwenden, können Duo Agent Platform sofort nutzen (Beta- und experimentelle Funktionen für GitLab Duo [müssen aktiviert sein](https://docs.gitlab.com/user/gitlab_duo/turn_on_off/#turn-on-beta-and-experimental-features)).\n* Nutzer(innen) sollten die [VS Code-Erweiterung](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) oder das [JetBrains IDEs-Plugin](https://plugins.jetbrains.com/plugin/22857-gitlab) herunterladen und unserem [Leitfaden zur Verwendung von GitLab Duo Agentic Chat](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#use-agentic-chat) folgen, einschließlich der Duo Chat [Slash-Befehle](https://docs.gitlab.com/user/gitlab_duo_chat/examples/#gitlab-duo-chat-slash-commands).\n\n**Neu bei GitLab?** Jeder kann an unserer kommenden (englischsprachigen) [Technischen Demo teilnehmen, um GitLab Duo Agent Platform](https://page.gitlab.com/webcasts-jul16-gitlab-duo-agentic-ai-emea-amer.html) in Aktion zu sehen. Um GitLab Duo Agent Platform selbst praktisch zu erleben, melde dich noch heute für eine [kostenlose Testversion](https://gitlab.com/-/trials/new?glm_content=default-saas-trial&glm_source=about.gitlab.com%2Fsales%2F) an.\n\n\u003Csmall>*Dieser Blogbeitrag enthält „zukunftsgerichtete Aussagen\" im Sinne von Abschnitt 27A des Securities Act von 1933 in der geänderten Fassung und Abschnitt 21E des Securities Exchange Act von 1934. Obwohl wir glauben, dass die in den zukunftsgerichteten Aussagen in diesem Blogbeitrag zum Ausdruck gebrachten Erwartungen angemessen sind, unterliegen sie bekannten und unbekannten Risiken, Unsicherheiten, Annahmen und anderen Faktoren, die dazu führen können, dass die tatsächlichen Ergebnisse oder Resultate wesentlich von den in den zukunftsgerichteten Aussagen ausgedrückten oder implizierten zukünftigen Ergebnissen oder Resultaten abweichen.*\n\n*Weitere Informationen zu Risiken, Unsicherheiten und anderen Faktoren, die dazu führen könnten, dass die tatsächlichen Ergebnisse und Resultate wesentlich von den in den zukunftsgerichteten Aussagen in diesem Blogbeitrag enthaltenen oder betrachteten abweichen, finden sich unter der Überschrift „Risikofaktoren\" und an anderer Stelle in den Einreichungen und Berichten, die wir bei der Securities and Exchange Commission einreichen. Wir übernehmen keine Verpflichtung, zukunftsgerichtete Aussagen zu aktualisieren oder zu überarbeiten oder über Ereignisse oder Umstände nach dem Datum dieses Blogbeitrags zu berichten oder das Eintreten unvorhergesehener Ereignisse widerzuspiegeln, es sei denn, dies ist gesetzlich vorgeschrieben.*\u003C/small>",{"featured":91,"template":796,"slug":839},"gitlab-duo-agent-platform-public-beta",{"content":841,"config":851},{"heroImage":842,"body":843,"authors":844,"updatedDate":846,"date":847,"title":848,"tags":849,"description":850,"category":683},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","KI ist schnell zu einem Kernbestandteil der modernen Softwareentwicklung geworden. Sie hilft Entwickler(innen) nicht nur dabei, schneller als je zuvor zu programmieren, sondern automatisiert auch Low-Level-Aufgaben wie das Schreiben von Testfällen oder das Zusammenfassen von Dokumentationen. Laut unserer [2024 Global DevSecOps Survey](https://about.gitlab.com/de-de/developer-survey/) nutzen bereits 81 % der Entwickler(innen) KI in ihren Workflows oder planen dies in den nächsten zwei Jahren.\n\nDa Code mit weniger manuellem Aufwand geschrieben wird, beobachten wir eine subtile, aber wichtige Verhaltensänderung: Entwickler(innen) beginnen, KI-generiertem Code mit weniger Prüfung zu vertrauen. Dieses Vertrauen – so verständlich es auch sein mag – kann stillschweigend Sicherheitsrisiken einführen, insbesondere wenn das Gesamtvolumen des Codes zunimmt. \n\nVon Entwickler(innen) kann nicht erwartet werden, dass sie über jede Schwachstelle oder jeden Exploit auf dem Laufenden bleiben. Deshalb brauchen wir Systeme und Sicherheitsvorkehrungen, die mit ihnen skalieren. KI-Tools sind gekommen, um zu bleiben. Als Sicherheitsexperten ist es daher die Pflicht, Entwickler(innen) zu befähigen, diese so zu übernehmen, dass sowohl Geschwindigkeit als auch Sicherheit verbessert werden.\n\nHier sind drei praktische Wege, dies zu erreichen.\n\n## Niemals vertrauen, immer verifizieren\n\nWie bereits erwähnt, beginnen Entwickler(innen), KI-generiertem Code bereitwilliger zu vertrauen, besonders wenn er sauber aussieht und fehlerfrei kompiliert. Um dem entgegenzuwirken, sollte eine Zero-Trust-Mentalität angenommen werden. Während oft über [Zero Trust (englischsprachiger Artikel)](https://about.gitlab.com/blog/why-devops-and-zero-trust-go-together/) im Kontext von Identitäts- und Zugriffsmanagement gesprochen wird, kann dasselbe Prinzip hier mit einem etwas anderen Rahmen angewendet werden. KI-generierten Code wie Input von einem Junior-Entwickler behandeln: hilfreich, aber nicht produktionsreif ohne ordnungsgemäße Überprüfung.\n\nEntwickler(innen) sollten erklären können, was der Code tut und warum er sicher ist, bevor er gemergt wird. Die Überprüfung von KI-generiertem Code könnte sich sogar als eine aufkommende Fähigkeit herausstellen, die in der Welt der Softwareentwicklung erforderlich ist. Die Entwickler(innen), die darin sehr gut sind, werden unverzichtbar sein, weil sie die Geschwindigkeit von LLMs mit der Denkweise zur Risikominderung verbinden, um sicheren Code schneller zu produzieren.\n\nHier können Tools wie [GitLab Duo Code Review (englischsprachiger Artikel)](https://docs.gitlab.com/user/project/merge_requests/duo_in_merge_requests/) helfen. Als Feature unseres KI-Begleiters über den gesamten Softwareentwicklungszyklus hinweg bringt es KI in den Code-Review-Prozess – nicht um menschliches Urteilsvermögen zu ersetzen, sondern um es zu verbessern. Durch das Aufzeigen von Fragen, Inkonsistenzen und übersehenen Problemen in den Merge Requests kann KI Entwickler(innen) dabei helfen, mit genau der KI Schritt zu halten, die Entwicklungszyklen beschleunigt.\n\n## Prompts für sichere Muster\n\nLarge Language Models [LLMs (englischsprachiger Artikel)](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) sind leistungsfähig, aber nur so präzise wie die ihnen gegebenen Prompts. Deshalb wird Prompt Engineering zu einem Kernbestandteil der Arbeit mit KI-Tools. In der Welt der LLMs *ist* die Eingabe die Schnittstelle. Entwickler(innen), die lernen, klare, sicherheitsbewusste Prompts zu schreiben, werden eine Schlüsselrolle beim Aufbau sichererer Software von Anfang an spielen.\n\nBeispielsweise führen vage Anfragen wie „baue ein Login-Formular\" oft zu unsicheren oder zu vereinfachten Ergebnissen. Durch die Einbeziehung von mehr Kontext, wie „baue ein Login-Formular **mit** Eingabevalidierung, Rate Limiting und Hashing, **und** unterstütze Phishing-resistente Authentifizierungsmethoden wie Passkeys\", ist es wahrscheinlicher, dass eine Ausgabe produziert wird, die den Sicherheitsstandards der Organisation entspricht.\n\nAktuelle [Forschung (englischsprachiger Artikel)](https://www.backslash.security/press-releases/backslash-security-reveals-in-new-research-that-gpt-4-1-other-popular-llms-generate-insecure-code-unless-explicitly-prompted) von Backlash Security unterstützt dies. Hiernach verbessere sicheres Prompting die Ergebnisse bei beliebten LLMs. Wenn Entwickler(innen) die Modelle einfach baten, „sicheren Code zu schreiben\", blieben die Erfolgsraten niedrig. Wenn jedoch Prompts auf [OWASP Best Practices (englischsprachiger Artikel)](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) verwiesen, stieg die Rate der sicheren Code-Generierung.\n\nPrompt Engineering sollte Teil dessen sein, wie Security Champions innerhalb von Entwicklungsteams geschult und befähigt werden. Genau wie sichere Coding-Muster und Threat Modeling gelehrt werden, sollte Entwickler(innen) auch beigebracht werden, wie KI-Tools mit derselben Sicherheitsdenkweise geleitet werden.\n\n> Erfahre mehr mit diesen hilfreichen englischsprachigen [Prompt-Engineering-Tipps](https://docs.gitlab.com/development/ai_features/prompt_engineering/).\n\n## Alles scannen, keine Ausnahmen\n\nDer Aufstieg der KI bedeutet, dass mehr Code schneller mit der gleichen Anzahl von Menschen geschrieben wird. Diese Verschiebung sollte die Denkweise über Sicherheit ändern – nicht nur als abschließende Überprüfung, sondern als ständig aktive Schutzmaßnahme, die in jeden Aspekt des Entwicklungsprozesses eingewoben ist.\n\nMehr Code bedeutet eine größere Angriffsfläche. Und wenn dieser Code teilweise oder vollständig generiert ist, können wir uns nicht allein auf sichere Coding-Praktiken oder individuelle Intuition verlassen, um Risiken zu erkennen. Hier kommt automatisiertes Scannen ins Spiel. [Static Application Security Testing (SAST) (englischsprachiger Artikel)](https://docs.gitlab.com/user/application_security/sast/), [Software Composition Analysis (SCA) (englischsprachiger Artikel)](https://docs.gitlab.com/user/application_security/dependency_scanning/) und [Secret Detection (englischsprachiger Artikel)](https://docs.gitlab.com/user/application_security/secret_detection/) werden zu kritischen Kontrollen, um das Risiko von Secret Leaks, Supply-Chain-Angriffen und Schwachstellen wie SQL-Injections zu mindern. Mit Plattformen wie GitLab ist \\[Application Security] (englischsprachiger Artikel)(https://about.gitlab.com/solutions/security-compliance/) nativ in den Workflow der Entwickler(innen) integriert, was sie zu einem natürlichen Teil des Entwicklungslebenszyklus macht. Scanner können auch durch das gesamte Programm verfolgen, um sicherzustellen, dass neuer KI-generierter Code sicher ist *im Kontext des gesamten anderen Codes* – das kann schwer zu erkennen sein, wenn nur neuer Code in der IDE oder in einem KI-generierten Patch betrachtet wird.\n\nAber es geht nicht nur ums Scannen, es geht darum, Schritt zu halten. Wenn Entwicklungsteams mit der Geschwindigkeit der KI-unterstützten Entwicklung mithalten wollen, brauchen sie Scans, die schnell, genau und auf Skalierung ausgelegt sind. Genauigkeit ist besonders wichtig. Wenn Scanner Entwickler(innen) mit False Positives überwältigen, besteht das Risiko, das Vertrauen in das System insgesamt zu verlieren.\n\nDer einzige Weg, schnell zu agieren *und* sicher zu bleiben, ist, das Scannen nicht verhandelbar zu machen.\n\nJeder Commit. Jeder Branch. Keine Ausnahmen.\n\n## Sicherer KI-generierter Code mit GitLab\n\nKI verändert die Art und Weise, wie Software entwickelt wird, aber die Grundlagen der sicheren Softwareentwicklung gelten weiterhin. Code muss immer noch überprüft werden. Bedrohungen müssen immer noch getestet werden. Und Sicherheit muss immer noch in die Arbeitsweise eingebettet sein. Bei GitLab haben wir genau das getan.\n\nAls Entwicklerplattform schrauben wir Sicherheit nicht an den Workflow – wir betten sie direkt dort ein, wo Entwickler(innen) bereits arbeiten: in der IDE, in Merge Requests und in der Pipeline. Scans laufen automatisch und relevanter Sicherheitskontext wird angezeigt, um schnellere Behebungszyklen zu ermöglichen. Und da es Teil derselben Plattform ist, auf der Entwickler(innen) Software erstellen, testen und bereitstellen, gibt es weniger Tools zu jonglieren, weniger Kontextwechsel und einen viel reibungsloseren Weg zu sicherem Code.\n\nKI-Funktionen wie [Duo Vulnerability Explanation und Vulnerability Resolution](https://about.gitlab.com/de-de/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/) fügen eine weitere Ebene von Geschwindigkeit und Einblick hinzu und helfen Entwickler(innen), Risiken zu verstehen und sie schneller zu beheben, ohne ihren Flow zu unterbrechen.\n\nKI ist keine Abkürzung zur Sicherheit. Aber mit den richtigen Praktiken – und einer Plattform, die Entwickler(innen) dort abholt, wo sie sind – kann sie absolut Teil des Aufbaus von Software sein, die schnell, sicher und skalierbar ist.\n\n> Starte deine [kostenlose 60-tägige Testversion von GitLab Ultimate mit Duo Enterprise](https://about.gitlab.com/de-de/free-trial/) und erlebe, wie es ist, sichere Software schneller zu entwickeln. Mit nativer Sicherheitsprüfung, KI-gestützten Einblicken und einer nahtlosen Entwicklererfahrung hilft GitLab dabei, Sicherheit nach links zu verschieben, ohne zu verlangsamen.",[845],"Salman Ladha","2025-07-22","2025-07-10","3 Best Practices für die Softwareentwicklung im Zeitalter von LLMs",[830,775],"Da KI die Entwicklungsgeschwindigkeit transformiert, brauchen Entwickler(innen) neue Sicherheitsgewohnheiten. Erfahre, welche das sind und wie sie im DevSecOps-Workflow eingesetzt werden.",{"featured":91,"template":796,"slug":852},"3-best-practices-for-building-software-in-the-era-of-llms",{"content":854,"config":863},{"date":855,"authors":856,"heroImage":858,"body":859,"title":860,"description":861,"category":683,"updatedDate":862},"2025-07-08",[857],"Cesar Saavedra","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750096976/Blog/Hero%20Images/Blog/Hero%20Images/Screenshot%202024-11-27%20at%204.55.28%E2%80%AFPM_4VVz6DgGBOvbGY8BUmd068_1750096975734.png","Code Reviews sind wichtig, um Bugs zu finden, die Lesbarkeit des Codes zu verbessern und Programmierstandards einzuhalten, aber sie können auch zu einem großen Engpass in deinem Workflow führen. Wenn du versuchst, Features schnell zu veröffentlichen, kann es ziemlich frustrierend sein, auf andere Teammitglieder zu warten, die deinen Code überprüfen. Langwierige Diskussionen, Terminkonflikte und die Zeit, die es braucht, um alle Beteiligten auf einen Nenner zu bringen, können eine einfache Review über Tage oder sogar Wochen in die Länge ziehen.\n\nHier kommt [GitLab Duo mit Amazon Q](/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), unser neues Angebot, das AWS-Kund(inn)en agentenbasierte KI während des gesamten Software-Entwicklungsprozesses zur Verfügung stellt, ins Spiel, um deinen Review-Prozess zu transformieren.\n\nDiese intelligente, KI-gestützte Lösung kann umfassende Code Reviews für dich durchführen, und das in einem Bruchteil der Zeit, die deine menschlichen Kolleg(inn)en dafür benötigen würden. Durch die Nutzung fortschrittlicher agentischer KI-Funktionen optimiert GitLab Duo mit Amazon Q deinen gesamten Review-Workflow, ohne dass du dabei Abstriche bei der Qualität und Gründlichkeit machen musst. Stell dir vor, es gäbe jemanden, der immer zur Verfügung steht, deinen Code sofort analysiert und dir umsetzbares Feedback gibt.\n\n## So funktioniert’s: Einen Code Review starten\n\nWie funktioniert GitLab Duo mit Amazon Q eigentlich? Angenommen, du hast gerade die Arbeit an einem Feature abgeschlossen und einen Merge Request mit mehreren Code-Updates erstellt. Traditionell würdest du deine Teammitglieder anschreiben und auf ihre Verfügbarkeit warten. Mit GitLab Duo mit Amazon Q gibst du einfach einen kurzen Befehl in den Kommentarbereich ein: „/q review“. Das war’s – mit diesen beiden Worten tritt die KI in Aktion.\n\n![Auslösen einer Code Review mit GitLab Duo mit Amazon Q](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097002/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097002096.png)\n\nSobald du den Befehl eingegeben hast, beginnt der Amazon-Q-Service sofort mit der Analyse deiner Codeänderungen. Du erhältst eine Bestätigung, dass die Review läuft, und in kürzester Zeit prüft die KI jede Zeile deiner Änderungen auf mögliche Probleme in verschiedenen Bereichen.\n\nNach Abschluss der Review erhältst du ein umfassendes Feedback, das alle Bereiche abdeckt: Fehlererkennung, Verbesserungen der Lesbarkeit, Syntaxfehler und die Einhaltung der Programmierstandards deines Teams. Die KI weist nicht nur auf Probleme hin, sondern liefert auch den Kontext und Vorschläge für deren Behebung, sodass du leicht verstehen kannst, worauf du achten musst und warum.\n\nDas Schöne an diesem agentenbasierten KI-Ansatz ist, dass er dir die mühselige Arbeit der Code Review abnimmt, während du dich auf das konzentrieren kannst, was am wichtigsten ist: die Entwicklung großartiger Software.\n\nDu profitierst von den Vorteilen gründlicher Code Reviews – bessere Fehlererkennung, konsistente Programmierstandards und verbesserte Codequalität – ohne den Zeitaufwand. Deine Bereitstellungszeiten verkürzen sich drastisch, weil du nicht mehr in Review-Warteschlangen steckst, und dein gesamtes Team wird produktiver.\n\n## Warum solltest du GitLab Duo mit Amazon Q verwenden?\n\nGitLab Duo mit Amazon Q verändert deinen Entwicklungsworkflow auf folgende Weise:\n\n* Blitzschnelle Code Reviews, die keine Kompromisse bei der Qualität eingehen\n* Konsistente Anwendung von Programmierstandards in deiner gesamten Codebase\n* Sofortiges Feedback, das dir hilft, Fehler zu beheben, bevor sie in die Produktion gelangen\n* Kürzere Bereitstellungszeiten, damit du Funktionen schneller bereitstellen kannst\n* Mehr Zeit für dein Team, sich auf kreative Problemlösungen zu konzentrieren, statt auf sich wiederholende Reviews\n\nBist du bereit, diese neue Funktion in Aktion zu erleben? Sieh dir an, wie GitLab Duo mit Amazon Q deinen Code-Review-Prozess revolutionieren kann:\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure>\n\n\u003C!-- blank line -->\n\n> Besuche uns auf einem der bevorstehenden [AWS Summits in einer Stadt in deiner Nähe](https://about.gitlab.com/de-de/events/aws-summits/) oder [wende dich an deine(n) GitLab-Vertreter(in)](//about.gitlab.com/de-de/partners/technology-partners/aws/#form), um mehr über GitLab Duo mit Amazon Q zu erfahren.\n>\n> Und nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über unsere Pläne für agentische KI und mehr zu erfahren. [Registriere dich noch heute!](https://about.gitlab.com/de-de/eighteen/)","Von Tagen zu Sekunden: So revolutioniert /q review deine Code Reviews","Nutze KI-basierte Tools, um Code Reviews zu optimieren. Analysiere Merge Requests automatisch und erhalte Feedback zu Bugs, Lesbarkeit und Programmierstandards.","2025-07-11",{"featured":6,"template":796,"slug":864},"accelerate-code-reviews-with-gitlab-duo-and-amazon-q",{"category":691,"slug":695,"posts":866},[867],{"content":868,"config":878},{"title":869,"description":870,"authors":871,"heroImage":873,"date":874,"body":875,"category":695,"tags":876,"updatedDate":877},"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.",[872],"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,807],"2025-04-21",{"slug":879,"featured":91,"template":796},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":703,"slug":707,"posts":881},[882,898,912],{"content":883,"config":896},{"heroImage":884,"body":885,"authors":886,"updatedDate":888,"date":889,"title":890,"tags":891,"description":895,"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",[887],"Fatima Sarah Khalid","2025-02-07","2025-01-30","Das Co-Create-Programm: Wie Kund(inn)en zusammenarbeiten, um GitLab zu entwickeln",[892,893,894],"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":897,"featured":91,"template":796},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":899,"config":910},{"title":900,"description":901,"authors":902,"heroImage":904,"date":905,"body":906,"category":707,"tags":907,"updatedDate":909},"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.",[903],"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.**",[894,109,908,807],"user stories","2024-10-31",{"slug":911,"featured":91,"template":796},"how-indeed-transformed-its-ci-platform-with-gitlab",{"content":913,"config":925},{"title":914,"description":915,"authors":916,"heroImage":918,"date":919,"body":920,"category":707,"tags":921,"updatedDate":924},"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.",[917],"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",[922,923,830,894],"DevOps","DevOps platform","2024-12-11",{"slug":926,"featured":6,"template":796},"southwest-looking-to-help-developers-take-flight",{"category":715,"slug":719,"posts":928},[929,941,954],{"content":930,"config":939},{"heroImage":931,"body":932,"authors":933,"updatedDate":7,"date":935,"title":936,"tags":937,"description":938,"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/).",[934],"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":796,"slug":940},"why-now-is-the-time-for-embedded-devsecops",{"content":942,"config":952},{"heroImage":943,"body":944,"authors":945,"updatedDate":947,"date":948,"title":949,"tags":950,"description":951,"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/)",[946],"Itzik Gan Baruch","2025-06-23","2025-06-02","Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?",[715,807,764],"Erfahre mehr über die einheitliche DevSecOps-Plattform von GitLab, die Tools integriert, Sicherheit verbessert und KI für eine effiziente Softwareentwicklung nutzt.",{"slug":953,"featured":6,"template":796},"why-are-organizations-moving-to-a-unified-devsecops-platform",{"content":955,"config":965},{"title":956,"description":957,"authors":958,"heroImage":960,"date":961,"body":962,"category":719,"tags":963,"updatedDate":964},"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.",[959],"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 60 Tage lang kostenlos.",[109,715,807,809,775,764],"2025-05-08",{"slug":966,"featured":91,"template":796},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"category":727,"slug":731,"posts":968},[969,981,994],{"content":970,"config":979},{"title":971,"description":972,"authors":973,"heroImage":975,"date":976,"body":977,"category":731,"tags":978},"Hinter den Kulissen von GitLabs Healthy Backlog Initiative","Wie GitLab 65.000 Issues in strategische Features, schnelle Entwicklung und direkte Community-Kommunikation verwandelt.",[974],"Stan Hu","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","2025-07-23","Bei GitLab pflegen wir eine starke Partnerschaft mit unserer Community und ermutigen jeden zur aktiven Mitarbeit. Diese Beiträge haben die GitLab-Plattform über Jahre hinweg gestärkt. Doch mit unserem Wachstum stieg auch die Anzahl der Community-Issues - bis hin zu einem schwer handhabbaren Backlog von über 65.000 Einträgen.\n\nDie Produkt- und Engineering-Teams von GitLab haben kürzlich die [Healthy Backlog Initiative](https://gitlab.com/groups/gitlab-org/-/epics/18639) gestartet, um dieses Backlog anzugehen und unseren Ansatz für die Verwaltung beigetragener Issues in Zukunft zu verfeinern.\n\nIssues mit laufendem Community-Engagement, aktueller Aktivität oder klarer strategischer Ausrichtung bleiben offen. Wir werden Issues schließen, die nicht mehr relevant sind, kein Community-Interesse haben oder nicht mehr zu unserer aktuellen Produktausrichtung passen.\n\nDieser Fokus wird zu mehr Innovation, besserer Erwartungshaltung und schnelleren Entwicklungs- und Bereitstellungszyklen von der Community beigetragenen Funktionen führen.\n\n## Die Healthy Backlog Initiative: 65.000 Issues strategisch reduzieren\n\nIm Laufe der Zeit hat die GitLab-Community zahlreiche Issues eingereicht, darunter Bugs, Feature-Anfragen und Feedback-Elemente. Derzeit enthält der zentrale [GitLab-Issue-Tracker](https://gitlab.com/gitlab-org/gitlab/-/issues) über 65.000 Issues, von denen einige heute nicht mehr relevant sind, andere hingegen schon.\n\nUnsere Healthy Backlog Initiative wird das Backlog bereinigen und einen Arbeitsstrom für unsere Produkt- und Engineering-Teams etablieren, um einen fokussierteren Ansatz zur Backlog-Verwaltung umzusetzen. Sie werden wöchentliche Bewertungen des Backlogs durchführen, um sicherzustellen, dass wir Issues priorisieren, die mit unserer Produktstrategie und Roadmap übereinstimmen.\n\n**Hinweis:** Wenn du der Meinung bist, dass ein geschlossenes Issue mit GitLabs Produktstrategie und Roadmap übereinstimmt, oder wenn du aktiv an der Anfrage arbeitest, ermutigen wir dich, das Issue mit aktualisiertem Kontext und aktuellen Details zu kommentieren. Wir verpflichten uns, diese aktualisierten Issues im Rahmen unserer regelmäßigen Bewertungen zu überprüfen.\n\n## Die Vorteile: Fokussierte Entwicklung und klarere Roadmaps\n\nDieser optimierte Ansatz bedeutet direkte, greifbare Verbesserungen für alle GitLab-Nutzer:\n\n* **Schärferer Fokus und schnellere Bereitstellung:** Durch die Eingrenzung unseres Backlogs auf strategisch ausgerichtete Funktionen können wir Entwicklungskapazitäten gezielter nutzen. Das bedeutet, dass du kürzere Entwicklungszyklen und spürbare Verbesserungen in GitLab erwarten kannst.\n* **Klarere Erwartungen:** Wir verpflichten uns zu transparenter Kommunikation darüber, was auf unserer Roadmap steht und was nicht, damit du fundierte Entscheidungen über deine Workflows treffen kannst.\n* **Beschleunigte Feedback-Schleifen:** Mit einem sauberen Backlog werden neue Feedbacks und Feature-Anfragen effizienter überprüft und priorisiert. Das verkürzt die Triage-Zeit und stellt sicher, dass zeitkritische Issues die notwendige Aufmerksamkeit erhalten. Dies schafft schnelleres Feedback für alle.\n\nDiese Initiative mindert nicht die Bedeutung von Community-Feedback und -Beiträgen. Wir ergreifen diese Maßnahme, um Klarheit darüber zu schaffen, was GitLab-Teammitglieder realistisch liefern können, und um sicherzustellen, dass alle Rückmeldungen angemessen berücksichtigt werden.\n\n## GitLabs Commitment: Transparente Prioritäten für die Community\n\nDie GitLab Healthy Backlog Initiative spiegelt unseren Anspruch wider, transparente und effektive Verwalter der GitLab-Plattform zu sein. Indem wir unsere Prioritäten klar kommunizieren und unsere Bemühungen auf das konzentrieren, was wir realistisch im nächsten Jahr erreichen können, sind wir besser positioniert, deine Erwartungen zu erfüllen und zu übertreffen.\n\nDeine kontinuierliche Teilnahme und dein Feedback helfen dabei, GitLab stärker zu machen. Jeder Kommentar, jede Merge Request, jeder Bug-Report und jeder Feature-Vorschlag trägt zu unserer gemeinsamen Vision bei. Und wir belohnen dich auch weiterhin dafür, mit Initiativen wie unserem monatlichen Notable Contributor-Programm, Swag-Belohnungen für Level-Ups, Hackathon-Gewinnern und mehr, alles verfügbar über unser [Contributor-Portal](https://contributors.gitlab.com).\n\n> Um mehr darüber zu erfahren, wie du zu GitLab beitragen kannst, [besuche unsere Community-Seite](https://about.gitlab.com/community/). Um Feedback zu diesem Projekt zu teilen, füge bitte deine Kommentare zum [Feedback-Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/556865) in diesem [Epic](https://gitlab.com/groups/gitlab-org/-/epics/18639) hinzu.",[269,764,742],{"featured":91,"template":796,"slug":980},"inside-gitlabs-healthy-backlog-initiative",{"content":982,"config":992},{"heroImage":983,"body":984,"authors":985,"updatedDate":862,"date":988,"title":989,"tags":990,"description":991,"category":731},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097166/Blog/Hero%20Images/Blog/Hero%20Images/REFERENCE%20-%20display%20preview%20for%20blog%20images%20%282%29_2pKf8RsKzAaThmQfqHIaa7_1750097166565.png","Backups von Repositorys sind ein wichtiger Bestandteil jeder robusten Strategie für die Notfallwiederherstellung. Mit zunehmender Größe der Repositorys wird die Erstellung zuverlässiger Backups jedoch immer schwieriger. Das Backup unseres eigenen [Rails-Repository](https://gitlab.com/gitlab-org/gitlab) dauerte 48 Stunden und zwang uns zu einer unmöglichen Entscheidung zwischen Backup-Häufigkeit und Systemleistung. Wir wollten dieses Thema sowohl für unsere Kund(inn)en als auch für unsere eigenen Benutzer(innen) in den Griff bekommen.\n\nSchließlich haben wir das Problem auf eine 15 Jahre alte Git-Funktion mit O(N²)-Komplexität zurückgeführt und sie mit einer algorithmischen Änderung behoben, die die **Backup-Zeiten exponentiell reduzierte**. Das Ergebnis: niedrigere Kosten, weniger Risiko und Backup-Strategien, die tatsächlich mit deiner Codebase mitwachsen.\n\nEs stellte sich heraus, dass es sich um ein Skalierungsproblem von Git handelt, das jedes große Repository betrifft. Hier erfährst du, wie wir es aufgespürt und behoben haben.\n\n## Skalierbare Backups\n\nSehen wir uns zunächst das Problem an. Wenn Unternehmen ihre Repositorys skalieren und Backups immer komplexer werden, stehen sie vor einigen Herausforderungen:\n\n* **Zeitintensive Backups:** Bei sehr großen Repositorys kann es mehrere Stunden dauern, bis ein Repository-Backup erstellt wird. Dies kann die Möglichkeit, regelmäßige Backups zu planen, beeinträchtigen. \n* **Ressourcenintensität:** Erweiterte Backup-Prozesse können erhebliche Serverressourcen verbrauchen, was sich möglicherweise auf andere Vorgänge auswirken kann.\n* **Backup-Fenster:** Für Teams, die rund um die Uhr arbeiten, kann es schwierig sein, angemessene Wartungsfenster für Prozesse zu finden, die so lange dauern.\n* **Erhöhtes Ausfallrisiko:** Prozesse, die über längere Zeit ausgeführt werden, sind anfälliger für Unterbrechungen durch Netzwerkprobleme, Neustarts von Servern und Systemfehler. So sind Teams manchmal dazu gezwungen, den gesamten sehr langen Backup-Prozess von Grund auf neu zu starten.\n* **Race Conditions:** Da es sehr lange dauert, ein Backup durchzuführen, kann sich das Repository während des Prozesses stark verändern. Dies kann möglicherweise zu einem ungültigen Backup führen oder das Backup unterbrechen, weil Objekte nicht mehr verfügbar sind.\n\nDiese Herausforderungen können zu Kompromissen bei der Häufigkeit oder Vollständigkeit von Backups führen – ein inakzeptabler Kompromiss, wenn es um den Datenschutz geht. Erweiterte Backup-Fenster können Kund(inn)en zu Problemumgehungen zwingen. Einige setzen möglicherweise externe Tools ein, während andere die Backup-Häufigkeit reduzieren, was zu potenziell inkonsistenten Datenschutzstrategien im Unternehmen führen kann.\n\nSehen wir uns nun an, wie wir einen Leistungsengpass identifiziert, eine Lösung gefunden und diese bereitgestellt haben, um die Backup-Zeiten zu verkürzen.\n\n## Die technische Herausforderung\n\nDie Repository-Backup-Funktionalität von GitLab basiert auf dem Befehl [`git bundle create`](https://git-scm.com/docs/git-bundle), der einen vollständigen Snapshot eines Repository erfasst, einschließlich aller Objekte und Referenzen wie Branches und Tags. Dieses Bundle dient als Wiederherstellungspunkt, um das Repository in seinem genauen Zustand neu zu erstellen.\n\nDie Implementierung des Befehls litt jedoch unter einer schlechten Skalierbarkeit im Zusammenhang mit der Referenzzählung, was zu einem Leistungsengpass führte. Je mehr Referenzen die Repositorys sammelten, desto mehr stieg die Verarbeitungszeit exponentiell an. In unseren größten Repositorys mit Millionen von Referenzen konnten Backup-Vorgänge mehr als 48 Stunden dauern.\n\n### Grundursachenanalyse\n\nUm die Grundursache dieses Leistungsengpasses zu identifizieren, haben wir ein Flammendiagramm des Befehls während der Ausführung analysiert.\n\n![Flammendiagramm, das den Befehl während der Ausführung zeigt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097176/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097176388.jpg)\n\nEin Flammendiagramm, das den Ausführungspfad eines Befehls durch seinen Stacktrace zeigt. Jeder Balken entspricht einer Funktion im Code. Die Breite des Balkens gibt an, wie viel Zeit der Befehl für die Ausführung innerhalb dieser bestimmten Funktion benötigt hat.\n\nBei der Untersuchung des Flammendiagramms von `git bundle create`, das auf einem Repository mit 10 000 Referenzen ausgeführt wird, werden etwa 80 % der Ausführungszeit von der Funktion `object_array_remove_duplicates()` verbraucht. Diese Funktion wurde in Git im [Commit b2a6d1c686](https://gitlab.com/gitlab-org/git/-/commit/b2a6d1c686) eingeführt (bundle: allow the same ref to be given more than once, 17.01.2009).\n\nUm diese Änderung zu verstehen, ist es wichtig zu wissen, dass `git bundle create` es Benutzer(inne)n ermöglicht, anzugeben, welche Referenzen in das Bundle aufgenommen werden sollen. Für vollständige Repository-Bundles werden mit dem Flag `--all` alle Referenzen gepackt.\n\nDer Commit löste ein Problem, bei dem Benutzer(innen), die über die Befehlszeile doppelte Referenzen bereitstellten – wie z. B. `git bundle create main.bundle main main` – ein Bundle erstellten, ohne die doppelte Hauptreferenz ordnungsgemäß zu verarbeiten. Das Entpacken dieses Bundles in einem Git-Repository würde fehlschlagen, da versucht würde, die gleiche Referenz zweimal zu schreiben. Der Code zum Vermeiden von Duplikaten verwendet verschachtelte `for`-Schleifen, die alle Referenzen durchlaufen, um Duplikate zu identifizieren. Dieser O(N²)-Algorithmus wird in Repositorys mit einer großen Anzahl von Referenzen zu einem erheblichen Leistungsengpass, da er viel Rechenzeit verbraucht.\n\n### Der Fix: Von O(N²) zu effizientem Mapping\n\nUm dieses Leistungsproblem zu lösen, haben wir einen Upstream-Fix für Git bereitgestellt, der die verschachtelten Schleifen durch eine Mapping-Datenstruktur ersetzt. Jede Referenz wird der Zuordnung hinzugefügt, wodurch automatisch sichergestellt wird, dass nur eine einzige Kopie jeder Referenz für die Bearbeitung gespeichert wird.\n\nDiese Änderung verbessert die Leistung von `git bundle create` drastisch und ermöglicht eine bessere Skalierbarkeit in Repositorys mit einer großen Anzahl von Referenzen. Benchmark-Tests mit einem Repository mit 10 000 Referenzen zeigen eine 6-fache Leistungssteigerung.\n\n```shell\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ): \t14.653 s ±  0.203 s\t[User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s\t10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):  \t2.394 s ±  0.023 s\t[User: 1.684 s, System: 0.798 s]\n  Range (min … max):\t2.364 s …  2.425 s\t10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n  6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nDer Patch wurde akzeptiert und in den Git-Upstream [zusammengeführt](https://gitlab.com/gitlab-org/git/-/commit/bb74c0abbc31da35be52999569ea481ebd149d1d). Wir haben diesen Fix zurückportiert, damit unsere Kund(inn)en sofort davon profitieren können, ohne auf die nächste Git-Version warten zu müssen.\n\n## Das Ergebnis: Drastisch verkürzte Backup-Zeiten\n\nDie Leistungssteigerungen, die sich aus dieser Verbesserung ergeben haben, sind bahnbrechend:\n\n* **Von 48 Stunden auf 41 Minuten:** Das Erstellen eines Backups unseres größten Repositorys (`gitlab-org/gitlab`) dauert jetzt nur noch 1,4 % der ursprünglichen Zeit.\n* **Konsistente Leistung:** Die Verbesserung funktioniert zuverlässig bei Repositorys jeder Größe.\n* **Ressourceneffizienz:** Wir haben die Serverlast während der Backup-Vorgänge deutlich reduziert.\n* **Breitere Anwendbarkeit:** Bei der Erstellung von Backups ist die Verbesserung am größten, aber auch alle Bundle-basierten Vorgänge, die mit vielen Referenzen arbeiten, profitieren davon.\n\n## Was bedeutet das für GitLab-Kund(inn)en?\n\nGitLab-Kund(inn)en profitieren von dieser Erweiterung unmittelbar und spürbar, wenn es darum geht, wie Unternehmen die Sicherung von Repositorys und die Notfallwiederherstellung planen:\n\n* **Transformierte Backup-Strategien**   \n\n  * Enterprise-Teams können umfassende nächtliche Zeitpläne aufstellen, ohne dass die Entwicklungs-Workflows beeinträchtigt werden oder umfangreiche Backup-Fenster erforderlich sind.   \n  * Backups können jetzt während der nächtlichen Zeitpläne nahtlos im Hintergrund ausgeführt werden, anstatt separat und langwierig durchgeführt zu werden.  \n* **Bessere Geschäftskontinuität**  \n\n  * Durch die Verkürzung der Backup-Zeiten von Tagen auf Minuten können Unternehmen ihr Wiederherstellungsziel deutlich minimieren. Dies führt zu einem geringeren Geschäftsrisiko – in einem Katastrophenszenario musst du möglicherweise nur noch Stunden anstatt Tage an Arbeit wiederherstellen.  \n* **Reduzierter betrieblicher Mehraufwand**   \n\n  * Geringerer Verbrauch von Serverressourcen und kürzere Wartungsfenster.  \n  * Kürzere Backup-Fenster bedeuten geringere Compute-Kosten, vor allem in Cloud-Umgebungen, wo sich längere Verarbeitungszeiten direkt in höheren Rechnungen niederschlagen.  \n* **Zukunftssichere Infrastruktur**   \n\n  * Wachsende Repositorys erzwingen keine schwierigen Entscheidungen mehr zwischen Backup-Häufigkeit und Systemleistung.   \n  * Wenn deine Codebase wächst, kann deine Backup-Strategie nahtlos mitwachsen.\n\nUnternehmen können jetzt robustere Backup-Strategien umsetzen, ohne Kompromisse bei der Leistung oder Vollständigkeit einzugehen. Was früher ein schwieriger Kompromiss war, ist heute ein ganz normaler Vorgang.\n\nMit dem Release von [GitLab 18.0 (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/) können alle GitLab-Kund(inn)en unabhängig von ihrem Tarif diese Verbesserungen bereits in vollem Umfang für ihre [Backup-Strategie und Ausführung (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/) nutzen. Es ist keine weitere Änderung der Konfiguration erforderlich.\n\n## Wie geht es weiter?\n\nDieser Durchbruch ist Teil unseres kontinuierlichen Engagements für eine skalierbare, unternehmensgerechte Git-Infrastruktur. Die Reduzierung der Zeit für die Erstellung von Backups von 48 Stunden auf 41 Minuten ist bereits ein wichtiger Meilenstein. Wir arbeiten weiter daran, Leistungsengpässe in unserem gesamten Stack zu identifizieren und zu beheben.\n\nWir sind besonders stolz darauf, dass diese Verbesserung in das Git-Projekt integriert wurde und nicht nur den Benutzer(inn)en von GitLab, sondern auch der gesamten Git-Community zugutekommt. Dieser kollaborative Ansatz bei der Entwicklung stellt sicher, dass Verbesserungen gründlich geprüft, umfassend getestet und für alle zugänglich gemacht werden.\n\n> Tiefgreifende Infrastrukturarbeit wie diese ist die Art, wie wir bei GitLab an die Leistung herangehen. Nimm am virtuellen Launch-Event von GitLab 18 teil, um zu sehen, welche weiteren grundlegenden Verbesserungen wir einführen werden. [Registriere dich noch heute!](https://about.gitlab.com/de-de/eighteen/)",[986,987],"Karthik Nayak","Manuel Kraft","2025-06-05","So haben wir GitLab-Backups von 48 Stunden auf 41 Minuten beschleunigt",[],"Erfahre, wie GitLab einen Leistungsengpass in einer 15 Jahre alten Git-Funktion aufgespürt und behoben hat, was zu einer verbesserten Effizienz führte.",{"slug":993,"featured":91,"template":796},"how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes",{"content":995,"config":1003},{"title":996,"description":997,"authors":998,"heroImage":999,"date":1000,"body":1001,"category":731,"tags":1002,"updatedDate":1000},"Was ist Kubernetes?","Container haben Softwareentwicklung und -Deployment revolutioniert. Wir zeigen dir hier die Vorteile von Kubernetes.",[788],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662245/Blog/Hero%20Images/blog-image-template-1800x945__16_.png","2025-05-15","# Kubernetes: Einfach erklärt\n\nKubernetes hat sich weltweit als führende Technologie in der Container-Orchestrierung durchgesetzt. Die Vielfalt an Funktionalitäten, die Kubernetes bereitstellt, ist aber nicht immer leicht zu nutzen. Lukas Gentele schreibt auf entwickler.de, dass \"von vielen Entwicklern Kubernetes als zu komplex und kaum zu beherrschen wahrgenommen wird\". Damit spricht er aus, was viele denken.\n\nIronischerweise besteht der Hauptnutzen von Kubernetes darin, viele Anwendungen überhaupt erst beherrschbar zu machen. Warum das kein Widerspruch ist, was Kubernetes ist und wie es funktioniert, erfährst du in diesem Artikel. \n\n## Inhaltsverzeichnis\n- [Kubernetes: Einfach erklärt](#kubernetes-einfach-erklärt)\n  - [Kubernetes-Container: Kein Pod kommt ohne aus](#kubernetes-container-kein-pod-kommt-ohne-aus)\n  - [Container – übersichtlich, kollaborativ, effizient](#container-–-übersichtlich-kollaborativ%2C-effizient)\n  - [Pod: Container Kombinationen](#pod-container-kombinationen)\n  - [Orchestrierung: Container kontrollieren](#orchestrierung-container-kontrollieren)\n  - [Abstraktion und Zustandsorientierung](#abstraktion-und-zustandsorientierung)\n  - [Node, Kubelet, Cluster: Die Welt von Kubernetes](#node-kubelet%2C-cluster-die-welt-von-kubernetes)\n  - [Wie funktioniert Kubernetes?](#wie-funktioniert-kubernetes%3F)\n  - [Kubernetes in der Praxis](#kubernetes-in-der-praxis)\n  - [Die Vorteile von Kubernetes](#die-vorteile-von-kubernetes)\n  - [Wie funktioniert die Kubernetes-Integration unter GitLab?](#wie-funktioniert-die-kubernetes-integration-unter-gitlab)\n  - [FAQs zu Kubernetes (K8s)](#faqs-zu-kubernetes-(k8s))\n\n## Kubernetes-Container: Kein Pod kommt ohne aus\n\nWenn wir ein Verständnis über Kubernetes vermitteln wollen, kommen wir an einem Bestandteil nicht vorbei – dem Container. \n\nÄhnlich wie Betriebssysteme wurden Anwendungen noch bis vor wenigen Jahre als Monolith entwickelt. Das bedeutet, Anwendungen bestanden aus einer einzigen unteilbaren Codebasis, welche alle Informationen enthält, die zum Betrieb notwendig sind.\n\nAuch, wenn nur wenige Teile der Anwendung benötigt wurden, musste trotzdem das gesamte Programm geladen werden. Das verbrauchte offensichtlich viele Ressourcen, das System wurde langsam und fehleranfällig.\n\n## Container – übersichtlich, kollaborativ, effizient\n\nErste Versuche, die Nachteile einer monolithischen Architektur zu umgehen und Teile eines Programms gezielt zu isolieren, entstanden in den späten 70ern und frühen 80er-Jahren. Doch erst Docker, welches 2013 veröffentlicht wurde, verhalf dem Gedanken auf breiter Basis zum Durchbruch.\n\nDie verschiedenen Funktionalitäten einer Anwendung werden mit einer Software wie Docker isoliert und in Pakete aufgeteilt. Diese Container enthalten sämtliche Daten, Software und Bibliotheken, die zum Betrieb genau dieser Funktionalitäten erforderlich sind.\n\nDie Container können eigenständig genutzt oder getestet werden. Aber man kann sie auch zu einer größeren Architektur verknüpfen und \"aufeinanderstapeln\" wie Container (die Idee entstand [laut dem ehemaligen Docker-CEO Ben Golub](https://www.computerwoche.de/a/der-niedergang-von-docker,3551769) \"als wir all die Containerschiffe im Hafen von Oakland einlaufen sahen\").\n\nFrüher als monolithische Anwendungen entwickelt, werden Programme heute als Zusammensetzungen einzelner Container betrachtet. Anstatt den gesamten Code zu laden, werden nur die Container verwendet, die für die jeweils auszuführenden Aufgaben notwendig sind. Dadurch, dass die Container bereits alle Daten enthalten, die benötigt werden, um das Programm zu starten, wird es deutlich einfacher, einzelne Komponenten von einem Server mit Betriebssystem A auf einen anderen mit Betriebssystem B zu verschieben.\n\n## Pod: Container Kombinationen\n\nAusgehend von den einzelnen Docker-Containern bilden Anwender(innen) nun Gruppen aus Containern, die im Rahmen einer bestimmten Anwendung oder eines größeren Systems zusammenarbeiten. Jede dieser virtuellen Gruppen bezeichnet man als \"Pod\".\n\nIm Beispiel eines E-Commerces Unternehmen, kann nun ein Pod die Benutzeroberfläche enthalten, während andere Pods die Bezahlung, oder die Lieferung abwickeln. Die Vorteile sind klar: Dieser Ansatz ist schlanker und robuster als der monolithische und lässt sich konsistent auf verschiedenen Betriebssystemen verwenden. Gerade in der Softwareentwicklung bedeutete diese Zuverlässigkeit einen deutlichen Sprung nach vorne.\n\n## Orchestrierung: Container kontrollieren\n\nGleichzeitig erfordert eine Anwendung, die aus mehreren Containern zusammengesetzt ist, ein höheres Maß an Management.\n\nWas passiert beispielsweise, wenn ein Pod ausfällt? Wie geht man mit Fehlern in einem Pod um? Wo sollen die Pods ausgeführt werden? Wie wirkt sich die Containerisierung auf die Entwicklung neuer Funktionalitäten aus? Wie funktioniert überhaupt die ständige Neuverteilung verschiedener Pods innerhalb derselben Anwendung während des laufenden Betriebs?\n\nDiese Fragen werden dringlicher, je mehr Container eine Anwendung verwendet. Und sie werden geradezu kritisch in einer Umgebung, in der sehr viele Nutzer(innen) auf eine Vielzahl containerisierter Anwendungen zugreifen sollen.\n\nWenn es keinen monolithischen Code mehr gibt, welcher festlegt, in welchen Situationen bestimmte Kombinationen zur Anwendung kommen, werden neue Prinzipien zur Aktivierung benötigt. Darüber hinaus ergeben sich durch die Containerisierung eine Vielzahl spezifischer Herausforderungen.\n\nDie Lösungsansätze, die sich mit dieser Herausforderung beschäftigen, werden unter dem Begriff Container-Orchestrierung zusammengefasst. Einfach erklärt ist Kubernetes das derzeit wohl leistungsfähigste und effizienteste Orchestrierungs-Tool.\n\n## Abstraktion und Zustandsorientierung\n\nVor der Einführung der Containerisierung, die mit Docker ihren Durchbruch fand, waren Programme im Wesentlichen Stories, die durch ihren Code zusammengehalten wurden. Mit Containern wird dieses Narrativ jedoch aufgebrochen und in seine einzelnen Bestandteile zerlegt. Damit aus diesen Teilen wieder eine sinnvolle Geschichte entsteht, benötigt man einen „roten Faden\", der die einzelnen Komponenten zusammenführt.\n\nAus der Perspektive von Kubernetes werden Anwendungen schlicht als „Arbeitslasten\" (Workloads) betrachtet – also Dienste, die eine bestimmte Menge an Systemressourcen beanspruchen. Pods fungieren dabei als Abstraktionen, da der Zusammenhang zwischen den einzelnen Pods jederzeit aufgelöst und neu gestaltet werden kann.\n\nDas bedeutet, dass du jederzeit eine bestehende Struktur aufbrechen und nach Belieben neu zusammensetzen kannst. Mit denselben Komponenten lässt sich so etwas völlig Neues erschaffen.\n\nWichtig bei der Wahl der geeigneten Abstraktion ist der Zustand (State), der durch die Kombination oder Aktivierung von Nutzlasten im System entsteht. Manche Zustände sind gewünscht, andere nicht.\n\nWenn man Kubernetes einfach definieren würde, würde man sagen Kubernetes stellt sicher, dass alle Komponenten im richtigen Zustand sind.\n\n## Node, Kubelet, Cluster: Die Welt von Kubernetes\n\nIn einem System werden Pods, also funktional zusammengehörige Kombinationen von Kubernetes-Containern auf sogenannte Knoten (englisch: Nodes) verteilt. Ein Knoten kann sowohl ein physischer Rechner (PC) als auch eine virtuelle Maschine (VM) sein.\n\nEs gibt zwei Formen von Knoten:\n\n* Die sogenannten Master-Nodes, welche die Steuerung und Kontrolle übernehmen sowie  \n* die Work-Nodes, auf denen die Anwendungen liegen, welche die Funktionalität einer Anwendung übernehmen.\n\nDie Kommunikation zwischen diesen Ebenen wird von kleinen Managementagenten übernommen, den Kubelets.\n\nSchließlich kann man mehrere Knoten zu Kubernetes-Clustern aufsetzen. Diese bilden dann die Umgebung ab, die Kubernetes verwaltet und auf welcher Kubernetes läuft.\n\n## Wie funktioniert Kubernetes?\n\nKubernetes automatisiert die Container-Orchestrierung, jedoch ist es als Administrator wichtig, stets die Kontrolle darüber zu behalten, welche Prioritäten dabei gesetzt und welche Aspekte berücksichtigt werden müssen.\n\nAdministrator(inn)en erarbeiten zusammen mit den Entwickler(innen)/Anwender(innen) eine Liste an gewünschten Zuständen. Dazu kann beispielsweise der Wunsch gehören, dass gewisse Pods stets aktiv sein sollten. Auch dann, wenn sie formal nicht ununterbrochen benötigt werden.\n\nDas ist ein völlig neuer Ansatz, wie über die Kontrolle der Software nachgedacht werden muss. Statt ständig auf sich ändernde Anforderungen mit neuen Befehlen zu reagieren, definiert man stattdessen, welche Zustände erfüllt werden sollen und überlässt es dann Kubernetes diese zu erfüllen. \n\n*Man bezeichnet diese Form der Kontrolle auch als \"deklarativ\", gegenüber dem traditionellen Modell der \"imperativen\" (befehlsgebenden) Kontrolle.*\n\nEin weiteres Eingreifen seitens Administrator(inn)en ist im Idealfall nicht mehr erforderlich. Senior Solutions Manager Brendan O'Leary von GitLab hat das einmal folgendermaßen auf den Punkt gebracht: *\"Kubernetes sorgt dafür, dass das System so bleibt, wie wir es haben wollen.\"*\n\n## Kubernetes in der Praxis\n\nWie funktioniert die Orchestrierung nun?\n\nKubernetes übernimmt eine Vielzahl von Funktionen, welche die Verwendung der Pods im Cluster optimieren: \n\n* Der Kubernetes Scheduler sorgt dafür, dass Pods den für sie besten Knoten zugeordnet werden.  \n* Kubernetes bringt die Nachfrage nach Nutzlasten mit dem Angebot in Einklang. Das bedeutet: Wenn besonders viele Nutzer(inn)en ein ganz bestimmtes Pod anfragen, droht eine Überlastung. Kubernetes kann hierauf mit zwei Antworten reagieren: Es kann für diesen Pod mehr Ressourcen bereitstellen, oder es kann den Pod duplizieren, also Kopien erstellen und die Anfragen auf diese neuen Pods verteilen. Dieser Prozess wird als load balancing bezeichnet.  \n* Kubernetes aktualisiert sich stets selbst und bleibt somit immer auf dem neuesten Stand.  \n* Entstehen in einem Pod Fehler, die zu einem Ausfall führen, kann Kubernetes im Rahmen seines Self-healings (Selbstheilung) entweder den Pod reparieren oder es auf einen funktionsfähigen früheren Zustand zurücksetzen.  \n* Hast du einmal ein Kubernetes-Cluster aufgesetzt, werden Nutzlasten oft von einem Knoten auf einen anderen verschoben. Interne IP-Adressen können hier also nicht mehr verwendet werden, um den aktuellen Ort eines Pods zu bestimmen (weil er sich ständig ändert). Mit der Service-Discovery-Funktion übernimmt Kubernetes die Aufgabe, dass Anfragen auf dem richtigen Pod auch ankommen.\n\n## Die Vorteile von Kubernetes\n\nGerade bei sehr großen Cloud-Umgebungen ist leicht ersichtlich, warum die oben beschriebene, automatisierte Gewährleistung eines optimalen Zustands einen großen Nutzen mit sich bringt.\n\nEin weiterer Vorteil von Kubernetes besteht in der Entwicklung neuer Funktionen. Es ermöglicht ein reibungsloses Testen, ohne dass es dabei zum Ausfall des Systems kommt. Neue Container und Pods können unkompliziert hinzugefügt werden. Teams können gezielt nur an den Diensten arbeiten, für die sie zuständig sind und so ganz gezielt und spezifisch das System optimieren.\n\nGerade Letzteres war der Grund, dass GitLab sich bereits 2017 für ein Container-zentriertes System mit Kubernetes entschieden hat.\n\nLukas Gentele schreibt dazu:\n\n*\"Dass das Kubernetes-Ökosystem so vielseitig ist, mag auf den ersten Blick abschrecken, doch es ist notwendig, da die Architektur von Kubernetes ein großes Maß an Flexibilität bietet.\"*\n\n## Wie funktioniert die Kubernetes-Integration unter GitLab?\n\nGitLab ist eine Platform die [Kontinuierlichen Integration und Auslieferung](https://about.gitlab.com/de-de/solutions/continuous-integration/) ermöglicht. Somit kannst du als GitLab-Nutzer(in) die Vorteile von Kubernetes bezüglich der Container-Orchestrierung für dich nutzen.\n\nWeil GitLab CE und Kubernetes so natürlich miteinander harmonieren, fällt die Integration recht unkompliziert aus. Wir haben für dich einen Artikel vorbereitet, der genau erklärt, wie du ein [Kubernetes Cluster mit GitLab verbindest](https://docs.gitlab.com/ee/user/clusters/agent/). \n\nKurz zusammengefasst erfordert die Integration folgende Punkte:\n\n* Definiere das Cluster, welches über Kubernetes automatisiert werden soll.  \n* Installiere einen Agenten, der die Kommunikation mit dem Cluster übernimmt.  \n* Konfiguriere die GitLab-CI/CD Pipeline so, dass sie die Kubernetes-API verwendet.\n\n## FAQs zu Kubernetes (K8s)\n\n### Warum wird Kubernetes auch K8s genannt? Was bedeutet der Begriff?\n\nK8s ist eine smarte, leicht kryptische Abkürzung des Begriffs Kubernetes: \"K\" und \"s\" bezeichnen den ersten und letzten Buchstaben, die \"8\" schlicht die Anzahl der Buchstaben, die dazwischen liegen.\n\nDas Wort Kubernetes stammt aus dem Griechischen und bedeutet Steuer- oder Fährmann. Der Begriff bezieht sich auf die zentrale Aufgabe von Kubernetes, ein System auch bei \"hohem Wellengang\" stets stabil zu halten und vor dem Kentern zu bewahren.\n\n### Wer hat Kubernetes entwickelt?\n\nDie ersten Impulse für Kubernetes setzte Google mit seinen Vorläuferprojekten \"Borg\" und \"Project 7\". Beide beschäftigten sich mit der Problemstellung, die Komplexität containierisierter Anwendungen beherrschbar zu machen.\n\nBewusst als Open-Source-Plattform entwickelt, entstand Kubernetes aus der Kollaboration verschiedener großer und kleiner Unternehmen, die sich in der Cloud Native Computing Foundation zusammenschlossen.\n\nDarüber hinaus wurde es maßgeblich über die Git-Community ergänzt und weiterentwickelt.\n\n### Was kostet die Nutzung von Kubernetes?\n\nBei Kubernetes handelt es sich um ein Open-Source-System. Das bedeutet, dass das Programm kostenfrei heruntergeladen werden kann. Trotzdem entstehen bei der Nutzung von Kubernetes in deinem Unternehmen Kosten, potentiell sogar recht hohe.\n\nDer Grund dafür ist, dass die nackte Basisversion der Anwendung letzten Endes für die meisten Anwender(innen) nicht nutzbar ist.\n\nNeben den Kosten, die für das Hosten der Kubernetes-Cluster in der Cloud anfallen, solltest du folgende möglichen Kostenpunkte berücksichtigen:\n\n* Die Nutzung von Kubernetes-Dienstleistungen, welche den Einsatz vereinfachen.  \n* Experten, die das Kubernetes-System konfigurieren, es gegebenenfalls warten und es auf dem neuesten Stand halten. Gerade angesichts des hohen Spezialisierungsgrads des Anforderungsprofils sowie der Menge der anfallenden Arbeitsstunden können hierbei erhebliche Kosten entstehen.  \n* Nach dem Aufsetzen eines Kubernetes-Clusters liegen Ressourcen auf verschiedenen Cloud-Speichern. Ein wichtiger Teil der Funktionalität von Kubernetes besteht darin, Nutzlasten dynamisch zwischen diesen Cloud-Speichern zu verschieben, so dass die Stabilität, Sicherheit und Geschwindigkeit des Systems optimiert wird. Allerdings wird dir das Verschieben von Datenpaketen von einem Speicher auf einen anderen sogar dann berechnet, wenn alle deine Daten bei demselben/derselben Provider(in) liegen. Diese Egress-Kosten werden gemäß des verschobenen Datenvolumens kalkuliert und können sich, abhängig von der Größe der Kubernetes-Cluster, am Ende des Jahres wahrhaft auftürmen.\n\nImmer mehr Anbieter(innen) haben inzwischen Kubernetes-Online-Rechner im Angebot, mit denen du einen besseren Eindruck über die möglichen Kosten erhältst. Allerdings bleibt es meistens bei einer [Schätzung](https://www.heise.de/news/Kosten-der-Google-Kubernetes-Engine-vorab-berechnen-zumindest-grob-7120708.html).",[550],{"slug":1004,"featured":6,"template":796},"definition-what-is-kubernetes",{"category":738,"slug":742,"posts":1006},[1007,1021,1034],{"content":1008,"config":1019},{"heroImage":1009,"body":1010,"authors":1011,"updatedDate":1013,"date":1014,"title":1015,"tags":1016,"description":1018,"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.*",[1012],"Dave Steer","2024-11-26","2024-11-13","Wirtschaftliche Gesamtauswirkungen von GitLab Ultimate: 483 % ROI über 3 Jahre",[807,1017,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":1020,"featured":91,"template":796},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"content":1022,"config":1032},{"title":1023,"description":1024,"authors":1025,"heroImage":1027,"date":1028,"body":1029,"category":742,"tags":1030,"updatedDate":1031},"Einführung in The Source: Einblicke in die Zukunft der Softwareentwicklung","In unserer neuen Publikation findest du transformative Softwareentwicklungsstrategien und Ratschläge von Expert(inn)en zu neuen Technologien.",[1026],"Chandler Gibbons","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674616/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","2024-10-29","Die moderne Softwareentwicklung verändert die Art und Weise, wie Unternehmen geschäftlichen Mehrwert schaffen, liefern und skalieren. Die Teams müssen in der Lage sein, schnell und effizient Lösungen zu entwickeln und gleichzeitig mit den zunehmenden Sicherheitsbedrohungen, neuen Technologien und immer komplexeren Compliance-Anforderungen umzugehen.\n\nHeute bringt GitLab [The Source](https://about.gitlab.com/the-source/) auf den Markt, eine neue Publikation, die sich mit der Entwicklung der Softwareentwicklung als Motor für den Geschäftserfolg beschäftigt. Wir bieten regelmäßig Einblicke in die Zukunft der Softwareentwicklung, gestützt auf eigene Forschung und Analysen unserer Fachleute und Vordenker(innen).\n\nAuf The Source findest du zum Beispiel Antworten auf folgende Fragen:  \n* Wie können Führungskräfte den ROI von KI über den gesamten Software-Entwicklungsprozess hinweg messen?    \n* Wie lassen sich Sicherheit und Compliance in der gesamten Software-Lieferkette am besten gewährleisten?\n* Welche Arten von Effizienzgewinnen können Teams durch die Konsolidierung von Plattformen und Toolchains erzielen?\n\nHier ein aktueller Auszug von The Source:\n\n**4 Schritte zur Messung der Auswirkungen von KI**\n\n„Die Bewertung der Produktivität von KI-gestütztem Coding erfordert einen differenzierteren Ansatz als herkömmliche Kennzahlen wie Codezeilen, Code Commits oder die Erledigung von Aufgaben. Es ist notwendig, den Fokus auf reale Geschäftsergebnisse zu verlagern, die ein Gleichgewicht zwischen Entwicklungsgeschwindigkeit, Softwarequalität und Sicherheit herstellen.“  \n- [Erfahre mehr über die 4 nötigen Schritte vom KI-Experten Taylor McCaslin (nur in englischer Sprache)](https://about.gitlab.com/the-source/ai/4-steps-for-measuring-the-impact-of-ai/)\n\n**Behebung der Grundursache für häufigen Frust, der durch umständliche Sicherheitsanforderungen verursacht wird**\n\n„DevSecOps verspricht eine bessere Integration zwischen Engineering und Sicherheit, aber es ist klar, dass Frustrationen und Fehlausrichtungen bestehen bleiben. Das liegt daran, dass diese Herausforderungen Symptome eines größeren Problems sind, wie Unternehmen Sicherheit sehen, wie Teams zusammenarbeiten und wie sie Zeit für Sicherheit aufwenden.“\n- [Löse dieses Problem mit fachkundigem Rat des CISO von GitLab, Josh Lemos (nur in englischer Sprache).](https://about.gitlab.com/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/)\n\n**Bessere Geschäftsergebnisse durch Platform Engineering**\n\n„Platform Engineering zielt darauf ab, die Workflows von Entwickler(inne)n zu normalisieren und zu standardisieren, indem es Entwickler(inne)n optimierte „Golden Paths“ für die meisten ihrer Workloads und Flexibilität bei der Definition von Ausnahmen für den Rest bietet.“\n- [Entdecke die Best Practices für den Erfolg des Platform Engineerings von Brian Wald, Field CTO von GitLab (nur in englischer Sprache).](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/)\n\n## Lass dir von The Source bei deinen Entscheidungen helfen\n\nAuf [The Source (nur in englischer Sprache)](https://about.gitlab.com/the-source/), findest du die neuesten Erkenntnisse, Antworten auf deine Fragen zu Führungsthemen und kannst immer etwas Neues lernen, das du mit deinen Teams teilen kannst. Du kannst auch unseren Newsletter abonnieren, um regelmäßige Updates direkt in deinem Posteingang zu erhalten. Werde Teil unserer Community zukunftsorientierter Technologie-Leader und gestalte die Zukunft der Softwareentwicklung mit.",[830,775,742,715],"2024-11-14",{"slug":1033,"featured":91,"template":796},"introducing-the-source-insights-for-the-future-of-software-development",{"content":1035,"config":1044},{"title":1036,"description":1037,"authors":1038,"heroImage":842,"date":1040,"body":1041,"category":742,"tags":1042,"updatedDate":1043},"GitLab ist ein Leader im Gartner Magic Quadrant für DevOps-Plattformen 2024","GitLab ist in den Bereichen „Ability to execute“ und „Completeness of vision“ am besten positioniert. Eine Anerkennung für unsere Kund(inn)en und GitLabs DevOps-Innovationen.",[1039],"Ashley Kramer","2024-09-05","DevOps war ursprünglich nur ein Konzept – eine Methode, um Software schneller bereitzustellen, indem traditionell getrennte Teams zusammengebracht werden. Es war eine Antwort auf alle Probleme, die durch die Trennung zwischen denen, die Software entwickelten, und denen, die sie einsetzten, verursacht wurden. \n\nBei GitLab haben wir dieses Konzept weiterentwickelt: Anstatt Tools zu einer komplexen DevOps-Toolchain zusammenzufügen, würde eine [einheitliche DevOps-Plattform](https://about.gitlab.com/de-de/platform/) eine engere Zusammenarbeit, eine stärkere Automatisierung sowie skalierbare und standardisierte Prozesse ermöglichen. \n\nWir glauben, dass diese Strategie, die auf den Erfolg unserer Kund(inn)en ausgerichtet ist, die richtige Wahl war. In der zweiten Iteration des [Gartner Magic Quadrant für DevOps-Plattformen](https://about.gitlab.com/de-de/gartner-magic-quadrant/) sind wir erneut Leader. Diesmal sind wir auf beiden Achsen „Ability to Execute“ und „Completeness of vision“ am besten positioniert.\n\n![Bild von Gartner MQ für DevOps-Plattformen 2024](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674334/Blog/Content%20Images/figure1.png)\n\n> Lade den [Bericht des Gartner® Magic Quadrant™ für DevOps-Plattformen 2024](https://about.gitlab.com/gartner-magic-quadrant/) herunter.\n\nDie Softwareunternehmen von heute müssen sich mit zunehmenden Sicherheitsbedrohungen, komplexen Compliance-Anforderungen und der vorsichtigen Einführung neuer Technologien wie generativer KI auseinandersetzen. Außerdem müssen sie ihr Versprechen von skalierbaren Dienstleistungen und kontinuierlicher Innovation gegenüber ihren eigenen Kund(inn)en einhalten.\n\nMit GitLab können unseren Kund(inn)en sich diesen Herausforderungen stellen und in ihren Branchen führend werden. Dank unserer KI-basierten DevSecOps-Plattform wird die Sicherheit früher im SDLC berücksichtigt, Transparenz im gesamten Entwicklungslebenszyklus geschaffen und alle Beteiligten zusammengebracht, um die Software zu entwickeln, die unsere Welt antreibt.\n\n## Die DevOps-Vision fördern\n\nUnsere Arbeit hier ist noch nicht erledigt. Wir werden die DevOps-Vision weiter vorantreiben und unsere DevSecOps-Plattform auf zwei Arten weiterentwickeln.\n\nZum einen wollen wir noch mehr Teams dazu einladen, auf einer gemeinsamen Plattform zusammenzuarbeiten, und zwar mit speziellen Funktionen für diejenigen, die sich mit [Agile Planning](https://about.gitlab.com/de-de/blog/categories/agile-planning/), [Data Science](https://about.gitlab.com/de-de/topics/devops/the-role-of-ai-in-devops/) und [Beobachtbarkeit und Anwendungsüberwachung](https://docs.gitlab.com/operations/observability/) (englischsprachige Seite) beschäftigen.\n\nZum anderen wollen wir die Optionen für die Einführung und Bereitstellung unserer Plattform noch flexibler gestalten, um die unterschiedlichen Bedürfnisse unserer Kund(inn)en zu erfüllen. Dazu gehört auch die Investition in [GitLab Dedicated](https://about.gitlab.com/de-de/dedicated/), unsere gehostete Single-Tenant-Option, mit der Unternehmen in stark regulierten Branchen die Einfachheit von SaaS und die Leistungsfähigkeit der neuesten Funktionen und Möglichkeiten nutzen und gleichzeitig die Compliance-Anforderungen einer isolierten Infrastruktur erfüllen können.\n\n## Unterstützung von Unternehmen bei der Entwicklung sicherer Software\n\nNeben der Entwicklung einer besseren Plattform für die Zusammenarbeit bei der Bereitstellung von Software gehört es zu den wichtigsten Aufgaben von GitLab, Unternehmen bei der Entwicklung sicherer und gesetzeskonformer Software zu unterstützen. Unsere Vision unterscheidet uns hier von anderen, denn GitLab integriert [Sicherheitsscans](https://about.gitlab.com/de-de/solutions/security-compliance/) bereits bei der Übergabe des Codes und nicht erst, wenn die Anwendungen zur Veröffentlichung bereit sind. Das hilft den Teams, Sicherheitslücken früher zu erkennen, was zu schnelleren Release-Zyklen führt. GitLab erleichtert außerdem die Einhaltung von Richtlinien durch Leitlinien und die automatische Erstellung [einer Software-Stückliste](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/).\n\nWir wissen, dass unsere Kund(inn)en mit immer mehr Sicherheitsbedrohungen konfrontiert sind, wenn die Angriffsfläche für ihre eigene Software wächst. Deshalb planen wir, in den nächsten 12 Monaten unsere SAST-Scanner weiter zu verbessern, zusätzliche Richtlinienkontrollen hinzuzufügen und [einen neuen nativen Geheimnismanager](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/) (englischsprachiger Artikel) zu erstellen.\n\n## Führend mit KI im gesamten SDLC\n\nUnsere Vision ist es, auch im Bereich KI führend zu sein – und zwar nicht nur, wenn es darum geht, unseren Kund(inn)en zu ermöglichen, innovative Software mit KI zu entwickeln, sondern auch, wenn es darum geht, dies mit datenschutzorientierter KI-Technologie zu tun. Die künstliche Intelligenz bedeutet einen gewaltigen Sprung nach vorn und bietet unglaublich viele Möglichkeiten, wenn sie in den gesamten Software-Entwicklungsprozess integriert wird. Wir entwickeln Innovationen verantwortungsbewusst. Wir haben die Bedenken unserer Kund(inn)en gehört: Sie wollen [KI mit Leitlinien](https://about.gitlab.com/the-source/ai/velocity-with-guardrails-ai-automation/) (englischsprachiger Artikel), [KI, die transparent ist](https://about.gitlab.com/de-de/ai-transparency-center/) und KI, die ihren Code und ihr geistiges Eigentum respektiert.\n\n[GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/), eine Suite von KI-gestützten Funktionen für unsere DevSecOps-Plattform, soll die folgenden Kriterien erfüllen: sie soll umfassend, datenschutzorientiert und den gesamten Lebenszyklus der Softwareentwicklung unterstützen.\n\nWir glauben, dass dieses Engagement und unsere GitLab-Duo-Funktionen der Grund dafür sind, dass [Gartner® uns kürzlich auch in seinem ersten Magic Quadrant™ für KI-Programmierassistenten zum Leader ernannt hat](https://about.gitlab.com/de-de/blog/gitlab-named-a-leader-in-2024-gartner-magic-quadrant-for-ai-code-assistants/).\n\nWir sind stolz auf diese Auszeichnung und sehen sie als Signal, weiterhin auf euch – unsere Kund(inn)en – zu hören, denn das treibt unsere Vision, unsere Produkt-Roadmap und unser Engagement an, die beste DevSecOps-Plattform zu liefern.\n\n> Lade den [Bericht des Gartner® Magic Quadrant™ für DevOps-Plattformen 2024](https://about.gitlab.com/de-de/gartner-magic-quadrant/) herunter.\n\n***Quelle: Gartner, Magic Quadrant für DevOps-Plattformen, Keith Mann, Thomas Murphy, Bill Holz, George Spafford, August 2024***\n\n***GARTNER ist eine eingetragene Marke und Dienstleistungsmarke von Gartner, Inc. und/oder seinen verbundenen Unternehmen in den USA und international, und MAGIC QUADRANT ist eine\neingetragene Marke von Gartner, Inc. und/oder seinen verbundenen Unternehmen und wird hierin mit Genehmigung verwendet. Alle Rechte vorbehalten.***\n\n***Gartner empfiehlt keine Anbieter, Produkte oder Dienstleistungen, die in seinen Forschungspublikationen abgebildet sind, und rät Technologiebenutzer(inne)n nicht, nur die Anbieter mit den höchsten Bewertungen oder anderen Bezeichnungen auszuwählen. Gartner-Forschungspublikationen stellen die Meinungen der Forschungsorganisation von Gartner dar und sollten nicht als Tatsachenbehauptungen ausgelegt werden. Gartner lehnt alle ausdrücklichen oder stillschweigenden Gewährleistungen in Bezug auf diese Studie ab, einschließlich aller Gewährleistungen der Marktgängigkeit oder Eignung für einen bestimmten Zweck.***\n\n***Diese Grafik wurde von Gartner Inc. als Teil eines umfassenderen Berichts veröffentlicht und sollte im Kontext des gesamten Dokuments bewertet werden. Das Gartner-Dokument ist auf Anfrage bei Gartner erhältlich.***",[742,1017,807,922,715],"2025-04-28",{"slug":1045,"featured":91,"template":796},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"category":750,"slug":754,"posts":1047},[1048,1061,1074],{"content":1049,"config":1059},{"heroImage":1050,"body":1051,"authors":1052,"updatedDate":976,"date":1055,"title":1056,"tags":1057,"description":1058,"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.\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/),\nallen das Mitwirken zu ermöglichen, wollten wir es besser machen.\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\nund übertrafen damit erstmals unser Teamziel von 170.\n\nDrei Monate später brachen wir den Rekord erneut mit 192.\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## Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben\n\n2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch.\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\nDie Teilnehmenden sagten uns:\n\n* Die Mitwirkenden-Dokumentation war verwirrend\n* Der Einstieg fühlte sich überwältigend an\n* Es war nicht klar, wie oder wo man Hilfe finden konnte\n\nNur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.\n\nEs wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben.\nAlso haben wir [iteriert](https://handbook.gitlab.com/handbook/values/#iteration)!\n\nUnser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools\nwie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.\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\nMaintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.\n\nNoch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten:\n„Ich fühlte einen kleinen Adrenalinstoß bei dem Gedanken, sagen zu können: ‚Ich habe beim Aufbau von GitLab geholfen.'\"\n\n## Wir haben persönliches Onboarding mit GitLab aufgebaut\n\nUnsere Lösung begann mit Engagement.\nUm Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden\nMitwirkenden mit einem Community-Maintainer verbindet.\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\nDas Onboarding-Issue behandelt auch die Zugangsgenehmigung für die\n[GitLab Community Forks](https://about.gitlab.com/blog/gitlab-community-forks/),\neine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten\nund auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.\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![GitLab onboarding issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\nWir begannen mit einem Ruby-Skript, das über eine [geplante Pipeline](https://docs.gitlab.com/ci/pipelines/schedules/) ausgeführt wurde,\nnach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.\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## Wir standardisierten Antworten mit Kommentar-Templates\n\nMit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.\n\nWir erstellten [Kommentar-Templates](https://docs.gitlab.com/user/profile/comment_templates/),\ndie wir mit dem Repository über die GraphQL-API und ein\n[Ruby-Skript](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb) synchronisieren.\n\nDas Skript wird in `.gitlab-ci.yml` ausgelöst, wenn Änderungen an Kommentar-Templates\nzum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).\n\n```yaml\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![GitLab comment template](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n## Wir eliminierten die 5-Minuten-Wartezeit\n\nUnsere erste Iteration war etwas langsam.\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.\nFünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.\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\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\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```json\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![Pipeline list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n## Wir automatisierten Nachfassaktionen\n\nMit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen,\nhatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.\n\nWir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden.\nDies schafft ein klares Signal des Issue-Status für Maintainer.\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\nstupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.\n\n![Automated nudge for idle GitLab onboarding issues](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n## Wir organisierten die Issue-Verfolgung mit GLQL\n\nWir bauten eine [GLQL-Ansicht](https://docs.gitlab.com/user/glql/), um Issues im Blick zu behalten.\nDiese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen,\ndamit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.\n\n![GLQL view of issue tracking](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\nDiese GLQL-Ansichten verbesserten unsere gesamte Triage-[Effizienz](https://handbook.gitlab.com/handbook/values/#efficiency).\nEs war so erfolgreich, dass wir diese Strategie auch bei den Programmen [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/)\nund [GitLab for Education](https://about.gitlab.com/solutions/education/) anwendeten.\nMit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.\n\n## Wir machten die README auffindbar\n\nDie [@gitlab-community-Gruppe](https://gitlab.com/gitlab-community/)\nist das Zuhause für Mitwirkende auf GitLab.com.\nWir hatten bereits eine `README.md`-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei\nbefand sich in unserem Meta-Projekt.\nMit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre\nOnboarding-Issues unter einem anderen Projekt waren.\n\nWir nutzten [GitLabs Projekt-Spiegelung](https://docs.gitlab.com/user/project/repository/mirror/),\num dies zu lösen und spiegelten das Meta-Projekt zu `gitlab-profile`.\nDies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.\n\n![GitLab project mirroiring](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n![Group README](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n## Die Ergebnisse sprechen für sich selbst\n\nDurch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine\nund transformierten die GitLab-Mitwirkenden-Journey.\nWir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen,\nFunktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.\n\nUnser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der\nMitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.\n\n![Community forks growth chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\nWir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie\nschneller mit Maintainern verbinden und sie beim Einstieg unterstützen.\nWir nutzen [GitLabs Value Stream Analytics](https://docs.gitlab.com/user/group/value_stream_analytics/),\num unsere Antwortzeiten zu verfolgen.\n\n* Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten\n* Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde\n\n![Value stream analytics timeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\nDie 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.\n\n## Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden\n\nDie Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von\nMitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen.\nDas Ergebnis ist [contributors.gitlab.com](https://contributors.gitlab.com/).\nWir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten,\nErfolge und Belohnungen bietet.\nMitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.\n\n## Was wir gelernt haben teilen\n\nDiese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar.\nWir teilen unseren Ansatz über Communities und Konferenzen hinweg, damit andere Projekte in Betracht ziehen können, diese Tools zum Wachstum zu nutzen.\n\nWenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen.\nMit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten.\nWir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.\n\n## Das Gespräch beginnen\n\nMöchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst?\nSende eine E-Mail an `contributors@gitlab.com` oder [öffne ein Issue](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues),\num eine Diskussion zu beginnen.\nWir sind hier, um beim Aufbau von Communities zu helfen.",[1053,1054],"Lee Tickett","Daniel Murphy","2025-07-15","Von 17 % auf 100 %: Wie wir das Open-Source-Onboarding revolutionierten",[893,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":796,"slug":1060},"how-we-use-gitlab-to-grow-open-source-communities",{"content":1062,"config":1072},{"title":1063,"description":1064,"authors":1065,"heroImage":1067,"body":1068,"date":1069,"category":754,"tags":1070},"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.",[1066],"Justin Tobler","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","Das Git-Projekt hat kürzlich [Git Version 2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u) veröffentlicht. Werfen wir einen Blick auf die Highlights dieser Veröffentlichung, die Beiträge des Git-Teams von GitLab und der gesamten Git-Community enthält.\n\n## Neuer Befehl git-diff-pairs(1)\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\nIm Hintergrund wird die Diff-Generierung von [`git-diff(1)`](https://git-scm.com/docs/git-diff/de) verwendet. Ein Beispiel:\n\n```shell\n$ git diff HEAD~1 HEAD\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\nes eine Möglichkeit gäbe, die Diff-Berechnung in kleinere, leichter verarbeitbare Blöcke zu unterteilen.\n\nEine Möglichkeit dafür ist die Verwendung von\n[`git-diff-tree(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-diff-tree), um Informationen\nüber alle geänderten Dateien abzurufen:\n\n```shell\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\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).\nKurz gesagt, listet jede Zeile der Ausgabe Dateipaare und die dazugehörigen Metadaten\ndarüber auf, was sich zwischen dem Anfangscode und der letzten Revision geändert hat. Im Vergleich zur\nErzeugung der „Patch“-Ausgabe für große Änderungen verläuft dieser Prozess relativ\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\nMit diesen Informationen könnten wir `git-diff(1)` verwenden, um jedes der\nDateipaar-Diffs einzeln zu erstellen. Zum Beispiel können wir die Blob-IDs\ndirekt angeben:\n\n```shell\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f\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\nseparaten Git-Prozess zu starten.\nAußerdem verliert das Diff bei der Verwendung von Blob-IDs einige Kontextinformationen,\nwie den Änderungsstatus und die Dateimodi, die im übergeordneten\nBaumobjekt gespeichert sind. Was wir wirklich möchten, ist ein Mechanismus, um „unbearbeitete“ Dateipaarinformationen einzuspeisen und\ndie entsprechende Patch-Ausgabe zu generieren.\n\nMit der Version 2.50 bietet Git einen neuen integrierten Befehl mit der Bezeichnung\n[`git-diff-pairs(1)` (in englischer Sprache verfügbar](https://git-scm.com/docs/git-diff-pairs). Dieser Befehl\nakzeptiert „unbearbeitete“ formatierte Dateipaarinformationen als Eingabe auf stdin, um exakt zu bestimmen, welche Patches ausgegeben werden sollen. Das folgende Beispiel zeigt, wie dieser Befehl\nverwendet werden kann:\n\n```shell\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n```\n\nBei dieser Nutzung ist die resultierende Ausgabe identisch mit der Verwendung von `git-diff(1)`.\nDurch einen separaten Befehl zur Generierung der Patch-Ausgabe kann die „unbearbeitete“ Ausgabe von\n`git-diff-tree(1)` in kleinere Chargen von Dateipaaren aufgeteilt und separaten\n`git-diff-pairs(1)`-Prozessen zugeführt werden. Dies löst das zuvor erwähnte\nSkalierbarkeitsproblem, da die Diffs nicht länger alle auf einmal berechnet werden müssen. Zukünftige\nGitLab-Versionen könnten auf diesem Mechanismus aufbauen, um die Leistung der\nDiff-Generierung zu verbessern, insbesondere wenn es sich um große Änderungssätze\nhandelt. Weitere Informationen zu dieser Änderung findest du im entsprechenden\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n*Dieses Projekt wurde von [Justin Tobler](https://gitlab.com/justintobler) geleitet.*\n\n## Gesammelte Referenz-Updates\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\nangegeben werden, die auf stdin durchgeführt werden soll.\nDie Massenaktualisierung von Referenzen auf diese Weise zeigt auch ein atomares Verhalten, bei dem ein\neinzelner Fehler bei der Referenzaktualisierung eine Transaktion abbricht und\nReferenzen nicht aktualisiert werden. Hier ist ein Beispiel für dieses Verhalten:\n\n```shell\n# Erstelle ein Repository mit drei leeren Commits und einem Branch mit dem Namen „foo“\n$ git init\n$ git commit --allow-empty -m 1\n$ git commit --allow-empty -m 2\n$ git commit --allow-empty -m 3\n$ git branch foo\n\n# Gib die Commit-IDs aus\n$ git rev-list HEAD\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n5a74cd330f04b96ce0666af89682d4d7580c354c\n5a6b339a8ebffde8c0590553045403dbda831518\n\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n# Es wird erwartet, dass die Aktualisierung fehlschlägt, da die angegebene alte Objekt-ID nicht richtig ist.\n$ git update-ref --stdin \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nfatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c\n\n# Die Referenz „bar“ wurde nicht erstellt.\n$ git switch bar\nfatal: invalid reference: bar\n```\n\nIm Vergleich zur einzelnen Aktualisierung vieler Referenzen ist die Massenaktualisierung\nauch viel effizienter. Das ist zwar grundsätzlich eine gute Lösung, aber es kann bestimmte\nUmstände geben, unter denen es akzeptabel ist, wenn ein Teil der angeforderten Referenzaktualisierungen\nfehlschlägt, wir aber dennoch die Effizienzvorteile von\nMassenaktualisierungen nutzen möchten.\n\nAb dieser Version verfügt `git-update-ref(1)` über die neue Option `--batch-updates`, mit\nder die Aktualisierungen auch dann fortgesetzt werden können, wenn eine oder mehrere Referenzaktualisierungen\nfehlschlagen. In diesem Modus werden einzelne Fehler im folgenden Format gemeldet:\n\n```text\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP \u003Crejection-reason> LF\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```shell\n# Versuche, eine neue Referenz zu erstellen und die vorhandene Referenz in der Transaktion zu aktualisieren.\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c\n> EOF\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n# Die Referenz „bar“ wurde erstellt, obwohl die Aktualisierung auf „foo“ abgelehnt wurde.\n$ git switch bar\nSwitched to branch 'bar'\n```\n\nMit der Option `--batch-updates` war die Referenzerstellung diesmal erfolgreich,\nobwohl die Aktualisierung nicht funktioniert hat. Diese Patch-Serie legt den Grundstein für\nzukünftige Leistungsverbesserungen in `git-fetch(1)` und `git-receive-pack(1)`,\nwenn Referenzen in großer Zahl aktualisiert werden. Weitere Informationen findest du im\n[Mailinglisten-Thread](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)\n\n*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n## Neue Filteroption für git-cat-file(1)\n\nMit [`git-cat-file(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-cat-file) ist es möglich,\nInformationen für alle im Repository enthaltenen Objekte über die Option\n`--batch–all-objects` auszugeben. Zum Beispiel:\n\n```shell\n# Richte ein einfaches Repository ein.\n$ git init\n$ echo foo >foo\n$ git add foo\n$ git commit -m init\n\n# Erstelle ein nicht erreichbares Objekt.\n$ git commit --amend --no-edit\n\n# Verwende git-cat-file(1), um Informationen über alle Objekte einschließlich nicht erreichbarer Objekte auszugeben.\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nIn einigen Situationen möchte ein(e) Benutzer(in) möglicherweise alle Objekte im\nRepository durchsuchen, aber nur eine Teilmenge basierend auf einem bestimmten Attribut ausgeben. Wenn\nwir beispielsweise nur die Objekte anzeigen möchten, die Commits sind, könnten wir\n`grep(1)` verwenden:\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nDas funktioniert zwar, aber ein Nachteil beim Filtern der Ausgabe ist, dass\n`git-cat-file(1)` nach wie vor alle Objekte im Repository durchlaufen muss, auch\ndiejenigen, an denen wir nicht interessiert sind. Dies kann ziemlich ineffizient sein.\n\nMit dieser Version verfügt `git-cat-file(1)` jetzt über die Option `--filter`, die nur jene Objekte\nanzeigt, die den angegebenen Kriterien entsprechen. Dies ähnelt der gleichnamigen Option\nfür `git-rev-list(1)`, unterstützt jedoch nur eine Teilmenge der\nFilter. Die folgenden Filter werden unterstützt: `blob:none`, `blob:limit=` und\n`object:type=`. Ähnlich wie im vorherigen Beispiel können Objekte mit Git direkt nach\nihrem Typ gefiltert werden:\n\n```shell\n$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n```\n\nEs ist nicht nur praktisch, dass Git die Verarbeitung übernimmt, sondern bei großen\nRepositories mit vielen Objekten ist dies möglicherweise auch effizienter. Wenn ein\nRepository über Bitmap-Indizes verfügt, kann Git Objekte eines bestimmten Typs effizient\nnachschlagen und so das Durchsuchen der\nPaketierungsdatei vermeiden, wodurch die Geschwindigkeit deutlich erhöht wird. Benchmarks, die im\n[Chromium-Repository](https://github.com/chromium/chromium.git) durchgeführt wurden, zeigen signifikante Verbesserungen:\n\n```text\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\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\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\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\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\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\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\nInteressanterweise zeigen diese Ergebnisse, dass die Berechnungszeit jetzt mit\nder Anzahl der Objekte für einen bestimmten Typ skaliert, anstatt mit der Anzahl der gesamten Objekte\nin der Paketierungsdatei. Den ursprünglichen (englischsprachigen) Mailinglisten-Thread findest du\n[hier](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n*Dieses Projekt wurde von [Patrick Steinhardt](https://gitlab.com/pks-gitlab) geleitet.*\n\n## Verbesserte Leistung beim Generieren von Bundles\n\nGit bietet die Möglichkeit, über den Befehl\n[`git-bundle(1)` (in englischer Sprache verfügbar)](https://git-scm.com/docs/git-bundle) ein Archiv eines Repositories zu generieren, das einen\nbestimmten Satz von Referenzen und zugehörigen erreichbaren Objekten enthält. Dieser Vorgang\nwird von GitLab verwendet, um Repository-Backups zu erstellen, und ist auch ein Teil des\n[Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus.\n\nBei großen Repositories mit Millionen von Referenzen kann dieser Vorgang Stunden oder sogar Tage\ndauern. Zum Beispiel lagen die Backup-Zeiten für das Haupt-GitLab-Repository\n([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), bei\netwa 48 Stunden. Die Untersuchung zeigte einen Leistungsengpass, der\nauf die Art zurückzuführen war, wie Git eine Überprüfung durchführte, um zu vermeiden, dass doppelte Referenzen\nin das Bundle aufgenommen wurden. Die Implementierung verwendete eine verschachtelte `for`-Schleife, um alle aufgelisteten Referenzen zu durchlaufen und zu\nvergleichen, was zu einer Zeitkomplexität von O(N^2) führte. Die Skalierbarkeit\nist sehr schlecht, wenn die Anzahl der Referenzen in einem Repository zunimmt.\n\nIn dieser Version wurde dieses Problem behoben, indem die verschachtelten Schleifen durch eine \nDatenzuordnungsstruktur ersetzt wurden, was die Geschwindigkeit erheblich erhöht. Der folgende Benchmark zeigt\ndie Leistungssteigerung beim Erstellen eines Bundles mit einem Repository, das\n100 000 Referenzen enthält:\n\n```text\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\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\nSummary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\nWeitere Informationen findest du in unserem Blogbeitrag\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/).\nDen ursprünglichen englischsprachigen Mailinglisten-Thread findest du\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*Dieses Projekt wurde von [Karthik Nayak](https://gitlab.com/knayakgl) geleitet.*\n\n## Bessere Auflösung von URI-Bundles\n\nDurch den [Bundle-URI (in englischer Sprache verfügbar)](https://git-scm.com/docs/bundle-uri)-Mechanismus in Git können den Clients\nOrte zum Abrufen von Bundles zur Verfügung gestellt werden, um\nKlone und Abrufe zu beschleunigen. Wenn ein Client ein Bundle herunterlädt, werden Referenzen\nunter `refs/heads/*` zusammen mit\nden zugehörigen Objekten aus dem Bundle in das Repository kopiert. Ein Bundle kann zusätzliche Referenzen\naußerhalb von `refs/heads/*` enthalten, wie z. B. `refs/tags/*`, die einfach ignoriert werden, wenn\ndie Bundle-URI beim Klonen verwendet wird.\n\nIn Git 2.50 wird diese Einschränkung aufgehoben und alle Referenzen, die mit\n`refs/*` übereinstimmen und im heruntergeladenen Bundle enthalten sind, werden kopiert.\n[Scott Chacon](https://github.com/schacon), der diese Funktionalität beigesteuert hat,\ndemonstriert den Unterschied beim Klonen von\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss):\n\n```shell\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\nCloning into 'gl2.49'...\nremote: Enumerating objects: 1092703, done.\nremote: Counting objects: 100% (973405/973405), done.\nremote: Compressing objects: 100% (385827/385827), done.\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\nChecking objects: 100% (4194304/4194304), done.\nChecking connectivity: 959668, done.\nUpdating files: 100% (59972/59972), done.\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\nCloning into 'gl-2.50'...\nremote: Enumerating objects: 65538, done.\nremote: Counting objects: 100% (56054/56054), done.\nremote: Compressing objects: 100% (28950/28950), done.\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\nUpdating files: 100% (59972/59972), done.\n```\n\nWenn wir diese Ergebnisse vergleichen, sehen wir, dass Git 2.50 43 887 Objekte\n(40,42 MiB) abruft, nachdem das Bundle extrahiert wurde, während Git 2.49\ninsgesamt 959 773 Objekte (366,94 MiB) abruft. Git 2.50 ruft etwa 95 % weniger\nObjekte und 90 % weniger Daten ab, was vorteilhaft sowohl für den Client als auch für den Server ist. Der\nServer muss viel weniger Daten für den Client verarbeiten und der Client muss weniger Daten\nherunterladen und extrahieren. In dem von Scott angegebenen Beispiel führte dies zu einer\nBeschleunigung um 25 %.\n\nWeitere Informationen findest du im entsprechenden englischsprachigen\n[Mailinglisten-Thread](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n*TDiese Patch-Serie wurde von [Scott Chacon](https://github.com/schacon) beigesteuert.*\n\n## Weiterlesen\n\nIn diesem Artikel werden nur einige der Beiträge von GitLab und\nder größeren Git-Community für diese neueste Veröffentlichung vorgestellt. Mehr darüber erfährst du in\nder [offiziellen Veröffentlichungsankündigung](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/) des Git-Projekts. Sieh dir auch\nunsere [letzten Blogbeiträge zu Git-Releases (in englischer Sprache verfügbar)](https://about.gitlab.com/blog/tags/git/)\nan, um weitere wichtige Beiträge von GitLab-Teammitgliedern zu entdecken.","2025-06-16",[1071,893,269],"git",{"featured":91,"template":796,"slug":1073},"what-s-new-in-git-2-50-0",{"content":1075,"config":1084},{"title":1076,"description":1077,"authors":1078,"heroImage":1080,"date":1081,"body":1082,"category":754,"tags":1083,"updatedDate":789},"20 Jahre GitLab: Begib dich mit uns auf eine Reise","Begib dich mit uns auf die Spuren des ersten Commits, die einzigartigen Aspekte der frühen Releases und die Verwirrung, die ein Update des Standardverhaltens von git-push(1) ausgelöst hat.",[1079],"Patrick Steinhardt","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","2025-04-14","Das Git-Projekt ist gerade 20 Jahre alt geworden. In diesen Jahren ist viel passiert – während das konzeptionelle Design von [GitLab](https://about.gitlab.com/de-de/) seit seiner Entstehung nicht wesentlich verändert wurde, hat sich doch die Art und Weise, wie Benutzer(innen) mit dem Tool interagieren, deutlich geändert. Wir bei GitLab sind stolz darauf, auf dieser wichtigen Software aufzubauen und Teil ihrer Erfolgsgeschichte zu sein.\n\nBegleite uns auf einer Reise durch die Geschichte von Git und entdecke, wie sich das System im Laufe der Jahre entwickelt hat.\n\n## Der erste Commit\n\nDer erste Commit wurde am 7. April 2005 von [Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/), dem Schöpfer des Linux-Kernels, vorgenommen: `e83c5163316 (Initial revision\nof \"git\", the information manager from hell, 2005-04-07)`.\n\nWie wir sehen können, enthält dieser Commit nicht viele Dateien:\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nNeben der Build-Infrastruktur bietet der erste Commit sieben Top-Level-Befehle:\n\n- `init-db` zum Initialisieren eines neuen Git-Repositorys\n- `update-cache` zum Hinzufügen von Dateien zum Index\n- `write-tree`, um den Inhalt des Index heranzuziehen und daraus einen neuen Baum zu erstellen\n- `read-tree` zum Lesen eines Baum-Objekts\n- `commit-tree` zum Erstellen eines Commits aus einem Baum\n- `cat-file` zum Lesen eines spezifischen Objekts in eine temporäre Datei\n\nBeachte, dass der Befehl `git` zu der Zeit noch gar nicht existierte.\n\nStattdessen mussten diese Befehle direkt ausgeführt werden.\n\nErstellen wir zum Beispiel ein neues Repository:\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nDas sieht ziemlich unbekannt aus: Es gibt kein `.git`-Verzeichnis, aber dafür gibt es das Verzeichnis `.dircache`. Und wo war der private Speicherbereich?\n\nDas frühe Design von Git unterschied zwischen einem „geteilten“ und einem „privaten“ Objektspeicherbereich. In diesem Objektspeicherbereich befanden sich alle Git-Objekte. Zum Beispiel deine Commits und Blobs.\n\nStandardmäßig erstellte `init-db` einen privaten Objektspeicherbereich, der nur für das verwaltete Verzeichnis verwendet wurde, in dem es erstellt wurde. Ein „geteilter“ Objektspeicherbereich hingegen teilte Objektinhalte über mehrere verwaltete Verzeichnisse, so dass dasselbe Objekt nicht zweimal gespeichert werden musste.\n\n### Einen Commit erstellen\n\nWir haben nun ein Repository, doch wie wurde damals ein Commit erstellt? Das war nicht ganz so einfach wie heute mit `git add . && git commit`. Stattdessen musste man wie folgt vorgehen:\n\n1. Man musste den Index aktualisieren, indem man `update-cache` für jede Datei aufrief, die man hinzufügen wollte.\n2. Dann schrieb man einen neuen Baum, indem man `write-tree` aufrief, wodurch alles herangezogen wurde, was zum Index hinzugefügt worden war.\n3. Man richtete Umgebungsvariablen ein, um Git mitzuteilen, wer man ist.\n4. Dann schrieb man ein Commit-Objekt, indem man `commit-tree` aufrief.\n\nErstellen wir einen Commit im Repository:\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\nDas ist nicht gerade ergonomisch, aber es funktioniert! Werfen wir einen Blick auf den generierten Commit:\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\nBeachte, dass `cat-file` den Inhalt nicht direkt gedruckt hat, sondern ihn zuerst in eine temporäre Datei geschrieben hat. Der Inhalt der Datei sieht jedoch genauso aus, wie ein moderner Commit aussehen würde.\n\n### Änderungen vornehmen\n\nWie können wir nun den Status der Dateien ermitteln? Vielleicht hast du es erraten: mit `show-diff`:\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\nLustigerweise konnte `show-diff` bereits diffs zwischen dem alten und neuen Zustand der geänderten Datei generieren! Git hat das jedoch erreicht, indem es einfach das Unix-Tool diff(1) ausgeführt hat.\n\nZusammenfassend lässt sich sagen, dass dies zwar alles noch recht spartanisch war, aber das Nötige bot, um den Verlauf nachzuverfolgen. Es gab aber noch viele Einschränkungen:\n\n- Es gab noch keine einfache Möglichkeit, zwischen Commits zu wechseln.\n- Es gab keine Möglichkeit, Protokolle anzuzeigen.\n- Es gab keine Branches, Tags und nicht einmal Referenzen. Von den Benutzer(inne)n wurde erwartet, dass sie die Objekt-IDs manuell verfolgen.- Es gab keine Möglichkeit, zwei Repositories miteinander zu synchronisieren. Stattdessen wurde von den Benutzer(inne)n erwartet, dass sie „rsync(1)“ verwenden, um die `.dircache`-Verzeichnisse zu synchronisieren.\n- Es gab keine Möglichkeit, Merges durchzuführen.\n\n## Git 0.99\n\nDie erste Testversion von Git war Version 0.99. Diese Release kam nur zwei Monate nach dem ersten Commit auf, enthielt aber bereits 1.076 Commits. Es waren fast 50 verschiedene Entwickler(innen) beteiligt. Der häufigste Commiter war zu diesem Zeitpunkt Linus selbst, dicht gefolgt von Junio Hamano, dem aktuellen Betreuer.\n\nViele Dinge hatten sich seit dem ersten Commit geändert:\n\n- Git begann, verschiedene Entwicklungs-Branches mithilfe von Referenzen zu verfolgen, wodurch in den meisten Fällen Objekt-IDs nicht mehr manuell nachverfolgt werden mussten.\n- Es gab ein neues Remote-Protokoll, das es zwei Repositories ermöglichte, Objekte miteinander auszutauschen.\n- Das Verzeichnis `.dircache` wurde in `.git` umbenannt.\n- Es wurde möglich, einzelne Dateien zusammenzuführen.\n\nDie wichtigste offensichtliche Änderung war jedoch die Einführung des Top-Level-Befehls `git` und seiner Unterbefehle. Interessanterweise wurden mit dieser Version auch die Befehle „Plumbing“ und „Porcelain“ eingeführt:\n\n- „Plumbing“-Tools sind Low-Level-Befehle, die auf das zugrunde liegende Git-Repository zugreifen.\n- „Porcelain“-Tools sind Shell-Skripte, die die Plumbing-Befehle einpacken, um eine schönere, hochwertige Benutzeroberfläche zu bieten.Diese Aufteilung existiert auch heute noch, wie in [`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain) dokumentiert ist. Da die meisten Porcelain-Tools jedoch von Shell-Skripten zu C umgeschrieben wurden, verschwimmt die Trennung zwischen den beiden Kategorien mittlerweile deutlich.\n\n## Linus übergibt die Leitung\n\nLinus hat Git nie gegründet, weil sein Herz für Versionskontrollsysteme schlägt, sondern weil er für die Entwicklung des Linux-Kernels eine brauchbare Alternative zu BitKeeper suchte. Daher hatte er nie vor, Git für immer zu leiten. Die Absicht war, es so lange zu leiten, bis er eine(n) vertrauenswürdige(n) Nachfolger(in) gefunden hatte.\n\nDieser Jemand war Junio Hamano. Junio stieg etwa eine Woche nach dem ersten Commit von Linus bei Git ein und hatte nach der Veröffentlichung von Git 0.99 bereits einige hundert Commits im Verlauf. Am 26. Juli 2005 machte [Linus daher Junio zum neuen Betreuer des Git-Projekts](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/). Linus trug zwar weiter zu Git bei, doch seine Beteiligung wurde nach und nach immer weniger – nicht verwunderlich, da er als Leiter des Linux-Projektes ziemlich beschäftigt ist.\n\nJunio leitet das Git-Projekt auch heute noch.\n\n> Lies unser großes [Interview mit Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/) und erfahre noch mehr über die Geschichte von Git.\n\n## Git 1.0\n\nDie erste größere Version von Git wurde am 21. Dezember 2005 von Junio veröffentlicht. Interessanterweise gab es 34 Releases zwischen Version 0.99 und Version 1.0: 0.99.1 bis 0.99.7, 0.99.7a bis 0.99.7d, 0.99.8 bis 0.99.8g und 0.99.9 bis 0.99.9n.\n\nEiner der wichtigsten Meilensteine seit Version 0.99 war wahrscheinlich der Befehl `git-merge(1)`, der hinzugefügt wurde und mit dem man zwei Bäume zusammenführen kann. Dies ist eine enorme Veränderung zu vorher, wo man im Grunde die Zusammenführungen Datei für Datei skripten musste.\n\n### Remotes\n\nEine weitere wesentliche Änderung war die Einführung der Kurzschreibweise für Remote-Repositories. Während Git bereits wusste, wie man mit Remote-Repositories kommuniziert, mussten Benutzer(innen) jedes Mal die URL angeben, von der sie abrufen wollten, um Änderungen daran vorzunehmen. Dies war ziemlich unpraktisch für die Benutzer(innen), da sie im Normalfall immer wieder mit demselben Remote interagieren wollten.\n\nDu weißt vielleicht, wie Remotes jetzt funktionieren, aber der Vorgang war damals noch deutlich anders. Es gab keinen `git-remote(1)`-Befehl, mit dem man seine Remotes verwalten konnte. Remotes wurden nicht einmal in der Datei `.git/config` gespeichert. Als Remotes in Version 0.99.2 eingeführt wurden, *gab* es in Git nicht einmal Konfigurationsdateien.\n\nStattdessen musste man Remotes konfigurieren, indem man eine Datei in das Verzeichnis `.git/branches` schrieb, was dem heutigen Empfinden nach gegen jegliche Intuition geht. Aber der Mechanismus funktioniert auch heute noch:\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nAber das ist noch nicht alles! Das Verzeichnis wurde bald darauf mit der Git-Version 0.99.5 in „remotes“ umbenannt, also gibt es in einem modernen Git-Client insgesamt drei verschiedene Möglichkeiten, Remotes zu konfigurieren.\n\nDie meisten von euch haben wahrscheinlich weder `.git/branches` noch `.git/remotes` verwendet, denn beide Mechanismen gelten seit 2005 bzw. 2011 als veraltet. Darüber hinaus werden diese Verzeichnisse in Git 3.0 endgültig entfernt.\n\n## Git-Branding\n\nIm Jahr 2007 wurde das erste Git-Logo erstellt. Ob man das schon als Logo bezeichnen kann, ist fraglich, da es nur aus drei roten Minuszeichen über drei grünen Pluszeichen bestand. Dies sollte widerspiegeln, wie die Ausgabe von `git diff` aussah:\n\n![Drei rote Minuszeichen über drei grünen Pluszeichen, die die Ausgabe von `git diff` widerspiegeln](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nEtwas später, im Jahr 2008, wurde die Website [git-scm.com](https://git-scm.com) veröffentlicht:\n\n![Startseite für git-scm.com im Jahr 2006](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\nIm Jahr 2012 wurde die Git-Webseite von Scott Chacon und Jason Long [überarbeitet](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/). Sie sieht ziemlich ähnlich aus wie heute:\n\n![Die Git-Website wurde 2012 überarbeitet](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\nDieses neue Design der Website weist das neue rot-orangefarbene Logo von Jason Long auf, das auch derzeit verwendet wird:\n\n![Git-Logo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nGit begann schon in der Version 1.0, dem modernen Git sehr ähnlich zu sehen. Daher folgt nun der große historische Sprung zu Git 2.0. Diese Version wurde etwa 10 Jahre nach Git 1.0 veröffentlicht und war die erste Version, die absichtlich abwärtskompatible Änderungen in zentralen Workflows enthielt.\n\n### Standardverhalten von `git-push(1)`\n\nDie Änderung, die wohl die meiste Verwirrung in dieser Version verursachte, war das geänderte Standardverhalten von `git-push(1)`.\n\nEs gibt ein paar verschiedene Aktionen, die Git ausführen kann, wenn du in ein Remote-Repository pusht und nicht genau angibst, was genau du pushen möchtest:\n\n- Git kann verweigern, irgendetwas zu tun, und bittet dich um weitere Informationen darüber, was genau du pushen möchtest.\n- Git kann den aktuell ausgecheckten Branch pushen.\n- Git kann den aktuell ausgecheckten Branch pushen, aber nur, wenn es weiß, dass es ein Äquivalent auf der Remote-Seite gibt.\n- Git kann alle deine Branches pushen, die ein Äquivalent auf der Remote-Seite haben.\n\nDas Verhalten des modernen Git ist die sogenannte „einfache“ Strategie, also die dritte der oben angeführten Optionen. Vor Git 2.0 war das Standardverhalten jedoch die „Matching“-Strategie, also die letzte der genannten Optionen.\n\nDie „Matching“-Strategie war deutlich riskanter. Man musste vor dem Pushen immer sicherstellen, dass es in Ordnung war, alle lokalen Branches zu pushen, die ein Äquivalent auf der Remote-Seite haben. Andernfalls hätte man möglicherweise unbeabsichtigt Änderungen gepusht. Daher wurde beschlossen, die Strategie auf die „einfache“ Strategie zu ändern, um das Risiko zu verringern und Einsteiger(inne)n die ersten Schritte mit Git zu erleichtern.\n\n### `git-add(1)`\n\nEine weitere große Änderung war das Standardverhalten von `git-add(1)` im Hinblick auf nachverfolgte Dateien, die gelöscht wurden. Vor Git 2.0 hätte `git-add(1)` gelöschte Dateien nicht automatisch gestaged, sondern du hättest jede gelöschte Datei manuell mit `git-rm(1)` hinzufügen müssen, damit sie Teil des Commits ist. Mit Git 2.0 wurde dieses Verhalten geändert, sodass `git-add(1)` auch gelöschte Dateien zum Index hinzufügt.\n\n## Wir feiern die Git-Community\n\nIch werde dich nicht mit Details darüber langweilen, wie Git heute funktioniert – du nutzt es wahrscheinlich ohnehin täglich, und wenn nicht, gibt es viele tolle Tutorials, die dir beim Einstieg helfen. Stattdessen wollen wir die Git-Community hochleben lassen – sie ist es nämlich, dank der Git auch 20 Jahre später noch wunderbar funktioniert.\n\nIm Laufe der Zeit hat Git:\n\n- 56 721 Commits seit der Veröffentlichung von Git 2.49 erhalten.\n- Beiträge von mehr als 2 000 verschiedenen Personen erhalten.\n- 60 Hauptversionen veröffentlicht.Das Git-Projekt hat auch einen stetigen Zustrom neuer Mitwirkender durch die Teilnahme am [Google Summer of Code](https://summerofcode.withgoogle.com/) und [Outreachy](https://www.outreachy.org/) erfahren. Neue Mitwirkende wie diese werden dafür sorgen, dass das Git-Projekt auch langfristig weitergeführt wird.\n\nDaher möchte ich allen Mitwirkenden von Herzen danken. Es sind eure Beiträge, die Git erst möglich gemacht haben.\n\n## Ein Blick in die Zukunft\n\nEs steht außer Frage, dass Git den Wettlauf um das beste Versionskontrollsystem gewonnen hat. Es hat einen bedeutenden Marktanteil, und es ist nicht einfach, Open-Source-Projekte zu finden, die ein anderes Versionskontrollsystem als Git verwenden. Git hat also eindeutig vieles richtig gemacht.\n\nDennoch ist die Entwicklung nicht stillgestanden und auch in Zukunft werden viele Herausforderungen auf Git warten. Einerseits sind das technische Herausforderungen:\n- Modernisierung einer alternden Codebasis\n- Skalierung mit der ständig wachsenden Größe von Monorepos\n- Bessere Handhabung großer Binärdateien\n\nAndererseits tauchen Probleme sozialer Art auf:\n- Verbesserung der Benutzerfreundlichkeit von Git\n- Förderung der Git-Community, damit das Projekt langfristig gesund bleibt\n\nEs gibt immer noch viel zu tun und wir bei GitLab sind stolz darauf, Teil dieser Bemühungen zu sein. Gemeinsam können wir sicherstellen, dass Git auch in den nächsten 20 Jahren ein so fantastisches Versionskontrollsystem bleibt.\n\n## Erfahre mehr über Git\n\n- [Wir feiern das 20-jährige Git-Jubiläum mit dessen Erfinder Linus Torvalds](https://about.gitlab.com/de-de/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n- [Was gibt es Neues in Git 2.49.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-49-0/)\n- [Was gibt es Neues in Git 2.48.0?](https://about.gitlab.com/de-de/blog/whats-new-in-git-2-48-0/)\n- [Der Anfängerleitfaden zum „reftable“-Format von Git](https://about.gitlab.com/de-de/blog/a-beginners-guide-to-the-git-reftable-format/)",[893,1071],{"slug":1085,"featured":91,"template":796},"journey-through-gits-20-year-history",{"category":90,"slug":764,"posts":1087},[1088,1100,1113],{"content":1089,"config":1098},{"title":1090,"description":1091,"authors":1092,"heroImage":1094,"date":1095,"body":1096,"category":764,"tags":1097},"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.",[1093],"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 in Millisekunden finden könntest? GitLabs neue [Exact Code Search](https://docs.gitlab.com/ee/user/search/exact_code_search.html) macht genau das möglich – mit präzisen Treffern, leistungsstarker Regex-Unterstützung und kontextbezogenen mehrzeiligen Ergebnissen, die die Arbeit mit großen Codebasen revolutionieren.\n\n## Warum traditionelle Code-Suche herausfordernd ist\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\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\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## Wir stellen vor: Exact Code Search – drei bahnbrechende Funktionen\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\nDiese Funktion revolutioniert, wie du Code findest und verstehst, mit drei Hauptfunktionen:\n\n**1. Exact Match-Modus: Null False Positives**\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* Suchen nach spezifischen Fehlermeldungen\n* Finden bestimmter Funktionssignaturen\n* Aufspüren von Instanzen spezifischer Variablennamen\n\n**2. Regular Expression-Modus: Leistungsstarkes Pattern Matching**\n\nFür komplexe Suchanforderungen ermöglicht der Regular Expression-Modus die Erstellung ausgefeilter Suchmuster:\n\n* Finde Funktionen, die bestimmten Namensmustern folgen\n* Lokalisiere Variablen mit bestimmten Einschränkungen\n* Identifiziere potenzielle Sicherheitslücken mittels Pattern Matching\n\n**3. Mehrzeilige Treffer: Code im Kontext sehen**\n\n![Exact Code Search](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750704179/ttjuilkt3v7gtyywnchx.png)\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## Von Funktionen zu Workflows: Anwendungsfälle und Auswirkungen aus der Praxis\n\nSchauen wir uns an, wie diese Funktionen zu echten Produktivitätssteigerungen in alltäglichen Entwicklungsszenarien führen:\n\n### Debugging: Von der Fehlermeldung zur Ursache in Sekunden\n\nVor Exact Code Search:\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\nMit Exact Code Search:\n\n1. Die exakte Fehlermeldung kopieren\n2. Sie in Exact Code Search im Exact Match-Modus einfügen\n3. Sofort die präzise Stelle finden, wo der Fehler ausgelöst wird, mit umgebendem Kontext\n\n**Auswirkung:** Reduziere die Debugging-Zeit von Minuten auf Sekunden und eliminiere die Frustration durch False Positives.\n\n### Code-Exploration: Unbekannte Codebasen schnell meistern\n\nVor Exact Code Search:\nDurch Verzeichnisse browsen, fundierte Vermutungen über Dateispeicherorte anstellen, Dutzende von Dateien öffnen und langsam eine mentale Karte der Codebasis aufbauen.\n\nMit Exact Code Search:\n\n* Nach Schlüsselmethoden oder -klassen im Exact Match-Modus suchen\n* Mehrzeilige Treffer überprüfen, um Implementierungsdetails zu verstehen\n* Den Regular Expression-Modus nutzen, um ähnliche Muster in der Codebasis zu finden\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### Refactoring mit Zuversicht\n\nVor Exact Code Search:\nVersuchen, alle Instanzen einer Methode zu finden, einige Vorkommen übersehen und durch unvollständiges Refactoring Fehler einführen.\n\nMit Exact Code Search:\n\n* Den Exact Match-Modus nutzen, um alle Vorkommen von Methoden oder Variablen zu finden\n* Kontext überprüfen, um Verwendungsmuster zu verstehen\n* Dein Refactoring mit vollständigen Informationen über die Auswirkungen planen\n\n**Auswirkung:** Eliminiere die \"übersehene Instanz\"-Fehler, die Refactoring-Bemühungen oft plagen, verbessere die Code-Qualität und reduziere Nacharbeit.\n\n### Sicherheitsaudits: Verwundbare Muster finden\n\nSicherheitsteams können:\n\n* Regex-Muster erstellen, die bekanntem verwundbarem Code entsprechen\n* Über alle Repositories in einem Namespace suchen\n* Schnell potenzielle Sicherheitsprobleme mit Kontext identifizieren, der bei der Risikobewertung hilft\n\n**Auswirkung:** Verwandle Sicherheitsaudits von manuellen, fehleranfälligen Prozessen in systematische, umfassende Überprüfungen.\n\n### Repository-übergreifende Einblicke\n\nSuche über deinen gesamten Namespace oder deine Instanz, um:\n\n* Ähnliche Implementierungen in verschiedenen Projekten zu identifizieren\n* Möglichkeiten für gemeinsame Bibliotheken oder Standardisierung zu entdecken\n\n**Auswirkung:** Baue Silos zwischen Projekten ab und identifiziere Möglichkeiten für Code-Wiederverwendung und Standardisierung.\n\n## Die technische Grundlage: Wie Zoekt Geschwindigkeit und Präzision liefert\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### Positionale Trigramme: Das Geheimnis blitzschneller exakter Treffer\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\nSo funktioniert es:\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**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\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### Regular Expression-Performance im großen Maßstab\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## Entwickelt für Unternehmensmaßstäbe\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### Terabytes von Code mit Leichtigkeit bewältigen\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### Selbstregistrierende Node-Architektur\n\nUnsere innovative Implementierung bietet:\n\n* **Automatische Node-Registrierung:** Zoekt-Nodes registrieren sich selbst bei GitLab\n* **Dynamische Shard-Zuweisung:** Das System weist Namespaces automatisch Nodes zu\n* **Gesundheitsüberwachung:** Nodes, die sich nicht melden, werden automatisch als offline markiert\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### Verteiltes System mit intelligentem Load Balancing\n\nHinter den Kulissen arbeitet Exact Code Search als verteiltes System mit diesen Schlüsselkomponenten:\n\n* **Spezialisierte Such-Nodes:** Zweckgebundene Server, die Indexierung und Suche übernehmen\n* **Intelligentes Sharding:** Code wird basierend auf Namespaces über Nodes verteilt\n* **Automatisches Load Balancing:** Das System verteilt Arbeit intelligent basierend auf Kapazität\n* **Hohe Verfügbarkeit:** Mehrere Replikate gewährleisten kontinuierlichen Betrieb, selbst wenn Nodes ausfallen\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### Nahtlose Sicherheitsintegration\n\nExact Code Search integriert sich automatisch mit GitLabs Berechtigungssystem:\n\n* Suchergebnisse werden basierend auf den Zugriffsrechten des Nutzers gefiltert\n* Nur Code aus Projekten, auf die der Nutzer Zugriff hat, wird angezeigt\n* Sicherheit ist in die Kernarchitektur integriert, nicht nachträglich hinzugefügt\n\n### Optimierte Performance\n\n* **Effiziente Indexierung:** Große Repositories werden in Dutzenden von Sekunden indexiert\n* **Schnelle Query-Ausführung:** Die meisten Suchen liefern Ergebnisse mit Antwortzeiten unter einer Sekunde\n* **Streaming-Ergebnisse:** Die neue gRPC-basierte föderierte Suche streamt Ergebnisse, sobald sie gefunden werden\n* **Frühzeitiger Abbruch:** Sobald genügend Ergebnisse gesammelt wurden, pausiert das System die Suche\n\n## Von der Bibliothek zum verteilten System: Technische Herausforderungen, die wir gelöst haben\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### Herausforderung 1: Aufbau einer Orchestrierungsschicht\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**Unsere Lösung:** Wir haben eine umfassende Orchestrierungsschicht aufgebaut, die:\n\n* Datenbankmodelle erstellt und verwaltet, um Nodes, Indizes, Repositories und Aufgaben zu verfolgen\n* Eine selbstregistrierende Node-Architektur implementiert (inspiriert von GitLab Runner)\n* Automatische Shard-Zuweisung und Load Balancing über Nodes hinweg handhabt\n* Bidirektionale API-Kommunikation zwischen GitLab Rails und Zoekt-Nodes bereitstellt\n\n### Herausforderung 2: Skalierung von Speicher und Indexierung\n\n**Das Problem:** Wie verwaltet man effizient Terabytes von Indexdaten über mehrere Nodes bei gleichzeitig schnellen Updates?\n\n**Unsere Lösung:** Wir implementierten:\n\n* Intelligentes Sharding: Namespaces werden basierend auf Kapazität und Last über Nodes verteilt\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* Watermark-Management: Ausgefeilte Speicherzuweisung, die verhindert, dass Nodes der Speicherplatz ausgeht\n* Einheitliche Binary-Architektur: Ein einzelnes `gitlab-zoekt`-Binary, das sowohl im Indexer- als auch im Webserver-Modus arbeiten kann\n\n### Herausforderung 3: Berechtigungsintegration\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**Unsere Lösung:** Wir haben native Berechtigungsfilterung direkt in den Suchablauf integriert:\n\n* Suchanfragen enthalten Nutzerberechtigungskontext\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### Herausforderung 4: Betriebliche Einfachheit\n\n**Das Problem:** Die Verwaltung eines verteilten Suchsystems sollte kein dediziertes Team erfordern.\n\n**Unsere Lösung:**\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* Selbstheilung: Nodes, die sich nicht melden, werden automatisch als offline markiert und ihre Arbeit wird umverteilt\n* Zero-Configuration-Sharding: Das System bestimmt automatisch optimale Shard-Zuweisungen\n\n## Schrittweiser Rollout: Risikominimierung im großen Maßstab\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### Phase 1: Kontrolliertes Testen (gitlab-org-Gruppe)\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* Das System mit echten Produktions-Workloads zu testen\n* Performance-Engpässe zu identifizieren und zu beheben\n* Den Bereitstellungsprozess zu optimieren\n* Aus den Workflows und dem Feedback echter Nutzer zu lernen\n\n### Phase 2: Performance-Validierung und -Optimierung\n\nVor der Erweiterung konzentrierten wir uns darauf sicherzustellen, dass das System GitLab.coms Maßstab bewältigen konnte:\n\n* Umfassendes Monitoring und Alerting implementiert\n* Speicherverwaltung mit echtem Produktionsdatenwachstum validiert\n\n### Phase 3: Schrittweise Kundenerweiterung\n\nWir erweiterten schrittweise auf Kunden, die daran interessiert waren, Exact Code Search zu testen:\n\n* Feedback zu Performance und Benutzererfahrung gesammelt\n* Die Such-UI basierend auf echten Nutzer-Workflows verfeinert\n* Indexierungs-Performance optimiert (große Repositories wie `gitlab-org/gitlab` indexieren jetzt in ~10 Sekunden)\n* Die Architektur basierend auf betrieblichen Erkenntnissen verfeinert\n* Indexierungs-Durchsatz massiv erhöht und Zustandsübergangs-Lebenszyklus verbessert\n\n### Phase 4: Breiter Rollout\n\nHeute haben über 99 % der Premium- und Ultimate-lizenzierten Gruppen auf GitLab.com Zugriff auf Exact Code Search. Nutzer können:\n\n* Zwischen Regex- und exaktem Suchmodus umschalten\n* Die Vorteile ohne Konfigurationsänderungen erleben\n* Bei Bedarf auf die vorherige Suche zurückgreifen (obwohl wenige dies wählen)\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> **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## Erste Schritte mit Exact Code Search\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### Schnellstart-Anleitung\n\n1. Navigiere zur erweiterten Suche in deinem GitLab-Projekt oder deiner Gruppe\n2. Gib deinen Suchbegriff im Code-Tab ein\n3. Wechsle zwischen Exact Match- und Regular Expression-Modus\n4. Nutze Filter, um deine Suche zu verfeinern\n\n### Grundlegende Such-Syntax\n\nEgal ob du den Exact Match- oder Regular Expression-Modus verwendest, du kannst deine Suche mit Modifikatoren verfeinern:\n\n| Abfrage-Beispiel | Was es bewirkt                                              |\n| ---------------- | ----------------------------------------------------------- |\n| `file:js`        | Sucht nur in Dateien, die \"js\" im Namen enthalten           |\n| `foo -bar`       | Findet \"foo\", schließt aber Ergebnisse mit \"bar\" aus        |\n| `lang:ruby`      | Sucht nur in Ruby-Dateien                                   |\n| `sym:process`    | Findet \"process\" in Symbolen (Methoden, Klassen, Variablen) |\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### Erweiterte Suchtechniken\n\nStapele mehrere Filter für Präzision:\n\n```\nis_expected file:rb -file:spec\n```\n\nDas findet \"is_expected\" in Ruby-Dateien, die nicht \"spec\" im Namen haben.\n\nNutze reguläre Ausdrücke für leistungsstarke Muster:\n\n```\ntoken.*=.*[\\\"']\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\nDie Suche hilft, hartcodierte Passwörter zu finden, die, wenn nicht gefunden, ein Sicherheitsproblem darstellen können.\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## Verfügbarkeit und Bereitstellung\n\n### Aktuelle Verfügbarkeit\n\nExact Code Search befindet sich derzeit in der Beta-Phase für GitLab.com-Nutzer mit Premium- und Ultimate-Lizenzen:\n\n* Verfügbar für über 99 % der lizenzierten Gruppen\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### Bereitstellungsoptionen für Self-Managed\n\nFür Self-Managed-Instanzen bieten wir mehrere Bereitstellungsmethoden:\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* Andere Bereitstellungsoptionen: Wir arbeiten an der Vereinfachung der Bereitstellung für Omnibus und andere Installationsmethoden\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## Was als Nächstes kommt\n\nWährend Exact Code Search bereits leistungsstark ist, verbessern wir sie kontinuierlich:\n\n* **Skalierungsoptimierungen** zur Unterstützung von Instanzen mit Hunderttausenden von Repositories\n* **Verbesserte Self-Managed-Bereitstellungsoptionen**, einschließlich vereinfachter Omnibus-Unterstützung\n* **Vollständige Hochverfügbarkeits-Unterstützung** mit automatischem Failover und Load Balancing\n\nBleib dran für Updates, während wir von Beta zu General Availability übergehen.\n\n## Transformiere deine Arbeitsweise mit Code\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* Keine Zeitverschwendung mehr mit irrelevanten Ergebnissen\n* Keine wichtigen Treffer mehr verpassen\n* Kein Durchklicken von Dateien mehr nur für grundlegendes Verständnis\n* Keine Performance-Probleme mehr bei wachsenden Codebasen\n\nDie Auswirkungen gehen über die individuelle Produktivität hinaus:\n\n* **Teams arbeiten besser zusammen** mit einfacher Code-Referenzierung\n* **Wissensaustausch beschleunigt sich**, wenn Muster auffindbar sind\n* **Onboarding wird schneller** mit schnellem Codebasis-Verständnis\n* **Sicherheit verbessert sich** mit effektivem Muster-Auditing\n* **Abbau technischer Schulden** wird machbarer\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**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> ### 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 für 60 Tage](https://about.gitlab.com/free-trial/)!",[764,809,893],{"featured":6,"template":796,"slug":1099},"exact-code-search-find-code-faster-across-repositories",{"content":1101,"config":1111},{"heroImage":1102,"body":1103,"authors":1104,"updatedDate":947,"date":1107,"title":1108,"tags":1109,"description":1110,"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/).",[1105,1106],"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":796,"slug":1112},"gitlab-ultimate-for-ibm-z-modern-devsecops-for-mainframes",{"content":1114,"config":1121},{"heroImage":1115,"body":1116,"authors":1117,"updatedDate":7,"date":948,"title":1118,"tags":1119,"description":1120,"category":764},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658898/Blog/Hero%20Images/blog-post-image-forrester-wave-1800x945px-fy26.png","Die Wahl einer DevSecOps-Plattform ist eine der wichtigesten technologischen Entscheidungen, die ein Unternehmen zu treffen hat. Deshalb freuen wir uns sehr, dass wir als [**führender Anbieter in The Forrester Wave™: DevOps Platforms, Q2 2025** (nur in englischer Sprache verfügbar)](https://about.gitlab.com/forrester-wave-devops-platform/) ausgezeichnet wurden. \n\nWir haben die höchstmöglichen Punktzahlen bei den Kriterien erhalten, die unseren Kund(inn)en laut ihren eigenen Angaben am wichtigsten sind, einschließlich der Benutzungserfahrung am ersten Tag, der Entwicklungstools, der Build-Automatisierung und CI, der automatisierten Bereitstellung, der Risikominderung im Zusammenhang mit KI, KI-Infusion, direkt integrierter Sicherheitstools und Plattformkohäsion.\n\n***„GitLab ist die All-in-One-Lösung unter den All-in-One-Lösungen, die ihrem Namen am stärksten gerecht wird, und eignet sich damit für Unternehmen, die mit einem einzigen Kauf eine Standardisierung herbeiführen möchten.“ –*** Forrester Wave™: DevOps Platforms, Q2 2025\n\nDiese Auszeichnung spiegelt das wider, was wir selbst von unseren Kund(inn)en gehört haben: Sie müssen sichere Software schneller bereitstellen, doch ihre bestehenden Lösungen zwingen sie, Kompromisse bei der Geschwindigkeit, Sicherheit oder Einfachheit einzugehen. GitLab wird jedoch allen drei Anforderungen gerecht. Und mit unserer [Veröffentlichung von GitLab 18.0 (nur in englischer Sprache verfügbar)](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/) im Mai sind wir noch einen Schritt weiter gegangen, indem wir ohne zusätzliche Kosten [die KI-nativen Funktionen von GitLab Duo](https://about.gitlab.com/de-de/blog/gitlab-premium-with-duo/) – wie Test Generation, Code Suggestions und Code Refactoring – direkt in GitLab Premium und GitLab Ultimate integriert haben.\n\n> **[Erhalte jetzt Zugang zum englischsprachigen Bericht.](https://about.gitlab.com/forrester-wave-devops-platform/)**\n\n![ Forrester Wave™: DevOps-Plattformen, Grafik Q2 2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673518/Blog/Content%20Images/Image_DevOps-Platforms-Q2-2025.png)\n\n## Mit unternehmensweiter Kontrolle an der Spitze der KI-Transformation bleiben\n\nDevSecOps entwickelt sich rasant weiter, wobei die KI an der Spitze dieses Wandels steht. Leider zwingen viele KI-Tools die Anwender(innen) zu einer Wahl: entweder modernste Funktionen oder eine höchstmögliche Unternehmenssicherheit. \n\nGitLab hat sowohl bei den Kriterien **KI-Infusion** als auch **KI-Risikominderung** 5 Punkte erhalten – die höchste mögliche Punktzahl. Wir freuen uns, dass unser klarer Fokus auf die Entwicklung innovativer KI-Funktionen, bei denen gleichermaßen eine umfassende Sicherheit gewährleistet bleibt, nicht nur von unseren Kund(inn)en wahrgenommen wird.\n\nDiese doppelte Stärke zeigt sich in unseren KI-Angeboten von GitLab Duo, unter anderem:\n\n* Duo Workflow (private Beta-Version): Autonome KI-Agenten, die komplexe Aufgaben bei der Entwicklung, Sicherheit und Betrieb bewältigen – mit Leitlinien und Audit-Trails auf Enterprise-Niveau.  \n* Agentic Chat: Kontextbezogene, dialogorientierte KI-Unterstützung für alles von Codeerläuterungen bis hin zur Erstellung von Tests – mit integriertem Schutz des geistigen Eigentums und Datenschutzkontrollen.  \n* Code Suggestions: KI-Unterstützung, die Codeblöcke vorausschauend vervollständigen, eine Funktionslogik definieren, Tests generieren und häufig verwendeten Code wie Regex-Muster vorschlagen kann.  \n* KI-native Vulnerability Resolution: Findet und behebt Sicherheitslücken mit automatischen Erklärungen und automatisch erstellten Merge Requests, um so den Entwicklungsprozess zu optimieren.\n\n## Mit weniger mehr erreichen\n\nWir haben deutlich vernommen, dass DevSecOps-Teams nicht noch mehr Tools und Integrationen benötigen, die sie bei einzelnen Abschnitten ihres Software-Entwicklungsprozesses unterstützen. Sie benötigen stattdessen eine nahtlose, integrierte Entwicklererfahrung, die den gesamten Lebenszyklus der Softwareentwicklung abdeckt.\n\nWir sind überzeugt, dass die Bewertungen von GitLab in den folgenden Kriterien unsere kundenorientierte Strategie bestätigen:\n\n* **Nutzungserfahrung am ersten Tag:** Forrester zitiert unsere „starke Nutzungserfahrung am ersten Tag“ und stellt fest, dass „alles sofort einsatzbereit ist“, unterstützt durch umfangreiche Migrationstools und Tutorials. \n* **Entwicklertools:** Forrester verweist beispielhaft auf [GitLab Duo mit Amazon Q](https://about.gitlab.com/de-de/blog/gitlab-duo-with-amazon-q-agentic-ai-optimized-for-aws/), unser Angebot für agentische KI für AWS-Kund(inn)en, sowie auf unsere Entwicklungsumgebung in der Cloud, die integrierte Entwicklungsplattform und Wikis für die Dokumentation.  \n* **Projektplanung und -abstimmung:** Forrester hebt unser „starkes Compliance Center“ hervor und stellt fest, dass wir über Tools verfügen, um die Abstimmung in beide Richtungen voranzutreiben.  \n* **Pipeline-Sicherheit:** Forrester gibt uns die höchstmögliche Punktzahl beim Kriterium Pipeline-Sicherheit.  \n* **Build-Automatisierung und CI:** Forrester erwähnt unsere Build-Automatisierung und CI mit mehrstufigen Build-Pipelines und einer starken Unterstützung für selbst gehostete Installationen.\n\n## Bericht lesen \n\nFür uns spiegelt sich in unserer Auszeichnung als führender Anbieter in The Forrester Wave™: DevOps-Plattformen, Q2 2025 die Breite und Tiefe der Funktionen unserer Plattform wider, die als Single Source of Truth über den gesamten Lebenszyklus der Softwareentwicklung hinweg fungiert. Kein Jonglieren mit mehreren Tools und Integrationen mehr – GitLab bietet eine nahtlose, integrierte Erfahrung, die die Produktivität steigert und Reibungsverluste reduziert. \n\nWir sind überzeugt, dass sich in dieser hervorragenden Platzierung die harte Arbeit unseres Teams, die vielen Beiträge der Open-Source-Community von GitLab, das unschätzbare Feedback unserer Kund(inn)en und unser Engagement für die Gestaltung der Zukunft der Softwareentwicklung widerspiegeln.\n\n> **[Öffne den englischsprachigen Bericht.](https://about.gitlab.com/forrester-wave-devops-platform/)**\n\n*Forrester spricht keine Empfehlung für Unternehmen, Produkte, Marken oder Dienstleistungen aus, die in seinen Forschungspublikationen vorkommen, und rät niemandem, sich auf der Grundlage der in diesen Publikationen aufgeführten Bewertungen für die Produkte oder Dienstleistungen eines Unternehmens oder einer Marke zu entscheiden. Die Informationen basieren auf den besten verfügbaren Ressourcen. Die Meinungen spiegeln die jeweils aktuelle Einschätzung wider und können sich ändern. Weitere Informationen zur Objektivität von Forrester (in englischer Sprache) findest du [hier](https://www.forrester.com/about-us/objectivity/).*",[1012],"GitLab ist ein Leader in der Forrester Wave™: DevOps Platforms, Q2 2025",[1017,764,742,807],"Forrester bezeichnet die GitLab-Plattform als die „All-in-One-Lösung unter den All-in-One-Lösungen“ und geeignet „für Unternehmen, die mit einem Kauf eine Standardisierung herbeiführen möchten“.",{"slug":1122,"featured":91,"template":796},"gitlab-named-a-leader-in-the-forrester-wave-devops-platforms-q2-2025",{"category":126,"slug":775,"posts":1124},[1125,1137,1147],{"content":1126,"config":1135},{"title":1127,"description":1128,"authors":1129,"heroImage":1094,"date":1131,"body":1132,"category":775,"tags":1133},"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.",[1130],"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,1134],"inside GitLab",{"featured":6,"template":796,"slug":1136},"how-to-transform-compliance-observation-management-with-gitlab",{"content":1138,"config":1145},{"title":1139,"description":1140,"authors":1141,"heroImage":1142,"date":1131,"body":1143,"category":775,"tags":1144},"Warum Organisationen bei der Software Supply Chain Security kämpfen","Der erste Teil dieser Serie behandelt die wichtigsten Herausforderungen, praktische Lösungsansätze und aktuelle Trends wie KI – Wissen, das jedes Entwicklungsteam braucht.",[946],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097701/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%285%29_1iy516k40hwBDChKcUJ2zb_1750097700983.png","Wenn du die meisten Entwicklungsteams nach Supply Chain Security fragst, konzentrieren sich ihre Antworten auf Schwachstellenscans oder Abhängigkeitsmanagement. Diese Bereiche sind zwar wichtige Komponenten, stellen aber eine gefährlich eingeschränkte Sichtweise auf eine viel komplexere Herausforderung dar.\n\n**Software-Supply-Chain-Sicherheit beschränkt sich nicht nur auf das Scannen von Abhängigkeiten.** Sie umfasst den gesamten Prozess von der Code-Entwicklung bis zur Produktionsbereitstellung, einschließlich:\n\n* **Quellsicherheit:** Schutz von Code-Repositorys, Verwaltung von Mitwirkenden-Zugriff, Sicherstellung der Code-Integrität  \n* **Build-Sicherheit:** Sichere Build-Umgebungen, Verhinderung von Manipulationen während der Kompilierung und Paketierung  \n* **Artefakt-Sicherheit:** Sicherstellung der Integrität von Containern, Paketen und Bereitstellungsartefakten  \n* **Bereitstellungssicherheit:** Sicherung der Liefermechanismen und Laufzeitumgebungen  \n* **Tool-Sicherheit:** Härtung der Entwicklungstools und Plattformen selbst\n\nDie \"Kette\" in Supply Chain Security bezieht sich auf diese miteinander verbundene Reihe von Schritten. Eine Schwachstelle an irgendeiner Stelle in der Kette kann den gesamten Software-Lieferprozess kompromittieren.\n\nDer [SolarWinds-Angriff von 2020](https://www.cisa.gov/news-events/news/joint-statement-federal-bureau-investigation-fbi-cybersecurity-and-infrastructure-security) veranschaulicht dies perfekt. In einem der größten Supply-Chain-Angriffe der Geschichte kompromittierten staatlich geförderte Angreifer die Build-Pipeline von SolarWinds' Orion-Netzwerkverwaltungssoftware. Anstatt eine anfällige Abhängigkeit auszunutzen oder die fertige Anwendung zu hacken, injizierten sie bösartigen Code während des Kompilierungsprozesses selbst.\n\nDas Ergebnis war verheerend: Mehr als 18.000 Organisationen, einschließlich mehrerer US-Regierungsbehörden, installierten unwissentlich Software mit Hintertüren durch normale Updates. Der Quellcode war sauber, die fertige Anwendung erschien legitim. Doch der Build-Prozess war kompromittiert worden. Dieser Angriff blieb monatelang unentdeckt und zeigte, wie Supply-Chain-Schwachstellen traditionelle Sicherheitsmaßnahmen umgehen können.\n\n### Häufige Missverständnisse, die Organisationen verwundbar machen\n\nTrotz des wachsenden Bewusstseins für Supply-Chain-Bedrohungen bleiben viele Organisationen anfällig, weil sie grundlegenden Missverständnissen über Software-Supply-Chain-Sicherheit unterliegen. Diese Missverständnisse schaffen gefährliche Sicherheitslücken:\n\n* Denken, dass Software Supply Chain Security gleich Abhängigkeitsscanning ist  \n* Sich nur auf Open-Source-Komponenten konzentrieren und proprietäre Code-Risiken ignorieren  \n* Glauben, dass Code-Signierung allein ausreichenden Schutz bietet  \n* Annehmen, dass sichere Codierungspraktiken Supply-Chain-Risiken eliminieren  \n* Es als Problem des Sicherheitsteams behandeln statt als Herausforderung des Entwicklungsworkflows\n\n![Software Supply Chain Security Abhängigkeitsdiagramm](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200077/kqndvlxyvncshdiq0xea.png)\n\n## Wie KI das Spiel verändert\n\nWährend Organisationen noch mit traditionellen Herausforderungen der Software-Supply-Chain-Sicherheit kämpfen, führt künstliche Intelligenz (KI) völlig neue Angriffsvektoren ein und verstärkt bestehende auf beispiellose Weise.\n\n### KI-gestützte Angriffe: Ausgefeilter, skalierbarer\n\nAngreifer nutzen KI, um die Schwachstellenentdeckung zu automatisieren, überzeugende Social-Engineering-Angriffe gegen Entwickler zu generieren und öffentliche Codebasen systematisch auf Schwächen zu analysieren. Was früher manuelle Arbeit erforderte, lässt sich jetzt in großem Maßstab durchführen – mit Präzision.\n\n### Die KI-Entwicklungs-Supply-Chain führt neue Risiken ein\n\nKI gestaltet den gesamten Entwicklungslebenszyklus neu, führt aber auch erhebliche Sicherheitslücken ein:\n\n* **Modell-Supply-Chain-Angriffe:** Vortrainierte Modelle von Quellen wie Hugging Face oder GitHub können Hintertüren oder vergiftete Trainingsdaten enthalten.  \n* **Unsicherer KI-generierter Code:** Entwickler(innen), die KI-Coding-Assistenten verwenden, könnten unwissentlich verwundbare Muster oder unsichere Abhängigkeiten einführen.  \n* **Kompromittierte KI-Toolchains:** Die Infrastruktur zum Trainieren, Bereitstellen und Verwalten von KI-Modellen schafft eine neue Angriffsoberfläche.  \n* **Automatisierte Aufklärung:** KI ermöglicht es Angreifern, ganze Ökosysteme zu scannen, um hochwertige Supply-Chain-Ziele zu identifizieren.  \n* **Schatten-KI und nicht genehmigte Tools:** Entwickler(innen) könnten externe KI-Tools integrieren, die nicht überprüft wurden.\n\nDas Ergebnis? KI führt nicht nur neue Schwachstellen ein, sie verstärkt auch das Ausmaß und die Auswirkungen bestehender Schwachstellen. Organisationen können sich nicht länger auf schrittweise Verbesserungen verlassen. Die Bedrohungslandschaft entwickelt sich schneller, als sich aktuelle Sicherheitspraktiken anpassen können.\n\n![KI-Verstärkungseffekt](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753200139/xuxezxld6ztlvjocgjlx.png)\n\n## Warum die meisten Organisationen immer noch kämpfen\n\nSelbst Organisationen, die Supply-Chain-Sicherheit verstehen, scheitern oft daran, effektiv zu handeln. Die Statistiken zeigen ein beunruhigendes Muster: Bewusstsein ohne entsprechende Verhaltensänderung.\n\nAls [Colonial Pipeline 2021 Hackern 4,4 Millionen Dollar zahlte](https://www.cnn.com/2021/05/19/politics/colonial-pipeline-ransom/index.html), um den Betrieb wiederherzustellen, oder als 18.000 Organisationen dem SolarWinds-Angriff zum Opfer fielen, war die Botschaft klar: Supply-Chain-Schwachstellen können kritische Infrastruktur lahmlegen und sensible Daten in beispiellosem Ausmaß kompromittieren.\n\nDennoch machen die meisten Organisationen trotz dieses Bewusstseins weiter wie gewohnt. Die eigentliche Frage ist nicht, ob sich Organisationen um Supply-Chain-Sicherheit sorgen – sondern warum sich diese Sorge nicht in effektiven Schutz umsetzt.\n\nDie Antwort liegt in vier kritischen Barrieren, die effektives Handeln verhindern:\n\n**1. Die falsche Sparsamkeitsmentalität**\n\nOrganisationen konzentrieren sich manchmal auf die Kosten, anstatt zu fragen: \"Was ist der effektivste Ansatz?\" Dieses kostenorientierte Denken schafft teure Folgeprobleme.\n\n**2. Die Realität des Fachkräftemangels**\n\nMit [durchschnittlich 4 Sicherheitsfachleuten pro 100 Entwickler(innen)](https://codific.com/bsimm-building-security-in-maturity-model-a-complete-guide/) laut BSIMM-Forschung und [90% der Organisationen, die kritische Cybersicherheits-Qualifikationslücken melden](https://www.isc2.org/Insights/2024/09/Employers-Must-Act-Cybersecurity-Workforce-Growth-Stalls-as-Skills-Gaps-Widen) laut ISC2, sind traditionelle Ansätze mathematisch unmöglich zu skalieren.\n\n**3. Fehlausgerichtete organisatorische Anreize**\n\nEntwickler-OKRs konzentrieren sich auf Feature-Geschwindigkeit, während Sicherheitsteams andere Ergebnisse messen. Wenn die Prioritäten der Geschäftsleitung die Markteinführungsgeschwindigkeit über die Sicherheitslage stellen, wird Reibung unvermeidlich.\n\n**4. Tool-Komplexitätsüberlastung**\n\nDas [durchschnittliche Unternehmen nutzt 45 Cybersicherheitstools](https://www.gartner.com/en/newsroom/press-releases/2025-03-03-gartner-identifiesthe-top-cybersecurity-trends-for-2025), wobei [40% der Sicherheitswarnungen Fehlalarme sind](https://www.ponemon.org/news-updates/blog/security/new-ponemon-study-on-malware-detection-prevention-released.html) und muss [durchschnittlich 19 Tools für jeden Vorfall koordinieren](https://newsroom.ibm.com/2020-06-30-IBM-Study-Security-Response-Planning-on-the-Rise-But-Containing-Attacks-Remains-an-Issue).\n\nDiese Barrieren schaffen einen Teufelskreis: Organisationen erkennen die Bedrohung, investieren in Sicherheitslösungen, setzen sie aber so um, dass sie nicht die gewünschten Ergebnisse erzielen.\n\n## Der wahre Preis der Supply-Chain-Unsicherheit\n\nSupply-Chain-Angriffe schaffen Risiken und Kosten, die weit über die anfängliche Behebung hinausgehen. Das Verständnis dieser versteckten Multiplikatoren hilft zu erklären, warum Prävention nicht nur vorzuziehen ist – sie ist essentiell für die Geschäftskontinuität.\n\n**Zeit wird zum Feind**\n\n* Durchschnittliche Zeit zur Identifizierung und Eindämmung einer Supply-Chain-Verletzung: [277 Tage](https://keepnetlabs.com/blog/171-cyber-security-statistics-2024-s-updated-trends-and-data)  \n* Zeitraum zum Wiederaufbau des Kundenvertrauens: [2-3+ Jahre](https://www.bcg.com/publications/2024/rebuilding-corporate-trust)   \n* Entwicklungsstunden, die von der Produktentwicklung zur Sicherheitsbehebung umgeleitet werden\n\n**Reputationsschäden summieren sich** \n\nWenn Angreifer deine Supply Chain kompromittieren, stehlen sie nicht nur Daten – sie untergraben das Fundament des Kundenvertrauens. [Kundenabwanderungsraten steigen typischerweise um 33% nach einem Verstoß](https://www.metacompliance.com/blog/data-breaches/5-damaging-consequences-of-a-data-breach), während Partnerbeziehungen kostspielige Rezertifizierungsprozesse erfordern. Die Wettbewerbsposition leidet, da Interessenten Alternativen wählen, die als \"sicherer\" wahrgenommen werden.\n\n**Die regulatorische Realität schlägt zu** \n\nDie Regulierungslandschaft hat sich grundlegend verändert. [DSGVO-Strafen betragen jetzt durchschnittlich über 50 Millionen Dollar für erhebliche Datenverstöße](https://www.skillcast.com/blog/20-biggest-gdpr-fines). Der neue [Cyber Resilience Act](https://about.gitlab.com/blog/gitlab-supports-banks-in-navigating-regulatory-challenges/#european-cyber-resilience-act-(cra)) der EU verlangt Supply-Chain-Transparenz. US-Bundesauftragnehmer müssen Software-Stücklisten ([SBOMs](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/)) für alle Softwarekäufe bereitstellen – eine Anforderung, die sich schnell auf die Beschaffung im privaten Sektor ausbreitet.\n\n**Betriebsstörungen multiplizieren sich** \n\nÜber die direkten Kosten hinaus schaffen Supply-Chain-Angriffe betriebliches Chaos: Plattformausfälle während der Angriffsbehebung, Notfall-Sicherheitsaudits über ganze Technologie-Stacks und Rechtskosten aus Kundenklagen und behördlichen Untersuchungen.\n\n## Was an aktuellen Ansätzen falsch ist\n\nDie meisten Organisationen verwechseln Sicherheitsaktivität mit Sicherheitswirkung. Sie setzen Scanner ein, generieren lange Berichte und jagen Teams durch manuelle Nachfassaktionen hinterher. Aber diese Bemühungen gehen oft nach hinten los – und schaffen mehr Probleme, als sie lösen.\n\n### Massives Scannen vs. effektiver Schutz\n\nUnternehmen generieren über [10.000 Sicherheitswarnungen pro Monat, wobei die aktivsten etwa 150.000 Ereignisse pro Tag generieren.](https://www.securityweek.com/enterprises-generate-10000-security-events-day-average-report/) [Aber 63%](https://panther.com/blog/identifying-and-mitigating-false-positive-alerts) davon sind Fehlalarme oder unwichtiges Rauschen. Sicherheitsteams sind überfordert und werden zu Engpässen statt zu Befähigern.\n\n### Der Zusammenbruch der Zusammenarbeit\n\nDie sichersten Organisationen haben nicht die meisten Tools; sie haben die stärkste DevSecOps-Zusammenarbeit. Aber die meisten aktuellen Setups machen dies schwieriger, indem sie Workflows über inkompatible Tools aufteilen, Entwicklern keine Sicherheitsergebnisse in ihrer Umgebung zeigen und keine gemeinsame Sichtbarkeit auf Risiko und geschäftliche Auswirkungen bieten.\n\n## Der Weg nach vorn\n\nDas Verständnis dieser Herausforderungen ist der erste Schritt zum Aufbau effektiver Supply-Chain-Sicherheit. Die Organisationen, die erfolgreich sind, fügen nicht nur mehr Sicherheitstools hinzu, sie überdenken grundlegend, wie Sicherheit in Entwicklungsworkflows integriert wird. Sie überprüfen auch End-to-End-Software-Lieferworkflows, um Prozesse zu vereinfachen, Tools zu reduzieren und die Zusammenarbeit zu verbessern.\n\nBei GitLab haben wir gesehen, wie integrierte DevSecOps-Plattformen diese Herausforderungen angehen können, indem sie Sicherheit direkt in den Entwicklungsworkflow bringen. In unserem nächsten Artikel dieser Serie werden wir untersuchen, wie führende Organisationen ihren Ansatz zur Supply-Chain-Sicherheit durch entwicklerfreundliche Lösungen, KI-gestützte Automatisierung und Plattformen transformieren, die Sicherheit zu einem natürlichen Teil der Entwicklung großartiger Software machen.\n\n> Erfahre mehr über [GitLabs Software Supply Chain Security-Funktionen](https://about.gitlab.com/de-de/solutions/supply-chain/).",[775,764,809],{"featured":6,"template":796,"slug":1146},"software-supply-chain-security-guide-why-organizations-struggle",{"content":1148,"config":1156},{"title":1149,"description":1150,"authors":1151,"heroImage":1152,"date":1153,"body":1154,"category":775,"tags":1155},"Die Sichtbarkeitslücke in der Software Supply Chain Security schließen","GitLab 18.2 bietet Unterstützung für umfassende Scanner-Abdeckung und Visualisierung transitiver Abhängigkeiten.",[845],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","2025-07-21","Unser neuestes Release, [GitLab 18.2](https://about.gitlab.com/de-de/releases/2025/07/17/gitlab-18-2-released/), führt zwei neue Funktionen zur Verbesserung der Software Supply Chain Security ein: Security Inventory und Dependency Path-Visualisierung.\nSecurity Inventory bietet Application Security Teams eine zentrale, portfolioweite Übersicht über Risiken und Scan-Abdeckung über alle GitLab-Gruppen und -Projekte hinweg. So können sie blinde Flecken identifizieren und Maßnahmen zur Risikominderung priorisieren. Die Dependency Path-Visualisierung zeigt Entwickler(inne)n klar auf, wie Open-Source-Schwachstellen durch die Abhängigkeitskette eingeführt werden, was es einfacher macht, die richtige Lösung zu finden.\nGemeinsam helfen diese Funktionen Sicherheits- und Entwicklungsteams dabei, sicherere Anwendungen zu erstellen, indem sie Transparenz darüber schaffen, wo Risiken bestehen, Kontext zur Behebung liefern und Workflows bereitstellen, die die Zusammenarbeit unterstützen. Im Gegensatz zu anderen Lösungen geschieht all das in derselben Plattform, die Entwickler(innen) zum Erstellen, Überprüfen und Bereitstellen von Software verwenden – ohne den zusätzlichen Integrationsaufwand.\n\n## Open Source erweitert die Angriffsfläche\n\nModerne Anwendungen verlassen sich [stark](https://about.gitlab.com/de-de/developer-survey/) auf Open-Source-Software. Open Source bringt jedoch ein erhebliches Sicherheitsrisiko mit sich – Komponenten können veraltet, nicht mehr gewartet oder unwissentlich anfällig sein. Deshalb ist die Software Composition Analysis (SCA) zu einem Eckpfeiler moderner AppSec-Programme geworden.\nEine zentrale Herausforderung im Schwachstellen-Management ist die effektive Verwaltung des *Risikos transitiver Abhängigkeiten*. Diese Komponenten sind oft tief in der Abhängigkeitskette vergraben. Daher ist es schwierig nachzuvollziehen, wie eine Schwachstelle eingeführt wurde. Ebenso schwer ist es zu bestimmen, was aktualisiert werden muss. Noch schlimmer: Sie machen fast [zwei Drittel](https://arxiv.org/abs/2503.22134?) der bekannten Open-Source-Schwachstellen aus. Ohne klare Sicht auf den gesamten Abhängigkeitspfad sind Teams auf Vermutungen angewiesen, was die Behebung verzögert und das Risiko erhöht.\n\n> Transitive Abhängigkeiten sind Pakete, die deine Anwendung indirekt verwendet. Sie werden automatisch von den direkten Abhängigkeiten eingezogen, die du explizit einbindest. Diese verschachtelten Abhängigkeiten können Schwachstellen einführen, ohne dass der/die Entwickler(in) jemals weiß, dass sie im Projekt vorhanden sind.\n> Diese Herausforderung wird exponentiell schwieriger bei großem Umfang. Sicherheitsteams verwalten oft Hunderte oder Tausende von Repositories. Jedes Repository hat eigene Abhängigkeiten, Build-Pipelines und Verantwortliche. In diesem Umfang wird selbst die Beantwortung grundlegender Sicherheitsfragen zur Herausforderung. Und in einer Zeit wachsender Software Supply Chain-Bedrohungen, in der sich Schwachstellen über geteilte Bibliotheken und CI/CD-Konfigurationen systemübergreifend ausbreiten können, haben diese blinden Flecken noch gravierendere Folgen.\n\n## Security Inventory: Skalierbare Transparenz\n\nSecurity Inventory konsolidiert Risikoinformationen aller Gruppen und Projekte in einer einheitlichen Ansicht. Es zeigt auf, welche Assets durch Sicherheitsscans abgedeckt sind und welche nicht. Anstatt Probleme isoliert zu verwalten, können Sicherheitsteams die Lage ganzheitlich bewerten. So identifizieren sie schnell, wo sie ihre Bemühungen fokussieren sollten.\nDiese zentrale Übersicht ist besonders wichtig für Organisationen mit vielen Repositories. Plattform- und AppSec-Teams verstehen sofort, wo Risiken existieren. Das System hebt ungescannte oder unzureichend geschützte Projekte hervor.\nAußerdem können Teams direkt aus der Oberfläche heraus handeln und über das bloße Bewusstsein hinausgehen. Mit vollem Kontext verstehen sie, welche Anwendungen das größte Risiko darstellen. Security Inventory wandelt fragmentierte Einblicke in eine zentrale Informationsquelle um. So können Organisationen von reaktiver Problem-Triage zu strategischer, datengesteuerter Sicherheits-Governance wechseln.\n![Security Inventory-Anzeige](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101068/qhujktnbkhl2rzgqfead.png)\nErfahre mehr, indem du dir Security Inventory in Aktion ansiehst:\n\n\u003C!-- blank line --> \u003Cfigure class=\"video_container\"> \u003Ciframe src=\"https://www.youtube.com/embed/yqo6aJLS9Fw?si=CtYmsF-PLN1UKt83\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe> \u003C/figure> \u003C!-- blank line -->\n\n## Dependency Path-Visualisierung: Klarheit für effektive Behebung\n\nSecurity Inventory zeigt auf hoher Ebene, wo die Risiken liegen; die Dependency Path-Visualisierung zeigt, wie man sie behebt.\nWenn eine Schwachstelle tief in einer Abhängigkeitskette entdeckt wird, kann die Identifizierung der richtigen Lösung kompliziert sein. Die meisten Sicherheitstools heben das betroffene Paket hervor, erklären aber nicht, wie es in die Codebasis gelangt ist. Entwickler(innen) müssen raten, welche Abhängigkeiten direkt eingeführt werden und welche transitiv eingezogen werden, was es schwierig macht zu bestimmen, wo eine Änderung erforderlich ist – oder schlimmer noch: Patches anzuwenden, die die Grundursache nicht beheben.\nUnsere neue Dependency Path-Visualisierung zeigt nach einem SCA-Scan den vollständigen Weg auf: vom Top-Level-Paket zur anfälligen Komponente. Diese wird manchmal auch als Abhängigkeitsgraph bezeichnet. Diese Klarheit ist unerlässlich. Denn tief eingebettete Schwachstellen sind in Abhängigkeitsketten weit verbreitet. Die Funktion ist direkt in den GitLab-Workflow integriert. Dadurch erhalten Entwickler(innen) umsetzbare Einblicke ohne Kontextwechsel oder Rätselraten. Sicherheitsteams können Probleme effektiver priorisieren. Gleichzeitig haben Entwickler(innen) die Gewissheit, dass ihre Behebungen die Grundursachen angehen.\n![Dependency Path-Visualisierung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753101069/kf5ym62gylm5ck6iebjk.png)\n\n## Entwicklerorientierte Sicherheit: Risiken strategisch mindern\n\nDiese Funktionen sind Teil von GitLabs umfassenderer Strategie: Sicherheit innerhalb derselben Plattform bereitzustellen, in der Code geplant, erstellt und bereitgestellt wird. GitLab bettet Sicherheitseinblicke direkt in den DevSecOps-Workflow ein. Das reduziert Reibung und fördert die Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams.\nSecurity Inventory und Dependency Path-Visualisierung bieten komplementäre Perspektiven: Security Inventory ermöglicht skalierungsbewusste Überwachung, Dependency Path unterstützt präzise Korrekturen. Diese Kombination hilft Teams, das Wichtigste zu priorisieren und Lücken zu schließen. Und das ohne neue Tools oder komplexe Integrationen.\n\n> Starte noch heute mit Security Inventory und Dependency Path-Visualisierung! Melde dich für eine [kostenlose Testversion von GitLab Ultimate](https://about.gitlab.com/de-de/free-trial/) an.\n\n## Weiterlesen\n\n* [GitLab 18.2 veröffentlicht](https://about.gitlab.com/de-de/releases/2025/07/17/gitlab-18-2-released/)\n* [GitLab-Sicherheitslösungen](https://about.gitlab.com/de-de/solutions/security-compliance/)\n* [Ein Leitfaden zu Bedrohungsvektoren in der Software Supply Chain](https://about.gitlab.com/de-de/the-source/security/field-guide-to-threat-vectors-in-the-software-supply-chain/)",[775,808,764],{"featured":6,"template":796,"slug":1157},"bridging-the-visibility-gap-in-software-supply-chain-security",{"content":1159,"config":1162},{"title":971,"description":972,"authors":1160,"heroImage":975,"date":976,"body":977,"category":731,"tags":1161},[974],[269,764,742],{"featured":91,"template":796,"slug":980},[1164,1169,1174],{"content":1165,"config":1168},{"title":1127,"description":1128,"authors":1166,"heroImage":1094,"date":1131,"body":1132,"category":775,"tags":1167},[1130],[775,1134],{"featured":6,"template":796,"slug":1136},{"content":1170,"config":1173},{"title":1139,"description":1140,"authors":1171,"heroImage":1142,"date":1131,"body":1143,"category":775,"tags":1172},[946],[775,764,809],{"featured":6,"template":796,"slug":1146},{"content":1175,"config":1178},{"title":1149,"description":1150,"authors":1176,"heroImage":1152,"date":1153,"body":1154,"category":775,"tags":1177},[845],[775,808,764],{"featured":6,"template":796,"slug":1157},[1180,1185,1190],{"content":1181,"config":1184},{"heroImage":1050,"body":1051,"authors":1182,"updatedDate":976,"date":1055,"title":1056,"tags":1183,"description":1058,"category":754},[1053,1054],[893,269,764],{"featured":6,"template":796,"slug":1060},{"content":1186,"config":1189},{"heroImage":842,"body":843,"authors":1187,"updatedDate":846,"date":847,"title":848,"tags":1188,"description":850,"category":683},[845],[830,775],{"featured":91,"template":796,"slug":852},{"content":1191,"config":1193},{"date":855,"authors":1192,"heroImage":858,"body":859,"title":860,"description":861,"category":683,"updatedDate":862},[857],{"featured":6,"template":796,"slug":864},1753981610946]