[{"data":1,"prerenderedAt":900},["ShallowReactive",2],{"/en-us/blog/tags/devops/":3,"navigation-de-de":20,"banner-de-de":441,"footer-de-de":454,"DevOps-tag-page-de-de":663},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/devops","tags",false,"",{"tag":9,"tagSlug":10},"DevOps","devops",{"template":12},"BlogTag","content:en-us:blog:tags:devops.yml","yaml","Devops","content","en-us/blog/tags/devops.yml","en-us/blog/tags/devops","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":437,"_type":14,"title":438,"_source":16,"_file":439,"_stem":440,"_extension":19},"/shared/de-de/main-navigation","de-de",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":378,"minimal":414,"duo":428},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/de-de/","gitlab logo","header",{"text":30,"config":31},"Kostenlose Testversion anfordern",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Vertrieb kontaktieren",{"href":37,"dataGaName":38,"dataGaLocation":28},"/de-de/sales/","sales",{"text":40,"config":41},"Anmelden",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,299,359],{"text":46,"config":47,"cards":49,"footer":72},"Plattform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":53,"config":54},"Erkunde unsere Plattform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/de-de/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":60,"config":61},"Lerne GitLab Duo kennen",{"href":62,"dataGaName":63,"dataGaLocation":28},"/de-de/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":68,"config":69},"Mehr erfahren",{"href":70,"dataGaName":71,"dataGaLocation":28},"/de-de/why-gitlab/","why gitlab",{"title":73,"items":74},"Erste Schritte mit",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/de-de/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Entwicklererfahrung",{"href":83,"dataGaName":84,"dataGaLocation":28},"/de-de/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"Produkt",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"Alle Lösungen anzeigen",{"href":97,"dataGaName":93,"dataGaLocation":28},"/de-de/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/de-de/solutions/continuous-integration/",{"text":113,"config":114},"KI-unterstützte Entwicklung",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Quellcodeverwaltung",{"href":119,"dataGaLocation":28,"dataGaName":120},"/de-de/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"Automatisierte Softwarebereitstellung",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"Schutz der Software-Lieferkette",{"href":142,"dataGaLocation":28,"dataGaName":143},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"Bewertung",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"Sichtbarkeit und Bewertung",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Wertstrommanagement",{"href":163,"dataGaLocation":28,"dataGaName":164},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"Analysen und Einblicke",{"href":168,"dataGaLocation":28,"dataGaName":169},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLab für",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/de-de/enterprise/","enterprise",{"text":179,"config":180},"Kleinunternehmen",{"href":181,"dataGaLocation":28,"dataGaName":182},"/de-de/small-business/","small business",{"text":184,"config":185},"den öffentlichen Sektor",{"href":186,"dataGaLocation":28,"dataGaName":187},"/de-de/solutions/public-sector/","public sector",{"text":189,"config":190},"Preise",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/de-de/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"Ressourcen",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"Alle Ressourcen anzeigen",{"href":200,"dataGaName":196,"dataGaLocation":28},"/de-de/resources/",[202,235,258],{"title":203,"items":204},"Erste Schritte",[205,210,215,220,225,230],{"text":206,"config":207},"Installieren",{"href":208,"dataGaName":209,"dataGaLocation":28},"/de-de/install/","install",{"text":211,"config":212},"Kurzanleitungen",{"href":213,"dataGaName":214,"dataGaLocation":28},"/de-de/get-started/","quick setup checklists",{"text":216,"config":217},"Lernen",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"Produktdokumentation",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"Best-Practice-Videos",{"href":228,"dataGaName":229,"dataGaLocation":28},"/de-de/getting-started-videos/","best practice videos",{"text":231,"config":232},"Integrationen",{"href":233,"dataGaName":234,"dataGaLocation":28},"/de-de/integrations/","integrations",{"title":236,"items":237},"Entdecken",[238,243,248,253],{"text":239,"config":240},"Kundenerfolge",{"href":241,"dataGaName":242,"dataGaLocation":28},"/de-de/customers/","customer success stories",{"text":244,"config":245},"Blog",{"href":246,"dataGaName":247,"dataGaLocation":28},"/de-de/blog/","blog",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/de-de/teamops/","teamops",{"title":259,"items":260},"Vernetzen",[261,266,271,276,281],{"text":262,"config":263},"GitLab-Services",{"href":264,"dataGaName":265,"dataGaLocation":28},"/de-de/services/","services",{"text":267,"config":268},"Community",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"Forum",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"Veranstaltungen",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"Partner",{"href":284,"dataGaName":285,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":291,"config":292},"the source promo card",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"Lies die News",{"href":297,"dataGaName":298,"dataGaLocation":28},"/de-de/the-source/","the source",{"text":300,"config":301,"lists":303},"Unternehmen",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"Über",{"href":309,"dataGaName":310,"dataGaLocation":28},"/de-de/company/","about",{"text":312,"config":313,"footerGa":316},"Karriere",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"Geschäftsführung",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"Team",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"Handbuch",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"Investor Relations",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"Trust Center",{"href":342,"dataGaName":343,"dataGaLocation":28},"/de-de/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":28},"/de-de/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"Newsletter",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"Presse",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":360,"config":361,"lists":362},"Kontakt",{"dataNavLevelOne":302},[363],{"items":364},[365,368,373],{"text":35,"config":366},{"href":37,"dataGaName":367,"dataGaLocation":28},"talk to sales",{"text":369,"config":370},"Support",{"href":371,"dataGaName":372,"dataGaLocation":28},"/support/","get help",{"text":374,"config":375},"Kundenportal",{"href":376,"dataGaName":377,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":379,"login":380,"suggestions":387},"Schließen",{"text":381,"link":382},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":383,"config":384},"gitlab.com",{"href":42,"dataGaName":385,"dataGaLocation":386},"search login","search",{"text":388,"default":389},"Vorschläge",[390,393,398,400,405,410],{"text":57,"config":391},{"href":62,"dataGaName":392,"dataGaLocation":386},"GitLab Duo (AI)",{"text":394,"config":395},"Code Suggestions (KI)",{"href":396,"dataGaName":397,"dataGaLocation":386},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":399},{"href":111,"dataGaName":109,"dataGaLocation":386},{"text":401,"config":402},"GitLab auf AWS",{"href":403,"dataGaName":404,"dataGaLocation":386},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":406,"config":407},"GitLab auf Google Cloud",{"href":408,"dataGaName":409,"dataGaLocation":386},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":411,"config":412},"Warum GitLab?",{"href":70,"dataGaName":413,"dataGaLocation":386},"Why GitLab?",{"freeTrial":415,"mobileIcon":420,"desktopIcon":425},{"text":416,"config":417},"Kostenlos testen",{"href":418,"dataGaName":33,"dataGaLocation":419},"https://gitlab.com/-/trials/new/","nav",{"altText":421,"config":422},"GitLab-Symbol",{"src":423,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":421,"config":426},{"src":427,"dataGaName":424,"dataGaLocation":419},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":429,"mobileIcon":433,"desktopIcon":435},{"text":430,"config":431},"Erfahre mehr über GitLab Duo",{"href":62,"dataGaName":432,"dataGaLocation":419},"gitlab duo",{"altText":421,"config":434},{"src":423,"dataGaName":424,"dataGaLocation":419},{"altText":421,"config":436},{"src":427,"dataGaName":424,"dataGaLocation":419},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":442,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":443,"button":444,"config":449,"_id":451,"_type":14,"_source":16,"_file":452,"_stem":453,"_extension":19},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":445,"config":446},"Beta testen",{"href":447,"dataGaName":448,"dataGaLocation":28},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":450},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":455,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":456,"_id":659,"_type":14,"title":660,"_source":16,"_file":661,"_stem":662,"_extension":19},"/shared/de-de/main-footer",{"text":457,"source":458,"edit":464,"contribute":469,"config":474,"items":479,"minimal":651},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":459,"config":460},"Quelltext der Seite anzeigen",{"href":461,"dataGaName":462,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":465,"config":466},"Diese Seite bearbeiten",{"href":467,"dataGaName":468,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":470,"config":471},"Beteilige dich",{"href":472,"dataGaName":473,"dataGaLocation":463},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":475,"facebook":476,"youtube":477,"linkedin":478},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[480,503,558,587,621],{"title":46,"links":481,"subMenu":486},[482],{"text":483,"config":484},"DevSecOps-Plattform",{"href":55,"dataGaName":485,"dataGaLocation":463},"devsecops platform",[487],{"title":189,"links":488},[489,493,498],{"text":490,"config":491},"Tarife anzeigen",{"href":191,"dataGaName":492,"dataGaLocation":463},"view plans",{"text":494,"config":495},"Vorteile von Premium",{"href":496,"dataGaName":497,"dataGaLocation":463},"/de-de/pricing/premium/","why premium",{"text":499,"config":500},"Vorteile von Ultimate",{"href":501,"dataGaName":502,"dataGaLocation":463},"/de-de/pricing/ultimate/","why ultimate",{"title":504,"links":505},"Lösungen",[506,511,514,516,521,526,530,533,536,541,543,545,548,553],{"text":507,"config":508},"Digitale Transformation",{"href":509,"dataGaName":510,"dataGaLocation":463},"/de-de/topics/digital-transformation/","digital transformation",{"text":512,"config":513},"Sicherheit und Compliance",{"href":137,"dataGaName":138,"dataGaLocation":463},{"text":122,"config":515},{"href":105,"dataGaName":106,"dataGaLocation":463},{"text":517,"config":518},"Agile Entwicklung",{"href":519,"dataGaName":520,"dataGaLocation":463},"/de-de/solutions/agile-delivery/","agile delivery",{"text":522,"config":523},"Cloud-Transformation",{"href":524,"dataGaName":525,"dataGaLocation":463},"/de-de/topics/cloud-native/","cloud transformation",{"text":527,"config":528},"SCM",{"href":119,"dataGaName":529,"dataGaLocation":463},"source code management",{"text":109,"config":531},{"href":111,"dataGaName":532,"dataGaLocation":463},"continuous integration & delivery",{"text":161,"config":534},{"href":163,"dataGaName":535,"dataGaLocation":463},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":463},"/de-de/solutions/gitops/","gitops",{"text":174,"config":542},{"href":176,"dataGaName":177,"dataGaLocation":463},{"text":179,"config":544},{"href":181,"dataGaName":182,"dataGaLocation":463},{"text":546,"config":547},"Öffentlicher Sektor",{"href":186,"dataGaName":187,"dataGaLocation":463},{"text":549,"config":550},"Bildungswesen",{"href":551,"dataGaName":552,"dataGaLocation":463},"/de-de/solutions/education/","education",{"text":554,"config":555},"Finanzdienstleistungen",{"href":556,"dataGaName":557,"dataGaLocation":463},"/de-de/solutions/finance/","financial services",{"title":194,"links":559},[560,562,564,566,569,571,573,575,577,579,581,583,585],{"text":206,"config":561},{"href":208,"dataGaName":209,"dataGaLocation":463},{"text":211,"config":563},{"href":213,"dataGaName":214,"dataGaLocation":463},{"text":216,"config":565},{"href":218,"dataGaName":219,"dataGaLocation":463},{"text":221,"config":567},{"href":223,"dataGaName":568,"dataGaLocation":463},"docs",{"text":244,"config":570},{"href":246,"dataGaName":247,"dataGaLocation":463},{"text":239,"config":572},{"href":241,"dataGaName":242,"dataGaLocation":463},{"text":249,"config":574},{"href":251,"dataGaName":252,"dataGaLocation":463},{"text":262,"config":576},{"href":264,"dataGaName":265,"dataGaLocation":463},{"text":254,"config":578},{"href":256,"dataGaName":257,"dataGaLocation":463},{"text":267,"config":580},{"href":269,"dataGaName":270,"dataGaLocation":463},{"text":272,"config":582},{"href":274,"dataGaName":275,"dataGaLocation":463},{"text":277,"config":584},{"href":279,"dataGaName":280,"dataGaLocation":463},{"text":282,"config":586},{"href":284,"dataGaName":285,"dataGaLocation":463},{"title":300,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":307,"config":590},{"href":309,"dataGaName":302,"dataGaLocation":463},{"text":312,"config":592},{"href":314,"dataGaName":315,"dataGaLocation":463},{"text":320,"config":594},{"href":322,"dataGaName":323,"dataGaLocation":463},{"text":325,"config":596},{"href":327,"dataGaName":328,"dataGaLocation":463},{"text":330,"config":598},{"href":332,"dataGaName":333,"dataGaLocation":463},{"text":335,"config":600},{"href":337,"dataGaName":338,"dataGaLocation":463},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":463},"/sustainability/",{"text":606,"config":607},"Vielfalt, Inklusion und Zugehörigkeit",{"href":608,"dataGaName":609,"dataGaLocation":463},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":611},{"href":342,"dataGaName":343,"dataGaLocation":463},{"text":350,"config":613},{"href":352,"dataGaName":353,"dataGaLocation":463},{"text":355,"config":615},{"href":357,"dataGaName":358,"dataGaLocation":463},{"text":617,"config":618},"Transparenzerklärung zu moderner Sklaverei",{"href":619,"dataGaName":620,"dataGaLocation":463},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":622,"links":623},"Nimm Kontakt auf",[624,627,629,631,636,641,646],{"text":625,"config":626},"Sprich mit einem Experten/einer Expertin",{"href":37,"dataGaName":38,"dataGaLocation":463},{"text":369,"config":628},{"href":371,"dataGaName":372,"dataGaLocation":463},{"text":374,"config":630},{"href":376,"dataGaName":377,"dataGaLocation":463},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":463},"https://status.gitlab.com/","status",{"text":637,"config":638},"Nutzungsbedingungen",{"href":639,"dataGaName":640,"dataGaLocation":463},"/terms/","terms of use",{"text":642,"config":643},"Datenschutzerklärung",{"href":644,"dataGaName":645,"dataGaLocation":463},"/de-de/privacy/","privacy statement",{"text":647,"config":648},"Cookie-Einstellungen",{"dataGaName":649,"dataGaLocation":463,"id":650,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":463},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":463},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":463,"id":650,"isOneTrustButton":91},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"allPosts":664,"featuredPost":878,"totalPagesCount":898,"initialPosts":899},[665,693,718,741,765,790,815,838,857],{"_path":666,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":675,"config":686,"_id":689,"_type":14,"title":690,"_source":16,"_file":691,"_stem":692,"_extension":19},"/de-de/blog/agile-pairing-sessions",{"title":668,"description":669,"ogTitle":668,"ogDescription":669,"noIndex":6,"ogImage":670,"ogUrl":671,"ogSiteName":672,"ogType":673,"canonicalUrls":671,"schema":674},"Pair-Programming-Guide: Was, wie und warum?","In diesem Artikel erfahrt ihr, wie Pair Programming in agile funktioniert und worauf ihr bei der Zusammenarbeit in Pairing Sessions achten müsst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665897/Blog/Hero%20Images/incrementalcodedevelopment.jpg","https://about.gitlab.com/blog/agile-pairing-sessions","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Pair-Programming-Guide: Was, wie und warum?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2019-08-20\",\n      }",{"title":668,"description":669,"authors":676,"heroImage":670,"date":678,"body":679,"category":680,"tags":681,"updatedDate":685},[677],"Suri Patel","2019-08-20","Viele Aufgaben sind oft leicht im Team zu lösen, während andere Aufgaben alleine ausgeführt werden müssen. In diesem Artikel erfährst du, wie Pair Programming in einem agilen Umfeld funktioniert und worauf du bei der Zusammenarbeit achten musst. Du lernst, wie du durch Pair Programming  Probleme löst und Hindernisse überwinden kannst. Außerdem erhältst du praktische Tipps dazu, wie du erfolgreich mit Pair Programming  starten kannst.\n\n## Was ist Pair Programming?\n\nBeim Pair Programming, einem agilen Ansatz zur Softwareentwicklung, arbeitest du zusammen mit einem Partner an einem Arbeitsplatz. Dabei ist eine Person der Driver oder auch Pilot(in) und schreibt den Code, während die andere Person die Rolle des Observers, auch Navigator genannt, übernimmt. Der Navigator überprüft dabei den vom Driver geschriebenen Code. Solche Pairing-Sessions können die Entwicklung vorantreiben, da ihr kollaborativ an Lösungen für verschiedene Herausforderungen arbeiten könnt.\n\nAnstatt isoliert zu arbeiten, teilst du und dein Partner euer Wissen und könnt so Hindernisse schnell überwinden. Einige Unternehmen sehen Pair Programming als ineffizient an, da zwei Entwickler(innen) am gleichen Code arbeiten. Dennoch bringt Pair Programming zahlreiche Vorteile mit, die man nicht außer Acht lassen sollte.\n\n## Wie beginnt ihr richtig mit dem Pair Programming?\n\nDer Schlüssel zu einer erfolgreichen Pair Programming Session liegt in der offenen Kommunikation und der Erstellung eines gemeinsamen Plans, um Engpässe während des Projektverlaufs zu vermeiden.\n\nHier sind einige Punkte, die ihr als Team vor Beginn der Session bedenken solltet:\n\n- __Definiert den Rahmen der Aufgabe:__ Hier ist es wichtig, auch die relevanten Stakeholder, wie die Projektverantwortlichen, miteinzubeziehen. Es ist wichtig, zu verstehen, wann die Aufgabe als abgeschlossen gilt. \n\n- __Erstellt einen detaillierten Projektplan:__ Überlegt euch, wie ihr die Verantwortlichkeiten für die Programmierung und die Überprüfung verteilen wollt, wie ihr das Testen angeht und welche externen Ressourcen ihr möglicherweise benötigt, um das Projekt erfolgreich abzuschließen.\n\n- __Führt ein Brainstorming zu potenziellen Hindernissen durch:__ Denkt über alle möglichen Blocker nach, die auftreten könnten und sucht nach möglichen Lösungen. Ihr könnt gemeinsam darüber diskutieren oder euch erstmal individuell Gedanken dazu machen und euch dann im Nachgang zusammensetzen. \n\n- __Von Computer und Maus bis hin zum Whiteboard__ – einigt euch, welches Setup ihr verwenden wollt.\n\nWenn ihr diese Punkte berücksichtigt, könnt ihr als Team effektiver zusammenarbeiten und die Chancen auf einen erfolgreichen Abschluss des Projekts erhöhen.\n\n## Kontinuierliches Lernen durch Pair Programming\n\nPair Programming kann zunächst als ineffizient erscheinen, weil zwei Entwickler(innen) gleichzeitig an einem Problem arbeiten. Es ist jedoch wichtig zu verstehen, dass kontinuierliches Lernen ein wesentlicher Bestandteil agiler Methodiken ist und maßgeblich zur Verbesserung aller Aspekte der Projektabwicklung beiträgt. \n\n- __Vorteile des Austauschs:__ Gerade für weniger erfahrene Entwickler(innen) kann es sehr hilfreich sein,  Gedankengänge zu besprechen und zu hören, wie erfahrene Kolleg(innen) an dieselben Probleme herangehen. Dies fördert nicht nur das Verständnis und die Lösungskompetenz, sondern auch die persönliche Entwicklung und das Vertrauen in die eigenen Fähigkeiten.\n\n- __Flexible Anwendung:__ Pair Programming muss nicht immer nach einem strikten Driver-/Navigator-Modell erfolgen. Ein kollaborativeres Modell, bei dem sich die Beteiligten einfach unterhalten und füreinander Aufgaben übernehmen, kann ebenfalls sehr effektiv sein. Dies kann vor allem in einer Vollzeit-Pairing-Umgebung mit etwas Übung und der richtigen Partnerin oder dem richtigen Partner eine bereichernde Erfahrung sein.\n\n- __Förderung von Teamarbeit und Lernen:__ Pairing-Sessions bieten eine Plattform, auf der Teammitglieder gemeinsam lernen und sich entwickeln können. Dies stärkt nicht nur individuelle Fähigkeiten, sondern auch den Teamgeist und die kollektive Problemlösungskompetenz.\n\nTrotz potenzieller Bedenken kann Pair Programming eine wertvolle Methode sein, um die Ausliefergeschwindigkeit zu erhöhen und gleichzeitig eine Lernkultur innerhalb des Teams zu fördern. Es lohnt sich, die Vorteile dieser Methode zu erwägen und gegebenenfalls einmal auszuprobieren.\n\n## Vorteile von Pair Programming\n\nBeim Pair Programming könnt ihr von der direkten Zusammenarbeit in vielerlei Hinsicht profitieren:\n\n- __Steigerung der Arbeitsmoral:__ Die Paarprogrammierung kann die Arbeitsmoral verbessern und der direkte Austausch den Arbeitsalltag mitunter abwechslungsreicher und unterhaltsamer gestalten.\n\n- __Lernmöglichkeiten:__ Durch die Arbeit mit einer Partnerin oder einem Partner könnt ihr verschiedene Programmierpraktiken und Workflow-Techniken erlernen. Dies fördert nicht nur die persönliche Entwicklung, sondern auch die des gesamten Teams.\n\n- __Innovation und Effizienz:__ Gemeinsames Arbeiten kann zu neuen Herangehensweisen und Lösungen führen. So kann die Innovation und Effizienz innerhalb des Teams gesteigert werden.\n\n- __Abbau von Wissenssilos:__ Durch den regelmäßigen Austausch von Wissen werden Wissenssilos vermieden und das gesamte Team kann vom jeweiligen Fachwissen der anderen profitieren.\n\n- __Effektive Problemlösung:__ Das gemeinsame Programmieren kann dazu führen, dass größere und komplexere Probleme schneller gelöst werden, da ihr einander unterstützt und ergänzt.\n\n- __Sofortiges Feedback und Mentoring:__ Gerade für neue oder weniger erfahrene Teammitglieder ist das sofortige Feedback von Kolleg(innen) sehr wertvoll. Erfahrene Entwickler(innen) können ihre Kenntnisse weitergeben und gleichzeitig ihre eigenen Fähigkeiten im Umgang mit komplexen Problemen verbessern.\n\n## Nachteile von Pair Programming\n\nTrotz der vielen Vorteile gibt es auch einige Herausforderungen, die beim Pair Programming auftreten können:\n\n- __Potenzielle Ineffizienz:__ Pair Programming kann in manchen Situationen als ineffizient empfunden werden, besonders wenn es zu oft angewendet oder für Aufgaben genutzt wird, die alleine einfacher umzusetzen sind, wie z.B. Boilerplate-Code oder kleinere Änderungen.\n\n- __Schwierigkeit der Erfolgsmessung:__ Die Wirksamkeit von Pair Programming ist oft schwer zu messen. Obwohl es Indikatoren wie Funktionsausfälle, Fehlerzahlen und Produktivitätssteigerungen gibt, bleibt der konkrete Nachweis des Nutzens manchmal unklar.\n\n- __Anpassungsbedarf:__ Wenn Teams mit Pair Programming beginnen, kann es einige Zeit und Übung erfordern, bis sich die Mitglieder an diese Arbeitsweise gewöhnen. Es ist wichtig, dass ihr nach jeder Pairing Session reflektiert, was gut und was weniger gut funktioniert hat, um zukünftige Sessions kontinuierlich verbessern zu können.\n\n## Pair Programming: Best Practices\n\nUm das beste Ergebnis beim Pair Programming zu erzielen, empfehlen wir euch, die folgenden Best Practices zu befolgen:\n\n- __ABC (Always be communicating):__ Egal, ob ihr schon früher gut zusammengearbeitet habt oder das gerade zum ersten Mal tut, Kommunikation ist besonders wichtig. Da zwei Personen unterschiedliche Gedanken und Meinungen haben, ist es wichtig, frühzeitig offene und häufige Kommunikationspraktiken einzuführen, um Probleme im Projekt und zwischen euch zu vermeiden.\n\n- __Wechselt die Rollen:__ Niemand sollte durchgehend nur navigieren oder programmieren. Wechselt euch in jeder Rolle regelmäßig ab, um sicherzustellen, dass ihr nicht müde werdet und ihr weiterhin Qualitätsarbeit leisten könnt.\n\n- __Macht Pausen:__ Wie das Sprichwort sagt: *Rom wurde nicht an einem Tag erbaut*. Das gilt auch für das Programmieren. Achtet darauf, dass ihr Pausen macht, um ein Burn-out zu vermeiden.\n\n- __Nutzt gute technische Hilfsmittel und setzt auf Videokommunikation:__ Oftmals wird Pair Programming online durchgeführt. Um die Zusammenarbeit zu stärken, hilft es, die Kamera anzumachen und beim Programmieren im Austausch zu bleiben.\n\n- __Bittet um Hilfe:__ Wenn es einen Teil des Projekts gibt, den ihr beide nicht versteht, zögert nicht, um Hilfe zu bitten. Es ist besser, Fragen zu stellen, bevor das Projekt abgeschlossen ist, als danach.\n\n## See it in action\nObwohl Pair Programming meistens vor Ort angewendet wird, kann es trotzdem auch online angewendet werden. Als fully remote Firma haben wir die Erfahrung gemacht, dass Remote Pair Programming aufgrund der räumlichen Distanz und der damit verbundenen technischen Einschränkungen eine Herausforderung darstellen kann. Nicht immer sind die verfügbaren Tools ideal, aber es ist dennoch möglich, effektiv remote zu arbeiten. Im Folgenden geben wir dir ein paar Tipps dazu an die Hand:\n\n### Lösungsansätze und Werkzeuge\n\nUm diese Herausforderungen zu überwinden, haben wir spezielle Projekt- und Problemvorlagen für Pairing-Sessions entwickelt. Tools wie VSCode Live Share ermöglichen es, trotz Distanz gemeinsam an Code zu arbeiten. Der Austausch von Patches und die offene Diskussion werden ebenfalls gefördert.\n\n### Kollaborative Sitzungen\n\nIn unserem Support-Team führen wir regelmäßig Pairing-Sessions durch, die wir „Crush-Sessions“ nennen. Dabei stellen wir fest, dass die Zusammenarbeit oft zu einer höheren Ticketbearbeitungsrate führt. Diese Sitzungen haben sich als sehr effektiv erwiesen. Deshalb planen wir sie jedes Quartal als Meilensteine ein.\n\n### Community-Driven Pairing\n\nIm Frontend-Team haben wir getestet, wie Pair Programming am besten unterstützt werden kann. Eine erfolgreiche Methode ist das Posten von Pairing-Anfragen in einem separaten Slack-Kanal, in dem sich interessierte Kolleg(innen) melden können. Anschließend wird ein Termin festgelegt, in dem eine Art Mob-Programming-Session stattfindet, die es ermöglicht, gemeinsam an Lösungen zu arbeiten.\n\nWenn du also das nächste Mal vor einer komplexen Herausforderung stehst, erwäge die Möglichkeit, mit Teamkolleg(innen) zusammenzuarbeiten. Gemeinsames Programmieren kann nicht nur die Lösungsfindung beschleunigen, sondern auch die Angst vor schwierigen Aufgaben verringern.\n","insights",[682,683,9,684],"agile","collaboration","workflow","2024-09-26",{"slug":687,"featured":6,"template":688},"agile-pairing-sessions","BlogPost","content:de-de:blog:agile-pairing-sessions.yml","Agile Pairing Sessions","de-de/blog/agile-pairing-sessions.yml","de-de/blog/agile-pairing-sessions",{"_path":694,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":695,"content":701,"config":712,"_id":714,"_type":14,"title":715,"_source":16,"_file":716,"_stem":717,"_extension":19},"/de-de/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"title":696,"description":697,"ogTitle":696,"ogDescription":697,"noIndex":6,"ogImage":698,"ogUrl":699,"ogSiteName":672,"ogType":673,"canonicalUrls":699,"schema":700},"GitLab ist ein Leader im Gartner Magic Quadrant für DevOps-Plattformen 2024","GitLab ist in den Bereichen „Ability to execute“ und „Completeness of vision“ am besten positioniert. Eine Anerkennung für unsere Kund(inn)en und GitLabs DevOps-Innovationen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662523/Blog/Hero%20Images/Gartner_DevOps_Blog_Post_Cover_Image_1800x945__2_.png","https://about.gitlab.com/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab ist ein Leader im Gartner Magic Quadrant für DevOps-Plattformen 2024\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Kramer\"}],\n        \"datePublished\": \"2024-09-05\",\n      }\n                  ",{"title":696,"description":697,"authors":702,"heroImage":698,"date":704,"body":705,"category":706,"tags":707,"updatedDate":711},[703],"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.***","news",[706,708,709,9,710],"research","DevSecOps platform","DevSecOps","2025-04-28",{"slug":713,"featured":91,"template":688},"gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops","content:de-de:blog:gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","Gitlab Named A Leader In The 2024 Gartner Magic Quadrant For Devops","de-de/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops.yml","de-de/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops",{"_path":719,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":720,"content":726,"config":735,"_id":737,"_type":14,"title":738,"_source":16,"_file":739,"_stem":740,"_extension":19},"/de-de/blog/how-to-keep-up-with-ci-cd-best-practices",{"title":721,"description":722,"ogTitle":721,"ogDescription":722,"noIndex":6,"ogImage":723,"ogUrl":724,"ogSiteName":672,"ogType":673,"canonicalUrls":724,"schema":725},"CI/CD Best Practices für mehr Effizienz","Erfahre, was Continuous Integration/Continuous Delivery (CI/CD) bedeutet, wie du CI/CD Best Practices implementierst und warum sie wichtig sind.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661856/Blog/Hero%20Images/ci-cd-demo.jpg","https://about.gitlab.com/blog/how-to-keep-up-with-ci-cd-best-practices","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"CI/CD Best Practices für mehr Effizienz\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n        \"datePublished\": \"2022-02-03\",\n      }",{"title":721,"description":722,"authors":727,"heroImage":723,"date":729,"body":730,"category":680,"tags":731,"updatedDate":734},[728],"Valerie Silverthorne","2022-02-03","Continuous Integration und Continuous Delivery [(CI/CD)](/de-de/topics/ci-cd/) stehen im Mittelpunkt jeder erfolgreichen DevOps-Praxis. Teams, die ihre Softwareentwicklung modern gestalten wollen, müssen mit den GitLab CI/CD Best Practices Schritt halten. \n\nIn diesem Artikel, erfährst du, was Continuous Integration/Continuous Delivery (CI/CD) bedeutet, wie du einige Best Practices implementierst und warum sie wichtig sind.\n\n## Was bedeutet CI/CD?\nCI/CD umfasst verschiedene Aspekte: Es ist ein technischer Prozess, eine Denkweise und eine Abfolge von Schritten. Im Kern steht die Automatisierung, die DevOps-Teams ermöglicht, die Code-Entwicklung zu optimieren.\n\nContinuous Integration (CI) erleichtert den Software-Build und die Integration des Quellcodes, verbessert die Versionskontrolle und fördert durch Automatisierung eine intensivere Zusammenarbeit. Nach der Integration folgt Continuous Delivery (CD), das automatisierte Tests und Deployments umfasst. CD verringert den manuellen Aufwand für Bereitstellung und Deployment erheblich und hilft Teams, die Verwaltungstools für den Lebenszyklus der Software deutlich zu reduzieren.\n\n### CI/CD- vs. CI/CD-Pipeline: Erklärung\nCI/CD (Continuous Integration/Continuous Delivery bzw. Continuous Deployment) und CI/CD-Pipeline sind eng miteinander verbundene Begriffe, die jedoch unterschiedliche Bedeutungen haben. \n\n**CI/CD steht für Continuous Integration und Continuous Delivery oder Continuous Deployment.** Es ist ein methodischer Ansatz in der Softwareentwicklung, der darauf abzielt, die Integration, das Testen und die Bereitstellung von Codeänderungen zu automatisieren. \n\n**Eine CI/CD-Pipeline ist die konkrete Umsetzung des CI/CD-Prinzips.** Sie besteht aus einer Reihe von automatisierten Schritten, die den gesamten Prozess der Softwareentwicklung und -bereitstellung abbilden. Eine typische CI/CD-Pipeline umfasst Stufen wie Code-Commit, Build, Test, Bereitstellung und Monitoring. Jede dieser Stufen ist so konzipiert, dass sie den Übergang von einer Entwicklungsphase zur nächsten automatisiert und beschleunigt. Eine CI/CD-Pipeline nutzt verschiedene Automatisierungswerkzeuge, um sicherzustellen, dass Codeänderungen nahtlos und effizient durch die einzelnen Phasen des Entwicklungszyklus fließen.\n\n## Best Practices: CI/CD-Pipeline\nUm mit CI/CD erfolgreich zu sein, sollte [kontinuierliche Integration](/de-de/solutions/continuous-integration/), Lieferung und Bereitstellung fest in deiner Arbeitsweise verankert sein, da sie die Basis moderner Softwareentwicklung bilden. DevOps zielt darauf ab, Software schneller als herkömmliche Methoden zu den Nutzer(innen) zu bringen. \n\nFragt man 10 Teams nach den DevOps CI/CD Best Practices, erhält man wahrscheinlich 10 verschiedene Antworten.\n\n**Dennoch gibt es einige allgemein anerkannte Tipps für DevOps CI/CD Best Practices:**\n\n**Einmaliger Build:** Vermeide es, für jede Stufe einen neuen Build zu erstellen, da dies zu Unregelmäßigkeiten führen kann. Nutze stattdessen dieselben Build-Artefakte in jeder Stufe der CI/CD-Pipeline. Das setzt einen Build voraus, der unabhängig von der Umgebung ist.\n\n**Tests optimieren:** Finde ein gutes Gleichgewicht zwischen Testabdeckung und Performance. Dauern die Tests zu lange, versuchen die Nutzer(innen) möglicherweise, den Prozess zu umgehen.\n\n**Fail Fast:** Auf der CI-Seite müssen die Entwickler, die den Code übertragen, so schnell wie möglich wissen, ob es Probleme gibt, damit sie den Code neu aufsetzen und beheben können, bevor er in Vergessenheit gerät. Die Idee des „Fail Fast“ hilft auch, den Kontextwechsel der Entwickler zu reduzieren. Das macht die DevOps-Profis zufriedener.\n\n**Regelmäßige Code-Commits:** Je regelmäßiger der Code übertragen wird, desto größer ist der Nutzen für die DevOps-Teams.\n\n**Schnelle Fehlerbehebung:** CI/CD ermöglicht es, fehlerhafte Builds schnell zu reparieren.\n\n**Bereinigte Pre-Production-Umgebungen:** Je länger Umgebungen in Gebrauch sind, desto schwieriger wird es, alle Konfigurationsänderungen und Aktualisierungen nachzuvollziehen, die vorgenommen wurden. Daher ist es ratsam, die Vorproduktionsumgebungen zwischen den einzelnen Einsätzen zu bereinigen.\n\n**Ständige Automatisierung:** Optimiere die CI/CD-Pipeline kontinuierlich, um einen Zustand der „kontinuierlichen Automatisierung“ zu erreichen.\n\n**Klare Prozesse:** Stelle sicher, dass die Release- und Rollback-Pläne gut dokumentiert sind und vom gesamten Team verstanden werden.\n\n**Frühzeitige Sicherheit:** CCI/CD ist eine Verschiebung des Schwerpunkts und bietet daher eine gute Gelegenheit, die Sicherheit früher in den Prozess zu integrieren. Somit gibt es auch CI/CD Pipeline Security Best Practices, die du beachten solltest.\n\n**Feedback-Schleifen einrichten:** Sorge dafür, dass das gesamte Team leicht Feedback erhalten und geben kann.\n\n## Best Practices für Continuous Delivery\nBest Practices für Continuous Delivery und Deployment sollten genauer betrachtet werden, da Continuous Integration oft mehr Aufmerksamkeit erhält. \n\n**Hier ist eine Übersicht der bewährten Praktiken für CD:**\n\n**Starte mit dem Vorhandenen:** Warte nicht auf eine neue Plattform. Es ist immer möglich, bestehende Systeme zu optimieren, um schneller und effizienter zu arbeiten.\n\n**Setze auf Einfachheit:** Die effektivste CD wird mit einem Minimum an Tools durchgeführt.\n\n**Behalte den Überblick:** Probleme und Merge-Anfragen können leicht außer Kontrolle geraten. Wenn möglich, nutze Meilensteine, um den Überblick zu behalten. Bonus: Meilensteine können auch bei der Planung von Agile-Sprints und -Releases hilfreich sein.\n\n**Automatisiere Bereitstellungen:** Setze auf Automatisierung beim User Acceptance Testing und in der Staging-Phase.\n\n**Release-Pipeline optimieren:** Automatisierung ist der Schlüssel zur effizienten Verwaltung der Release-Pipeline.\n\n**Überwachung einrichten:** Eine effektive Überwachung des Produktionsprozesses spart Zeit und Geld und liefert zudem wertvolle Daten für geschäftliche Entscheidungen.\n\n**Führe Continuous Deployment ein:** Sobald Continuous Delivery stabil läuft, führe ein „hands-free“-Deployment ein, das es ermöglicht, Änderungen automatisch in die Produktion zu überführen.\n\n## Optimierung der CI/CD-Pipeline\nEine CI/CD-Pipeline stellt die Abfolge von Schritten dar, die erforderlich sind, um eine neue Softwareversion bereitzustellen. Durch Überwachung und Automatisierung können diese Prozesse erheblich verbessert werden, insbesondere in den Phasen der Integration, des Testens, der Bereitstellung und des Deployments.\n\n**Die wesentlichen Bestandteile einer CI/CD-Pipeline umfassen:**\n\n**1. Planung**\n**2. Analyse**\n**3. Design**\n**4. Build**\n**5. Test**\n**6. Release**\n**7. Deployment**\n**8. Validierung**\n**9. Compliance**\n**10. Wartung**\n\nObwohl diese Schritte manuell durchgeführt werden können, entfaltet die CI/CD-Pipeline ihren vollen Nutzen erst durch Automatisierung.\n\n**Zur Verbesserung der CI/CD-Pipeline bieten sich folgende Maßnahmen an:**\n\n**Release-Strategie variieren:** Ein Canary-Release (oder [Canary Deployment](https://docs.gitlab.com/user/project/canary_deployments/)) könnte in Betracht gezogen werden. Dabei werden neue Funktionen zunächst nur einer ausgewählten Gruppe von Nutzern zur Verfügung gestellt.\n\n**Automatisierung ausweiten:** Erhöhe die Anzahl der automatisierten Tests – davon kann es nie genug geben.\n\n**Tools rationalisieren:** Weniger Tools führen zu weniger Übergaben und vereinfachten Abläufen. Eine integrierte [DevOps-Plattform](/de-de/solutions/devops-platform/), die CI/CD umfasst, kann hier besonders vorteilhaft sein.\n\n**Regelmäßige Softwarekompositionsanalysen:** Führe kontinuierlich Analysen der Softwarezusammensetzung durch, um sicherzustellen, dass das DevOps-Team kritische Probleme mit Open-Source-Software frühzeitig erkennt und verfolgt.\n\n## CI/CD: Metriken zur Erfolgsmessung\nUm zu erkennen, wie effektiv CI/CD-Praktiken sind, ist eine kontinuierliche Messung notwendig. Metriken sind entscheidend, um die Systemleistung zu verbessern und den Mehrwert zu identifizieren. Sie dienen auch als Basis zur Beurteilung der Auswirkungen von Optimierungen.\n\n### Zykluszeit\nDie Zykluszeit misst die Dauer vom Beginn der Arbeit am Code bis zur Bereitstellung einer funktionalen Anwendung. Durch die Messung der verschiedenen Entwicklungsphasen erhältst du wertvolle Einblicke in die gesamte Entwicklungsdauer und erkennst mögliche Engpässe im Prozess. \n\n### Time to Value\n„Time to Value“ beschreibt, wie lange es dauert, bis geschriebener Code veröffentlicht wird. Idealerweise sollten Integration, Testen, Lieferung und Deployment innerhalb von Minuten bis wenigen Stunden abgeschlossen sein. Dauert der Durchlauf durch die CI/CD-Pipeline Tage, ist eine Optimierung erforderlich, um den Wert zu realisieren.\n\n### Uptime\nUptime ist ein Maß für die Stabilität und Zuverlässigkeit des Systems und dafür, ob alles so funktioniert, wie es sollte. Sie ist eine der wichtigsten Aufgaben des Ops-Teams. Wenn die CI/CD-Strategie automatisiert ist, können die Ops-Leiter mehr Zeit auf die Systemstabilität und weniger Zeit auf Workflow-Probleme verwenden.\n\n### Fehlerquoten\nDie Fehlerquote bei Anwendungen ist eine alltägliche Erscheinung im Entwicklungsprozess. Ihre Verfolgung ist sehr wichtig, denn die Fehlerquoten können nicht nur auf Qualitätsprobleme hinweisen, sondern auch auf laufende Probleme mit der Leistung und der Uptime. Wenn die Uptime und die Fehlerquoten hoch erscheinen, kann dies ein Hinweis auf eine gängige CI/CD-Problematik zwischen Dev- und Ops-Teams sein. Betriebsziele sind ein wichtiger Indikator für den Prozesserfolg.\n\n### Infrastrukturkosten\nDie Infrastrukturkosten sind besonders bei Cloud-nativer Entwicklung entscheidend. Die Verwaltung einer CI/CD-Plattform kann teuer werden, wenn die Kosten nicht kontrolliert werden. Cloud-Anbieter berücksichtigen bei der Preisgestaltung die Ausgaben für Netzwerkausrüstung, Infrastrukturwartung und Personal.\n\n### Teambindung\nEntwickler(innen) und Mitarbeiter(innen) bleiben tendenziell länger im Unternehmen, wenn sie sich wertgeschätzt und zufrieden fühlen. Gute Zusammenarbeit und effektive Kommunikation innerhalb der Teams fördern die Teambindung. Andererseits kann eine niedrige Bindungsrate auf Unzufriedenheit hinweisen, was eine Analyse der internen Abläufe notwendig macht.\n\n## Vorteile der Einhaltung von CI/CD Best Practices\nWenn Best Practices befolgt werden, sind die Vorteile von CI/CD in der gesamten Organisation spürbar: Von HR bis zu den Betriebsabteilungen arbeiten die Teams besser und erreichen ihre Ziele. Die Etablierung von Metriken zur Bewertung der CI/CD-Performance kann über die Bereitstellung von Einblicken in die Entwicklung hinausgehen und sich auf viele Aspekte des Unternehmens auswirken.\n\nEine gut funktionierende CI/CD-Pipeline kann für DevOps-Teams ein entscheidender Faktor sein. \n\n**Dies sind einige der größten Vorteile einer guten CI/CD-Pipeline:**\n\n***Entwickler(innen) reparieren nichts, sie schreiben Code.*** Weniger Tools und Toolchains bedeuten weniger Zeitaufwand für Wartung und mehr Zeit, tatsächlich hochwertige Softwareanwendungen zu produzieren.\n\n***Code ist in Produktion.*** Anstatt in einer Warteschlange zu sitzen, gelangt der Code tatsächlich in die reale Welt. Dies führt auch zu glücklicheren Entwicklern.\n\n***Entwickler(innen) haben die Kapazität, sich auf die Lösung von Geschäftsproblemen zu konzentrieren.*** Ein optimierter CI/CD-Prozess gibt Entwickler(innen) Zeit, sich auf das Wesentliche zu konzentrieren und nicht auf die Ablenkungen durch fehlerhaften Code, verpasste Übergaben, Produktionsprobleme und mehr.\n\n***Innovation macht alles einfacher.*** In einer wettbewerbsorientierten Welt benötigen Unternehmen alle verfügbaren Tools, um sich zu behaupten. Ein gut aufgebauter CI/CD-Prozess erleichtert, beschleunigt und sichert die Softwareentwicklung, was bedeutet, dass DevOps-Teams die Zeit und Energie haben, außerhalb des Rahmens zu denken.\n\n***Talente kommen und bleiben.*** Der Arbeitsmarkt ist sehr wettbewerbsintensiv, und DevOps-Talente sind schwer zu beeindrucken. Nichts sagt „Wir nehmen unser DevOps-Team ernst“ mehr, als eine Organisation, die in die Technologie und Prozesse rund um CI/CD investiert.\n\n***Jeder und jede macht das, was er oder sie am besten kann.*** Dev, Ops, Sec und Test haben jeweils eine wichtige Rolle zu spielen und CI/CD hilft, die Verantwortlichkeiten klar zu definieren.\n\n## CI/CD-Deployment-Strategie\nDenke daran, dass es bei CI/CD darum geht, Kund(innen) eine Softwareanwendung schneller und in besserer Qualität zu liefern als zuvor. Unternehmen, die CI/CD einführen, erleben oft eine erhebliche Steigerung ihrer Produktivität. Der Schlüssel zum Erfolg liegt darin, eine Bereitstellungsstrategie zu entwickeln, die auf die spezifischen Bedürfnisse des Unternehmens zugeschnitten ist.\n\n**Hier sind einige Strategien, die zu einer erfolgreichen CI/CD-Implementierung beitragen:**\n\n**Häufige Releases festlegen:** Plane regelmäßige und häufige Veröffentlichungen, um die Vorteile von CI/CD voll auszuschöpfen.\n\n**Build-Prozess automatisieren:** Setze auf Automatisierung im Build-Prozess, um Konsistenz und Effizienz zu gewährleisten.\n\n**Tests parallel durchführen:** Führe Tests parallel aus und erstelle eine effiziente Bereitstellungspipeline.\n\n**Schnelles Scheitern und „Shift Left“-Mentalität:** Fördere eine Kultur des schnellen Scheiterns und verschiebe Tests und Qualitätskontrollen frühzeitig in den Entwicklungsprozess. Dies gibt den Entwickler(innen) die Tools und Fähigkeiten, um schneller und sicherer zu arbeiten.\n\n**Schnelles Feedback durch CI-Tools:** Verwende CI-Tools, die schnelles Feedback liefern, um Entwicklungszyklen zu verkürzen und die Qualität zu verbessern.\n\nDiese Strategien helfen dabei, die Vorteile von CI/CD voll auszuschöpfen und die Effizienz sowie die Qualität der Softwareentwicklung zu steigern.\n\n## Wie kann ich CI/CD in meiner Organisation implementieren?\nBevor eine Software implementiert wird, ist es entscheidend, die Unternehmensziele klar zu definieren. Dies gilt ebenso für die Einführung von CI/CD. Alle Beteiligten in der Entwicklung sollten frühzeitig in den Implementierungsprozess eingebunden werden. Entwickler(innen) sollten besonders berücksichtigt werden, da sie die Hauptnutzer(innen) der neuen Tools und Prozesse sein werden.\n\nFühre gründliche Recherchen durch, wenn du Software bewertest, die CI/CD unterstützt, und frage nach kostenlosen Testversionen, um deren Eignung zu prüfen.\n\nObwohl CI/CD darauf abzielt, die Softwarebereitstellung durch Automatisierung zu beschleunigen, ist es ratsam, den Implementierungsprozess mit einer „Langsam und stetig“-Einstellung zu beginnen. Eine langsame, sorgfältige Einführung hilft, Fehler in der fertigen Anwendung zu minimieren und die langfristige Effizienz zu sichern.\n\nKonsistenz im Integrationsprozess ist entscheidend. Führe regelmäßige Unit-Tests durch, löse Releases zunächst manuell aus und verfolge relevante Metriken. Bestimme dann, welche Prozesse automatisiert werden können und sollten, um die Effizienz weiter zu steigern.\n\n[Mit GitLab findest du jetzt die richtige Lösung, um die CI/CD Best Practices richtig umzusetzen.](/de-de/solutions/github/)",[732,733,9],"CI","CD","2025-04-16",{"slug":736,"featured":6,"template":688},"how-to-keep-up-with-ci-cd-best-practices","content:de-de:blog:how-to-keep-up-with-ci-cd-best-practices.yml","How To Keep Up With Ci Cd Best Practices","de-de/blog/how-to-keep-up-with-ci-cd-best-practices.yml","de-de/blog/how-to-keep-up-with-ci-cd-best-practices",{"_path":742,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":743,"content":749,"config":759,"_id":761,"_type":14,"title":762,"_source":16,"_file":763,"_stem":764,"_extension":19},"/de-de/blog/observability-vs-monitoring-in-devops",{"title":744,"description":745,"ogTitle":744,"ogDescription":745,"noIndex":6,"ogImage":746,"ogUrl":747,"ogSiteName":672,"ogType":673,"canonicalUrls":747,"schema":748},"Observability vs. Monitoring in DevOps","Observability sammelt Daten, um Prozesse zu optimieren und Probleme zu beheben. Wir zeigen dir, wie das geht - und warum es dem Monitoring überlegen ist.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665484/Blog/Hero%20Images/monitoring-update-feature-image.jpg","https://about.gitlab.com/blog/observability-vs-monitoring-in-devops","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Observability vs. Monitoring in DevOps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Mike Vanbuskirk\"}],\n        \"datePublished\": \"2022-06-14\",\n      }",{"title":744,"description":745,"authors":750,"heroImage":746,"date":752,"body":753,"category":754,"tags":755,"updatedDate":758},[751],"Mike Vanbuskirk","2022-06-14","Logging und Monitoring sind feste Bestandteile moderner Software-Infrastrukturen. Die Einführung von syslog in den 1980ern markierte hierbei einen Wendepunkt. Ursprünglich für Unix-Systeme entwickelt, verdeutlichte syslog zwei zentrale Punkte: Wie wichtig es ist, sich einen Überblick darüber zu verschaffen, was genau in einem System geschieht – und dass es von Vorteil ist, diesen Kontrollmechanismus von der Grundfunktionalität des Systems zu trennen.\n\nDie Vorzüge dieser erhöhten Sichtbarkeit waren offensichtlich. Trotzdem wurden Monitoring und Logging lange eher stiefmütterlich behandelt. So kam es immer wieder vor, dass Systeme eine Vielzahl von Einträgen produzierten, ohne dass diese aber jemals sinnvoll zusammengefasst oder analysiert wurden. Oder es wurden in der Vergangenheit Monitoring-Infrastrukturen geschaffen, die dann aber über ein Jahrzehnt lang verkümmerten, bis sie nicht mehr dem aktuellen Stand entsprachen.\n\nSeitdem hat sich die operative Landschaft verändert. Observability ist das Stichwort der Stunde. Für die Einschätzung der Application-Performance bietet Observability gegenüber Monitoring den großen Vorzug, dass Entwickler(innen) nun nicht mehr auf ihre eigenen Interpretationen oder statische Messungen angewiesen sind. Stattdessen ermöglicht das Konzept der Observability es, sich ein ganzheitliches Bild darüber zu machen, wie sich die Applikation verhält und vor allem, wie sich ihre Leistung für Anwender(innen) darstellt.\n\n## Was ist Observability?\n\nUm die Bedeutung von Observability zu verstehen, hilft es, sich zunächst einen Überblick darüber zu verschaffen, was Monitoring ist, was es leisten kann und worin seine Beschränkungen liegen.\n\nAuf der grundlegendsten Ebene werden beim Monitoring verschiedene Werte und Outputs eines gegebenen Systems oder Software-Stacks gemessen. Dazu gehören beispielsweise die CPU-Auslastung, RAM-Nutzung sowie die Reaktionszeit (Latenz). In dieser Hinsicht ähnelt das Monitoring klassischen Logging-Systemen, die statische Informationen über Ereignisse aus dem aktiven Betrieb des Systems liefern.\n\nDie Messungen des Monitorings bieten in einem eingegrenzten Rahmen Hinweise auf systematische Probleme. Traditionelle DevOps-Monitoring-Tools erlauben es, die Daten zu aggregieren und miteinander zu korrelieren. Um aber holistische Aussagen treffen zu können, müssen diese Tools darüber hinaus üblicherweise noch manuell konfiguriert und angepasst werden. Statische Werte wie die CPU-Auslastung sind deswegen lediglich ein erster Schritt.\n\nIn seinem inzwischen berühmten SRE-Buch hat Google vier Kennzahlen - die sogenannten goldenen Signale - hervorgehoben, welche die Aussagekraft des Monitorings erhöhen sollen:\n\n- Latenz: Misst die Zeit, die benötigt wird, um eine Anfrage durchzuführen\n- Traffic: Misst die systemspezifische Nachfrage nach Leistungen auf höchster Ebene\n- Fehlerwahrscheinlichkeit: Misst die Rate, mit der Anfragen scheitern\n- Saturierung: Misst die Auslastung des Systems als das Verhältnis der Ressourcennutzung zu den verfügbaren Ressourcen insgesamt; üblicherweise liegt die Betonung hierbei auf knappen Ressourcen\n\nTatsächlich bieten diese goldenen Signale eine weitaus bessere Einschätzung der Systemleistung als die Kennziffern des konventionellen DevOps-Monitorings. Trotzdem muss um sie herum noch immer ein Monitoring-System entworfen, gebaut und in die bestehenden Abläufe integriert werden. Dies erfordert einen nicht zu unterschätzenden Aufwand. So müssen sämtliche potentiellen Fehler genau spezifiziert und händisch definiert und korrekt korreliert werden. Sogar in verhältnismäßig einfachen Fällen kann sich dies als sehr zeitintensiv erweisen.\n\n## Was also ist Observability?\n\nIm direkten Vergleich Observability vs. Monitoring ist Observability intuitiver und vollständiger. Das manuelle Harmonisieren unterschiedlicher DevOps-Monitoring-Tools entfällt. Während ein aggregiertes Monitoring-Dashboard nur so gut ist wie die letzten Entwickler(innen), die daran gearbeitet hat, passt sich eine Observability-Plattform eigenständig an. So liefert Observability automatisch kritische Informationen im passenden Kontext. Dies kann sogar auf den Software-Entwicklungszyklus ausgedehnt werden (Software Development Life Cycle, SDLC). Dabei liefern die Observability-Tools, im Gegensatz zum DevOps-Monitorings, während der CI/CD-Runs wichtige Informationen, die Entwickler(innen) operative Rückmeldungen zu ihrem Code bieten.\n\nLetzten Endes trägtObservability schlicht zu einer ganzheitlicheren Fehlerbeseitigung und einem holistischen Verständnis bei. Die Daten, die es produziert, lassen die „unbekannten Unbekannten” deutlicher hervortreten. So werden Produktionsprobleme erklärbarer. Im nächsten Abschnitt wollen wir verdeutlichen, warum genau dies so wertvoll ist. Anhand eines Beispiels werden wir dir zeigen, warum Monitoring alleine oftmals nicht ausreicht - und welche Lücken durch Observability geschlossen werden.\n\n## Warum sich Observability auszahlt\n\nEine Priorisierung von Observability kann dazu beitragen, die Zeit zu reduzieren, die zur Lösung eines Problems benötigt wird (mean time to resolution, MTTR). Dadurch können Ausfälle zeitlich eingeschränkt werden, die Application-Performance verbessert sich und das Kundenerlebnis fällt positiver aus. Man könnte meinen, Monitoring biete sehr ähnliche Vorzüge. Die folgende Anekdote soll veranschaulichen, dass dies jedoch nicht immer der Fall ist.\n\nDie Buchhaltung einer Engineering-Organisation gibt eine Warnung aus: Die Rechnungen für Cloud-Services steigen und sogar die Finanzleiterin hat ihre Sorge ausgedrückt. Entwickler(innen) haben bereits ebenso intensiv wie erfolglos das DevOps-Monitoring-System zu Rate gezogen: Alle Monitoring-Werte sind durchgehend im grünen Bereich, darunter der Speicher, die CPU-Auslastung sowie disk I/O. Wie sich herausstellt, lag die Ursache in einer anderen „unbekannten Unbekannten”: Eine erhöhte DNS-Latenz in den CI/CD-Pipelines führte zu einer erhöhten Ausfallrate in den Builds. Weil für jeden Build nun mehr Versuche benötigt wurden, kam es unweigerlich zu einer höheren Beanspruchung der Cloud-Ressourcen. Allerdings war jeder einzelne Versuch für sich verhältnismäßig kurz und fiel im Monitoring-System nicht auf. Durch die Einführung von DevOps-Observability-Tools konnte Ops eine weitaus breitere Palette an Ereignissen sammeln, das Problem damit einkreisen und es schließlich beheben. Dies wäre in einem traditionellen Monitoring-System nicht möglich gewesen. Hier hätte die Organisation selbst auf das DNS-Latenz-Problem schließen müssen.\n\nAuch für nichttechnische Stakeholder(innen) und Geschäftseinheiten erweist sich Observability als wichtig. Da Technologie zunehmend zu einem Profitfaktor wird, tragen die wirtschaftlichen Kennzahlen der Softwarestruktur unmittelbar zum gesamten Unternehmenserfolg bei. Observability bietet einen klaren Blick auf diese Kennzahlen und kann von verschiedenen Teams individuell genutzt werden.\n\nOhne eine positive Nutzererfahrung (User Experience, UX) sind moderne Software und Applikationen nicht möglich. Wie das Beispiel illustriert, reichen die statischen Kennziffern des Monitorings nicht aus. Unter einer scheinbar unauffälligen Oberfläche können sich schwerwiegende Probleme verbergen.\n\n## Zentrale Observability-Kennzahlen\n\nFür Organisationen, die sich dafür entschieden haben, DevOps-Observability-Tools zu verwenden, besteht der erste Schritt darin, die wichtigsten Ziele zu identifizieren und die besten Umsetzungsoptionen festzulegen.\n\nWir empfehlen, mit den drei grundlegenden Säulen der Observability anzufangen:\n\n- Logs: Informationen und Ereignisse\n- Kennziffern (metrics): Messungen spezifischer Kennziffern und Performance-Daten\n- Tracing: Die lückenlose Dokumentation einer Anfrage und ihrer Performance\n\nWer sein Observability-System auf diesen drei Säulen aufbaut, muss mit einem hohen Aufwand rechnen.  Projekte wie OpenTelemetry tragen aber erheblich zur Realisierbarkeit bei. Sie begünstigen die Akzeptanz industrieweiter Standards für Logging, Kennzahlen und Tracing und schaffen die Bedingungen für ein in sich stimmiges Ökosystem. Das verkürzt für alle Unternehmen, die DevOps-Observability-Tools umzusetzen gedenken, die auf OpenTelemetry-Standards basieren, die Zeit von der Einführung bis zur Profitabilität.\n\nAuch bei GitLab ist Observability ein zentraler Aspekt unseres Produkts, damit du Fehler und Engpässe so früh wie möglich erkennst und im laufenden Betrieb Anpassungen vornehmen kannst. Wenn du näher interessiert bist, besteht die Möglichkeit, die neue GitLab-Observability-Suite zu testen. Melde dich dazu als [Beta-Tester(in)](https://docs.gitlab.com/operations/observability/ \"GitLab Observability\") an.\n\nAls weitere Observability-Daten und -Säulen sind darüber hinaus zu nennen:\n\n- Das Tracking von Fehlern: Feinmaschigere (granulare) Logs mit Aggregation\n- Kontinuierliches Profiling: Auswertung der granularen Code-Performance\n- Real User Monitoring: Beurteilung der Application-Performance anhand echter Nutzer(innen)\n\nWenn wir uns diese Säulen ansehen, wird ein gemeinsames Prinzip erkennbar. Es reicht nicht mehr aus, sich bei der Analyse moderner, distribuierter Systeme auf einen sehr kurzen Zeitraum zu beschränken. Vielmehr ist eine holistische Betrachtung aus der Vogelperspektive erforderlich. Ein tiefes Verständnis der Application-Performance mittels Observability statt Monitoring beginnt damit, Ereignisse aus der erlebten Perspektive der Kundinnen und Kunden zu betrachten und anschließend die vollständige Performance und die Interaktion mit ihrer Software zu überwachen. Darin liegt der Hauptgrund, warum Observability im direkten Vergleich mit dem Monitoring die Oberhand behält.\n\nObservability erlaubt es einer Engineering-Organisation, über das konventionelle Monitoring hinaus die betriebliche Exzellenz zu verbessern. Letzten Endes ergeben sich die wertvollsten Warnsysteme und Problembehebungs-Programme aus schmerzhaft erlittenen Ausfällen. Hier bietet das sogenannte Chaos-Engineering eine Möglichkeit, Beobachtbarkeirs-Plattformen zu Testzwecken zu nutzen. Dabei werden die Konsequenzen echter Ausfälle in einer kontrollierten Umgebung und mit bekannten Ergebnissen geprüft. Wenn du vermutest, dass dein System „unbekannte Unbekannte” enthalten könnte, bietet Chaos-Engineering für deine [CI/CD-Pipelines](https://about.gitlab.com/de-de/topics/ci-cd/ \"CI/CD pipelines\"), Supply-Chain und DNS signifikante Zugewinne, was die operative Basis anbelangt.\n\n## Observability ist ein zentraler Teil von DevOps\n\nObservability ist nicht  nur für DevOps von zentraler Bedeutung, sondern für die gesamte Organisation. Indem du die statischen Daten überholter Monitoring-Lösungen ersetzt, erreichst du durch die Einführung von Observability einen 360-Grad-Blick auf deine Applikations-Infrastruktur.\n\nDevOps-Teams sollten eng mit Stakeholdern zusammenarbeiten, um ihre Observability-Kennziffern so miteinander zu teilen, dass sie der Organisation als Ganzes dienen und gemeinsam an ihrer Umsetzung arbeiten. Es kann für eine höhere Effektivität von Vorteil sein, sich die Vorteile der Apps-Instrumentierung zu verdeutlichen und diese Vorteile anschließend dem Entwicklungs-Team nahezulegen. DevOps-Teams können dazu beitragen, die Grundursachen von Produktionsproblemen schneller zu erkennen: gut eingesetzter Applikations-Code macht es zudem einfacher, diese von Ursachen zu unterscheiden, die auf der Infrastruktur beruhen. Je früher Observability in der CI/CD-Pipeline zur Anwendung kommt, umso größer ist die Wahrscheinlichkeit, dass SLO-Deltas erkannt werden, bevor das Produkt veröffentlicht wird.\n\nDevOps-Teams, die sowohl die Applikations-Performance als auch Geschäftswerte signifikant verbessern möchten, erhalten durch Observability die Möglichkeit, beide Aspekte gleichzeitig zu optimieren.\n","engineering",[9,756,757],"security","performance","2024-10-16",{"slug":760,"featured":6,"template":688},"observability-vs-monitoring-in-devops","content:de-de:blog:observability-vs-monitoring-in-devops.yml","Observability Vs Monitoring In Devops","de-de/blog/observability-vs-monitoring-in-devops.yml","de-de/blog/observability-vs-monitoring-in-devops",{"_path":766,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":767,"content":773,"config":784,"_id":786,"_type":14,"title":787,"_source":16,"_file":788,"_stem":789,"_extension":19},"/de-de/blog/southwest-looking-to-help-developers-take-flight",{"title":768,"description":769,"ogTitle":768,"ogDescription":769,"noIndex":6,"ogImage":770,"ogUrl":771,"ogSiteName":672,"ogType":673,"canonicalUrls":771,"schema":772},"Southwest möchte mit seinen Entwickler(inne)n abheben","Erfahre, wie die DevOps-Teams der Fluglinie dank GitLab Probleme viel einfacher erkennen und beheben können.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665272/Blog/Hero%20Images/AdobeStock_380312133.jpg","https://about.gitlab.com/blog/southwest-looking-to-help-developers-take-flight","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Southwest möchte mit seinen Entwickler(inne)n abheben\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n        \"datePublished\": \"2024-01-30\",\n      }",{"title":768,"description":769,"authors":774,"heroImage":770,"date":776,"body":777,"category":778,"tags":779,"updatedDate":783},[775],"Sharon Gaudin","2024-01-30","Southwest Airlines Co. ist bestrebt, die Arbeit seiner Entwickler(innen) zu leichter zu machen.\n\nDie IT-Führungskräfte der weltweit größten Billigfluglinie arbeiten daran, zeitaufwändige und sich wiederholende Aufgaben aus den Workflows der Entwickler(innen) zu eliminieren, damit diese mehr Zeit haben, sich auf größere Projekte zu konzentrieren.\n\n„Das schaffen wir, indem wir Hürden für sie aus dem Weg räumen“, erklärt Jim Dayton, Vice President und CISO bei Southwest Airlines. „Ich bin fest davon überzeugt, dass die Leute in der Softwareentwicklung arbeiten wollen, weil sie die Kreativität lieben. Sie lieben es, Probleme zu lösen. Dabei dürfen wir ihnen nicht im Weg stehen und müssen die Dinge, die sie behindern, aus dem Weg räumen.“\n\nDas möchte Dayton unter anderem mit der Plattform von GitLab erreichen.\n\nDayton hat bei einem Event der [DevSecOps World Tour von GitLab](https://about.gitlab.com/events/devsecops-world-tour/) in Dallas auf der Bühne in einem Interview über die Bestrebungen von Southwest gesprochen, sich um seine Entwickler(innen) zu kümmern und ihre Arbeit zu würdigen. Ein Teil seines Vortrags war ein Gespräch mit Reshmi Krishna, Director für Enterprise Solutions Architecture bei GitLab, in dem er mit ihm darüber sprach, welche Vorteile künstliche Intelligenz seinen Teams bieten könnte.\n\nDer Southwest-Manager sprach darüber, in seinem Unternehmen vermehrt auf einen DevOps-Ansatz bei der Anwendungsentwicklung zu setzen und fügte hinzu, dass den Entwickler(inne)n mehr Self-Service-Möglichkeiten und Wissensmanagement-Prozesse geboten werden sollten. „Wir wollen, dass Entwickler(innen) schnell ein Problem nachschlagen und eine Lösung finden können. Außerdem sollte Kontextwechsel reduziert werden“, sagte er. „Wir müssen sehen können, was wir von ihnen verlangen und was sie daran hindert, produktiv zu sein.“\n\nDayton merkte an, dass Southwest, das seit 2019 mit GitLab zusammenarbeitet, sich darauf konzentriert, seine Software-Entwicklungsprozesse konsistenter zu machen. Zum Teil bedeutet das, Code in ein gemeinsames GitLab-Repository zu verschieben. Wenn Teams wissen, wo sich ihr Code befindet, können sie Metriken einfacher bewerten und sich darauf konzentrieren, Code wiederzuverwenden und dadurch effizienter zu werden.\n\n„Wir sind auch dabei, unsere Enterprise-Pipelines fertigzustellen, und wir sind bereit, mit der Migration der Teams zu beginnen“, sagte Dayton. „Wir arbeiten intensiv mit vielen verschiedenen Anwendungsentwicklungsteams zusammen, um zu verstehen, was sie in den Pipelines benötigen, die wir aufbauen, und wir bereiten uns darauf vor, Teams auf sie zu migrieren. Ich denke, wir werden bis Ende des Jahres ziemlich nah dran sein.“\n\n### Das Versprechen der KI\n\nEine der Möglichkeiten, wie sich Entwickler(innen) auf größere und innovativere Aufgaben konzentrieren können, ist der Einsatz künstlicher Intelligenz, so Dayton.\n\nGenerative KI, ob in Form von Erklärungen zu Sicherheitslücken, Codevorschlägen oder Code-Vervollständigung, kann Arbeitsabläufe im gesamten Software-Entwicklungsprozess signifikant beeinflussen. Der Einsatz von KI-Tools, die direkt in eine Plattform integriert sind, kann die Sicherheit erhöhen und den Zeitaufwand für Code Reviews und Anwendungsentwicklung verringern.\n\nDayton freut sich bereits darauf, die Entwicklung und Bereitstellung mithilfe von KI-Funktionen zu beschleunigen und zu erleichtern.\n\n„Wir wollen alltägliche Aufgaben und die Bürokratie für unsere Entwickler(innen) so weit wie möglich aus dem Weg räumen“, erklärt Dayton und fügt hinzu, dass es rund um das Thema KI zwar einen riesigen Hype, aber auch großes Potenzial gebe. „Mit der KI könnten wir das schaffen. Ein gutes Beispiel ist meiner Meinung nach, wenn die KI eine Lösung für eine Sicherheitslücke bietet, die gerade entdeckt wurde, oder wenn sie uns sagen kann, was ein Teil des Codes tut. Womit wird er integriert? Auf welche Daten wird zugegriffen und warum? Sag mir zum Beispiel im Klartext, dass dieser bestimmte Code für 20 % der Vorfälle in dieser Anwendung im letzten Jahr verantwortlich war. Hier kann KI meiner Meinung nach helfen.“Dayton erläutert auch, dass er nicht glaubt, dass KI die Entwickler(innen) ersetzen wird. Stattdessen sollte sie ihnen die Arbeit erleichtern. KI kann in der Welt nach COVID außerdem dazu beitragen, die remote arbeitenden Entwickler(innen) zu verbinden.\n\n„Eines der coolen Dinge, die in der Roadmap [von GitLab] enthalten sind, sind vorgeschlagene Prüfer(innen)“, sagte er. „Das hilft bei Code Reviews, bei denen man früher einfach quer durch den Raum oder über die nächste Trennwand rief: ‚Hey, kann sich jemand meinen Code ansehen?‘ Das ist jetzt nicht mehr so einfach. KI kann Personen vorschlagen, die schon einmal in diesem Code gearbeitet haben, die Vorfälle in diesem Code gelöst haben und so etwas machen. Wie wichtig wird das für den Review-Prozess sein? Ich denke, je mehr Automatisierung wir einsetzen können, desto weniger manuelle Schritte oder Wartezeiten wird es geben.“\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/UnUfp7pKnEQ?si=qcX2Qm3zpgQOV4xy\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n*Southwest Airlines ist ein rund 24 Milliarden Dollar schweres Unternehmen mit Sitz in Dallas, Texas. Die Fluglinie hat 72 000 Mitarbeitende und fliegt mit 4 000 Flügen pro Trag 120 verschiedene Ziele an. Mit Southwest fliegen mehr Inlandspassagiere als mit jeder anderen Fluglinie.\nLies weitere GitLab-Kundenstorys auf unserer [Kundenseite](https://about.gitlab.com/de-de/customers/).*\n","customer-stories",[9,780,781,782],"DevOps platform","AI/ML","customers","2024-12-11",{"slug":785,"featured":6,"template":688},"southwest-looking-to-help-developers-take-flight","content:de-de:blog:southwest-looking-to-help-developers-take-flight.yml","Southwest Looking To Help Developers Take Flight","de-de/blog/southwest-looking-to-help-developers-take-flight.yml","de-de/blog/southwest-looking-to-help-developers-take-flight",{"_path":791,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":792,"content":799,"config":809,"_id":811,"_type":14,"title":812,"_source":16,"_file":813,"_stem":814,"_extension":19},"/de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"title":793,"description":794,"ogTitle":793,"ogDescription":794,"noIndex":6,"ogImage":795,"ogUrl":796,"ogSiteName":672,"ogType":797,"canonicalUrls":796,"schema":798},"GitLab-Tutorial: Releases & Versionshinweise automatisieren","Mit GitLab kannst du Release-Artefakte, Versionshinweise und Änderungsprotokolle, die benutzerbezogenen Software-Änderungen enthalten, automatisieren.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab","Artikel","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tutorial: Releases und Versionshinweise mit GitLab automatisieren\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Ridley\"}],\n        \"datePublished\": \"2023-11-01\",\n      }",{"title":793,"description":794,"authors":800,"heroImage":795,"date":802,"body":803,"category":804,"tags":805,"updatedDate":808},[801],"Ben Ridley","2023-11-01","***Update 2025** - Die Änderungsprotokoll-API wurde weiterentwickelt und enthält jetzt geniale neue Funktionen, auf die wir in diesem Blog nicht eingehen, wie die Möglichkeit, benutzerdefinierte Änderungsprotokolle mit Vorlagenwerten aus deinem Commit-Verlauf bereitzustellen. [Mehr dazu erfährst du in der offiziellen Dokumentation zu Änderungsprotokollen (nur in englischer Sprache verfügbar).](https://docs.gitlab.com/user/project/changelogs/)*\n\nWenn du Software entwickelst, auf die sich Benutzer(innen) verlassen, ist eine effektive Kommunikation über Änderungen bei jeder Release unerlässlich. Indem du Benutzer(innen) über neue Funktionen sowie darüber informierst, was geändert oder entfernt wurde, stellst du sicher, dass sie die Vorteile der Software wirklich nutzen können und sie bei Upgrades keine unangenehmen Überraschungen erwarten.\n\nIn der Vergangenheit war das Erstellen von Versionshinweisen und die Pflege eines Änderungsprotokolls eine mühsame Aufgabe, bei der Entwickler(innen) die Änderungen extern überwachen oder eigene Release Manager den Verlauf der Zusammenführungen durcharbeiten mussten. Mit der Änderungsprotokoll-API von GitLab kannst du den umfassenden Verlauf, der in unserem Git-Repository gespeichert ist, heranziehen, um ganz einfach Versionshinweise zu erstellen und ein Änderungsprotokoll zu führen.\n\nIn diesem Tutorial sehen wir uns an, wie du Releases mit GitLab automatisieren kannst und finden heraus, wie man Release-Artefakte, Versionshinweise und ein umfassendes Änderungsprotokoll, das alle benutzerbezogenen Software-Änderungen enthält, erstellt.\n\n## Releases in GitLab\nZuerst wollen wir uns ansehen, wie Releases in GitLab funktionieren.\n\nIn GitLab ist eine Release eine bestimmte Version deines Codes, die durch ein Git-Tag identifiziert wird. Dieses enthält Details zu den Änderungen seit der letzten Release (und Versionshinweise) sowie zugehörige Artefakte, die aus dieser Version des Codes erstellt wurden, wie Docker-Images, Installationspakete und Dokumentation.\n\nDu kannst Releases in GitLab über die UI erstellen und nachverfolgen, indem du unsere Release-API aufrufst oder den Job `release` innerhalb einer CI-Pipeline aufrufst. In diesem Tutorial verwenden wir den Job `release` in einer CI/CD-Pipeline, sodass wir die Automatisierung, die wir in unserer Pipeline zum Testen, für Code-Scans und mehr verwenden, auch für automatisierte Releases nutzen können.\n\nUm unsere Releases zu automatisieren, müssen wir zunächst die folgende Frage beantworten: Wo bekommen wir für unsere Versionshinweise und unser Änderungsprotokoll Informationen zu den vorgenommenen Änderungen? Die Antwort: In unserem Git-Repository, in dem wir durch Commit-Nachrichten und den Merge-Commit-Verlauf eine umfassende Übersicht über die Entwicklungsaktivitäten haben. Sehen wir uns an, ob wir diesen umfassenden Verlauf nutzen können, um automatisch unsere Versionshinweise und Änderungsprotokolle zu erstellen.\n\n## Einführung in Commit-Trailer\n[Commit-Trailer](https://git-scm.com/docs/git-interpret-trailers) sind strukturierte Einträge in deinen Git-Commits, die erstellt werden, indem du einfach die Formatierungsnachrichten `\u003CHEADER>:\u003CBODY>` am Ende deines Commits einfügst. Das CLI-Tool `git` kann diese dann parsen und für die Verwendung in anderen Systemen extrahieren. Ein Beispiel, das du vielleicht schon einmal verwendet hast, ist `git commit --sign-off`, um ein Commit zu beenden. Dies wird implementiert, indem der Trailer `Signed-off-by: \u003CDein Name>` zum Commit hinzugefügt wird. Wir können hier beliebige strukturierte Daten hinzufügen, sodass dies eine tolle Möglichkeit ist, Informationen zu speichern, die für das Änderungsprotokoll nützlich sein könnten.\n\nWenn wir in unseren Commits den Trailer `Changelog: \u003Cadded/changed/removed>` verwenden, parst die Änderungsprotokoll-API von GitLab diese und verwendet sie, um automatisch ein Änderungsprotokoll für uns zu erstellen!\n\nSehen wir uns das in Aktion an, indem wir Änderungen an einer echten Codebase vornehmen, eine Release durchführen und dann Versionshinweise und Änderungsprotokoll-Einträge generieren.\n\n## Beispielprojekt\nFür diesen Blog verwende ich ein einfaches Python-Web-App-Repository. Nehmen wir an, dass Version 1.0.0 der Anwendung gerade veröffentlicht wurde und die aktuelle Version des Codes ist. Ich habe auch die Release 1.0.0 in GitLab erstellt, was ich manuell tun musste, da wir unsere automatisierte Release-Pipeline ja noch nicht erstellt haben:\n\n![Ein Screenshot der GitLab-UI, die eine Release für Version 1.0.0 zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/1-0-release.png)\n\n## Nehmen wir unsere Änderungen vor\nWir entwickeln rasend schnell und arbeiten daher schon daran, Version 2.0.0 unserer Anwendung heute zu veröffentlichen. Im Rahmen unserer Release 2.0.0 fügen wir eine neue Funktion zu unserer App hinzu: einen Chatbot! Wir werden auch die Quanten-Blockchain-Funktion entfernen, da wir diese nur für die erste Finanzierungsrunde benötigt haben. Außerdem fügen wir einen automatisierten Release-Job zu unserer CI/CD-Pipeline für unsere Release 2.0.0 hinzu.\n\nZuerst entfernen wir die nicht benötigten Funktionen. Ich habe einen Merge Request erstellt, der die notwendigen Änderungen enthält. Wir müssen sicherstellen, dass wir eine Commit-Nachricht haben, die den Trailer `Changelog: removed` enthält. Dazu gibt es mehrere Möglichkeiten: Wir können ihn unter anderem direkt in einen Commit einbauen oder einen interaktiven Rebase durchführen und über das CLI hinzufügen. Der einfachste Weg in unserem Fall ist meiner Meinung nach, bis zum Ende zu warten und dann die Schaltfläche `Edit commit message` in GitLab zu verwenden, um den Trailer folgendermaßen zum Merge-Commit hinzuzufügen:\n\n![Screenshot der GitLab-UI, der einen Merge Request zum Entfernen nicht verwendeter Funktionen zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/remove-unused-features-mr.png)\n\nMit dieser Methode kannst du auch den Titel des Merge-Commits auf einen prägnanteren Titel ändern. Ich habe den Titel meines Merge-Commit auf „Nicht verwendete Funktionen entfernen“ geändert, da dies im Eintrag im Änderungsprotokoll angezeigt wird.\n\nAls nächstes fügen wir einige neue Funktionen für die Version 2.0.0 hinzu. Hier müssen wir nur einen weiteren Merge Request öffnen, der unsere neuen Funktionen enthält, und dann den Merge-Commit bearbeiten, sodass er den Trailer `Changelog: added` enthält, und dann den Commit-Titel auf einen prägnanteren Titel ändern:\n\n![Screenshot der GitLab-UI, der einen Merge Request zum Hinzufügen neuer Funktionen zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/add-chatbot-mr.png)\n\nJetzt sind wir eigentlich bereit, 2.0.0 zu veröffentlichen. Aber dieses Mal möchten wir unsere Release nicht manuell erstellen. Deshalb fügen wir vor der Release einige Jobs zur Datei `.gitlab-ci.yml` hinzu, die die Release automatisch für uns durchführen und die entsprechenden Versionshinweise und Einträge ins Änderungsprotokoll erstellen, wenn wir unseren Code mit einer neuen Version wie z. B. `2.0.0` taggen.\n\n**Hinweis:** Wenn du Änderungsprotokoll-Trailer erzwingen möchtest, solltest du überlegen, etwas wie [Gefahr bei der Durchführung automatischer Überprüfungen für MR-Konventionen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/development/dangerbot.html) zu verwenden.\n\n## Erstellen einer automatisierten Release-Pipeline\nDamit unsere Pipeline funktioniert, müssen wir ein Projektzugriffstoken erstellen, mit dem wir die GitLab-API aufrufen können, damit sie die Einträge im Änderungsprotokoll erstellt. [Erstelle ein Projektzugriffstoken im API-Bereich (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token) und [speichere das Token dann als CI/CD-Variable (nur in englischer Sprache verfügbar)]((https://docs.gitlab.com/ee/ci/variables/#define-a-cicd-variable-in-the-ui) mit dem Namen `CI_API_TOKEN`. Wir verweisen auf diese Variable, um uns bei der API zu authentifizieren.\n\nNun fügen wir zwei neue Jobs zu unserer Datei `gitlab-ci.yml` hinzu:\n```yaml\nprepare_job:\n  stage: prepare\n  image: alpine:latest\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - apk add curl jq\n    - 'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\" | jq -r .notes > release_notes.md'\n  artifacts:\n    paths:\n    - release_notes.md\n\nrelease_job:\n  stage: release\n  image: registry.gitlab.com/gitlab-org/release-cli:latest\n  needs:\n    - job: prepare_job\n      artifacts: true\n  rules:\n  - if: '$CI_COMMIT_TAG =~ /^v?\\d+\\.\\d+\\.\\d+$/'\n  script:\n    - echo \"Creating release\"\n  release:\n    name: 'Release $CI_COMMIT_TAG'\n    description: release_notes.md\n    tag_name: '$CI_COMMIT_TAG'\n    ref: '$CI_COMMIT_SHA'\n    assets:\n      links:\n        - name: 'Container Image $CI_COMMIT_TAG'\n          url: \"https://$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA\"\n```\n\nIn der oben angeführten Konfiguration verwendet `prepare_job` die Befehle `curl` und `jq`, um den Endpunkt der Änderungsprotokoll-API von GitLab aufzurufen und übergibt dies dann an unser `release_job`, um die Release zu erstellen. Genauer gesagt sieht das so aus:\n- Wir verwenden das Projektzugriffstoken, dass wir zuvor erstellt haben, um die Änderungsprotokoll-API von GitLab aufzurufen, die dann die Versionshinweise erstellt. Wir speichern dies als Artefakt.\n- Wir verwenden die Variable `$CI_COMMIT_TAG` als Version. Dazu müssen wir eine semantische Versionierung für unsere Tags verwenden (beispielsweise so etwas wie `2.0.0`). Du wirst auch bemerkt haben, dass ich den Release-Job mit dem Abschnitt `rules` eingeschränkt habe, der auf ein semantisches Versions-Tag überprüft.\n\t- Damit die Änderungsprotokoll-API von GitLab funktioniert, ist eine semantische Versionierung erforderlich. Sie verwendet dieses Format, um die neueste Release zu finden und sie mit unserer aktuellen Release zu vergleichen.\n- Wir verwenden das offizielle Image `release-cli` von GitLab. „release-cli“ ist erforderlich, um das Schlüsselwort `release` in einem Job zu verwenden.\n- Wir verwenden das Schlüsselwort `release`, um eine Release in GitLab zu erstellen. Dies ist ein spezielles Job-Schlüsselwort, das für die Erstellung einer Release und das Ausfüllen der erforderlichen Felder reserviert ist.\n- Wir können eine Datei als Argument an die `description` der Release übergeben. In unserem Fall ist es die Datei, die wir in `prepare_job` erstellt haben und die als Artefakt an diesen Job übergeben wurde.\n- Wir haben auch unser Container-Image, das früher in der Pipeline erstellt wurde, als Release-Asset hinzugefügt. Du kannst alle Assets aus deinem Build-Prozess anhängen, die du möchtest, z. B. Binärdateien oder Dokumentationen, indem du eine URL zu dem Ort angibst, an den du sie zuvor in der Pipeline hochgeladen hast.\n\n## Durchführen einer automatisierten Release\nMit dieser Konfiguration müssen wir nur ein Tag in unser Repository übertragen, das unserem Versionsschema entspricht, um eine Release durchzuführen. Du kannst einfach ein Tag mit dem CLI pushen. Für dieses Beispiel wird die GitLab-UI verwendet, um ein Tag im main-Branch zu erstellen. Erstelle ein Tag, indem du in der Seitenleiste „Code“ -> „Tags“ -> „Neues Tag“ auswählst:\n![Screenshot der GitLab-UI, der zeigt, wie man ein Tag erstellt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/create-2-tag.png)\n\nNach der Erstellung werden unsere Pipelines ausgeführt. Die Änderungsprotokoll-API von GitLab generiert automatisch Versionshinweise für uns als Markdown, der alle Änderungen zwischen dieser Release und der vorherigen Release enthält. Hier ist der Markdown, der in unserem Beispiel generiert wurde:\n\n```md\n## 2.0.0 (2023-08-25)\n\n### added (1 change)\n\n- [Add ChatBot](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@0c3601a45af617c5481322bfce4d71db1f911b02) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!4))\n\n### removed (1 change)\n\n- [Remove Unused Features](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo@463d453c5ae0f4fc611ea969e5442e3298bf0d8a) ([merge request](gl-demo-ultimate-bridley/super-devsecops-incorporated/simply-notes-release-demo!3))\n```\n\nWie du sehen kannst, hat GitLab die Einträge für unsere Versionshinweise automatisch mit unseren Git-Commit-Trailern extrahiert. Außerdem werden hilfreiche Links zum Merge Request bereitgestellt, damit die Leser(innen) weitere Details und Diskussionen zu den Änderungen sehen können.\n\nUnd jetzt folgt unsere letzte Release:\n![GitLab-Release-UI, die ein Release für Version 2.0.0 zeigt](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/2-0-release.png)\n\n## Erstellen des Änderungsprotokolls\nAls nächstes möchten wir unser Änderungsprotokoll aktualisieren (das im Grunde ein gesammelter Verlauf aller deiner Versionshinweise ist). Du kannst dazu eine `POST`-Anfrage an den Änderungsprotokoll-API-Endpunkt senden, den wir zuvor verwendet haben.\n\nDu kannst dies auch als Teil deiner Release-Pipeline tun, wenn du möchtest. Dazu kannst du beispielswiese den folgenden Code in den Abschnitt `script` deines Vorbereitungsjobs einfügen:\n```sh\n'curl -H \"PRIVATE-TOKEN: $CI_API_TOKEN\" -X POST \"$CI_API_V4_URL/projects/$CI_PROJECT_ID/repository/changelog?version=$CI_COMMIT_TAG\"\n```\n\n**Beachte dabei, dass dies das Repository ändert.** Es wird ein Commit erstellt, um die neuesten Notizen zu einer Datei `CHANGELOG.md` hinzuzufügen:\n![Screenshot des Repositorys, der einen Commit zeigt, der die Änderungsprotokolldatei aktualisiert](https://about.gitlab.com/images/blogimages/2023-08-22-automated-release-and-release-notes-with-gitlab/changelog-api-commit.png)\n\nUnd das war’s auch schon! Indem wir den umfassenden Verlauf, den uns `git` bietet, mit praktischen Commit-Trailern nutzen, können wir die leistungsstarke API und die CI/CD-Pipelines von GitLab optimal einsetzen, um unsere Release-Prozesse zu automatisieren und Versionshinweise für uns zu erstellen.\n\n> Wenn du das Projekt erkunden möchtest, das wir für diesen Artikel verwendet haben, [findest du es unter diesem Link](https://gitlab.com/gitlab-learn-labs/sample-projects/release-automation-demo).\n","product",[806,732,109,9,710,807],"Tutorial","Git","2025-06-05",{"slug":810,"featured":6,"template":688},"tutorial-automated-release-and-release-notes-with-gitlab","content:de-de:blog:tutorial-automated-release-and-release-notes-with-gitlab.yml","Tutorial Automated Release And Release Notes With Gitlab","de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab.yml","de-de/blog/tutorial-automated-release-and-release-notes-with-gitlab",{"_path":816,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":817,"content":823,"config":832,"_id":834,"_type":14,"title":835,"_source":16,"_file":836,"_stem":837,"_extension":19},"/de-de/blog/what-are-the-benefits-of-a-microservices-architecture",{"title":818,"description":819,"ogTitle":818,"ogDescription":819,"noIndex":6,"ogImage":820,"ogUrl":821,"ogSiteName":672,"ogType":673,"canonicalUrls":821,"schema":822},"Microservices-Architektur: Definition und Vorteile","Entdecke die Welt der Microservices-Architektur: Funktionsweise, Vorteile & Unterschiede zu traditionellen Architekturen für flexible & effiziente Anwendungen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662898/Blog/Hero%20Images/microservices-explosion.jpg","https://about.gitlab.com/blog/what-are-the-benefits-of-a-microservices-architecture","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Microservices-Architektur: Definition und Vorteile\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n        \"datePublished\": \"2022-09-29\",\n      }",{"title":818,"description":819,"authors":824,"heroImage":820,"date":826,"body":827,"category":828,"tags":829,"updatedDate":831},[825],"GitLab","2022-09-29","In der modernen Softwareentwicklung sind Microservices zu einem beliebten Architekturansatz geworden, um die Effizienz und Flexibilität von Anwendungen zu verbessern. \n\nIn diesem Artikel erfährst du alles über die Funktionsweise, Vorteile und Unterschiede zu anderen Architekturen. \n\n## Was sind Microservices?\n\n[Microservices](https://about.gitlab.com/topics/microservices/) sind eine Softwarearchitektur, bei der eine Anwendung in eine Reihe kleiner, unabhängiger Dienste unterteilt wird. Jeder dieser Dienste ist eigenständig, erfüllt eine spezifische Funktion und kommuniziert mit anderen Diensten über klar definierte Schnittstellen, häufig über APIs (Application Programming Interfaces). Im Gegensatz zur monolithischen Architektur, bei der die gesamte Anwendung als ein einziges, großes System entwickelt und bereitgestellt wird, ermöglichen Microservices eine modulare und flexible Entwicklung.\n\n### Microservices: Beispiel\n\nIn einer E-Commerce-Anwendung könnte der Bestellservice eine Anfrage erhalten, der Produktservice die Verfügbarkeit prüfen, der Zahlungsservice die Zahlung verarbeiten und der Benachrichtigungsservice eine Bestellbestätigung senden. Jeder dieser Schritte wird von einem eigenen Microservice ausgeführt.\n\n## Wie funktionieren Microservices und was sind die Vorteile?\n\nEs gibt zahlreiche Microservices-Vorteile, die sowohl Entwickler(innen) als auch Unternehmen ansprechen. Durch die Zerlegung einer Anwendung in kleinere, unabhängige Dienste können Entwickler(innen) effizienter arbeiten und schneller auf Marktanforderungen reagieren. Diese Flexibilität und Skalierbarkeit führen zu einer verbesserten Leistung und Ausfallsicherheit. \n\u003Ch3>1. Verbesserte Skalierbarkeit\u003C/h3>\nDa jeder Microservice unabhängig arbeitet, können Cloud-Microservices einfacher hinzugefügt, entfernt, aktualisiert oder skaliert werden. Entwickler(innen) können diese Aufgaben durchführen, ohne andere Microservices im System zu beeinträchtigen. Unternehmen haben die Möglichkeit, jeden Microservice nach Bedarf zu skalieren. Beispielsweise kann ein bestimmter Microservice, der während saisonaler Einkaufsspitzen eine erhöhte Nachfrage erfährt, effizient mit zusätzlichen Ressourcen ausgestattet werden. Sinkt die Nachfrage nach der Saison, kann der Microservice wieder heruntergefahren werden, sodass die freigewordenen Ressourcen oder Rechenkapazitäten anderweitig genutzt werden können.\n\n### 2. Verbesserte Fehlerisolierung\n\nBei einer monolithischen Architektur führt ein Fehler in einem Teil der Struktur dazu, dass alle Komponenten zusammenbrechen. Im Gegensatz dazu ist es bei einer Microservices-Architektur viel unwahrscheinlicher, dass der Ausfall eines Dienstes andere Teile der Anwendung beeinträchtigt, da jeder Microservice unabhängig läuft. Unternehmen sollten jedoch vorsichtig sein, da große Datenmengen in bestimmten Situationen immer noch problematisch sein können.\n\nDer Vorteil der Microservice-Architektur liegt darin, dass Entwickler(innen) Funktionen implementieren können, die Kaskadenausfälle verhindern. Zudem gibt es verschiedene [Tools von GitLab](https://handbook.gitlab.com/handbook/tools-and-tips/) und anderen Anbietern, die die Fehlertoleranz von Microservices erhöhen und somit die Ausfallsicherheit der Infrastruktur verbessern.\n\n### 3. Programmsprache und Technologieunabhängigkeit\n\nEine Microservice-Anwendung kann in jeder beliebigen Programmiersprache entwickelt werden, sodass die Entwickler(innen)teams die für ihre Arbeit am besten geeignete Sprache wählen können. Diese sprachunabhängige Flexibilität von Microservices-Architekturen ermöglicht es den Entwickler(innen), ihre vorhandenen Fähigkeiten optimal zu nutzen, ohne eine neue Programmiersprache erlernen zu müssen. Sie können somit effizienter arbeiten. Ein weiterer Vorteil von Cloud-basierten Microservices ist, dass Entwickler(innen) von jedem internetfähigen Gerät aus auf die Anwendung zugreifen können, unabhängig von der verwendeten Plattform.\n\n### 4. Einfachere Bereitstellung\n\nMit einer Microservices-Architektur können Teams unabhängige Anwendungen bereitstellen, ohne andere Dienste im System zu beeinträchtigen. Diese Fähigkeit, einer der Hauptvorteile von Microservices, ermöglicht es Entwickler(innen), neue Module hinzuzufügen, ohne die gesamte Systemstruktur umgestalten zu müssen. Unternehmen können dadurch effizient und flexibel neue Funktionen nach Bedarf integrieren.\n\n### 5. Wiederverwendbarkeit in verschiedenen Geschäftsbereichen\n\nEinige Microservice-Anwendungen können innerhalb eines Unternehmens mehrfach genutzt werden. Beispielsweise kann eine Website, die verschiedene Bereiche mit jeweils einer Anmelde- oder Zahlungsoption enthält, dieselbe Microservice-Anwendung für jede dieser Instanzen verwenden.\n\n### 6. Schnellere Markteinführung\n\nDie Entwickler(innen) können diese neuen „Mikroservices\" in die Architektur integrieren, ohne Konflikte mit anderem Code oder Ausfälle von Diensten befürchten zu müssen, die die gesamte Website beeinträchtigen könnten. Entwicklungsteams, die an verschiedenen Microservices arbeiten, müssen nicht auf die Fertigstellung der Arbeiten anderer Teams warten. Unternehmen können neue Funktionen schnell entwickeln und bereitstellen sowie ältere Komponenten aktualisieren, sobald neue Technologien die Weiterentwicklung ermöglichen.\n\n### 7. Möglichkeit zum Experimentieren\n\nDie Entscheidung, mit Experimenten fortzufahren, ist bei einer Microservices-Architektur wesentlich einfacher.\n\nNeue Funktionen können leicht eingeführt werden, da jeder Dienst unabhängig von den anderen arbeitet. Falls eine neue Funktion den Kunden nicht zusagt oder die geschäftlichen Vorteile nicht klar sind, kann sie problemlos zurückgenommen werden, ohne den restlichen Betrieb zu beeinträchtigen.\n\nWird eine neue Funktion von Kunden gewünscht, ermöglicht eine Microservices-Architektur die Einführung innerhalb von Wochen statt Monaten oder Jahren.\n\n### 8. Verbesserte Datensicherheit\n\nWenn die Komponenten der Computersystemarchitektur in kleinere Teile zerlegt werden, sind sensible Daten besser vor Eindringlingen aus anderen Bereichen geschützt. Obwohl es Verbindungen zwischen allen Mikrodiensten gibt, können Entwickler(innen) sichere APIs verwenden, um die Dienste zu verknüpfen. Sichere APIs gewährleisten, dass Daten nur für speziell autorisierte Benutzer, Anwendungen und Server zugänglich sind. Für Unternehmen, die mit sensiblen Daten wie Gesundheits- oder Finanzinformationen umgehen, wird die Einhaltung von Datensicherheitsstandards wie [HIPAA](https://www.hhs.gov/hipaa/index.html) im Gesundheitswesen oder der [europäischen DSGVO](https://dsgvo-gesetz.de/) durch diese Architektur vereinfacht.\n### 9. Flexibilität durch Outsourcing\n\nEs kann für ein Unternehmen notwendig sein, bestimmte Funktionen an Dritte auszulagern. Bei einer monolithischen Architektur sind viele Unternehmen besorgt über den Schutz ihres geistigen Eigentums. Eine Microservices-Architektur ermöglicht es jedoch, spezifische Bereiche nur für Partner zu segmentieren, ohne dass Kerndienste offengelegt werden.\n\n### 10. Optimierung der Teamarbeit\nWenn du dir überlegst, wie groß die Teams sein sollen, die du für jeden Microservice einsetzt, solltest du die sogenannte Zwei-Pizza-Regel beachten. Sie wurde erstmals von Amazon, dem Pionier der Microservices, formuliert und besagt, dass Entwicklungsteams so klein sein sollten, dass sie mit zwei Pizzen satt werden. Experten erklären, dass diese Richtlinie die Arbeitseffizienz verbessert, es den Unternehmen ermöglicht, ihre Ziele schneller zu erreichen, die Verwaltung der Teams erleichtert, einen stärkeren Fokus innerhalb der Gruppe schafft und zu qualitativ hochwertigeren Produkten führt.\n\n### 11. Bei Entwickler(innen) beliebt\n\nZuletzt ist einer der Microservices-Benefits auch, dass Entwickler(innen)(innen) die Microservices-Architektur attraktiv finden und Unternehmen bessere Chancen haben, hochkarätige Talente für die Entwicklung von Microservices-Anwendungen zu gewinnen. Microservices nutzen die neuesten technischen Verfahren und Entwickler(innen)werkzeuge. Dies ist ein wesentlicher Vorteil für Unternehmen, die Spezialist(innen) anziehen möchten.\n\n## Microservices: Nachteile\n\nTrotz der zahlreichen Vorteile für jedes Unternehmen gibt es auch einige Nachteile von Microservices, die vor der Einführung berücksichtigt werden sollten.\n\n### 1. Vorabkosten sind bei Microservices höher\n\nCloud-Microservices bieten langfristig Kosteneinsparungen, bringen jedoch auch Nachteile mit sich, wie etwa die hohen Anfangskosten für die Bereitstellung. Ein Unternehmen muss über eine ausreichende Hosting-Infrastruktur mit Sicherheits- und Wartungsunterstützung verfügen. Zudem ist es entscheidend, qualifizierte Teams zu haben, die alle Dienste verwalten können.\n### 2. Schnittstellenkontrolle ist entscheidend\n\nDa jeder Microservice eine eigene API besitzt, sind alle Anwendungen, die diesen Service nutzen, von Änderungen der API betroffen, wenn diese nicht abwärtskompatibel sind. Große Unternehmen, die eine Microservices-Architektur verwenden, haben oft Hunderte oder sogar Tausende von APIs. Die Kontrolle und Verwaltung dieser Schnittstellen ist entscheidend für den Betrieb des Unternehmens und kann somit einen Nachteil der Microservices-Architektur darstellen.\n\n### 3. Komplexität der anderen Art\n\nDie Fehlersuche kann bei einer Microservices-Architektur eine größere Herausforderung darstellen. Jeder Microservice hat seinen eigenen Satz von Protokollen. Das bereitet ein wenig Kopfzerbrechen, wenn es darum geht, die Quelle eines Problems im Code zu finden.\n\n### 4. Integrationsprüfung\n\nUnit-Tests sind bei einer Microservices-Architektur einfacher durchzuführen. Integrationstests hingegen nicht. Da die Architektur jeden Microservice verteilt, können die Entwickler(innen) das gesamte System nicht direkt von ihren Rechnern aus testen.\n\n## Unterschiede zwischen Serviceorientierte Architektur vs. Microservices\n\nWenn du im Bereich Cloud Computing arbeitest, kennst du wahrscheinlich die Debatte zwischen serviceorientierter Architektur (SOA) und Microservices. Beide Architekturen ähneln sich, da sie Cloud Computing für agile Entwicklung nutzen und große monolithische Komponenten in kleinere, handlichere Einheiten zerlegen.\n\nDer Hauptunterschied liegt im Umfang: SOA ist ein unternehmensweiter Ansatz für die Entwicklung von Softwarekomponenten, während Microservices eigenständige Anwendungen erstellen, die eine bestimmte Funktion erfüllen. Dieser Cloud-native Ansatz macht Microservices skalierbarer, flexibler und widerstandsfähiger.\n\nErfahre im Folgenden, wie du mit einer [Microservices-Architektur](https://about.gitlab.com/blog/get-started-with-microservices-architecture/) beginnen kannst.\n","devsecops",[9,9,830],"features","2024-11-19",{"slug":833,"featured":91,"template":688},"what-are-the-benefits-of-a-microservices-architecture","content:de-de:blog:what-are-the-benefits-of-a-microservices-architecture.yml","What Are The Benefits Of A Microservices Architecture","de-de/blog/what-are-the-benefits-of-a-microservices-architecture.yml","de-de/blog/what-are-the-benefits-of-a-microservices-architecture",{"_path":839,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":840,"content":846,"config":851,"_id":853,"_type":14,"title":854,"_source":16,"_file":855,"_stem":856,"_extension":19},"/de-de/blog/what-is-a-rest-api-guide-and-functions",{"title":841,"description":842,"ogTitle":841,"ogDescription":842,"noIndex":6,"ogImage":843,"ogUrl":844,"ogSiteName":672,"ogType":673,"canonicalUrls":844,"schema":845},"Was ist eine REST-API? Guide & Funktionen","REST-APIs sind der de-facto-Standard für die Kommunikation zwischen Server und Client. Erfahren Sie hier alles Wissenswerte zum Thema!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg","https://about.gitlab.com/blog/what-is-a-rest-api-guide-and-functions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Was ist eine REST-API? Guide & Funktionen\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-10-16\",\n      }",{"title":841,"description":842,"authors":847,"heroImage":843,"date":758,"body":849,"category":828,"tags":850},[848],"GitLab Germany Team","REST-APIs sind seit über zwei Jahrzehnten ein zentraler Baustein des Internets. Bei ihnen handelt es sich um Programmierschnittstellen (APIs), die den Austausch von Daten zwischen Client und Server regeln. REST-APIs unterliegen einem Satz von Bedingungen, welche der Wissenschaftler Roy Fielding im Jahr 2000 entwickelt und unter der Abkürzung REST (representational state transfer) [festgelegt hat](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 \"festgelegt hat\").\n\nREST legt die genaue technische Umsetzung dieser Schnittstellen nicht fest. Fielding hat REST vielmehr als einen „Architektur-Stil“ [bezeichnet](https://www.youtube.com/watch?v=6oFAmQUM8ws \"bezeichnet\"), der eine Vielzahl praktischer Lösungen erlaubt. Jede API, die sich innerhalb der Grenzen dieser Architektur bewegt, entspricht dem REST-Standard.\n\nIn diesem Artikel zeigen wir Ihnen, warum sich REST seit seiner Einführung zum dominanten Modell entwickelt hat und welche Vorteile sich für Web-Development-Teams daraus ergeben. \n\n## Constraints: Die Grundbausteine der REST-Architektur\n\nREST baut auf insgesamt sechs sogenannten „Constraints“ (Einschränkungen) auf. \n\nAus ihnen ergibt sich eine Architektur, die einfach und anpassungsfähig ist und auch in einem rasch wandelnden Geschäftsumfeld langfristig Bestand haben kann.\n\n## Definition: Was ist eine Rest-API?\n\nREST-APIs sind praktische Softwarelösungen, die auf der REST-Dokumentation aufbauen und gemäß der folgenden sechs REST-Prinzipien für ein Client-Server-Modell erstellt werden: \n\n- Unabhängigkeit zwischen Client und Server,\n- Zustandslosigkeit,\n- ein mehrschichtiges Systemmodell, \n- eine einheitliche Schnittstelle,\n- Cache-Fähigkeit und\n- ein optionales Constraint: Code on Demand.\n\nIn den folgenden Abschnitten betrachten wir diese Constraints genauer. \n\n### Unabhängigkeit zwischen Client und Server\n\nREST findet wie erwähnt für APIs Anwendung, die den Austausch von Ressourcen zwischen einem Client und einem Server ermöglichen. Entscheidend ist, dass Client und Server vollkommen unabhängig voneinander bleiben. \n\nSo kann beispielsweise der Code des Servers verändert werden, ohne dass der Client ebenfalls Änderungen vornehmen muss, um weiterhin Informationen anfragen und erhalten zu können. \n\n### Zustandslosigkeit\n\nDie Einschränkung der Zustandslosigkeit hat der REST-Architektur ihren Namen verliehen. Für APIs soll gemäß dieser Vorgabe gelten, dass für die korrekte Beantwortung einer Anfrage die übermittelten Informationen der aktuellen Sitzung ausreichen.\n\nDas bedeutet: Es ist keine dauerhafte Verbindung zwischen Client und Server erforderlich und Client-Anfragen müssen auf der Server-Seite auch nicht zwischengespeichert werden. \n\nZustandslosigkeit führt zu höherer Daten- und Ausfallsicherheit. Gleichzeitig gilt aber auch: Benötigen Nutzer(innen) dieselben Informationen ein zweites Mal, müssen sämtliche Informationen der vorigen Sitzung erneut eingeben werden. \n\n### Mehrschichtiges Systemmodell\n\nFür jedes Unternehmen ist eine andere Server-Struktur optimal. Werden Informationen beispielsweise in verschiedenen Schichten gespeichert, gestaltet sich die Abfrage mehr oder weniger komplex. Das aber sollte für eine Anfrage unerheblich bleiben, solange die Daten korrekt übermittelt werden.  \n\nDie Einschränkung des mehrschichtigen Systemmodells ist somit das Gegenstück zur Zustandslosigkeit. Während letztere besagt, dass der Server vom Client nichts weiter benötigt als die Anfrageinformationen, verlangt das mehrschichtige Modell, dass dem Client nicht bekannt zu sein braucht, wie der Server die angeforderten Daten bereitstellt. \n\nDer Server kann also mit einer Vielzahl verschiedener Architekturen arbeiten, ohne dass die REST-API-Schnittstelle beeinflusst wird. \n\n### Einheitliche Schnittstelle\n\nDiese Einschränkung ist etwas komplexer und wiederum aus vier Unterpunkten aufgebaut. Für Roy Fielding war sie die womöglich wichtigste der gesamten REST-API-Architektur. \n\nDie einheitliche Schnittstelle fordert:\n\n- dass jeder Datensatz über eine einzige URI eindeutig gekennzeichnet ist,\n- dass Veränderungen oder auch Löschungen der Daten nur mittels der grundlegenden Netzwerkprotokollbefehle, wie GET, POST, PUT/PATCH und DELETE, vorgenommen werden können,\n- dass jede Nachricht, die versandt wird, mittels Metadaten sämtliche Informationen bereithält, die für die Bearbeitung der Daten erforderlich ist und\n- dass, sofern erforderlich, Hyperlinks (HATEOAS) bereitgestellt werden, um weitere benötigte Informationen einzuholen.\n\nDie einheitliche Schnittstelle sorgt für maximale Klarheit und eine einfache, standardisierte Client-Server-Kommunikation. \n\n### Cache-Fähigkeit\n\nZwar findet bei REST-APIs der Ressourcenaustausch zustandslos statt, zugleich aber sollten einmal angeforderte Daten aus einer Sitzung auf demselben Endgerät weiterverwendet werden können.\n\nIndem REST das Cachen dieser Informationen ermöglicht, sorgt es für eine höhere Effizienz und beschleunigt viele Prozesse bedeutend.\n\n### Code on Demand\n\nFür die meisten Anwendungen reicht die Bereitstellung der Daten in der Form von XML or JSON vollkommen aus. In bestimmten Fällen aber kann es von Vorteil sein, dem Client darüber hinaus –      oder stattdessen – eine Anwendung bereitzustellen. Denken Sie dabei an Java Applets oder JavaScript.\n\nCode on Demand stellt eine sinnvolle Erweiterung der REST-Architektur dar, aber sie ist als einzige der sechs Einschränkungen optional. \n\n## Wofür eignen sich REST-APIs?\n\nFlexibilität ist eines der Hauptmerkmale von REST-APIs. So sind sehr viele praktische Anwendungen denkbar:\n\n- Ganz grundsätzlich das Abrufen und Bereitstellen von Daten. Social-Media-Seiten wie Instagram oder Facebook nutzen REST-APIs beispielsweise um Updates zu posten.\n- Gerade weil sie zustandslos sind, eignen sich REST-APIs für Cloud-Services: Auch wenn die Verbindung abbricht, können die Daten weiter genutzt werden. \n- [Microservices](https://microservices.io/ \"Microservices\") gewinnen rasch an Beliebtheit und Bedeutung. Mit ihnen geht ein umfassender Perspektivenwechsel einher: Applikationen werden nicht mehr als riesige, in sich geschlossene Systeme gedacht, sondern als modular und aus kleineren, schlanken Elementen zusammengesetzt. REST-APIs bilden die ideale Schnittstelle zur nahtlosen Integration dieser verschiedenen Bausteine.\n\nIm Laufe der letzten 20 Jahre sind Alternativen zu REST-APIs verfügbar geworden. Dennoch hat sich keine davon auf breiter Basis durchsetzen können. Ganz offensichtlich ist REST auch aktuell der beste Ansatz zum Datenaustausch im Netz. \n\n## Was sind die Vorteile einer Rest-     API?\n\nIn den frühen Tagen des Internets war SOAP (Simple object access protocol) die dominante Form des Datenaustauschs. \n\nDass sich REST seitdem durchgesetzt hat und fast ein Vierteljahrhundert lang relevant geblieben ist, lässt sich recht einfach aus seinen inhärenten Vorteilen erklären:\n\n- SOAP vs REST: SOAP ist ein Protokoll, das Regeln und auch technische Realisierungen im Gegensatz zu REST sehr präzise vorschreibt. Daraus ergibt sich unmittelbar, dass APIs, die auf diesen Anforderungen aufbauen, weitaus komplexer als REST-APIs sind.\n- Die APIs, die gemäß der REST-Richtlinien programmiert wurden, basieren auf dem HTTP-Standard. Sie sind schnell und effizient und in nahezu jedem Kontext einsetzbar. Aus genau diesen Gründen eignen sich REST-APIs auch besonders gut für mobile Anwendungen.\n- Der Begriff der Skalierbarkeit ist bereits gefallen und er ist auch einer der maßgeblichen Argumente für die Verwendung von REST-APIs. Darunter ist zu verstehen, dass bei Erweiterungen der Server-Architektur nicht die darunter liegende Datenaustausch-Technologie verändert werden muss. \n- Einige Unternehmen setzen aus Sicherheitserwägungen immer noch auf SOAP. Allerdings sind REST-APIs keineswegs grundsätzlich unsicher. Entscheidend ist, einige grundlegende Best Practices anzuwenden – darunter die Verwendung von HTTPS sowie Autorisierung und Authentifizierung. \n\n## Gibt es eine REST-API von GitLab?\n\nAuch bei GitLab sind wir von den Vorzügen der REST-Architektur überzeugt. Aus diesem Grund stellen wir unseren Nutzer(inne)n eine [GitLab-REST-API](https://docs.gitlab.com/ee/api/rest/ \"GitLab-REST-API\") zur Verfügung. \n\nBei GitLab handelt es sich um den führenden Anbieter von DevSecOps-Lösungen. Anwender(innen) nutzen die Plattform, um sicher, fehlerfrei und kollaborativ an Entwicklungsprojekten zu arbeiten. \n\nDie GitLab-API kann sowohl genutzt werden, um öffentlich sichtbare, als auch nicht öffentliche Daten (nach erfolgter Authentifizierung und Autorisierung) abzurufen. Weil die API unmittelbar auf GitLab abgestimmt ist, erfolgt der Austausch sicher, schnell und effizient. \n\n## REST-API FAQs\n\n### Ist REST ein Standard?\n\nREST ist ein Satz aus sechs Einschränkungen, die den Datenaustausch in einer Client-Server-Beziehung regeln. Alle API-Schnittstellen, die diesen Vorgaben entsprechen, sind „RESTful“. \nEs ist somit nicht falsch, REST als einen Standard zu bezeichnen. Allerdings gilt dies weniger im Sinne eines Protokolls oder konkreter Anweisungen. REST gibt vielmehr Leitlinien und Anforderungen vor, deren Umsetzung zu gewünschten Ergebnissen führen, unabhängig davon, wie diese technisch realisiert werden.\n\nAus diesem Grund wird REST zumeist als ein „Architektur-Stil“ definiert. \n\n### Muss ich alle sechs REST-Einschränkungen befolgen?\n\nRoy Fielding hat hierzu persönlich im Laufe der Jahre mehrfach [Stellung bezogen](https://www.infoq.com/articles/roy-fielding-on-versioning/ \"Stellung bezogen\"). Seine Ansichten zu dieser Frage sind eindeutig: REST ist nicht in allen Fällen zwangsläufig die beste Option. Wenn man aber eine REST-konforme Architektur wünscht, müssen sämtliche Constraints ausnahmslos umgesetzt werden. \n\nEine API beispielsweise, die alle Einschränkungen umsetzt, bei der aber keine Daten gecached werden können, ist nicht RESTful. \n\nDie einzige Ausnahme ist Code on Demand. Diese Einschränkung ist optional und muss somit nicht umgesetzt werden, damit eine REST-API die Kriterien erfüllt. \n\n### Wie passen Cache-Fähigkeit und Zustandslosigkeit zusammen?\n\nZwischen den Einschränkungen der Cache-Fähigkeit und Zustandslosigkeit scheint ein Spannungsverhältnis zu bestehen. Wenn bei jeder Anfrage die Daten neu übermittelt werden müssen, widerspricht das Zwischenspeichern von Daten im Cache dann nicht dieser Forderung? \n\nIn Wahrheit fordert Zustandslosigkeit lediglich, dass der Server jede Anfrage so behandelt, als wäre sie die erste. Es besteht keine Zuordnung der Daten im Cache zu einer aktuellen Anfrage. \n\nDas Cachen der Daten dient lediglich einer höheren Effizienz und sorgt für Stabilität. \n\n### Was bedeutet der Begriff Idempotenz im Zusammenhang mit REST-APIs?\n\nWenn ein Client dieselbe Anfrage mehrfach nacheinander stellt, spricht man von Idempotenz. Das kann entweder passieren, weil die Verbindung instabil oder der Code fehlerhaft ist. \n\nEntscheidend ist, dass eine solche idempotente Anfrage nicht zu einem Fehler bei der Beantwortung der Anfrage führt. \n\nDie Einschränkung der Cache-Fähigkeit sorgt dafür, dass idempotente Anfragen als solche erkannt und fehlerfrei bearbeitet werden können. \n\n### Wie lassen sich Rest-APIs sichern?\n\nREST-APIs können sehr effektiv gesichert werden. \n\nÜbliche und sehr effiziente Methoden sind die Verwendung von HTTPS und API-Schlüsseln, die Durchführung von Authentifizierungen und Autorisierungen sowie die Durchführung einer Input-Validation und eines Audit-Loggings. \n\nAuch die Begrenzung der Anfragen in einem bestimmten Zeitfenster im Sinne eines Rate-Limiting empfiehlt sich.",[9,710],{"slug":852,"featured":6,"template":688},"what-is-a-rest-api-guide-and-functions","content:de-de:blog:what-is-a-rest-api-guide-and-functions.yml","What Is A Rest Api Guide And Functions","de-de/blog/what-is-a-rest-api-guide-and-functions.yml","de-de/blog/what-is-a-rest-api-guide-and-functions",{"_path":858,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":859,"content":865,"config":872,"_id":874,"_type":14,"title":875,"_source":16,"_file":876,"_stem":877,"_extension":19},"/de-de/blog/what-is-docker",{"title":860,"description":861,"ogTitle":860,"ogDescription":861,"noIndex":6,"ogImage":862,"ogUrl":863,"ogSiteName":672,"ogType":673,"canonicalUrls":863,"schema":864},"So optimierst du mit Docker und GitLab deinen DevOps-Prozess","Docker Container bieten deinem Team mehr Raum für Kollaboration, kontinuierliche Integration und Kreativität. Wir zeigen dir, wie die Umsetzung klappt.\n\n","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664248/Blog/Hero%20Images/AdobeStock_564261524.jpg","https://about.gitlab.com/blog/what is docker","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"So optimierst du mit Docker und GitLab deinen DevOps-Prozess\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2025-02-27\",\n      }",{"title":860,"description":861,"authors":866,"heroImage":862,"date":867,"body":868,"category":869,"tags":870},[848],"2025-02-27","# So optimierst du mit Docker und GitLab deinen DevOps-Prozess\n\nIn wenigen Jahren hat sich Docker zu einem globalen Standard entwickelt. Laut aktuellen Statistiken liegt sein Marktanteil in der Containerisierung bei über [80 %](https://6sense.com/tech/containerization/docker-market-share); fast 50 % aller Entwickler(innen) nutzen Docker; und zum Zeitpunkt des Verkaufs des Unternehmens an Mirantis [schätzte man die Zahl seiner Nutzer auf 15 Millionen weltweit](https://cloudnativenow-com.translate.goog/features/docker-inc-dev-tools-boast-15-million-users/?_x_tr_sl=en&_x_tr_tl=de&_x_tr_hl=de&_x_tr_pto=rq). Wenn du im DevOps-Bereich tätig bist, kommst du um Docker somit nicht herum.\n\nDie Vorteile von Docker sprechen für sich. Gegenüber der früher dominanten Virtualisierung läuft es sowohl stabiler als auch schneller. Es unterstützt die Kernziele von [DevOps](https://about.gitlab.com/de-de/topics/devops/), erhöht signifikant die Transparenz eines Projekts und spart Ressourcen ein.\nEntwickler(innen), die mit GitLab arbeiten, können aufgrund einer nahtlosen Integration Docker-Container für sich nutzen. Gleichzeitig gleicht GitLab einige der Nachteile, die bei der Verwendung von Docker auftreten können, aus. Diese enge Verzahnung optimiert die Vorteile beider Anwendungen und bringt deinen DevOps-Prozess weiter nach vorne.\nIn diesem Artikel zeigen wir dir, wie das funktioniert und wie du Docker und GitLab am besten miteinander kombinierst. Aber fangen wir mit einer kurzen Definition an.\n\n## Was ist Docker?\n\nDocker ist eine Plattform zur Containerisierung. Dahinter steht ein neuer Ansatz, über Anwendungen nachzudenken.\nIn der traditionellen „monolithischen” Sichtweise ist das Programm wie eine Art Geschichte angelegt, mit einem Anfang, einem Ende und einer stringenten inneren Logik. Weil alle Funktionen geteilten Annahmen unterworfen sind, lassen sich einzelne Komponenten nur schwer voneinander trennen und ausgliedern.\nBei Docker bildet jede logische Funktion eines Programms eine eigenständige Anwendung, die für sich steht und isoliert ausgeführt werden kann. Dieser Ansatz ist eher modular, die einzelnen Anwendungen können in immer neuen Kombinationen zusammengesetzt und miteinander verzahnt werden. Man könnte sagen: Docker ist kybernetisch, weil es von Systemen, Regelkreisen und Kontrollmechanismen bestimmt wird.\nDocker-Container enthalten alles, was eine Anwendung zur Ausführung benötigt. Mit Docker kannst du Container definieren und anlegen, im Rahmen der Entwicklung plattformunabhängig testen und verbessern und unkompliziert ausliefern.\nDank seiner führenden Rolle ist Docker zu einem Synonym für Containerisierung geworden. Lange bevor Docker aber den Entwicklungsprozess revolutionierte, nutzten DevOps-Teams einen sehr ähnlichen Ansatz namens Virtualisierung.\n\n## Virtualisierung: Die Vorstufe der Containerisierung\n\nDer Grundgedanke der Virtualisierung stammt bereits aus den 1960ern, als IBM an Lösungen arbeitete, die es Anwendern ermöglichen sollten, auf nur einem Rechner mehrere Betriebssysteme laufen zu lassen. Virtualisierung in DevOps nimmt diesen Gedanken zum Ausgangspunkt dafür, Programme so anzulegen und zu verpacken, dass sie unabhängig von den spezifischen Gegebenheiten des Hosts laufen.\n\nJede dieser „virtuellen Maschinen” (VM) bringt alle Anwendungen mit, die für die Ausführung benötigt werden, einschließlich eines eigenen Betriebssystems. Damit können Projektteilnehmer(innen) die Anwendung nutzen, ohne sich mit Kompatibilitätsproblemen auseinandersetzen zu müssen.\n\nVirtuelle Maschinen sind extrem stabil, sicher und werden auch heute noch in vielen Bereichen bevorzugt genutzt. Allerdings haben sie zwei Nachteile:\n\n- Das in jeder VM enthaltene Betriebssystem belastet den Speicher und beeinträchtigt die Systemleistung des Hosts.\n- Der„Hypervisor” einer VM, der für den Betrieb benötigt wird, Ressourcen. Docker ist kein Ersatz für virtuelle Maschinen. Es soll sie vielmehr optimieren und ihre Nachteile so weit wie möglich beseitigen.\n\n## Wie Docker die Nachteile virtueller Maschinen ausgleicht\n\nContainer sind virtuellen Maschinen sehr ähnlich, betonen aber den Aspekt der Isolation über den der Autonomie (wir werden darauf noch genauer eingehen). In ihnen sind ebenfalls alle relevanten Daten und Apps enthalten. Das ermöglicht eine Ausführung unabhängig vom Host-Betriebssystem. Der Unterschied zur Virtualisierung besteht darin, dass Docker-Container kein eigenes Betriebssystem enthalten. Sie teilen sich stattdessen den Kernel des Hosts. Das ist effizienter, schont Systemressourcen und macht Container vor allem weitaus schneller als VM.\n\nDie Vorzüge von Docker waren derart offensichtlich, dass es einen rasanten Aufstieg durchmachte. 2013 veröffentlicht, wurde es ein Jahr später Teil der Pakete von Red Hat Enterprise Linux 7.0 und openSUSE. Die Beliebtheit von Docker war zu diesem Zeitpunkt bereits so stark angewachsen, dass sich einige der größten IT-Unternehmen der Welt zusammenschlossen, um ein System zu entwickeln, mit dem sich Docker-Container besser verwalten lassen sollten. Das daraus entstandene [Kubernetes](https://about.gitlab.com/de-de/solutions/kubernetes/) wird bis heute zur Orchestrierung (Verwaltung) von Containern verwendet.\n\n## Docker: Grundbegriffe\n\nDas Grundkonzept von Docker Containern ist die „Isolation”. Dieses Prinzip unterscheidet sie von den grundsätzlich sehr ähnlichen virtuellen Maschinen.\nVirtuelle Maschinen bilden ein eigenständiges System, das auf keine äußeren Ressourcen angewiesen ist. Container isolieren zwar ebenfalls den größten Teil ihrer Prozesse und Anwendungen, teilen sich aber mit dem Host den Kernel. Es mag so scheinen, als seien diese Unterschiede zwischen den beiden Begriffen eher gering. In der Praxis aber können sie recht große Konsequenzen haben.\n\nDer Lebenszyklus von Docker-Containern beginnt mit sogenannten „Images”. Was ist ein Docker-Image? In ihm ist gewissermaßen der „Bauplan” (oder auch das „Rezept”) enthalten, wie die ausführbaren Docker-Container zusammengestellt werden sollen. Entwickler(innen) „schreiben” den Bauplan in ein Docker-File, zu dem sie Informationen in Schichten („Layern”) sowie die erforderlichen Daten hinzufügen. Eine der entscheidenden Eigenschaften von Docker besteht darin, dass es ein Standardformat für diese Images bereitstellt.\n\nImages werden in der „Registry\" gespeichert und verwaltet. Hier können Änderungen der verschiedenen Versionen nachvollzogen werden, die ein Image bis zum heutigen Stand durchlaufen hat. GitLab bietet ebenfalls eine solche Registry an, von der aus du deine Programme direkt testen und optimieren kannst. Sobald ein Docker-Image mittels seiner Runtime zur Ausführung kommt, entsteht ein Container. Container sind somit das aktivierte Gegenstück eines Images. Sie sind sofort lauffähig und müssen nicht erst „hochgefahren” werden.\n\n## Wie funktioniert Docker im Rahmen von DevOps?\n\nGeschwindigkeit und Effizienz sind zweifelsohne wichtige Aspekte in allen Wirtschaftsbereichen. Im DevOps aber sind sie geradezu essenziell. Dies erklärt die besonders hohe Wertschätzung, die Docker in der Entwicklung genießt. Doch enden die Stärken von Docker dort nicht. Vielmehr kann die Containerisierung alle zentralen Aspekte von DevOps unterstützen:\n\n- Kollaboration: Container können auf jedem Rechner mit denselben Funktionalitäten gestartet werden. Das reduziert Probleme bei der plattformübergreifenden Zusammenarbeit, auch innerhalb eines Teams.\n\n- Kontinuierliche Verbesserung: Als Teil der Kollaboration können immer wieder sehr einfach neue Images geschrieben und neue Container generiert werden, die Optimierungen enthalten. So wird der Prozess der kontinuierlichen Verbesserung deutlich vereinfacht.\n\n- Kundenorientierung: Weil Docker-Container einfach und schnell auf allen Systemen laufen, kann der aktulle Stand eines Projekts jederzeit mit den Kund(inn)en geteilt werden. Damit kann man sich immer wieder wertvolles Feedback holen und das Produkt voll und ganz auf die Kundenwünsche ausrichten.\n\n- Lernen aus Fehlern: Einen Fehler in einer Entwicklungsumgebung zu beheben, war früher aufwändig und komplex. Mit Docker hingegen werden diese Änderungen zu einem selbstverständlichen Teil des Prozesses. Dies führt zu einer Arbeitsphilosophie, bei der mehr ausprobiert werden darf, neue Ideen stets willkommen sind und das Projekt durch Fehler gewinnt, statt durch sie aufgehalten zu werden.\n\n## DevSecOps: Wie sicher sind Docker-Container?\n\nContainer opfern gegenüber virtuellen Maschinen ein wenig Sicherheit zugunsten einer besseren Performance. Virtuelle Maschinen sind dank ihres mitgelieferten Betriebssystems vollständig unabhängig vom Host. Docker allerdings teilt sich den Kernel. Das bedeutet in Hinblick auf die Sicherheit, dass:\n\n- Sicherheitslücken im Kernel auch Auswirkungen auf die Container des Hosts haben können.\n- Sicherheitsprobleme mit einem Container auf alle Container übergreifen können.\n- Sicherheitslücken im Kernel das gesamte Host-System infizieren können - und von dort aus dann die Container.\n\nHinzu kommt, dass es bei Docker mehrere potentielle Stellen für Sicherheitsrisiken gibt. So gibt es nicht nur ein einziges Image, sondern mehrere Instanzen, den Docker-Daemon (der im Hintergrund die Anfragen an Docker verarbeitet), die Cloud in der der Server gehostet wird sowie verschiedene Netzwerke, welche die Kommunikation zwischen den Containern orchestrieren. Im Prinzip muss jede dieser potenziellen Schwachpunkte individuell gesichert werden.\n\n## Wie du die Sicherheit von Docker verbessern kannst\n\nZum Glück gibt es einige einfach umzusetzende Punkte, mit denen du den Einsatz von Docker in deinen Entwicklungsprojekten vor Eingriffen schützen kannst:\n\nNutze die Möglichkeit, Ressourcen zu beschränken. Mit der „Ressource Quota” schränkst du den Zugriff auf Speicher und CPU gezielt ein. Das ist bereits deswegen sinnvoll, da es die Performance des gesamten Container-Systems optimiert. Darüber hinaus blockiert es auch die Möglichkeit, dass ein „infizierter” Container die gesamte Systemleistung reduziert.\n\nVermeide es, die Zugriffsrechte zu umgehen, indem du einen Container als „root” laufen lässt. Das mag in manchen Situationen zwar komfortabler sein, sobald du aber geschützte Testumgebungen verlässt und kollektiv an einem Projekt arbeitest, solltest du der Datensicherheit stets oberste Priorität zuweisen. Stelle sicher, dass deine Registry ausreichend gesichert ist.\nUm die Sicherheit deiner Projekte weiter zu erhöhen, bietet sich GitLab als ein hervorragendes Instrument an, um Container im Rahmen von DevSecOps sicherer zu machen.\n\n## Welche Rolle spielt Docker für GitLabs DevSecOps-Funktionalität?\n\nSicherheitsaspekte spielen für GitLab eine zentrale Rolle: Der Schutz deiner Daten ist nicht von der Entwicklung zu trennen, sowohl was die Arbeit innerhalb des Teams angeht, als auch die Absprache und kontinuierliche Verbesserung mit Kund(inn)en. GitLab nutzt Docker-Container, um diesen Schutz jederzeit zu gewährleisten.\n\nEine der zentralen Funktionen von GitLab ist das [Container-Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/). Es basiert auf dem Gedanken, dass Sicherheits-Schwachpunkte bereits im Docker-Image ihren Ursprung haben können, oft in der Form von Abhängigkeiten, die du nicht selbst geschrieben hast, sondern aus externen Quellen importierst. Du kannst entweder nur die Container scannen oder die Abhängigkeiten - wobei wir dir für optimalen Schutz stets beides empfehlen.\n\nAuf einer noch grundlegenderen Ebene unterstützen selbstverständlich auch die allgemeinen Sicherheits-Features von GitLab die Verwendung von Docker-Images und Docker-Containern. Eine zentrale Funktion ist beispielsweise Auto-Remediation, eine intelligente kollaborative Anwendung, die dir bereits beim Entwickeln Vorschläge zur Fehlervermeidung und zu effizienterem Code macht.\n\n## 3 Docker Herausforderungen und wie GitLab bei der Lösung hilft\n\nDocker ist ein bestechendes Konzept, das die Arbeit für Millionen Entwickler(innen) täglich besser und einfacher macht. Seine Flexibilität und Individualisierung aber stellen Nutzer(innen) zugleich vor einige Herausforderungen.\nSehen wir uns drei zentrale Herausforderungen näher an - und wie GitLab dabei helfen kann, sie zu bewältigen.\n### Standardisierung:\n\nDocker ist ein offenes Konzept, das Entwickler(innen) höchst individuelle Lösungswege eröffnet. Wenn aber in Teams verschiedene Mitglieder an einem Projekt arbeiten und dabei sehr unterschiedliche Coding-Stile benutzen oder teilweise sogar widersprüchliche Anweisungen geben, kann es zu Konflikten kommen.\n\nGitLab bietet Standardisierungsoptionen an, beispielsweise durch [CI/CD-Templates](https://docs.gitlab.com/ee/ci/examples/), mit denen das gesamte DevOps-Team arbeiten kann. Shared Runners ermöglichen anschließend das Testen des aktuellen Standes in einer von dir vorgegebenen oder standardisierten Umgebung.\nAll dies ist gerade bei großen Projekten eine unermessliche Hilfe, da dabei bis zu tausende Container gleichzeitig miteinander abgestimmt werden müssen.\n\n### Ressourcenoptimierung:\n\nDocker Container nutzen Ressourcen in der Regel weitaus schonender als virtuelle Maschinen. Wie oben angesprochen kann sich die Gesamtzahl aller Container aber zu riesigen Zahlen summieren.\nMit verschiedenen Funktionen sorgt GitLab dafür, dass gerade speicherintensive Jobs optimiert- und gewisse Container zeitweise deaktiviert werden, um die Systemleistung zu verbessern.\n\n### Orchestrierung:\n\nDas wichtigste Thema in der Containerisierung ist heute zweifelsohne die Orchestrierung. Wenn du sehr viele Container nutzt, die zusammen mit den Anwendungen auf verschiedenen Servern untergebracht sind und zu unterschiedlichen Zeiten und in immer neuen Konstellationen miteinander kombiniert werden sollen, kommt es leicht zu Engpässen, Ausfällen oder Fehlern.\nKubernetes ist die komplexe Lösung für diese Probleme und GitLab ist direkt mit Kubernetes abgestimmt. Du kannst mit GitLab und Kubernetes die gesamte [CI/CD](https://about.gitlab.com/topics/ci-cd/)-Pipeline automatisieren und dabei dein System optimieren.\n\n## FAQ\n\n### Was ist Docker Compose?\n\nDocker Compose ist ein Tool, das dir bei der Orchestrierung hilft. Es findet in Multi-Container-Umgebungen Anwendung. In diesem Artikel haben wir bisher angenommen, dass eine Anwendung einem Container entspricht. Das ist zur Erklärung der grundlegenden Zusammenhänge sinnvoll. In der Praxis aber ergeben sich zumeist weitaus komplexere Sachverhalte.\n\nEin typischer Fall besteht darin, dass eine Anwendung mehrere Container benötigt, die zu unterschiedlichen Zeitpunkten gestartet und beendet werden. Diesen Ablauf präzise zu definieren sowie dabei die einzelnen Container-Aktionen aufeinander abzustimmen und im Rahmen eventueller Fehler oder Probleme zu optimieren, erweist sich als komplex. Wie [Data Scientist](https://datascientest.com/de/docker-compose-von-der-installation-bis-zur-bereitstellung-von-anwendungen) betont, liegt die Schwierigkeit darin, die verschiedenen Container „separat auszuführen, während sie gleichzeitig miteinander kommunizieren.”\n\n[Docker Compose](https://forum.gitlab.com/t/how-to-use-docker-compose-in-gitlab-ci/97671) unterstützt die Orchestrierung bei genau diesen Szenarien. Entwickler(innen) können in einer speziellen Datei mit einer laut [Heise](https://www.heise.de/hintergrund/Multi-Tier-Applikationen-mit-Docker-Compose-Machine-und-Swarm-3014669.html?seite=3) „simplen Syntax” alle Aktionen festlegen, die beim Aufbau und der Interaktion der Container zum Tragen kommen. Zurecht gilt Docker Compose deswegen als „ein mächtiges Werkzeug für den Einsatz und die Verwaltung von Multi-Container-Anwendungen”.\n\n### Wie funktioniert die Continuous Integration von Docker in GitLab?\n\nDocker wirkt sich positiv auf alle drei Prinzipien von CI/CD aus, vom kontinuierlichen Deployment bis hin zur kontinuierlichen Lieferung (delivery). Bei der kontinuierlichen Integration aber (Continuous Integration) sind die Vorteile ganz besonders offensichtlich.\nBei der Continuous Integration (CI) werden sämtliche branches (Enwticklungszweige) so oft wie möglich mit der main branch (dem Hauptentwicklungszweig) zusammengeführt. Dadurch haben alle Mitglieder eines Teams stets Zugriff auf den aktuellen Stand des Projekts und eine Änderung an einem Teil der Anwendung kann direkt auf seine Auswirkungen auf andere Bereiche hin überprüft werden. So wird vermieden, dass möglicherweise schwerwiegende Fehler im Zusammenspiel erst kurz vor Veröffentlichung des Produkts entdeckt werden.\n\nContainer sind das optimale Instrument, um Continuous Integration in deiner CI/CD-Pipeline zu realisieren. In ihrer containerisierten Form können Anwendungen schnell und in verschiedenen Umgebungen getestet werden. Das Feedback lässt sich unmittelbar auswerten und bewerten. Anschließend machst du Änderungen für alle branches durch das Definieren eines neuen, aktualisierten Images sichtbar und überprüfbar.\nZusammenfassend lässt sich sagen, dass Container die Integration im CI/CD-Prozess robuster und zuverlässiger gestalten und somit die Basis für erfolgreiches Deployment und Delivery bereiten.\n\n### Wann empfiehlt es sich, mit virtuellen Maschinen zu arbeiten statt mit Docker?\n\nDocker ist eine Weiterentwicklung virtueller Maschinen. Daraus sollte aber nicht der Schluss gezogen werden, dass es sich bei VM um eine veraltete oder gar überholte Technologie handelt. Vielmehr bleiben die Vorzüge dieses Modells auch in Zukunft bestehen.\n[Computer Weekly](https://www.computerweekly.com/de/ratgeber/Sechs-Anwendungsfaelle-fuer-die-sich-Docker-eignet) hat drei Situationen ermittelt, in denen Virtualisierung die bessere Option darstellt:\n\n__- Bei besonders sensiblen Daten:__ hier kann ein Höchstmaß an Isolierung erforderlich sein. Da sie mit dem Host in der Regel in keinem direkten Austausch stehen, sind virtuelle Maschinen hier zweifelsfrei die sicherste Wahl.\n\n__- Bei grafikintensiven Anwendungen__ lassen sich zwar grundsätzlich auch über Container verwenden, in der Regel aber ist Virtualisierung hier einfacher in der Handhabung.\n__In kleinen Teams__– wenn du nur selten Änderungen an deinen Anwendungen vornimmst, sind virtuelle Maschinen eine hervorragende Alternative, weil sie leichter zu verwalten sind.\n\n### Läuft Docker auch auf Windows und MacOs?\n\nDocker kann auf allen Hosts laufen, die Docker unterstützen. Tatsächlich aber ist die Plattform vor allem auf eine Linux-Nutzung hin optimiert.\nDie originäre Version von Docker ist so ausgelegt, dass sie die Funktionalitäten eines Linux-Kernels mit dem Host teilen kann. In diesem Umfeld funktionieren Container am effizientesten und die Vorteile der Containerisierung kommen voll zur Geltung.\n\nUm Docker auch für Windows und MacOs nutzbar zu machen, stehen entsprechende Docker-Versionen zur Verfügung. Diese aber geben das strenge Isolierungs-Prinzip auf und fügen eine virtuelle Maschine hinzu, welche eine Nutzung auf Linux-fremden Umgebungen erlaubt.\nAuch, wenn Docker unter Windows und MacOs nicht ganz so effizient ist wie unter Linux, ist die benötigte VM sehr leicht und schränkt Geschwindigkeit und Speicher nicht so stark ein wie eine vollständige virtuelle Maschine. Die gelegentliche Behauptung, Docker lasse sich nur unter Linux sinnvoll verwenden, ist deswegen zweifelsfrei sehr radikal.\n","open-source",[9,871],"open source",{"slug":873,"featured":6,"template":688},"what-is-docker","content:de-de:blog:what-is-docker.yml","What Is Docker","de-de/blog/what-is-docker.yml","de-de/blog/what-is-docker",{"_path":879,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":880,"content":886,"config":892,"_id":894,"_type":14,"title":895,"_source":16,"_file":896,"_stem":897,"_extension":19},"/de-de/blog/agile-epics-in-gitlab",{"title":881,"description":882,"ogTitle":881,"ogDescription":882,"noIndex":6,"ogImage":883,"ogUrl":884,"ogSiteName":672,"ogType":673,"canonicalUrls":884,"schema":885},"Agile Epics in GitLab: Mit Sicherheit zum Erfolg","Agile Epics sind eine Methode, auch bei komplexen Entwicklungsprojekten den Überblick zu behalten. Wir zeigen dir, wie es funktioniert.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665856/Blog/Hero%20Images/AdobeStock_869074524.jpg","https://about.gitlab.com/blog/agile-epics-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Agile Epics in GitLab: Mit Sicherheit zum Erfolg\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Germany Team\"}],\n        \"datePublished\": \"2024-10-17\",\n      }",{"title":881,"description":882,"authors":887,"heroImage":883,"date":888,"body":889,"category":890,"tags":891},[848],"2024-10-17","Agiles Projektmanagement führt schnell und effizient zu kundenorientierten Produkten. Aber es verlangt eine sehr genaue Planung. Epics helfen dabei.\n\nIn ihrer einfachsten Form sind Epics eine Methode, komplexe Ziele in kleine, leichter zu bewältigende Pakete aufzuteilen. Richtig angewandt können sie dazu beitragen, bessere agile Strategien für dein Unternehmen zu entwickeln.\n\nEpics bieten sich insbesondere für die Softwareentwicklung, beispielsweise in GitLab an. Doch beschränkt sich ihr Einsatz nicht darauf. Ein Epic ist ein flexibles Instrument, das in nahezu jeder Branche Anwendung finden kann.\n\nGerne zeigen wir dir, wie du Epics gewinnbringend einsetzen kannst.\n\n## Was ist ein Epic?\n\nGanz gleich, ob du neue Software entwickelst oder dir einen besseren Überblick über deine monatlichen Kennzahlen verschaffen möchtest: dein Anforderungsprofil wird in der Regel aus einer Liste von gewünschten Funktionen, Leistungen oder Informationen bestehen.\n\nDie meisten dieser Funktionen - auch „User Stories“ genannt – stellen das Team vor eine genau umrissene Aufgabe. Einige User Stories sind aber umfassender … Ihre Umsetzung erfordert eine Vielzahl von Aufgaben, die alle eng miteinander verknüpft und üblicherweise abteilungsübergreifend sind.\n\nDiese [größeren User Stories](https://www.business-wissen.de/artikel/user-storys-schreiben-beispiele-anleitung-tipps/ \"größeren User Stories\") bezeichnet man in der agilen Entwicklung als Epics. Epics spielen in der Planung eine zentrale Rolle, unabhängig davon, ob du mit Scrum oder Kanban oder einem anderen agilen Tool arbeitest.\n\n## Epics in GitLab\n\nAuch in GitLab dienen Epics dazu, umfassende User Stories oder geplante Features, die sich über verschiedene Projekte und Diskussionen erstrecken, thematisch zusammenzufassen und zu organisieren.\n\nEpics als umfassende User Stories sind kein exklusives GitLab-Feature. Ihre Integration ist hier aber besonders organisch, da GitLab als führende DevSecOps-Plattform eng mit derselben Agile-Philosophie verbunden ist, auf der auch Epics basieren.\n\nEinerseits erlauben GitLab Epics es dir, sehr präzise die unterschiedlichen Arbeitsphasen der Teams nachzuvollziehen und auf einer fast schon mikroskopischen Ebene detaillierte Planungen vorzunehmen. Andererseits bieten sie einen hervorragenden Rahmen, Projekte von einer übergeordneten Ebene aus zu betrachten und Synergien zu nutzen.\n\nIn dem folgenden Video findest du eine kurze Einleitung dazu, welchen praktischen Nutzen die Arbeit mit Epics in einem Tool wie GitLab bietet:\n\n\u003Ciframe width=\"760\" height=\"515\" src=\"https://www.youtube.com/embed/kdE-yb6Puuo?si=e8BxOIowpT-eDb7U\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## Was ist ein Epic?\n\nDer IT-Coach und -Berater Anthony Murphy [hat darauf hingewiesen](https://www.antmurphy.me/newsletter/from-epics-amp-stories-to-hypotheses-and-problem-statements-shifting-to-outcomes \"hat darauf hingewiesen\"), dass sich die Diskussion um Epics oftmals in Definitionen und Begriffserklärungen erschöpft. Wenn du den Begriff in eine Suchmaschine eingibst, wirst du in der Regel eine Vielzahl von Artikeln finden, die den Sachverhalt eher verkomplizieren.\n\nDabei lässt sich die Frage, was ein Epic ist, eigentlich ganz einfach beantworten: Sie unterstützen dich dabei, deine Visionen, die gerade in der Softwareentwicklung recht komplex sein können, so zu gliedern, dass sie sich Schritt für Schritt bewältigen lassen – und dabei schneller als traditionelle Methoden, wie z. B. dem Wasserfallmodell, zu marktfähigen Produkten führen.\n\nDas eigentliche Ziel besteht für Murphy darin, „unsere gewünschten Ergebnisse zu definieren, Experimente anzudenken oder auch schlicht und einfach unsere Nutzer(innen) besser zu verstehen.“\n\n## Denke Top-Down\n\nEntscheidend für eine gelungene Verwendung von Epics ist, Top-Down zu denken. Epics sind selbst eigenständige Ziele, die allerdings in kleinere Abschnitte aufgeteilt werden können und müssen.\n\nEs geht also weniger darum, penibel alle Epic Stories umzusetzen. Was zählt ist vielmehr, dass das Hauptziel erreicht wird – beispielsweise die Veröffentlichung eines neuen Features. So erlauben Epics eine bessere Einschätzung, welche User Stories wirklich relevant sind und welche unter Umständen ausgelassen werden können.\n\nDiese Top-Down-Sicht erlaubt es uns auch, die oftmals verwirrende Flut an Definitionen verständlich zu machen, die Epics umgibt. Dabei fallen häufig Begriffe wie „Themes“, „Initiatives“ oder „Milestones“. Nur wie lassen sich diese Begriffe voneinander abgrenzen?\n\n## Begrifflichkeiten: Themes, Initiatives, Epics, User Stories, Story Tasks\n\nDer Erfolg eines Unternehmens gerade in der Softwareentwicklung besteht darin, ein Gleichgewicht zwischen langfristigen Richtungsentscheidungen und einem schnellen, agilen Reagieren auf kurzfristige Entwicklungen zu erreichen.\n\nDer Zeithorizont entscheidet in der Regel, welcher Begriff in einem gegebenen Kontext der passendste ist:\n- Auf höchster Managementebene werden die grundlegenden Visionen mit sogenannten *Themes* vorgegeben, deren Zeithorizont sich auf mehrere Jahre erstrecken kann.\n- Themes werden durch die Umsetzung komplexer mittelfristiger Ziele – den *Initiatives* - erreicht.\n- *Epics* befinden sich auf der Ebene darunter und beschreiben in der Regel Projekte mit einer Laufzeit von circa sechs Monaten bis zu einem Jahr.\n- *User Stories* wiederum werden, beispielsweise in Scrum, durch iterative Zyklen von zweiwöchentlichen Sprints abgebildet.\n- Zur praktischen Umsetzung einer User Story werden konkrete Aufgaben – Tasks – an die Teams delegiert.\n\nZwischen diesen Ebenen findet eine ständige Kommunikation statt, so dass die Planung zwar von oben nach unten verläuft, aber dabei stets Rückmeldungen von unten in die zukünftige Aufgabenverteilung mit einbezogen werden.\n\n## Was ist ein Child Epic in GitLab? \n\nIm Zusammenhang mit GitLab Epics fällt auch oftmals der Begriff „Child Epic“. In GitLab bezeichnet er eine Unterkategorie, die unter der Ebene einer User Story ansetzt.\n\nHintergrund ist, dass auch manche User Stories mehrere Sprints umfassen und gelegentlich in verschiedene, kleinere Story Tasks aufgeteilt werden können. Um ein höheres Maß an Transparenz zu erreichen, können Child Epics Aufgaben kennzeichnen, die idealerweise in einem einzigen oder vielleicht zwei Sprints bewältigt werden können.\n\nSo helfen Child Epics dabei, einer noch genauere zeitliche Planung zu erreichen.\n\n## Alternative Sichtweisen auf Epics\n\nZwar empfiehlt es sich in der Regel, Epics Top-Down zu strukturieren. Alternativ kannst du Epics aber auch nutzen, um bestehende Aufgaben zu bündeln und so deine inneren betrieblichen Abläufe kohärenter zu gestalten oder neue Verbindungen zwischen scheinbar isolierten Abteilungen herzustellen.\n\nStell dir vor,Kundenkontakte werden von verschiedenen Abteilungen getrennt gepflegt. Dann kannst du ein Epic schaffen, mit dem du diese Aktivitäten zusammenführst. Besucher der Homepage können dann beispielsweise Leistungen und Produkte bewerten, Kommentare abgeben und direktes Feedback per E-Mail versenden. Diese Rückmeldungen werden an alle Teams weitergeleitet, gemeinsam diskutiert und eventuelle Optimierungen im Verbund entwickelt und umgesetzt.\n\nZudem können Epics auch im Rahmen von Themes entstehen, also aus einer visionären Planung heraus. Hierbei findet die Top-Down-Organisation eine Ebene höher statt und die Epics folgen ihr.\n\n## Epics: Beispiele aus der Scrum-Praxis\n\nEpics finden überall dort Anwendung, wo Teams kollaborativ und mit einem klaren Endziel an einem umfangreichen Projekt arbeiten.\n\nSehen wir uns einige Beispiele für agile Epics aus der Scrum-Praxis an:\n\n- Ein Unternehmen aus dem Bankbereich bittet dich, die bestehende Website um einen Mitgliederbereich zu ergänzen, auf dem Kund(inn)en deine Ressourcen visuell darstellen und verschiedene finanzielle Szenarien durchspielen können.\n- Die Geschäftsleitung deiner Firma hat die Vorgabe gemacht, die Umsätze in diesem Jahr um 10 % zu steigern. Dazu benötigst du präzisere Daten für deine strategische Planung. Aus diesem Grund arbeitest du gemeinsam mit den anderen Abteilungen an einem System zur Datenerfassung.\n- Du betreibst einen Onlineshop für Yoga-Produkte. Eine mobileApp soll Kund(inn)en aktuelle Produktneuheiten und Angebote direkt auf ihr Smartphone liefern und sie mit Informationen und Tipps zu deiner Yoga-Praxis längerfristig binden.\n\nEs lässt sich bei diesen Epics-Beispielen recht eindeutig erkennen, dass es sich hier nicht um einfache User Stories handelt, sondern um umfangreiche Projekte, die auf ein fassbares Endprodukt ausgerichtet sind.\n\nIn dem folgenden Video findest du eine noch detailliertere Betrachtungsweise, die zeigt, wie du in GitLab konkret Projekte mit Epics planen und aktualisieren kannst:\n\n\u003Ciframe width=\"760\" height=\"515\" src=\"https://www.youtube.com/embed/9W4oxjdAwUs?si=mV_ru2ExQ0SNRdC_\" title=\"YouTube video player\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen>\u003C/iframe>\n\n## Wie tragen Epics zur Agile-Methodologie bei?\n\nDie Aufteilung deiner Ziele in Themes, Initiatives, Epics und User Stories ist für die Umsetzung einer agilen Entwicklung unerlässlich.\n\nDas Prinzip agiler Entwicklung besteht darin, durch das kontinuierliche praktische Testen der Software in enger Zusammenarbeit mit Kund(inn)en schneller Produkte zu entwickeln, die den gewünschten Anforderungen in höherem Maße entsprechen.\n\nEpics tragen dazu in mehrfacher Hinsicht bei:\n- Auf höchster Ebene fördern agile Epics, um ein zentrales Beispiel zu nennen, *langfristiges strategisches Denken*.\n- Epics lassen sich ganz natürlich in *direkt umsetzbare Tasks* auffächern.\n- Indem du das Ziel in kleinere Schritte aufteilst, erreichst du weitaus schneller testbare *Zwischenstufen des Produkts*, sogenannte Minimum Viable Products, MVPs.\n- Indem du das Ziel gliederst und eine Hierarchie aufstellst, sorgst du für *Transparenz*. Umso transparenter der Prozess, umso leichter lassen sich die Ergebnisse erfassen und auswerten.\n- Epics unterstützen die Zusammenarbeit zwischen verschiedenen Abteilungen in deinem Unternehmen sowie zwischen dir und den Kund(inn)en.\n- Epics tragen dazu bei, *Prioritäten* zu setzen und die Arbeitslast darauf zu beschränken, was du wirklich umsetzen kannst.\n- Den richtigen Teams ausreichende Ressourcen zukommen zu lassen ist für die Zielerreichung von höchster Bedeutung. Auch hier erlaubt der modulare Charakter von Epics eine *präzise Ressourcenallokation*.\n- Epics sollten stets ein eindeutiges Enddatum haben. Sie sollen zu fassbaren Ergebnissen führen und innerhalb eines klar definierten Zeitraums beendet sein. Anders gesagt: Wenn deine User Story nicht eindeutig abgeschlossen werden kann, handelt es sich dabei nicht um ein Epic. Diese *Produktfokussierung* ist für Unternehmen sowohl intern als auch extern ein entscheidender Vorteil.\n\n## Epics und MVPs\n\nMVPs sind eine der Schlüsselkomponenten der agilen Methodologie: Mit ihnen lassen sich Ergebnisse von Sprints in Scrum den Kundinnen und Kunden mit einem funktionsfähigen Produkt anschaulich demonstrieren.\nMit Scrum Epics zu arbeiten bedeutet, kontinuierlich auf MVPs hinzuarbeiten. Denn jede User Story entspricht hier in der Regel einem Feature des zu entwickelnden Produkts.\n\nVor allem maximieren Scrum Epics eine der wichtigsten Vorteile von MVPs, der Optimierung der [Flow-Effizienz](https://fourweekmba.com/de/Str%C3%B6mungseffizienz/ \"Flow-Effizienz\") (auch: Durchflusseffizienz, Strömungseffizienz), also der Zeit, in der produktiv und ohne Wartepausen an der Entwicklung gearbeitet werden kann.\n\nDas Epic koordiniert dabei als übergeordnetes Ziel die Aktivitäten verschiedener Teams und sorgt so dafür, dass Tasks nicht linear abgearbeitet werden (eine der zentralen Schwächen des Wasserfallmodells), sondern parallel (eine der zentralen Stärken der agilen Philosophie).\n\n## Den Erfolg von Epics messen\n\nDie Philosophie von agile beruht auf der Überzeugung, dass es besser ist, ein Produkt wiederholt praxisnah zu testen, als es auf dem Papier durchzuplanen. Epics sind ein zentraler Baustein einer agilen Entwicklungsstrategie und so kann ihre Umsetzung nur gelingen, wenn sie ständig daran gemessen werden, ob der aktuelle Stand dich deinem Ziel näher bringt.\n\n Zu diesem Zweck lassen sich Epics in einem „Epic Burndown Report“ abbilden. Diese Berichte, auch als „[Epic Burndown Chart](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html \"Epic Burndown Chart\")“ bezeichnet, vergleichen die ursprünglichen Einschätzungen zum Erreichen der gewünschten Ziele zu Anfang eines Sprints mit der geleisteten Arbeit und den dabei konkret erreichten Ergebnissen am Ende des Sprints. So kommst du ständig zu aktualisierten Prognosen zum (noch) erforderlichen Aufwand und Ressourceneinsatz.\n\n Burndown-Reports sind dynamisch und werden ständig um neue Arbeitsschritte ergänzt. Mit ihnen lässt sich der Erfolg von Epics hervorragend kontinuierlich erfassen und die zukünftigen Aktionen können besser abgeleitet werden.\n\n## Epics: Best Practises\n\nEs gibt eine Vielzahl von Empfehlungen, wie du Epics in der Softwareentwicklung optimal nutzen kannst. Wir haben die wichtigsten Empfehlungen für dich zusammengestellt:\n\n- Beginne so früh wie möglich mit der Planung eines Epics, so dass alle benötigten Informationen zur Verfügung stehen.\n- Beziehe alle betroffenen Abteilungen sowie Kund(inn)en mit ein.\n- Setze einen klar definierten Zeitraum an.\n- Beschränke die Zahl der User Stories, die zum Erreichen des Epics benötigt werden. Umso geringer diese Zahl, um so übersichtlicher bleibt die Planung und umso schneller gelangst du zum MVP. Statt also einem perfekten Produkt nachzujagen, setze um, was zu diesem Zeitpunkt machbar ist – und schaffe dann für die nächste Version ein neues Epic.\n- Bleibe flexibel und sei bereit, das Epic grundlegend anzupassen, wenn Praxis-Feedback dies nahelegt.\n\n## GitLab Epics und DevSecOps\n\nEpics und DevOps gehören selbstverständlich zusammen. Doch es empfiehlt sich, darüber hinaus auch noch den Sicherheitsaspekt zu berücksichtigen.\n\nDenn Sicherheitslücken stellen für jede Software und jedes neue Feature ein entscheidendes Risiko dar. Sie zu schließen gelingt weitaus besser, wenn du bei jedem Schritt auf dem Weg zum fertigen Produkt die Sicherheit des Systems mit berücksichtigt und an die Anforderungen anpasst.\n\nGitLab ist die führende DevSecOps-Plattform und unterstützt den Einsatz von Epics sowohl zum Planen als auch im Hinblick auf das Thema Security. In diesem Artikel erfährst du mehr darüber, wie GitLab dich als [KI-gestützte DevSecOps-Plattform](https://about.gitlab.com/de-de/platform/ \"KI-gestützte DevSecOps-Plattform\") unterstützen kann.\n","agile-planning",[682,9],{"slug":893,"featured":6,"template":688},"agile-epics-in-gitlab","content:de-de:blog:agile-epics-in-gitlab.yml","Agile Epics In Gitlab","de-de/blog/agile-epics-in-gitlab.yml","de-de/blog/agile-epics-in-gitlab",2,[665,693,718,741,765,790,815,838,857],1758662401766]