[{"data":1,"prerenderedAt":825},["ShallowReactive",2],{"/de-de/blog/categories/devsecops/":3,"navigation-de-de":22,"banner-de-de":443,"footer-de-de":456,"devsecops-category-page-de-de":665},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":12,"_id":15,"_type":16,"title":17,"_source":18,"_file":19,"_stem":20,"_extension":21},"/de-de/blog/categories/devsecops","categories",false,"",{"title":9,"description":10},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":9},{"template":13,"slug":14,"hide":6},"BlogCategory","devsecops","content:de-de:blog:categories:devsecops.yml","yaml","Devsecops","content","de-de/blog/categories/devsecops.yml","de-de/blog/categories/devsecops","yml",{"_path":23,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":25,"_id":439,"_type":16,"title":440,"_source":18,"_file":441,"_stem":442,"_extension":21},"/shared/de-de/main-navigation","de-de",{"logo":26,"freeTrial":31,"sales":36,"login":41,"items":46,"search":380,"minimal":416,"duo":430},{"config":27},{"href":28,"dataGaName":29,"dataGaLocation":30},"/de-de/","gitlab logo","header",{"text":32,"config":33},"Kostenlose Testversion anfordern",{"href":34,"dataGaName":35,"dataGaLocation":30},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":37,"config":38},"Vertrieb kontaktieren",{"href":39,"dataGaName":40,"dataGaLocation":30},"/de-de/sales/","sales",{"text":42,"config":43},"Anmelden",{"href":44,"dataGaName":45,"dataGaLocation":30},"https://gitlab.com/users/sign_in/","sign in",[47,91,190,195,301,361],{"text":48,"config":49,"cards":51,"footer":74},"Plattform",{"dataNavLevelOne":50},"platform",[52,58,66],{"title":48,"description":53,"link":54},"Die umfassendste KI-basierte DevSecOps-Plattform",{"text":55,"config":56},"Erkunde unsere Plattform",{"href":57,"dataGaName":50,"dataGaLocation":30},"/de-de/platform/",{"title":59,"description":60,"link":61},"GitLab Duo (KI)","Entwickle Software schneller mit KI in jeder Phase der Entwicklung",{"text":62,"config":63},"Lerne GitLab Duo kennen",{"href":64,"dataGaName":65,"dataGaLocation":30},"/de-de/gitlab-duo/","gitlab duo ai",{"title":67,"description":68,"link":69},"Gründe, die für GitLab sprechen","10 Gründe, warum Unternehmen sich für GitLab entscheiden",{"text":70,"config":71},"Mehr erfahren",{"href":72,"dataGaName":73,"dataGaLocation":30},"/de-de/why-gitlab/","why gitlab",{"title":75,"items":76},"Erste Schritte mit",[77,82,87],{"text":78,"config":79},"Platform Engineering",{"href":80,"dataGaName":81,"dataGaLocation":30},"/de-de/solutions/platform-engineering/","platform engineering",{"text":83,"config":84},"Entwicklererfahrung",{"href":85,"dataGaName":86,"dataGaLocation":30},"/de-de/developer-experience/","Developer experience",{"text":88,"config":89},"MLOps",{"href":90,"dataGaName":88,"dataGaLocation":30},"/de-de/topics/devops/the-role-of-ai-in-devops/",{"text":92,"left":93,"config":94,"link":96,"lists":100,"footer":172},"Produkt",true,{"dataNavLevelOne":95},"solutions",{"text":97,"config":98},"Alle Lösungen anzeigen",{"href":99,"dataGaName":95,"dataGaLocation":30},"/de-de/solutions/",[101,127,150],{"title":102,"description":103,"link":104,"items":109},"Automatisierung","CI/CD und Automatisierung zur Beschleunigung der Bereitstellung",{"config":105},{"icon":106,"href":107,"dataGaName":108,"dataGaLocation":30},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[110,114,118,123],{"text":111,"config":112},"CI/CD",{"href":113,"dataGaLocation":30,"dataGaName":111},"/de-de/solutions/continuous-integration/",{"text":115,"config":116},"KI-unterstützte Entwicklung",{"href":64,"dataGaLocation":30,"dataGaName":117},"AI assisted development",{"text":119,"config":120},"Quellcodeverwaltung",{"href":121,"dataGaLocation":30,"dataGaName":122},"/de-de/solutions/source-code-management/","Source Code Management",{"text":124,"config":125},"Automatisierte Softwarebereitstellung",{"href":107,"dataGaLocation":30,"dataGaName":126},"Automated software delivery",{"title":128,"description":129,"link":130,"items":135},"Sicherheit","Entwickle schneller, ohne die Sicherheit zu gefährden",{"config":131},{"href":132,"dataGaName":133,"dataGaLocation":30,"icon":134},"/de-de/solutions/security-compliance/","security and compliance","ShieldCheckLight",[136,141,146],{"text":137,"config":138},"Application Security Testing",{"href":139,"dataGaName":140,"dataGaLocation":30},"/solutions/application-security-testing/","Application security testing",{"text":142,"config":143},"Schutz der Software-Lieferkette",{"href":144,"dataGaLocation":30,"dataGaName":145},"/de-de/solutions/supply-chain/","Software supply chain security",{"text":147,"config":148},"Software Compliance",{"href":149,"dataGaName":147,"dataGaLocation":30},"/solutions/software-compliance/",{"title":151,"link":152,"items":157},"Bewertung",{"config":153},{"icon":154,"href":155,"dataGaName":156,"dataGaLocation":30},"DigitalTransformation","/de-de/solutions/visibility-measurement/","visibility and measurement",[158,162,167],{"text":159,"config":160},"Sichtbarkeit und Bewertung",{"href":155,"dataGaLocation":30,"dataGaName":161},"Visibility and Measurement",{"text":163,"config":164},"Wertstrommanagement",{"href":165,"dataGaLocation":30,"dataGaName":166},"/de-de/solutions/value-stream-management/","Value Stream Management",{"text":168,"config":169},"Analysen und Einblicke",{"href":170,"dataGaLocation":30,"dataGaName":171},"/de-de/solutions/analytics-and-insights/","Analytics and insights",{"title":173,"items":174},"GitLab für",[175,180,185],{"text":176,"config":177},"Enterprise",{"href":178,"dataGaLocation":30,"dataGaName":179},"/de-de/enterprise/","enterprise",{"text":181,"config":182},"Kleinunternehmen",{"href":183,"dataGaLocation":30,"dataGaName":184},"/de-de/small-business/","small business",{"text":186,"config":187},"den öffentlichen Sektor",{"href":188,"dataGaLocation":30,"dataGaName":189},"/de-de/solutions/public-sector/","public sector",{"text":191,"config":192},"Preise",{"href":193,"dataGaName":194,"dataGaLocation":30,"dataNavLevelOne":194},"/de-de/pricing/","pricing",{"text":196,"config":197,"link":199,"lists":203,"feature":288},"Ressourcen",{"dataNavLevelOne":198},"resources",{"text":200,"config":201},"Alle Ressourcen anzeigen",{"href":202,"dataGaName":198,"dataGaLocation":30},"/de-de/resources/",[204,237,260],{"title":205,"items":206},"Erste Schritte",[207,212,217,222,227,232],{"text":208,"config":209},"Installieren",{"href":210,"dataGaName":211,"dataGaLocation":30},"/de-de/install/","install",{"text":213,"config":214},"Kurzanleitungen",{"href":215,"dataGaName":216,"dataGaLocation":30},"/de-de/get-started/","quick setup checklists",{"text":218,"config":219},"Lernen",{"href":220,"dataGaLocation":30,"dataGaName":221},"https://university.gitlab.com/","learn",{"text":223,"config":224},"Produktdokumentation",{"href":225,"dataGaName":226,"dataGaLocation":30},"https://docs.gitlab.com/","product documentation",{"text":228,"config":229},"Best-Practice-Videos",{"href":230,"dataGaName":231,"dataGaLocation":30},"/de-de/getting-started-videos/","best practice videos",{"text":233,"config":234},"Integrationen",{"href":235,"dataGaName":236,"dataGaLocation":30},"/de-de/integrations/","integrations",{"title":238,"items":239},"Entdecken",[240,245,250,255],{"text":241,"config":242},"Kundenerfolge",{"href":243,"dataGaName":244,"dataGaLocation":30},"/de-de/customers/","customer success stories",{"text":246,"config":247},"Blog",{"href":248,"dataGaName":249,"dataGaLocation":30},"/de-de/blog/","blog",{"text":251,"config":252},"Remote",{"href":253,"dataGaName":254,"dataGaLocation":30},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":256,"config":257},"TeamOps",{"href":258,"dataGaName":259,"dataGaLocation":30},"/de-de/teamops/","teamops",{"title":261,"items":262},"Vernetzen",[263,268,273,278,283],{"text":264,"config":265},"GitLab-Services",{"href":266,"dataGaName":267,"dataGaLocation":30},"/de-de/services/","services",{"text":269,"config":270},"Community",{"href":271,"dataGaName":272,"dataGaLocation":30},"/community/","community",{"text":274,"config":275},"Forum",{"href":276,"dataGaName":277,"dataGaLocation":30},"https://forum.gitlab.com/","forum",{"text":279,"config":280},"Veranstaltungen",{"href":281,"dataGaName":282,"dataGaLocation":30},"/events/","events",{"text":284,"config":285},"Partner",{"href":286,"dataGaName":287,"dataGaLocation":30},"/partners/","partners",{"backgroundColor":289,"textColor":290,"text":291,"image":292,"link":296},"#2f2a6b","#fff","Perspektiven für die Softwareentwicklung der Zukunft",{"altText":293,"config":294},"the source promo card",{"src":295},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":297,"config":298},"Lies die News",{"href":299,"dataGaName":300,"dataGaLocation":30},"/de-de/the-source/","the source",{"text":302,"config":303,"lists":305},"Unternehmen",{"dataNavLevelOne":304},"company",[306],{"items":307},[308,313,319,321,326,331,336,341,346,351,356],{"text":309,"config":310},"Über",{"href":311,"dataGaName":312,"dataGaLocation":30},"/de-de/company/","about",{"text":314,"config":315,"footerGa":318},"Karriere",{"href":316,"dataGaName":317,"dataGaLocation":30},"/jobs/","jobs",{"dataGaName":317},{"text":279,"config":320},{"href":281,"dataGaName":282,"dataGaLocation":30},{"text":322,"config":323},"Geschäftsführung",{"href":324,"dataGaName":325,"dataGaLocation":30},"/company/team/e-group/","leadership",{"text":327,"config":328},"Team",{"href":329,"dataGaName":330,"dataGaLocation":30},"/company/team/","team",{"text":332,"config":333},"Handbuch",{"href":334,"dataGaName":335,"dataGaLocation":30},"https://handbook.gitlab.com/","handbook",{"text":337,"config":338},"Investor Relations",{"href":339,"dataGaName":340,"dataGaLocation":30},"https://ir.gitlab.com/","investor relations",{"text":342,"config":343},"Trust Center",{"href":344,"dataGaName":345,"dataGaLocation":30},"/de-de/security/","trust center",{"text":347,"config":348},"AI Transparency Center",{"href":349,"dataGaName":350,"dataGaLocation":30},"/de-de/ai-transparency-center/","ai transparency center",{"text":352,"config":353},"Newsletter",{"href":354,"dataGaName":355,"dataGaLocation":30},"/company/contact/","newsletter",{"text":357,"config":358},"Presse",{"href":359,"dataGaName":360,"dataGaLocation":30},"/press/","press",{"text":362,"config":363,"lists":364},"Kontakt",{"dataNavLevelOne":304},[365],{"items":366},[367,370,375],{"text":37,"config":368},{"href":39,"dataGaName":369,"dataGaLocation":30},"talk to sales",{"text":371,"config":372},"Support",{"href":373,"dataGaName":374,"dataGaLocation":30},"/support/","get help",{"text":376,"config":377},"Kundenportal",{"href":378,"dataGaName":379,"dataGaLocation":30},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":381,"login":382,"suggestions":389},"Schließen",{"text":383,"link":384},"Um Repositories und Projekte zu durchsuchen, melde dich an bei",{"text":385,"config":386},"gitlab.com",{"href":44,"dataGaName":387,"dataGaLocation":388},"search login","search",{"text":390,"default":391},"Vorschläge",[392,395,400,402,407,412],{"text":59,"config":393},{"href":64,"dataGaName":394,"dataGaLocation":388},"GitLab Duo (AI)",{"text":396,"config":397},"Code Suggestions (KI)",{"href":398,"dataGaName":399,"dataGaLocation":388},"/de-de/solutions/code-suggestions/","Code Suggestions (AI)",{"text":111,"config":401},{"href":113,"dataGaName":111,"dataGaLocation":388},{"text":403,"config":404},"GitLab auf AWS",{"href":405,"dataGaName":406,"dataGaLocation":388},"/de-de/partners/technology-partners/aws/","GitLab on AWS",{"text":408,"config":409},"GitLab auf Google Cloud",{"href":410,"dataGaName":411,"dataGaLocation":388},"/de-de/partners/technology-partners/google-cloud-platform/","GitLab on Google Cloud",{"text":413,"config":414},"Warum GitLab?",{"href":72,"dataGaName":415,"dataGaLocation":388},"Why GitLab?",{"freeTrial":417,"mobileIcon":422,"desktopIcon":427},{"text":418,"config":419},"Kostenlos testen",{"href":420,"dataGaName":35,"dataGaLocation":421},"https://gitlab.com/-/trials/new/","nav",{"altText":423,"config":424},"GitLab-Symbol",{"src":425,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":423,"config":428},{"src":429,"dataGaName":426,"dataGaLocation":421},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":431,"mobileIcon":435,"desktopIcon":437},{"text":432,"config":433},"Erfahre mehr über GitLab Duo",{"href":64,"dataGaName":434,"dataGaLocation":421},"gitlab duo",{"altText":423,"config":436},{"src":425,"dataGaName":426,"dataGaLocation":421},{"altText":423,"config":438},{"src":429,"dataGaName":426,"dataGaLocation":421},"content:shared:de-de:main-navigation.yml","Main Navigation","shared/de-de/main-navigation.yml","shared/de-de/main-navigation",{"_path":444,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"title":445,"button":446,"config":451,"_id":453,"_type":16,"_source":18,"_file":454,"_stem":455,"_extension":21},"/shared/de-de/banner","GitLab Duo Agent Platform ist jetzt in öffentlicher Beta!",{"text":447,"config":448},"Beta testen",{"href":449,"dataGaName":450,"dataGaLocation":30},"/de-de/gitlab-duo/agent-platform/","duo banner",{"layout":452},"release","content:shared:de-de:banner.yml","shared/de-de/banner.yml","shared/de-de/banner",{"_path":457,"_dir":24,"_draft":6,"_partial":6,"_locale":7,"data":458,"_id":661,"_type":16,"title":662,"_source":18,"_file":663,"_stem":664,"_extension":21},"/shared/de-de/main-footer",{"text":459,"source":460,"edit":466,"contribute":471,"config":476,"items":481,"minimal":653},"Git ist eine Marke von Software Freedom Conservancy und unsere Verwendung von „GitLab“ erfolgt unter Lizenz.",{"text":461,"config":462},"Quelltext der Seite anzeigen",{"href":463,"dataGaName":464,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":467,"config":468},"Diese Seite bearbeiten",{"href":469,"dataGaName":470,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":472,"config":473},"Beteilige dich",{"href":474,"dataGaName":475,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":477,"facebook":478,"youtube":479,"linkedin":480},"https://x.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[482,505,560,589,623],{"title":48,"links":483,"subMenu":488},[484],{"text":485,"config":486},"DevSecOps-Plattform",{"href":57,"dataGaName":487,"dataGaLocation":465},"devsecops platform",[489],{"title":191,"links":490},[491,495,500],{"text":492,"config":493},"Tarife anzeigen",{"href":193,"dataGaName":494,"dataGaLocation":465},"view plans",{"text":496,"config":497},"Vorteile von Premium",{"href":498,"dataGaName":499,"dataGaLocation":465},"/de-de/pricing/premium/","why premium",{"text":501,"config":502},"Vorteile von Ultimate",{"href":503,"dataGaName":504,"dataGaLocation":465},"/de-de/pricing/ultimate/","why ultimate",{"title":506,"links":507},"Lösungen",[508,513,516,518,523,528,532,535,538,543,545,547,550,555],{"text":509,"config":510},"Digitale Transformation",{"href":511,"dataGaName":512,"dataGaLocation":465},"/de-de/topics/digital-transformation/","digital transformation",{"text":514,"config":515},"Sicherheit und Compliance",{"href":139,"dataGaName":140,"dataGaLocation":465},{"text":124,"config":517},{"href":107,"dataGaName":108,"dataGaLocation":465},{"text":519,"config":520},"Agile Entwicklung",{"href":521,"dataGaName":522,"dataGaLocation":465},"/de-de/solutions/agile-delivery/","agile delivery",{"text":524,"config":525},"Cloud-Transformation",{"href":526,"dataGaName":527,"dataGaLocation":465},"/de-de/topics/cloud-native/","cloud transformation",{"text":529,"config":530},"SCM",{"href":121,"dataGaName":531,"dataGaLocation":465},"source code management",{"text":111,"config":533},{"href":113,"dataGaName":534,"dataGaLocation":465},"continuous integration & delivery",{"text":163,"config":536},{"href":165,"dataGaName":537,"dataGaLocation":465},"value stream management",{"text":539,"config":540},"GitOps",{"href":541,"dataGaName":542,"dataGaLocation":465},"/de-de/solutions/gitops/","gitops",{"text":176,"config":544},{"href":178,"dataGaName":179,"dataGaLocation":465},{"text":181,"config":546},{"href":183,"dataGaName":184,"dataGaLocation":465},{"text":548,"config":549},"Öffentlicher Sektor",{"href":188,"dataGaName":189,"dataGaLocation":465},{"text":551,"config":552},"Bildungswesen",{"href":553,"dataGaName":554,"dataGaLocation":465},"/de-de/solutions/education/","education",{"text":556,"config":557},"Finanzdienstleistungen",{"href":558,"dataGaName":559,"dataGaLocation":465},"/de-de/solutions/finance/","financial services",{"title":196,"links":561},[562,564,566,568,571,573,575,577,579,581,583,585,587],{"text":208,"config":563},{"href":210,"dataGaName":211,"dataGaLocation":465},{"text":213,"config":565},{"href":215,"dataGaName":216,"dataGaLocation":465},{"text":218,"config":567},{"href":220,"dataGaName":221,"dataGaLocation":465},{"text":223,"config":569},{"href":225,"dataGaName":570,"dataGaLocation":465},"docs",{"text":246,"config":572},{"href":248,"dataGaName":249,"dataGaLocation":465},{"text":241,"config":574},{"href":243,"dataGaName":244,"dataGaLocation":465},{"text":251,"config":576},{"href":253,"dataGaName":254,"dataGaLocation":465},{"text":264,"config":578},{"href":266,"dataGaName":267,"dataGaLocation":465},{"text":256,"config":580},{"href":258,"dataGaName":259,"dataGaLocation":465},{"text":269,"config":582},{"href":271,"dataGaName":272,"dataGaLocation":465},{"text":274,"config":584},{"href":276,"dataGaName":277,"dataGaLocation":465},{"text":279,"config":586},{"href":281,"dataGaName":282,"dataGaLocation":465},{"text":284,"config":588},{"href":286,"dataGaName":287,"dataGaLocation":465},{"title":302,"links":590},[591,593,595,597,599,601,603,607,612,614,616,618],{"text":309,"config":592},{"href":311,"dataGaName":304,"dataGaLocation":465},{"text":314,"config":594},{"href":316,"dataGaName":317,"dataGaLocation":465},{"text":322,"config":596},{"href":324,"dataGaName":325,"dataGaLocation":465},{"text":327,"config":598},{"href":329,"dataGaName":330,"dataGaLocation":465},{"text":332,"config":600},{"href":334,"dataGaName":335,"dataGaLocation":465},{"text":337,"config":602},{"href":339,"dataGaName":340,"dataGaLocation":465},{"text":604,"config":605},"Sustainability",{"href":606,"dataGaName":604,"dataGaLocation":465},"/sustainability/",{"text":608,"config":609},"Vielfalt, Inklusion und Zugehörigkeit",{"href":610,"dataGaName":611,"dataGaLocation":465},"/de-de/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":342,"config":613},{"href":344,"dataGaName":345,"dataGaLocation":465},{"text":352,"config":615},{"href":354,"dataGaName":355,"dataGaLocation":465},{"text":357,"config":617},{"href":359,"dataGaName":360,"dataGaLocation":465},{"text":619,"config":620},"Transparenzerklärung zu moderner Sklaverei",{"href":621,"dataGaName":622,"dataGaLocation":465},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":624,"links":625},"Nimm Kontakt auf",[626,629,631,633,638,643,648],{"text":627,"config":628},"Sprich mit einem Experten/einer Expertin",{"href":39,"dataGaName":40,"dataGaLocation":465},{"text":371,"config":630},{"href":373,"dataGaName":374,"dataGaLocation":465},{"text":376,"config":632},{"href":378,"dataGaName":379,"dataGaLocation":465},{"text":634,"config":635},"Status",{"href":636,"dataGaName":637,"dataGaLocation":465},"https://status.gitlab.com/","status",{"text":639,"config":640},"Nutzungsbedingungen",{"href":641,"dataGaName":642,"dataGaLocation":465},"/terms/","terms of use",{"text":644,"config":645},"Datenschutzerklärung",{"href":646,"dataGaName":647,"dataGaLocation":465},"/de-de/privacy/","privacy statement",{"text":649,"config":650},"Cookie-Einstellungen",{"dataGaName":651,"dataGaLocation":465,"id":652,"isOneTrustButton":93},"cookie preferences","ot-sdk-btn",{"items":654},[655,657,659],{"text":639,"config":656},{"href":641,"dataGaName":642,"dataGaLocation":465},{"text":644,"config":658},{"href":646,"dataGaName":647,"dataGaLocation":465},{"text":649,"config":660},{"dataGaName":651,"dataGaLocation":465,"id":652,"isOneTrustButton":93},"content:shared:de-de:main-footer.yml","Main Footer","shared/de-de/main-footer.yml","shared/de-de/main-footer",{"featuredPost":666,"allPosts":687,"totalPages":823,"initialPosts":824},{"_path":667,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":671,"config":680,"_id":683,"_type":16,"title":684,"_source":18,"_file":685,"_stem":686,"_extension":21},"/de-de/blog/why-now-is-the-time-for-embedded-devsecops",{"noIndex":6,"title":669,"description":670,"ogTitle":669,"ogDescription":670},"Embedded DevSecOps: Warum 2025 der richtige Zeitpunkt ist","Embedded-Teams reduzieren Feedback-Zyklen von Wochen auf Stunden. Lerne, wie DevSecOps manuelle Compliance automatisiert und Innovation beschleunigt.",{"heroImage":672,"body":673,"authors":674,"updatedDate":7,"date":676,"title":677,"tags":678,"description":679,"category":14},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,w_1640,h_1000,c_lfill/v1749659978/Blog/Hero%20Images/automation.png","Für Embedded-Systeme-Teams schien DevSecOps traditionell eher ein Ansatz für SaaS-Anwendungen als für die Firmware-Entwicklung zu sein. Aber das ändert sich. Software ist jetzt ein primärer Differenzierungsfaktor bei Hardwareprodukten. Neue Erwartungen der Marktteilnehmer erfordern moderne Entwicklungspraktiken. Als Reaktion darauf verfolgen Unternehmen \"Embedded DevSecOps\".\n\nWas ist Embedded DevSecOps? Die Anwendung kollaborativer Engineering-Praktiken, integrierter Toolchains und Automatisierung für das Erstellen, Testen und Sichern von Software auf die Entwicklung eingebetteter Systeme. Embedded DevSecOps umfasst notwendige Anpassungen für die Hardware-Integration.\n\n## Drei Marktkräfte, welche die Embedded-Entwicklung revolutionieren\n\nDrei mächtige Marktkräfte konvergieren und zwingen Embedded-Teams dazu, ihre Entwicklungspraktiken zu modernisieren.\n\n### 1. Software wird zum primären Differenzierungsfaktor\n\nProdukte, die einst hauptsächlich durch ihre Hardware definiert wurden, unterscheiden sich jetzt durch ihre Softwarefähigkeiten. Der Markt für softwaredefinierte Fahrzeuge (SDV) erzählt in dieser Hinsicht eine überzeugende Geschichte. Er wird voraussichtlich von 213,5 Milliarden US-Dollar im Jahr 2024 auf [1,24 Billionen US-Dollar (Artikel auf Englisch)](https://www.marketsandmarkets.com/Market-Reports/software-defined-vehicles-market-187205966.html) bis 2030 wachsen – eine massive jährliche Wachstumsrate von 34%.\n\nDer Softwareanteil in diesen Produkten wächst erheblich. Bis Ende 2025 wird erwartet, dass das durchschnittliche Fahrzeug [650 Millionen Codezeilen (Artikel auf Englisch)](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/) enthält. Traditionelle Embedded-Entwicklungsansätze können diese Softwarekomplexität nicht bewältigen.\n\n### 2. Hardware-Virtualisierung ermöglicht neue Arbeitsweisen\n\nHardware-Virtualisierung ist ein wichtiger technischer Enabler für Embedded DevSecOps. Virtuelle elektronische Steuergeräte (vECUs), Cloud-basierte ARM-CPUs und anspruchsvolle Simulationsumgebungen werden immer verbreiteter. Virtuelle Hardware ermöglicht Tests, die einst physische Hardware erforderten.\n\nDiese Virtualisierungstechnologien bieten eine Grundlage für Continuous Integration ([CI](https://about.gitlab.com/topics/ci-cd/)). Aber ihr Wert wird nur vollständig realisiert, wenn sie in einen automatisierten Workflow integriert sind. In Kombination mit kollaborativen Entwicklungspraktiken und automatisierten Pipelines helfen virtuelle Tests den Teams, Probleme viel früher zu erkennen, wenn Korrekturen noch viel kostengünstiger sind. Ohne Embedded-DevSecOps-Praktiken und Tools zur Orchestrierung dieser virtuellen Ressourcen können Unternehmen den Virtualisierungstrend nicht nutzen.\n\n### 3. Der Wettbewerbsdruck steigt exponentiell\n\nDrei miteinander verbundene Kräfte gestalten die Wettbewerbslandschaft für die Embedded-Entwicklung neu:\n\n* Der Kampf um die größten Talente hat sich entscheidend verschoben. Wie ein Embedded-Systems-Leader bei einem GitLab-Kunden erklärte: \"Kein Embedded-Ingenieur, der heute vom College kommt, kennt Legacy-Tools wie Perforce. Sie kennen Git. Diese jungen Ingenieure arbeiten sechs Monate in einem Unternehmen mit Legacy-Tools und kündigen dann.\" Unternehmen, die veraltete Tools verwenden, könnten ihre technische Zukunft verlieren.\n* Dieser Vorsprung durch die besten Talente führt zu Wettbewerbsvorteilen. Technologieorientierte Unternehmen, die Top-Ingenieure mit modernen Praktiken anziehen, erzielen bemerkenswerte Ergebnisse. Beispielsweise führte [SpaceX (Artikel auf Englisch)](https://spacenews.com/spacex-launch-surge-helps-set-new-global-launch-record-in-2024/) im Jahr 2024 mehr Orbitalstarts durch als der Rest der Welt zusammen. Technologieorientierte Unternehmen zeichnen sich durch Softwareentwicklung aus und haben eine moderne Entwicklungskultur. Dies schafft unter anderem Effizienzen, die Legacy-Unternehmen nur schwer erreichen können.\n* Die steigenden Kosten der Embedded-Entwicklung – getrieben durch lange Feedback-Zyklen – schaffen einen dringenden Bedarf an Embedded DevSecOps. Wenn Entwickler(innen) wochenlang warten müssen, um Code auf Hardware-Testbänken zu testen, bleibt die Produktivität von Natur aus niedrig. Ingenieur(innen) verlieren den Kontext und müssen den Kontext wechseln, wenn die Ergebnisse eintreffen. Das Problem verschlimmert sich, wenn Fehler ins Spiel kommen. Bugs werden teurer zu beheben, je später sie entdeckt werden. Lange Feedback-Zyklen vergrößern dieses Problem in eingebetteten Systemen.\n\nUnternehmen setzen Embedded DevSecOps ein, um diese Herausforderungen zu bewältigen.\n\n## So setzen führende Unternehmen Embedded DevSecOps um\n\nBasierend auf diesen Marktkräften implementieren zukunftsorientierte Embedded-Systems-Leader Embedded DevSecOps auf folgende Weise.\n\n### Hardware-Tests automatisieren und beschleunigen\n\nHardware-Test-Engpässe stellen eine der bedeutendsten Einschränkungen in der traditionellen Embedded-Entwicklung dar. Diese Verzögerungen schaffen die zuvor beschriebene ungünstige Wirtschaftlichkeit – wenn Entwickler(innen) wochenlang auf Hardware-Zugriff warten, steigen die Fehlerkosten spiralförmig an.\n\nDie Bewältigung dieser Herausforderung erfordert einen facettenreichen Ansatz, einschließlich:\n\n* Automatisierung der Orchestrierung teurer gemeinsam genutzter Hardware-Testbänke unter Embedded-Entwickler(inne)n\n* Integration sowohl von SIL (Software-in-the-Loop) als auch HIL (Hardware-in-the-Loop) Tests in automatisierte CI-Pipelines\n* Standardisierung von Builds mit versionskontrollierten Umgebungen\n\nEmbedded-Entwickler(innen) können dies mit GitLabs [On-Premises Device Cloud (Seite auf Englisch)](https://gitlab.com/gitlab-accelerates-embedded/comp/device-cloud) erreichen, einer CI/CD-Komponente. Durch die Automatisierung der Orchestrierung von Firmware-Tests auf virtueller und realer Hardware sind Teams besser positioniert, um Feedback-Zyklen von Wochen auf Stunden zu reduzieren. Sie können auch mehr Bugs früh im Software-Entwicklungslebenszyklus erkennen.\n\n### Automatisierung von Compliance und Security Governance\n\nEingebettete Systeme unterliegen strengen regulatorischen Anforderungen. Manuelle Compliance-Prozesse sind nicht nachhaltig.\n\nFührende Unternehmen transformieren die Art und Weise, wie sie diese Anforderungen erfüllen, durch:\n\n* Ersetzen manueller Workflows durch automatisierte [Compliance-Frameworks](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)\n* Integration spezialisierter Funktionssicherheits-, Sicherheits- und Code-Qualitäts-Tools in automatisierte Continuous-Integration-Pipelines\n* Automatisierung von Genehmigungsworkflows, Durchsetzung von Code-Reviews und Pflege von Audit-Trails\n* Konfiguration von Compliance-Frameworks für spezifische Standards wie ISO 26262 oder DO-178C\n\nDieser Ansatz ermöglicht eine höhere Compliance-Reife ohne zusätzliches Personal – was einst eine Last war, wird zu einem Wettbewerbsvorteil. Ein führender Hersteller von Elektrofahrzeugen (EV) führt mit GitLab täglich 120.000 CI/CD-Jobs aus, von denen viele Compliance-Prüfungen beinhalten. Und sie können Fehlerbehebungen innerhalb einer Stunde nach der Entdeckung beheben und in Fahrzeuge bereitstellen. Dieses Maß an Skalierung und Geschwindigkeit wäre ohne automatisierte Compliance-Workflows extrem schwierig.\n\n### Compliance-Prozesse in CI/CD-Pipelines integrieren\n\nHistorisch gesehen haben Embedded-Entwickler(innen) aus berechtigten geschäftlichen und technischen Gründen weitgehend allein an ihren Schreibtischen gearbeitet. Die Zusammenarbeit war begrenzt. Innovative Unternehmen durchbrechen diese Barrieren, indem sie gemeinsame Code-Sichtbarkeit durch integrierte Source-Control- und CI/CD-Workflows ermöglichen. Diese modernen Praktiken ziehen Ingenieur(innen) an und halten sie, während sie Innovationen freischalten, die in isolierten Workflows verborgen bleiben würden.\n\nWie ein Director of DevOps bei einem technologieorientierten Automobilhersteller (ein GitLab-Kunde) erklärt: \"Es ist wirklich entscheidend für uns, eine einzige Übersicht zu haben, auf die wir schauen und die Status sehen können. Die Entwickler(innen) sind sich beim Einbringen eines Merge Requests des Status eines bestimmten Workflows bewusst, um sich so schnell wie möglich zu bewegen.\" Diese Transparenz beschleunigt die Innovation und ermöglicht es Automobilherstellern, schnell auf Softwarefunktionen zu iterieren, die ihre Fahrzeuge in einem zunehmend wettbewerbsintensiven Markt differenzieren.\n\n## Silos aufbrechen durch kollaborative Entwicklung\n\nEmbedded-Systems-Leader haben ein klares Zeitfenster, um durch die DevSecOps-Einführung einen Wettbewerbsvorteil zu erlangen. Aber das Fenster wird nicht für immer offen bleiben. Software wird weiterhin zum primären Differenzierungsfaktor in eingebetteten Produkten, und die Kluft zwischen Leadern und Nachzüglern wird nur größer werden.\n\nUnternehmen, die DevSecOps erfolgreich einführen, werden Kosten senken, die Markteinführungszeit beschleunigen und Innovationen freischalten, die sie auf dem Markt differenzieren. Die Embedded-Systems-Leader von morgen sind diejenigen, die heute DevSecOps annehmen.\n\n> Während dieser Artikel untersuchte, warum jetzt die kritische Zeit für Embedded-Teams ist, DevSecOps einzuführen, fragst du dich vielleicht nach den praktischen Schritten für den Einstieg. Erfahre, wie du diese Konzepte mit unserem Leitfaden in die Praxis umsetzen kannst: [4 Wege zur Beschleunigung der Embedded-Entwicklung mit GitLab (Artikel auf Englisch)](https://about.gitlab.com/blog/4-ways-to-accelerate-embedded-development-with-gitlab/).",[675],"Matt DeLaney","2025-07-03","Warum jetzt die Zeit für Embedded DevSecOps ist",[111],"Erfahre, wie Embedded-Entwicklungsteams lange Feedback-Zyklen, manuelle Compliance und isolierte Entwicklung mit DevSecOps bewältigen.",{"featured":6,"template":681,"slug":682},"BlogPost","why-now-is-the-time-for-embedded-devsecops","content:de-de:blog:why-now-is-the-time-for-embedded-devsecops.yml","Why Now Is The Time For Embedded Devsecops","de-de/blog/why-now-is-the-time-for-embedded-devsecops.yml","de-de/blog/why-now-is-the-time-for-embedded-devsecops",[688,715,738,759,781,802],{"_path":689,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":690,"content":698,"config":709,"_id":711,"_type":16,"title":712,"_source":18,"_file":713,"_stem":714,"_extension":21},"/de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"ogTitle":691,"schema":692,"ogImage":693,"ogDescription":694,"ogSiteName":695,"noIndex":6,"ogType":696,"ogUrl":697,"title":691,"canonicalUrls":697,"description":694},"Einheitliche DevSecOps-Plattform: Vorteile für Unternehmen","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Itzik Gan Baruch\"}],\n        \"datePublished\": \"2025-06-02\",\n      }","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","Erfahre mehr über GitLabs einheitliche DevSecOps-Plattform: Tool-Integration, verbesserte Sicherheit und KI für effiziente Entwicklung.","https://about.gitlab.com","article","https://about.gitlab.com/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"heroImage":693,"body":699,"authors":700,"updatedDate":702,"date":703,"title":704,"tags":705,"description":708,"category":14},"In der modernen Softwareentwicklung von heute migrieren viele Unternehmen in die Cloud und führen DevSecOps-Prozesse ein. Durch die Vielzahl von Tools und Legacy-Systemen, die nicht für die moderne Entwicklung ausgelegt sind, stellt diese Umstellung jedoch eine große Herausforderung dar. \n\nUm diese Systeme an DevSecOps anzupassen, müssen Unternehmen mehrere Tools für Aufgabenmanagement, CI/CD, Sicherheit, Überwachung und vieles mehr miteinander verknüpfen. Das Ergebnis? Komplexe Betriebsabläufe, hohe Wartungskosten und eine erschwerte Zusammenarbeit zwischen Entwicklungs- und Betriebsteams. Darüber hinaus sind Entwickler(innen) frustriert, da sie ständig zwischen verschiedenen Tools wechseln müssen, um einen einzigen Flow – von der Planung bis zur Produktion – abzuschließen.\n\n![Die Komplexität und die Betriebskosten der Integration mehrerer Tools in einen DevSecOps-Prozess](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>Wie komplex es sein kann, mehrere Tools in einen DevSecOps-Prozess zu integrieren\u003C/i>\u003C/center> \n\n\u003Cbr>\u003C/br>\n\nDie gute Nachricht ist, es gibt eine Lösung: Eine umfassende DevSecOps-Plattform, die einen einheitlichen Ansatz für die Softwareentwicklung bietet.\n\nDiese Plattformen sind für Unternehmen konzipiert, die in cloudbasierten und DevSecOps-Umgebungen arbeiten. Sie konsolidieren alle Phasen der Softwareentwicklung – von der Codeverwaltung, über CI/CD-Prozesse, Aufgabenmanagement und Sicherheit bis hin zur KI-gestützten Automatisierung – auf einer einzigen Plattform. Die Zentralisierung aller Softwareentwicklungs-Workflows in einer einheitlichen Oberfläche ermöglicht es den Entwicklungs- und Betriebsteams, effizienter zu arbeiten, die Kommunikation zu vereinfachen und die Komplexität der Vorgänge und Störungen zu minimieren. \n\nDarüber hinaus verbessert sich die Entwicklererfahrung erheblich – sie arbeiten viel lieber mit einem Produkt, das speziell für moderne Entwicklungsanforderungen konzipiert wurde.\n\nIn den folgenden Abschnitten erfahren wir, wie GitLab Teams bei der Bewältigung gängiger Herausforderungen hilft – sei es bei der Verwaltung von Projekten und Aufgaben, der Gewährleistung von Sicherheit und Compliance oder der Einführung von KI-basierten Entwicklungstools – und das alles auf einer einzigen, einheitlichen Plattform.\n\n## Integriertes Agile-Projektmanagement\n\n[GitLab](https://about.gitlab.com/de-de/) bietet eine ganzheitliche Lösung, bei der das Projekt- und Aufgabenmanagement über alle Phasen des Softwareentwicklungszyklus hinweg vollständig integriert ist, wie z. B. CI/CD, wodurch der Entwicklungsfortschritt in Echtzeit verfolgt werden kann. Tickets und Epics sind direkt mit den Automatisierungsprozessen verknüpft und ermöglichen einen nahtlosen Flow von der Planung bis zur Bereitstellung in der Produktion. Dieser Ansatz erhöht die Transparenz zwischen den Teams, verringert Verzögerungen und stellt sicher, dass alle Beteiligten einen klaren Überblick über den Entwicklungsstatus in Echtzeit haben.\n\n![Tickets und Epics sind direkt mit Automatisierungsprozessen verknüpft und ermöglichen einen nahtlosen Übergang von der Planung bis zur Bereitstellung in der Produktion.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## Integrierte Sicherheit\n\nGitLab legt großen Wert auf die Integration von umfassenden Sicherheitsfunktionen („security first“). Die Plattform integriert eine breite Palette automatisierter Sicherheitsscanner, darunter (Dokumentation nur in englischer Sprache verfügbar):\n\n* [Abhängigkeitssuche](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n* [Statische Anwendungssicherheitstests (SAST)](https://docs.gitlab.com/user/application_security/sast/)\n* [Dynamische Anwendungssicherheitstests (DAST)](https://docs.gitlab.com/user/application_security/dast/)\n* [Erkennung von Geheimnissen](https://docs.gitlab.com/user/application_security/secret_detection/)\n* [Container-Scanning](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![Sicherheitsscanning-Funktionen, die in verschiedenen Entwicklungsphasen in den CI/CD-Prozess integriert sind](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>Sicherheitsscanning-Funktionen, die in verschiedenen Entwicklungsphasen in den CI/CD-Prozess integriert sind\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nDiese Sicherheitsprüfungen werden direkt in jede Phase des Softwareentwicklungszyklus eingebaut, einschließlich der CI/CD-Pipeline, um den Entwickler(inne)n schon früh im Entwicklungszyklus ein unmittelbares Feedback zu potenziellen Sicherheitsproblemen zu geben.\n\n## Compliance und regulatorische Anforderungen\n\nNeben Effizienz und Benutzerfreundlichkeit müssen viele Unternehmen – insbesondere in regulierten Branchen wie Finanzinstituten oder Großunternehmen – sicherstellen, dass ihre Prozesse strengen Sicherheits- und Compliance-Standards entsprechen. Sie müssen in der Lage sein, Richtlinien für verschiedene Projekte durchzusetzen, z. B. einen Sicherheitsscanner vorzuschreiben, wenn eine CI/CD-Pipeline auf bestimmten Code-Branches (Main- oder geschützte Branches) ausgeführt wird, oder bestimmte Genehmigungen zu verlangen, bevor Code in den Main-Branch zusammengeführt wird.\n\nMit GitLab wird dies durch [Compliance-Frameworks (nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/) erleichtert, eine Funktion, mit der Unternehmen strukturierte Richtlinien für ausgewählte Projekte definieren und durchsetzen können. So wird die Einhaltung automatischer gesetzlicher und sicherheitstechnischer Anforderungen gewährleistet und gleichzeitig ein nahtloser und effizienter Workflow für Entwickler(innen) sichergestellt.\n\n## KI-basierte Entwicklung\n\n[GitLab Duo](https://about.gitlab.com/de-de/gitlab-duo/) unterstützt dich in allen Entwicklungsphasen mit KI, sodass du nicht mehr auf externe Tools zurückgreifen musst. Jede KI-unterstützte Anforderung wird im gesamten Kontext des Projekts und der Codebase bearbeitet, was eine intelligentere und effizientere Arbeit ermöglicht.\n\nDie KI kann zum Beispiel folgende Aufgaben übernehmen:\n\n* automatische Erstellung von Aufgabenbeschreibungen\n* intelligente Zusammenfassung von Diskussionen zu Tickets, was Entwickler(inne)n wertvolle Zeit spart\n* erweiterte Code-Review-Funktionen\n* Vorschläge zur Codeverbesserung und -optimierung\n* automatisierte Testgenerierung\n* Erkennung und Behebung von Sicherheitslücken\n* Fehlerbehebung bei der Grundursachenanalyse für CI-Pipeline-Fehler\n* Datenschutz und Datensicherheit\n\nGitLab kennt die Bedürfnisse von regulierten Unternehmen, insbesondere im öffentlichen und im Finanzsektor, und bietet eine einzigartige Lösung für den Einsatz von KI-Modellen in einer sicheren Umgebung. GitLab Duo Self-Hosted ermöglicht es Unternehmen, die volle Kontrolle über Datenschutz, Sicherheit und die Bereitstellung großer Sprachmodelle [(LLMs; nur in englischer Sprache verfügbar)](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) in ihrer eigenen Infrastruktur zu behalten. Dabei wird Folgendes gewährleistet:\n\n* Datenschutz\n* Einhaltung gesetzlicher Anforderungen\n* maximale Sicherheit\n* KI-Vorteile ohne externe Netzwerkabhängigkeiten oder -risiken\n\n## Zusammenfassung\n\nUnternehmen brauchen eine umfassende DevSecOps-Plattform, um Prozesse zu rationalisieren, die Sicherheit zu verbessern und Innovationen zu beschleunigen. GitLab bietet genau das – eine einzige Anwendung, die alle wichtigen Entwicklungs-, Sicherheits- und Betriebswerkzeuge mit integrierter Sicherheitsintegration und KI-basierter Automatisierung vereint.\n\nWillst du GitLab in Aktion sehen? Entdecke interaktive (englischsprachige) Demos für:\n\n* [GitLab Premium und Ultimate mit Duo](https://gitlab.navattic.com/gitlab-premium-with-duo): Erlebe KI-Unterstützung bei der Entwicklung,\n* [Sicherheit in der CI/CD-Pipeline](https://gitlab.navattic.com/gitlab-scans): Sieh dir an, wie integriertes Sicherheitsscanning deine Software schützt.\n* [Compliance-Frameworks](https://gitlab.navattic.com/compliance): Erfahre, wie GitLab Richtlinien projektübergreifend durchsetzt, um eine bessere Governance zu gewährleisten.\n\n> Nimm am virtuellen Launch-Event von GitLab 18 teil, um mehr über die Zukunft der DevSecOps-Plattform zu erfahren, einschließlich der Rolle der agentischen KI. [Registriere dich noch heute!](https://about.gitlab.com/de-de/eighteen/)",[701],"Itzik Gan Baruch","2025-06-23","2025-06-02","Warum steigen Unternehmen auf eine einheitliche DevSecOps-Plattform um?",[9,706,707],"DevSecOps platform","product","Erfahre mehr über die einheitliche DevSecOps-Plattform von GitLab, die Tools integriert, Sicherheit verbessert und KI für eine effiziente Softwareentwicklung nutzt.",{"slug":710,"featured":6,"template":681},"why-are-organizations-moving-to-a-unified-devsecops-platform","content:de-de:blog:why-are-organizations-moving-to-a-unified-devsecops-platform.yml","Why Are Organizations Moving To A Unified Devsecops Platform","de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform.yml","de-de/blog/why-are-organizations-moving-to-a-unified-devsecops-platform",{"_path":716,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":717,"content":723,"config":732,"_id":734,"_type":16,"title":735,"_source":18,"_file":736,"_stem":737,"_extension":21},"/de-de/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"title":718,"description":719,"ogTitle":718,"ogDescription":719,"noIndex":6,"ogImage":720,"ogUrl":721,"ogSiteName":695,"ogType":696,"canonicalUrls":721,"schema":722},"Der ultimative CI/CD-Leitfaden: Grundlagen für die erweiterte Implementierung","Erfahre, wie du die kontinuierliche Integration/kontinuierliche Bereitstellung modernisierst und die Entwicklung, Lieferung und Sicherheit von Pipelines automatisierst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660151/Blog/Hero%20Images/blog-image-template-1800x945__26_.png","https://about.gitlab.com/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Der ultimative CI/CD-Leitfaden: Grundlagen für die erweiterte Implementierung\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sandra Gittlen\"}],\n        \"datePublished\": \"2025-01-06\",\n      }",{"title":718,"description":719,"authors":724,"heroImage":720,"date":726,"body":727,"category":14,"tags":728,"updatedDate":731},[725],"Sandra Gittlen","2025-01-06","Die kontinuierliche Integration/kontinuierliche Lieferung ([CI/CD](https://about.gitlab.com/de-de/topics/ci-cd/)) hat die Art und Weise revolutioniert, wie Softwareteams Werte für ihre Benutzer(innen) schaffen. Vorbei sind die Zeiten manueller Bereitstellungen und komplizierter Integrationen – moderne Entwicklung erfordert Automatisierung, Zuverlässigkeit und Geschwindigkeit.\n\nIm Grunde geht es bei CI/CD darum, eine nahtlose Pipeline zu erstellen, die Code von der Umgebung der Entwickler(innen) bis hin zur Produktion überführt und Feedback in Echtzeit einbezieht. [CI](https://about.gitlab.com/de-de/topics/ci-cd/benefits-continuous-integration/) hilft Teams, Mängel frühzeitig zu erkennen – bevor sie zu kostspieligen Problemen werden –, indem sichergestellt wird, dass Codeänderungen häufig in einem gemeinsamen Repository zusammengeführt, automatisch getestet und validiert werden. [CD](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-delivery-cd) führt diesen Ansatz fort, indem es den Bereitstellungsprozess automatisiert und die Releases vorhersehbar und stressfrei macht.\n\nAnstatt sich auf manuelle Prozesse und komplexe Toolchains für die Softwareentwicklung zu verlassen, können Teams eine robuste CI/CD-Pipeline verwenden, um Software zu erstellen, zu testen und bereitzustellen. Die KI kann diesen Prozess noch weiter optimieren und automatisch CI/CD-Pipelines erstellen, die konsistente Qualität, Compliance und Sicherheitsüberprüfungen ermöglichen.\n\nIn diesem Leitfaden werden moderne CI/CD-Pipelines von den Grundprinzipien über Best Practices bis hin zu fortschrittlichen Strategien erklärt. Du erfährst außerdem, wie führende Unternehmen CI/CD nutzen, um wirkungsvolle Ergebnisse zu erzielen. Mit den Erkenntnissen dieses Leitfadens kannst du deine DevSecOps-Umgebung skalieren und Software [agil](https://about.gitlab.com/de-de/topics/ci-cd/continuous-integration-agile/), automatisiert und effizient entwickeln und bereitstellen.\n\n## Inhalt: Das erwartet dich\n\n- [Was ist kontinuierliche Integration?](#was-ist-kontinuierliche-integration%3F)\n- [Was ist kontinuierliche Lieferung?](#was-ist-kontinuierliche-lieferung%3F)\n- [Wie hängt die Quellcodeverwaltung mit CI/CD zusammen?](#wie-hängt-die-quellcodeverwaltung-mit-cicd-zusammen%3F)\n- [Die Vorteile von CI/CD in der modernen Softwareentwicklung](#die-vorteile-von-cicd-in-der-modernen-softwareentwicklung)\n - [Hauptunterschiede zwischen CI/CD und traditioneller Entwicklung](#hauptunterschiede-zwischen-cicd-und-traditioneller-entwicklung)\n- [Grundlagen von CI/CD verstehen](#grundlagen-von-cicd-verstehen)\n - [Was ist eine CI/CD-Pipeline?](#was-ist-eine-cicd-pipeline%3F)\n- [Best Practices für CI/CD-Implementierung und -Management](#best-practices-für-cicd-implementierung-und--management)\n - [Best Practices für CI](#best-practices-für-ci)\n - [Best Practices für CD](#best-practices-für-cd)\n- [Erste Schritte mit CI/CD](#erste-schritte-mit-cicd)\n- [Sicherheit, Compliance und CI/CD](#sicherheit-compliance-und-cicd)\n- [CI/CD und die Cloud](#cicd-und-die-cloud)\n- [Erweitertes CI/CD](#erweitertes-cicd)\n - [Wiederverwendung und Automatisierung in CI/CD](#wiederverwendung-und-automatisierung-in-cicd)\n - [Problembehebung für Pipelines mithilfe von KI](#problembehebung-für-pipelines-mithilfe-von-ki)\n- [So migrierst du zu GitLab CI/CD](#so-migrierst-du-zu-gitlab-cicd)\n- [Erfahrungsberichte von führenden Unternehmen](#erfahrungsberichte-von-führenden-unternehmen)\n- [CI/CD-Tutorials](#cicd-tutorials)\n\n## Was ist kontinuierliche Integration?\n\nUnter [kontinuierlicher Integration](https://about.gitlab.com/de-de/topics/ci-cd/benefits-continuous-integration/) (CI) versteht man das Vorgehen, alle Codeänderungen frühzeitig und häufig in den main-Branch eines gemeinsamen Quellcode-Repositorys zu integrieren, Änderungen automatisch zu testen, wenn sie committet oder zusammengeführt werden, und automatisch einen Build zu starten. Mit kontinuierlicher Integration können Teams Fehler und Sicherheitsprobleme leichter und viel früher im Entwicklungsprozess erkennen und beheben.\n\n## Was ist kontinuierliche Lieferung?\n[Kontinuierliche Lieferung](https://about.gitlab.com/de-de/topics/ci-cd/#what-is-continuous-delivery-cd) (CD) – manchmal auch _kontinuierliche Bereitstellung_ genannt – ermöglicht es Unternehmen, ihre Anwendungen automatisch bereitzustellen, sodass Entwickler(innen) mehr Zeit haben, sich auf die Überwachung des Bereitstellungsstatus zu konzentrieren und den Erfolg sicherzustellen. Bei der kontinuierlichen Lieferung legen DevOps-Teams die Kriterien für die Codefreigabe im Voraus fest. Wenn diese Kriterien erfüllt und validiert sind, wird der Code in der Produktivumgebung bereitgestellt. So können Unternehmen flexibler sein und neue Funktionen den Benutzer(inne)n schneller zur Verfügung stellen.\n\n## Wie hängt die Quellcodeverwaltung mit CI/CD zusammen?\n\nQuellcodeverwaltung ([Source Code Management, SCM](https://about.gitlab.com/de-de/solutions/source-code-management/)) und CI/CD bilden die Grundlage moderner Softwareentwicklungsverfahren. SCM-Systeme wie [Git](https://about.gitlab.com/de-de/blog/what-is-git-the-ultimate-guide-to-gits-role-and-functionality/) bieten eine zentrale Möglichkeit, Änderungen zu verfolgen, verschiedene Codeversionen zu verwalten und die Zusammenarbeit zwischen den Teammitgliedern zu erleichtern. Wenn Entwickler(innen) an neuen Funktionen oder Fehlerbehebungen arbeiten, erstellen sie Branches aus der main-Codebase, nehmen ihre Änderungen vor und [führen sie dann über Merge Requests zusammen](https://docs.gitlab.com/ee/user/project/merge_requests/) (Artikel nur in englischer Sprache verfügbar). Diese Branching-Strategie macht es möglich, dass mehrere Entwickler(innen) gleichzeitig arbeiten können, ohne sich gegenseitig in die Quere zu kommen, und gleichzeitig einen stabilen main-Branch zu bewahren, der immer produktionsreifen Code enthält.\n\nCI/CD übernimmt den von SCM-Systemen verwalteten Code und erstellt, testet und validiert ihn automatisch, wenn Änderungen gepusht werden. Wenn Entwickler(innen) Codeänderungen einreichen, ruft das CI/CD-System automatisch den neuesten Code ab, kombiniert ihn mit der vorhandenen Codebase und führt eine Reihe automatisierter Überprüfungen durch. Dazu gehören in der Regel das Kompilieren des Codes, das Ausführen von Unit-Tests, das Durchführen einer statischen Codeanalyse und das Überprüfen der Testabdeckung. Wenn einer dieser Schritte fehlschlägt, wird das Team sofort benachrichtigt, sodass es Probleme beheben kann, bevor sie sich auf andere Entwickler(innen) auswirken oder in die Produktivumgebung überführt werden. Durch diese enge Integration zwischen Versionskontrolle und kontinuierlicher Integration entsteht eine Feedbackschleife, die dazu beiträgt, die Codequalität aufrechtzuerhalten, und verhindert, dass sich Integrationsprobleme ansammeln.\n\n## Die Vorteile von CI/CD in der modernen Softwareentwicklung\n\n[CI/CD bringt transformative Vorteile für die moderne Softwareentwicklung](https://about.gitlab.com/blog/ten-reasons-why-your-business-needs-ci-cd/) (Blogbeitrag nur in englischer Sprache verfügbar), indem die Zeit und das Risiko drastisch reduziert werden, die neue Funktionen und Fixes mit sich bringen. Durch die kontinuierliche Feedbackschleife können DevSecOps-Teams sicher sein, dass ihre Änderungen automatisch für die gesamte Codebase validiert werden. Das Ergebnis sind hochwertigere Software, kürzere Lieferzeiten und häufigere Veröffentlichungen, mit denen man schneller auf Benutzer- und Marktanforderungen reagieren kann.\n\nEiner der wichtigsten Aspekte ist jedoch, dass CI/CD eine Kultur der Zusammenarbeit und Transparenz innerhalb von Softwareentwicklungsteams fördert. Wenn jeder den Status von Builds, Tests und Bereitstellungen in Echtzeit sehen kann, wird es einfacher, Engpässe im Bereitstellungsprozess zu identifizieren und zu beheben. Die von CI/CD ermöglichte Automatisierung reduziert auch die kognitive Belastung für Entwickler(innen) und gibt ihnen die Möglichkeit, sich auf das Schreiben von Code zu konzentrieren, anstatt manuelle Bereitstellungsprozesse zu verwalten. Dies führt zu einer höheren Zufriedenheit und Produktivität der Entwickler(innen) und reduziert gleichzeitig das Risiko, das traditionell mit dem gesamten Softwareveröffentlichungsprozess verbunden ist. Teams können freier experimentieren, wenn sie wissen, dass schnelle Code Reviews Teil des Prozesses sind, und sie können Änderungen bei Bedarf schnell zurücknehmen, was Innovationen und kontinuierliche Verbesserungen fördert.\n\n### Hauptunterschiede zwischen CI/CD und traditioneller Entwicklung\n\nCI/CD unterscheidet sich in vielerlei Hinsicht von der traditionellen Softwareentwicklung:\n\n**Häufige Code-Commits** \n\nEntwickler(innen) arbeiten oft unabhängig und laden ihren Code selten in eine main-Codebase hoch, was zu Merge-Konflikten und anderen zeitaufwändigen Problemen führt. Mit CI/CD pushen Entwickler(innen) Commits den ganzen Tag über, um sicherzustellen, dass Konflikte frühzeitig erkannt werden und die Codebase auf dem neuesten Stand bleibt.\n\n**Reduziertes Risiko**\n\nLangwierige Testzyklen und eine umfassende Vorabplanung kennzeichnen die traditionelle Softwareentwicklung. Dadurch sollen Risiken minimiert werden, jedoch wird die Möglichkeit eingeschränkt, Probleme zu finden und zu beheben. Das Risikomanagement in CI/CD basiert darauf, dass kleine, inkrementelle Änderungen vorgenommen werden, die genau überwacht und leicht rückgängig gemacht werden können.\n\n**Automatisierte und kontinuierliche Tests**\n\nIn der traditionellen Softwareentwicklung werden Tests durchgeführt, sobald die Entwicklung abgeschlossen ist. Dies führt jedoch zu Problemen wie verspäteter Lieferung und kostspieliger Fehlerbehebungen. CI/CD unterstützt automatisierte Tests, die während der gesamten Entwicklung kontinuierlich durchgeführt und durch jeden Code-Commit ausgelöst werden. Entwickler(innen) erhalten außerdem Feedback, auf das sie schnell reagieren können.\n\n**Automatisierte, wiederholbare und häufige Bereitstellungen**\n\nMit CI/CD sind Bereitstellungen automatisierte Prozesse, die den typischen Stress und Aufwand für große Software-Rollouts reduzieren. Der gleiche Bereitstellungsprozess kann in allen Umgebungen wiederholt werden, was Zeit spart und Fehler und Inkonsistenzen reduziert.\n\n## Grundlagen von CI/CD verstehen\n\nCI/CD dient als Framework für den Aufbau skalierbarer, wartbarer Bereitstellungsprozesse. Daher ist es für DevSecOps-Teams wichtig, die Kernkonzepte wirklich zu verstehen. Durch ein solides Verständnis der CI/CD-Prinzipien können Teams, Strategien und Praktiken an die Entwicklung der Technologie anpassen, anstatt an alte Ansätze gebunden zu sein. Hier sind einige der Grundlagen.\n\n### Was ist eine CI/CD-Pipeline?\n\nEine [CI/CD-Pipeline](https://about.gitlab.com/de-de/topics/ci-cd/cicd-pipeline/) ist eine Reihe von Schritten wie Erstellen, Testen und Bereitstellen, durch die der Softwarebereitstellungsprozess automatisiert und optimiert wird. [Jede Phase dient als Qualitätsüberprüfung](https://about.gitlab.com/blog/guide-to-ci-cd-pipelines/) (Blogbeitrag nur in englischer Sprache verfügbar) und stellt sicher, dass nur validierter Code weiterentwickelt wird. In den frühen Phasen werden in der Regel grundlegende Überprüfungen wie Kompilierung und Unit-Tests durchgeführt, während spätere Phasen Integrationstests, Leistungstests, Konformitätstests und gestaffelte Bereitstellungen in verschiedenen Umgebungen umfassen können.\n\nDie Pipeline kann so konfiguriert werden, dass manuelle Genehmigungen an kritischen Punkten erforderlich sind, z. B. vor der Bereitstellung für die Produktion, während gleichzeitig Routineaufgaben automatisiert werden und Entwickler(innen) schnelles Feedback über den Zustand ihrer Änderungen erhalten. Dieser strukturierte Ansatz sorgt für Konsistenz, reduziert menschliche Fehler und bietet einen klaren Audit-Trail, wie Codeänderungen sich von der Entwicklung bis in die Produktion bewegen. Moderne Pipelines werden oft als Code implementiert, so dass sie wie Anwendungscode versioniert, getestet und gepflegt werden können.\n\nAuch die folgenden Begriffe sind für CI/CD wichtig:\n- **Commit:** eine Codeänderung\n- **Job:** Anweisungen, die ein Runner ausführen muss\n- **Runner:** ein Agent oder Server, der jeden Job einzeln ausführt und nach Bedarf hoch- oder herunterfahren kann\n- **Phase:** ein Schlüsselwort, das bestimmte Jobphasen definiert, z. B. „Erstellen“ und „Bereitstellen“. Jobs der gleichen Phase werden parallel ausgeführt. Pipelines werden mithilfe der versionierten YAML-Datei `.gitlab-ci.yml` auf der Root-Ebene eines Projekts konfiguriert.\n\n![CI/CD-Pipeline-Schema](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673928/Blog/Content%20Images/1690824533476.png)\n\n## Best Practices für die Implementierung und das Management von CI/CD\n\nWie erfolgreich du mit CI/CD bist, hängt stark von den [Best Practices](https://about.gitlab.com/de-de/blog/how-to-keep-up-with-ci-cd-best-practices/) ab, die du implementierst. \n\n#### Best Practices für CI\n\n* Committe früh und oft.\n* Optimiere die Pipeline-Phasen.\n* Erstelle Builds schnell und einfach.\n* Nutze Fehlschläge, um Prozesse zu verbessern.\n* Stelle sicher, dass die Testumgebung die Produktion widerspiegelt.\n\n#### Best Practices für CD\n\n* Beginne dort, wo du gerade bist – du kannst jederzeit iterieren.\n* Die beste kontinuierliche Lieferung erfolgt mit minimalen Mitteln.\n* Verfolge, was passiert, damit Probleme und Merge Requests nicht außer Kontrolle geraten.\n* Optimiere Benutzerakzeptanztests und Staging mit Automatisierung.\n* Verwalte die Release-Pipeline durch Automatisierung.\n* Implementiere Überwachung für Transparenz und Effizienz. \n\n> ### Setz dir ein Lesezeichen!\n>\n>Sieh dir unser englischsprachiges [Webinar „Intro to CI/CD“](https://www.youtube.com/watch?v=sQ7Nw3o0izc) (Einführung in CI/CD) an!\n>\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sQ7Nw3o0izc?si=3HpNqIClrc2ncr7Y\" title=\"Intro to CI/CD webinar\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Erste Schritte mit CI/CD\n\nDer Einstieg in CI/CD beginnt mit einem einfachen, aber repräsentativen Projekt, das als Pilotprojekt dienen soll. Wähle eine einfache Anwendung mit simplen Testanforderungen aus, damit du dich auf das Erlernen der Pipeline-Mechanismen konzentrieren kannst, anstatt dich mit komplexen Bereitstellungsszenarien zu befassen. Stelle zunächst sicher, dass dein Code [versioniert](https://about.gitlab.com/de-de/topics/version-control/) ist und einige [grundlegende automatisierte Tests](https://about.gitlab.com/blog/develop-c-unit-testing-with-catch2-junit-and-gitlab-ci/) (Blogbeitrag nur in englischer Sprache verfügbar) enthält  – dabei reichen schon ein paar Unit-Tests aus. Das Ziel besteht darin, [eine minimale Pipeline zu erstellen](https://about.gitlab.com/blog/how-to-learn-ci-cd-fast/) (Blogbeitrag nur in englischer Sprache verfügbar), die du mit zunehmendem Verständnis nach und nach ausbauen kannst.\n\nIm Fall von GitLab beginnt der Prozess mit dem Erstellen der Datei `.gitlab-ci.yml` im Stammverzeichnis deines Projekts. Diese YAML-Datei definiert deine Pipeline-Phasen (grundlegende Phasen wie Erstellen, Testen und Bereitstellen) und Jobs. Eine einfache Pipeline könnte so aussehen: In der Phase „Erstellen“ wird deine Code kompiliert und es werden Artefakte erstellt, die Testphase führt deine Unit-Tests aus und die Phase „Bereitstellen“ pusht deine Anwendung in eine Staging-Umgebung. GitLab erkennt diese Datei automatisch und beginnt, deine Pipeline auszuführen, wenn Änderungen in dein Repository gepusht werden. Die Plattform bietet [integrierte Runner](https://docs.gitlab.com/runner/) (Artikel nur in englischer Sprache verfügbar), um deine Pipeline-Jobs auszuführen, aber du kannst auch eigene Runner einrichten, wenn du mehr Kontrolle haben willst.\n\nWenn du mit den Grundlagen vertraut bist, kannst du nach und nach anspruchsvollere Elemente zu deiner Pipeline hinzufügen. Du kannst zum Beispiel Code-Qualitätsprüfungen, [Sicherheitsscans](https://docs.gitlab.com/ee/user/application_security/#security-scanning) (Artikel nur in englischer Sprache verfügbar) oder die automatisierte Bereitstellung für die Produktion hinzufügen. Die DevSecOps-Plattform von GitLab bietet Funktionen wie [Compliance-Management](https://about.gitlab.com/blog/meet-regulatory-standards-with-gitlab/), [Bereitstellungsvariablen](https://about.gitlab.com/blog/demystifying-ci-cd-variables/) (Blogbeiträge nur in englischer Sprache verfügbar) und manuelle Genehmigungsprüfungen, die du integrieren kannst, wenn deine Pipeline ausgereift ist. Achte auf die Ausführungszeit der Pipeline und suche nach Möglichkeiten, Jobs parallel auszuführen. Denke daran, die richtige Fehlerbehandlung und Benachrichtigungen hinzuzufügen, damit deine Teammitglieder umgehend über alle Pipeline-Ausfälle informiert werden. Beginne damit, häufige Probleme und Lösungen zu dokumentieren, wenn sie auftauchen – dies wird von unschätzbarem Wert sein, wenn dein Team wächst.\n\n> ### Möchtest du mehr über die ersten Schritte mit CI/CD erfahren? Registriere dich für einen [kostenlosen, englischsprachigen CI/CD-Kurs auf GitLab University](https://university.gitlab.com/courses/continuous-integration-and-delivery-ci-cd-with-gitlab).\n\n## Sicherheit, Compliance und CI/CD\n\nEiner der größten Vorteile von CI/CD ist die Möglichkeit, Sicherheits- und Compliance-Prüfungen frühzeitig und häufig in den Software-Entwicklungsprozess einzubetten. In GitLab können Teams die Konfiguration `.gitlab-ci.yml` verwenden, um automatisch Sicherheitsscans in mehreren Phasen auszulösen, vom ersten Code Commit bis zur Bereitstellung in der Produktivumgebung. Container-Scanning, Abhängigkeitsuche und Sicherheitsscans auf der Plattform ([Dynamische Anwendungssicherheitstests](https://docs.gitlab.com/ee/user/application_security/dast/) und [Erweitertes SAST](https://about.gitlab.com/blog/gitlab-advanced-sast-is-now-generally-available/); beide nur in englischer Sprache verfügbar) können so konfiguriert werden, dass sie bei jeder Codeänderung automatisch ausgeführt werden, um auf Sicherheitslücken, Compliance-Verstöße und Sicherheitsfehlkonfigurationen zu prüfen. Die API der Plattform ermöglicht die Integration mit [externen Sicherheitstools](https://about.gitlab.com/blog/integrate-external-security-scanners-into-your-devsecops-workflow/) (Blogbeitrag nur in englischer Sprache verfügbar) und die Testabdeckungsfunktionen stellen sicher, dass die Sicherheitstests die erforderlichen Anforderungen erfüllen.\n\nDie Sicherheitstestberichte von GitLab enthalten detaillierte Informationen zu den Ergebnissen und sollen sicherstellen, dass Sicherheitsprobleme schnell behoben werden können, bevor sie in die Produktion kommen. Das Sicherheitsdashboard bietet eine zentrale Ansicht von Sicherheitslücken in allen Projekten, während [Sicherheitsrichtlinien](https://about.gitlab.com/blog/how-gitlab-supports-the-nsa-and-cisa-cicd-security-guidance/) (Blogbeitrag nur in englischer Sprache verfügbar) durch Merge-Request-Genehmigungen und Pipeline-Gates durchgesetzt werden können. Darüber hinaus bietet GitLab mehrere Sicherheitsebenen, um vertrauliche Daten während des gesamten CI/CD-Prozesses zu schützen, Audit-Protokolle, um den Zugriff auf Geheimnisse zu verfolgen, und rollenbasierte Zugriffskontrolle (RBAC), um sicherzustellen, dass nur autorisierte Benutzer(innen) vertrauliche Konfigurationsdaten anzeigen oder ändern können.\n\nGitLab unterstützt auch die Erstellung einer Software-Stückliste ([SBOM](https://about.gitlab.com/de-de/blog/the-ultimate-guide-to-sboms/)), die eine umfassende Bestandsaufnahme aller Softwarekomponenten, Abhängigkeiten und Lizenzen in einer Anwendung bietet und es den Teams ermöglicht, Sicherheitslücken schnell zu identifizieren, darauf zu reagieren und behördliche Auflagen zu erfüllen.\n\n## CI/CD und die Cloud\n\nDie CI/CD-Plattform von GitLab bietet eine robuste Integration mit großen Cloud-Anbietern wie [Amazon Web Services](https://about.gitlab.com/de-de/partners/technology-partners/aws/), [Google Cloud Platform](https://about.gitlab.com/blog/provision-group-runners-with-google-cloud-platform-and-gitlab-ci/) (Blogbeitrag nur in englischer Sprache verfügbar) und [Microsoft Azure](https://docs.gitlab.com/ee/install/azure/) (Artikel nur in englischer Sprache verfügbar), sodass Teams ihre Cloud-Bereitstellungen direkt aus ihren Pipelines heraus automatisieren können. Durch die Cloud-Integrationen von GitLab können Teams Cloud-Ressourcen verwalten, Anwendungen bereitstellen und Cloud-Dienste innerhalb der GitLab-Oberfläche überwachen. Die integrierten Cloud-Bereitstellungsvorlagen und [Auto-DevOps-Funktionen](https://docs.gitlab.com/ee/topics/autodevops/) (Artikel nur in englischer Sprache verfügbar) der Plattform reduzieren die Komplexität von Cloud-Bereitstellungen erheblich, sodass sich die Teams auf die Anwendungsentwicklung konzentrieren können und sich nicht mit dem Infrastrukturmanagement befassen müssen. Für Unternehmen, die ihre IT-Infrastruktur mit GitOps automatisieren möchten, bietet GitLab eine [Flux-CD-Integration](https://about.gitlab.com/blog/why-did-we-choose-to-integrate-fluxcd-with-gitlab/) (Blogbeitrag nur in englischer Sprache verfügbar).\n\nDie Cloud-Funktionen von GitLab gehen weit über die einfache Automatisierung der Bereitstellung hinaus. Die [Kubernetes-Integration](https://about.gitlab.com/blog/kubernetes-overview-operate-cluster-data-on-the-frontend/) (Blogbeitrag nur in englischer Sprache verfügbar) der Plattform ermöglicht es den Teams, die Container-Orchestrierung über mehrere Cloud-Anbieter hinweg zu verwalten, während die [Cloud-nativen Installationsoptionen von GitLab](https://about.gitlab.com/de-de/topics/ci-cd/cloud-native-continuous-integration/) den Betrieb der Plattform selbst in Cloud-Umgebungen ermöglichen. Durch die Cloud-nativen Funktionen von GitLab können Teams Runner mit automatischer Skalierung implementieren, die dynamisch Cloud-Ressourcen für die Pipeline-Ausführung bereitstellen und so Kosten und Leistung optimieren. Die Integration der Plattform mit den Sicherheitsdiensten von Cloud-Anbietern macht es möglich, dass die Sicherheits- und Konformitätsanforderungen während des gesamten Bereitstellungsprozesses erfüllt werden.\n\nFür Multi-Cloud-Umgebungen stellt GitLab konsistente Workflows und Tools zur Verfügung, unabhängig vom zugrunde liegenden Cloud-Anbieter. Teams können die Umgebungsverwaltung von GitLab verwenden, um verschiedene Cloud-Konfigurationen in Entwicklungs-, Staging- und Produktivumgebungen zu verwalten. Da die Plattform [Infrastructure as Code](https://docs.gitlab.com/ee/user/infrastructure/iac/) (Artikel nur in englischer Sprache verfügbar) unterstützt – insbesondere die native Integration mit Terraform – können Teams ihre Cloud-Infrastruktur-Bereitstellung steuern und automatisieren. Die Überwachungs- und Beobachtungsfunktionen von GitLab lassen sich in die Metriken von Cloud-Anbietern integrieren und bieten einen umfassenden Überblick über den Zustand von Anwendungen und Infrastruktur in allen Cloud-Umgebungen.\n\n## Erweitertes CI/CD \nCI/CD hat sich weit über das einfache Erstellen und Bereitstellen von Pipelines hinaus entwickelt. In umfassenderen Implementierungen bietet CI/CD eine ausgefeilte Orchestrierung von automatisierten Tests, Sicherheitsscans, Infrastrukturbereitstellung, KI und mehr. Hier findest du einige Strategien für Erweitertes CI/CD, die Entwicklungsteams dabei helfen können, ihre Pipelines zu skalieren und Probleme zu beheben, auch wenn die architektonische Komplexität zunimmt.\n\n### Wiederverwendung und Automatisierung in CI/CD\n\nGitLab verändert die Art und Weise, wie Entwicklungsteams CI/CD-Pipelines erstellen und verwalten. Dazu tragen vor allem zwei wichtige Innovationen bei: der [CI/CD-Katalog](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) und [CI/CD Steps](https://about.gitlab.com/blog/introducing-ci-cd-steps-a-programming-language-for-devsecops-automation/) (Blogbeiträge nur in englischer Sprache verfügbar), eine neue Programmiersprache für DevSecOps-Automatisierung, die derzeit getestet wird. Der CI/CD-Katalog ist eine zentralisierte Plattform, auf der Entwickler(innen) CI/CD-Komponenten entdecken, wiederverwenden und beitragen können. Komponenten fungieren als wiederverwendbare Bausteine mit einem einzigen Zweck und sollen die Pipeline-Konfiguration vereinfachen – du kannst sie dir wie Legosteine für CI/CD-Workflows vorstellen. CI/CD Steps unterstützt komplexe Workflows, indem es Entwickler(inne)n ermöglicht, Eingaben und Ausgaben für einen CI/CD-Job zu erstellen. Mit dem CI/CD-Katalog und CI/CD Steps können DevSecOps-Teams CI/CD und seine Komponenten einfach standardisieren und so die Entwicklung und Pflege von CI/CD-Pipelines vereinfachen.\n\n> Weitere Informationen findest du in unseren [CI/CD-Katalog-FAQ](https://about.gitlab.com/blog/faq-gitlab-ci-cd-catalog/) und der [Dokumentation für CI/CD Steps](https://docs.gitlab.com/ee/ci/steps/) (beide nur in englischer Sprache verfügbar).\n\n### Problembehebung für Pipelines mithilfe von KI\n\nCI/CD-Pipelines können zwar ab und zu ausfallen, aber eine schnelle Problembehebung kann die Auswirkungen minimieren. GitLab Duo Root Cause Analysis, schafft als Teil eines Programmpakets KI-basierter Funktionen Klarheit, indem es [die Grundursache für eine defekte CI/CD-Pipeline ermittelt](https://about.gitlab.com/blog/quickly-resolve-broken-ci-cd-pipelines-with-ai/) (Blogbeitrag nur in englischer Sprache verfügbar). Wenn eine Pipeline fehlschlägt, stellt GitLab detaillierte Job-Protokolle, Fehlermeldungen und Ausführungsverläufe bereit, die genau zeigen, wo und warum der Fehler aufgetreten ist. Root Cause Analysis schlägt dann mithilfe von KI eine Lösung vor.\nSieh dir GitLab Duo Root Cause Analysisin Aktion an:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/sTpSLwX5DIs?si=J6-0Bf6PtYjrHX1K\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## So migrierst zu GitLab CI/CD\n\nFür die Migration auf die DevSecOps-Plattform und ihr integriertes CI/CD ist ein systematischer Ansatz nötig, um deine vorhandene Pipeline-Konfigurationen, Abhängigkeiten und Bereitstellungsprozesse zu analysieren und dann den entsprechenden Funktionen und der Syntax von GitLab zuzuordnen. Die folgenden englischsprachigen Anleitungen sollen dir den Einstieg erleichtern.\n\n* [So migrierst du von Bamboo zu GitLab CI/CD](https://about.gitlab.com/blog/migrating-from-bamboo-to-gitlab-cicd/)\n* [Von Jenkins zu GitLab: der ultimative Leitfaden zur Modernisierung deiner CI/CD-Umgebung](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n* [Einfache Migration von GitHub zu GitLab](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n\n## Erfahrungsberichte von führenden Unternehmen\n\nDiese führenden Unternehmen sind zu GitLab migriert und profitieren von den unzähligen Vorteilen von CI/CD. Lies ihre Stories.\n\n- [Lockheed Martin](https://about.gitlab.com/de-de/customers/lockheed-martin/)\n- [Indeed](https://about.gitlab.com/de-de/blog/how-indeed-transformed-its-ci-platform-with-gitlab/)\n- [CARFAX](https://about.gitlab.com/de-de/customers/carfax/)\n- [HackerOne](https://about.gitlab.com/de-de/customers/hackerone/)\n- [Betstudios](https://about.gitlab.com/blog/betstudios-cto-on-improving-ci-cd-capabilities-with-gitlab-premium/) (nur in englischer Sprache verfügbar)\n- [Thales und Carrefour](https://about.gitlab.com/blog/how-carrefour-and-thales-are-evolving-their-ci-cd-platforms/) (nur in englischer Sprache verfügbar)\n\n## CI/CD-Tutorials\n\nWerde mit diesen einfach verständlichen Tutorials zum CI/CD-Profi. (Die Tutorials sind im Moment nur in englischer Sprache verfügbar.)\n\n* [Grundlagen von CI: So führst du Jobs sequenziell, parallel oder unregelmäßig aus](https://about.gitlab.com/blog/basics-of-gitlab-ci-updated/)\n* [So richtest du deine erste CI/CD-Komponente mit GitLab ein](https://about.gitlab.com/blog/tutorial-how-to-set-up-your-first-gitlab-ci-cd-component/)\n* [Einfacher Aufbau einer CI/CD-Pipeline mit GitLab für ein Monorepo](https://about.gitlab.com/blog/building-a-gitlab-ci-cd-pipeline-for-a-monorepo-the-easy-way/)\n* [Verwendung von untergeordneten Pipelines für die kontinuierliche Bereitstellung in fünf Umgebungen](https://about.gitlab.com/blog/using-child-pipelines-to-continuously-deploy-to-five-environments/)\n* [CI/CD-Automatisierung: Maximiere die Auswirkungen eines Bereitstellungsstopps auf GitLab-Gruppen](https://about.gitlab.com/blog/ci-cd-automation-maximize-deploy-freeze-impact-across-gitlab-groups/)\n* [Refaktorisierung einer CI/CD-Vorlage zu einer CI/CD-Komponente](https://about.gitlab.com/blog/refactoring-a-ci-cd-template-to-a-ci-cd-component/)\n* [Kommentiere Container-Images mit Build-Provenienz mithilfe von Cosign in GitLab CI/CD](https://about.gitlab.com/blog/annotate-container-images-with-build-provenance-using-cosign-in-gitlab-ci-cd)\n\n> #### Erste Schritte mit GitLab CI/CD. [Registriere dich für GitLab Ultimate](https://gitlab.com/-/trials/new) und teste die KI-basierte DevSecOps-Plattform kostenlos.",[111,9,706,729,730,707],"tutorial","security","2025-05-08",{"slug":733,"featured":93,"template":681},"ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation","content:de-de:blog:ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","Ultimate Guide To Ci Cd Fundamentals To Advanced Implementation","de-de/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation.yml","de-de/blog/ultimate-guide-to-ci-cd-fundamentals-to-advanced-implementation",{"_path":739,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":740,"content":746,"config":753,"_id":755,"_type":16,"title":756,"_source":18,"_file":757,"_stem":758,"_extension":21},"/de-de/blog/what-is-a-rest-api-guide-and-functions",{"title":741,"description":742,"ogTitle":741,"ogDescription":742,"noIndex":6,"ogImage":743,"ogUrl":744,"ogSiteName":695,"ogType":696,"canonicalUrls":744,"schema":745},"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":741,"description":742,"authors":747,"heroImage":743,"date":749,"body":750,"category":14,"tags":751},[748],"GitLab Germany Team","2024-10-16","REST-APIs sind seit über zwei Jahrzehnten ein zentraler Baustein des Internets. Bei ihnen handelt es sich um Programmierschnittstellen (APIs), die den Austausch von Daten zwischen Client und Server regeln. REST-APIs unterliegen einem Satz von Bedingungen, welche der Wissenschaftler Roy Fielding im Jahr 2000 entwickelt und unter der Abkürzung REST (representational state transfer) [festgelegt hat](https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_7 \"festgelegt hat\").\n\nREST legt die genaue technische Umsetzung dieser Schnittstellen nicht fest. Fielding hat REST vielmehr als einen „Architektur-Stil“ [bezeichnet](https://www.youtube.com/watch?v=6oFAmQUM8ws \"bezeichnet\"), der eine Vielzahl praktischer Lösungen erlaubt. Jede API, die sich innerhalb der Grenzen dieser Architektur bewegt, entspricht dem REST-Standard.\n\nIn diesem Artikel zeigen wir Ihnen, warum sich REST seit seiner Einführung zum dominanten Modell entwickelt hat und welche Vorteile sich für Web-Development-Teams daraus ergeben. \n\n## Constraints: Die Grundbausteine der REST-Architektur\n\nREST baut auf insgesamt sechs sogenannten „Constraints“ (Einschränkungen) auf. \n\nAus ihnen ergibt sich eine Architektur, die einfach und anpassungsfähig ist und auch in einem rasch wandelnden Geschäftsumfeld langfristig Bestand haben kann.\n\n## Definition: Was ist eine Rest-API?\n\nREST-APIs sind praktische Softwarelösungen, die auf der REST-Dokumentation aufbauen und gemäß der folgenden sechs REST-Prinzipien für ein Client-Server-Modell erstellt werden: \n\n- Unabhängigkeit zwischen Client und Server,\n- Zustandslosigkeit,\n- ein mehrschichtiges Systemmodell, \n- eine einheitliche Schnittstelle,\n- Cache-Fähigkeit und\n- ein optionales Constraint: Code on Demand.\n\nIn den folgenden Abschnitten betrachten wir diese Constraints genauer. \n\n### Unabhängigkeit zwischen Client und Server\n\nREST findet wie erwähnt für APIs Anwendung, die den Austausch von Ressourcen zwischen einem Client und einem Server ermöglichen. Entscheidend ist, dass Client und Server vollkommen unabhängig voneinander bleiben. \n\nSo kann beispielsweise der Code des Servers verändert werden, ohne dass der Client ebenfalls Änderungen vornehmen muss, um weiterhin Informationen anfragen und erhalten zu können. \n\n### Zustandslosigkeit\n\nDie Einschränkung der Zustandslosigkeit hat der REST-Architektur ihren Namen verliehen. Für APIs soll gemäß dieser Vorgabe gelten, dass für die korrekte Beantwortung einer Anfrage die übermittelten Informationen der aktuellen Sitzung ausreichen.\n\nDas bedeutet: Es ist keine dauerhafte Verbindung zwischen Client und Server erforderlich und Client-Anfragen müssen auf der Server-Seite auch nicht zwischengespeichert werden. \n\nZustandslosigkeit führt zu höherer Daten- und Ausfallsicherheit. Gleichzeitig gilt aber auch: Benötigen Nutzer(innen) dieselben Informationen ein zweites Mal, müssen sämtliche Informationen der vorigen Sitzung erneut eingeben werden. \n\n### Mehrschichtiges Systemmodell\n\nFür jedes Unternehmen ist eine andere Server-Struktur optimal. Werden Informationen beispielsweise in verschiedenen Schichten gespeichert, gestaltet sich die Abfrage mehr oder weniger komplex. Das aber sollte für eine Anfrage unerheblich bleiben, solange die Daten korrekt übermittelt werden.  \n\nDie Einschränkung des mehrschichtigen Systemmodells ist somit das Gegenstück zur Zustandslosigkeit. Während letztere besagt, dass der Server vom Client nichts weiter benötigt als die Anfrageinformationen, verlangt das mehrschichtige Modell, dass dem Client nicht bekannt zu sein braucht, wie der Server die angeforderten Daten bereitstellt. \n\nDer Server kann also mit einer Vielzahl verschiedener Architekturen arbeiten, ohne dass die REST-API-Schnittstelle beeinflusst wird. \n\n### Einheitliche Schnittstelle\n\nDiese Einschränkung ist etwas komplexer und wiederum aus vier Unterpunkten aufgebaut. Für Roy Fielding war sie die womöglich wichtigste der gesamten REST-API-Architektur. \n\nDie einheitliche Schnittstelle fordert:\n\n- dass jeder Datensatz über eine einzige URI eindeutig gekennzeichnet ist,\n- dass Veränderungen oder auch Löschungen der Daten nur mittels der grundlegenden Netzwerkprotokollbefehle, wie GET, POST, PUT/PATCH und DELETE, vorgenommen werden können,\n- dass jede Nachricht, die versandt wird, mittels Metadaten sämtliche Informationen bereithält, die für die Bearbeitung der Daten erforderlich ist und\n- dass, sofern erforderlich, Hyperlinks (HATEOAS) bereitgestellt werden, um weitere benötigte Informationen einzuholen.\n\nDie einheitliche Schnittstelle sorgt für maximale Klarheit und eine einfache, standardisierte Client-Server-Kommunikation. \n\n### Cache-Fähigkeit\n\nZwar findet bei REST-APIs der Ressourcenaustausch zustandslos statt, zugleich aber sollten einmal angeforderte Daten aus einer Sitzung auf demselben Endgerät weiterverwendet werden können.\n\nIndem REST das Cachen dieser Informationen ermöglicht, sorgt es für eine höhere Effizienz und beschleunigt viele Prozesse bedeutend.\n\n### Code on Demand\n\nFür die meisten Anwendungen reicht die Bereitstellung der Daten in der Form von XML or JSON vollkommen aus. In bestimmten Fällen aber kann es von Vorteil sein, dem Client darüber hinaus –      oder stattdessen – eine Anwendung bereitzustellen. Denken Sie dabei an Java Applets oder JavaScript.\n\nCode on Demand stellt eine sinnvolle Erweiterung der REST-Architektur dar, aber sie ist als einzige der sechs Einschränkungen optional. \n\n## Wofür eignen sich REST-APIs?\n\nFlexibilität ist eines der Hauptmerkmale von REST-APIs. So sind sehr viele praktische Anwendungen denkbar:\n\n- Ganz grundsätzlich das Abrufen und Bereitstellen von Daten. Social-Media-Seiten wie Instagram oder Facebook nutzen REST-APIs beispielsweise um Updates zu posten.\n- Gerade weil sie zustandslos sind, eignen sich REST-APIs für Cloud-Services: Auch wenn die Verbindung abbricht, können die Daten weiter genutzt werden. \n- [Microservices](https://microservices.io/ \"Microservices\") gewinnen rasch an Beliebtheit und Bedeutung. Mit ihnen geht ein umfassender Perspektivenwechsel einher: Applikationen werden nicht mehr als riesige, in sich geschlossene Systeme gedacht, sondern als modular und aus kleineren, schlanken Elementen zusammengesetzt. REST-APIs bilden die ideale Schnittstelle zur nahtlosen Integration dieser verschiedenen Bausteine.\n\nIm Laufe der letzten 20 Jahre sind Alternativen zu REST-APIs verfügbar geworden. Dennoch hat sich keine davon auf breiter Basis durchsetzen können. Ganz offensichtlich ist REST auch aktuell der beste Ansatz zum Datenaustausch im Netz. \n\n## Was sind die Vorteile einer Rest-     API?\n\nIn den frühen Tagen des Internets war SOAP (Simple object access protocol) die dominante Form des Datenaustauschs. \n\nDass sich REST seitdem durchgesetzt hat und fast ein Vierteljahrhundert lang relevant geblieben ist, lässt sich recht einfach aus seinen inhärenten Vorteilen erklären:\n\n- SOAP vs REST: SOAP ist ein Protokoll, das Regeln und auch technische Realisierungen im Gegensatz zu REST sehr präzise vorschreibt. Daraus ergibt sich unmittelbar, dass APIs, die auf diesen Anforderungen aufbauen, weitaus komplexer als REST-APIs sind.\n- Die APIs, die gemäß der REST-Richtlinien programmiert wurden, basieren auf dem HTTP-Standard. Sie sind schnell und effizient und in nahezu jedem Kontext einsetzbar. Aus genau diesen Gründen eignen sich REST-APIs auch besonders gut für mobile Anwendungen.\n- Der Begriff der Skalierbarkeit ist bereits gefallen und er ist auch einer der maßgeblichen Argumente für die Verwendung von REST-APIs. Darunter ist zu verstehen, dass bei Erweiterungen der Server-Architektur nicht die darunter liegende Datenaustausch-Technologie verändert werden muss. \n- Einige Unternehmen setzen aus Sicherheitserwägungen immer noch auf SOAP. Allerdings sind REST-APIs keineswegs grundsätzlich unsicher. Entscheidend ist, einige grundlegende Best Practices anzuwenden – darunter die Verwendung von HTTPS sowie Autorisierung und Authentifizierung. \n\n## Gibt es eine REST-API von GitLab?\n\nAuch bei GitLab sind wir von den Vorzügen der REST-Architektur überzeugt. Aus diesem Grund stellen wir unseren Nutzer(inne)n eine [GitLab-REST-API](https://docs.gitlab.com/ee/api/rest/ \"GitLab-REST-API\") zur Verfügung. \n\nBei GitLab handelt es sich um den führenden Anbieter von DevSecOps-Lösungen. Anwender(innen) nutzen die Plattform, um sicher, fehlerfrei und kollaborativ an Entwicklungsprojekten zu arbeiten. \n\nDie GitLab-API kann sowohl genutzt werden, um öffentlich sichtbare, als auch nicht öffentliche Daten (nach erfolgter Authentifizierung und Autorisierung) abzurufen. Weil die API unmittelbar auf GitLab abgestimmt ist, erfolgt der Austausch sicher, schnell und effizient. \n\n## REST-API FAQs\n\n### Ist REST ein Standard?\n\nREST ist ein Satz aus sechs Einschränkungen, die den Datenaustausch in einer Client-Server-Beziehung regeln. Alle API-Schnittstellen, die diesen Vorgaben entsprechen, sind „RESTful“. \nEs ist somit nicht falsch, REST als einen Standard zu bezeichnen. Allerdings gilt dies weniger im Sinne eines Protokolls oder konkreter Anweisungen. REST gibt vielmehr Leitlinien und Anforderungen vor, deren Umsetzung zu gewünschten Ergebnissen führen, unabhängig davon, wie diese technisch realisiert werden.\n\nAus diesem Grund wird REST zumeist als ein „Architektur-Stil“ definiert. \n\n### Muss ich alle sechs REST-Einschränkungen befolgen?\n\nRoy Fielding hat hierzu persönlich im Laufe der Jahre mehrfach [Stellung bezogen](https://www.infoq.com/articles/roy-fielding-on-versioning/ \"Stellung bezogen\"). Seine Ansichten zu dieser Frage sind eindeutig: REST ist nicht in allen Fällen zwangsläufig die beste Option. Wenn man aber eine REST-konforme Architektur wünscht, müssen sämtliche Constraints ausnahmslos umgesetzt werden. \n\nEine API beispielsweise, die alle Einschränkungen umsetzt, bei der aber keine Daten gecached werden können, ist nicht RESTful. \n\nDie einzige Ausnahme ist Code on Demand. Diese Einschränkung ist optional und muss somit nicht umgesetzt werden, damit eine REST-API die Kriterien erfüllt. \n\n### Wie passen Cache-Fähigkeit und Zustandslosigkeit zusammen?\n\nZwischen den Einschränkungen der Cache-Fähigkeit und Zustandslosigkeit scheint ein Spannungsverhältnis zu bestehen. Wenn bei jeder Anfrage die Daten neu übermittelt werden müssen, widerspricht das Zwischenspeichern von Daten im Cache dann nicht dieser Forderung? \n\nIn Wahrheit fordert Zustandslosigkeit lediglich, dass der Server jede Anfrage so behandelt, als wäre sie die erste. Es besteht keine Zuordnung der Daten im Cache zu einer aktuellen Anfrage. \n\nDas Cachen der Daten dient lediglich einer höheren Effizienz und sorgt für Stabilität. \n\n### Was bedeutet der Begriff Idempotenz im Zusammenhang mit REST-APIs?\n\nWenn ein Client dieselbe Anfrage mehrfach nacheinander stellt, spricht man von Idempotenz. Das kann entweder passieren, weil die Verbindung instabil oder der Code fehlerhaft ist. \n\nEntscheidend ist, dass eine solche idempotente Anfrage nicht zu einem Fehler bei der Beantwortung der Anfrage führt. \n\nDie Einschränkung der Cache-Fähigkeit sorgt dafür, dass idempotente Anfragen als solche erkannt und fehlerfrei bearbeitet werden können. \n\n### Wie lassen sich Rest-APIs sichern?\n\nREST-APIs können sehr effektiv gesichert werden. \n\nÜbliche und sehr effiziente Methoden sind die Verwendung von HTTPS und API-Schlüsseln, die Durchführung von Authentifizierungen und Autorisierungen sowie die Durchführung einer Input-Validation und eines Audit-Loggings. \n\nAuch die Begrenzung der Anfragen in einem bestimmten Zeitfenster im Sinne eines Rate-Limiting empfiehlt sich.",[752,9],"DevOps",{"slug":754,"featured":6,"template":681},"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":760,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":761,"content":767,"config":775,"_id":777,"_type":16,"title":778,"_source":18,"_file":779,"_stem":780,"_extension":21},"/de-de/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"title":762,"description":763,"ogTitle":762,"ogDescription":763,"noIndex":6,"ogImage":764,"ogUrl":765,"ogSiteName":695,"ogType":696,"canonicalUrls":765,"schema":766},"Die Top 10 GitLab-Workflow-Hacks, die du kennen musst","Eine Produktmanagerin von GitLab nennt ihre Lieblingstricks, um schnell und effizient durch die GitLab DevSecOps-Plattform zu navigieren und die Zusammenarbeit im Team zu fördern.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099361/Blog/Hero%20Images/Blog/Hero%20Images/lightvisibility_lightvisibility.png_1750099361252.png","https://about.gitlab.com/blog/top-10-gitlab-workflow-hacks-you-need-to-know","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Die Top 10 GitLab-Workflow-Hacks, die du kennen musst\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amanda Rueda\"}],\n        \"datePublished\": \"2024-04-09\",\n      }\n                  ",{"title":762,"description":763,"authors":768,"heroImage":764,"date":770,"body":771,"category":14,"tags":772},[769],"Amanda Rueda","2024-04-09","In der Welt der Softwareentwicklung geht es bei der Effizienz nicht nur um Schnelligkeit, sondern auch um intelligente Navigation. Als Produktmanagerin von GitLab weiß ich, wie wichtig Effizienz bei der Arbeit mit der DevSecOps-Plattform ist. Dies sind meine 10 Lieblingsfunktionen von GitLab. Vielleicht sind das genau die Workflow-Hacks, von denen du noch gar nicht wusstest, dass du sie brauchst.\n\nMit diesen Geheimtipps kannst du die Produktivität und Zusammenarbeit in deinem Team auf eine neue Stufe heben.\n\n## 1. Kommentare auflösen\n\nNicht nur für Merge Requests! Das Auflösen von Kommentaren zu Tickets sorgt für Ordnung und vereinfacht die Aufgabenverwaltung erheblich. Es ist besonders praktisch, um Feedback effizient zu verwalten.\n\n> **Warum liebe ich es?** Das Auflösen von Kommentaren sorgt nicht nur für Ordnung in einem Ticket, sondern ist auch eine gute Möglichkeit, Aufgaben zu verwalten.\n> \n> **Anwendungsfall.** Das Auflösen von Kommentaren ist ein großartiges Tool für Tickets, zu denen du Feedback sammelst. Du kannst auf das Feedback reagieren und einen Link bereitstellen, den Kommentar auflösen und mit dem nächsten fortfahren.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/discussions/#resolve-a-thread)__\n\n![Beispiel für das Auflösen von Kommentaren – Bild 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750099376147.gif)\n\n\u003Cp>\u003C/p>\n\n## 2. Interne Kommentare\n\nSprich direkt mit deinem Team, ohne externe Zuhörer(innen). Diskutiere privat innerhalb eines Tickets oder eines Merge Requests. Dabei sind die Kommentare nur für deine Teammitglieder sichtbar. Es ist die perfekte Balance zwischen Transparenz und Vertraulichkeit.\n\n> **Warum liebe ich es?** Es schafft ein Gleichgewicht zwischen Vertraulichkeit und Transparenz und hält gleichzeitig die breitere Diskussion für die Gemeinschaft offen.\n> \n> **Anwendungsfall.** Wenn du eine Produkteinführung koordinierst, kann dein Marketingteam interne Kommentare nutzen, um Nachrichten und Strategien zu diskutieren und zu verfeinern. So bleiben deine Diskussionen an einem zentralen Ort und sind im Entwurfsmodus für das Team leicht zugänglich.\n> \n> **[Anleitung](https://docs.gitlab.com/ee/user/discussions/#add-an-internal-note)**\n\n![Beispiel für interne Kommentare](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099376148.png)\n\n\u003Cp>\u003C/p>\n\n## 3. Und/oder in Filtern\n\nBei der Suche nach Datensätzen auf einer Listenseite kannst du mit Hilfe von Und/oder-Filtern das Durcheinander durchdringen und schnell und effizient genau das finden, wonach du suchst.\n\n> **Warum liebe ich es?** Es ist perfekt, um genau das zu finden, was du suchst, und um effiziente und optimierte Workflows zu ermöglichen.\n> \n> **Anwendungsfall.** Suche nach Funktionstickets zu einer bestimmten Initiative, die bestimmten Gruppen zugeordnet sind.\n>\n> __[Anleitung](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#filter-with-the-or-operator)__\n\n![Beispiel des Und/oder-Filters](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/and_or__1__aHR0cHM6_1750099376152.gif)\n\n\u003Cp>\u003C/p>\n\n## 4. Automatisches Erweitern von URLs\n\nWenn du ein „+“ oder „+s“ an das Ende einer GitLab-URL anhängst, wird sie zu einem informativen Code-Schnipsel, mit dem du den Fortschritt teilen kannst, ohne dass deine Teammitglieder die Seite verlassen müssen.\n\n> **Warum liebe ich es?** Es ist wie ein Röntgenblick für URLs – du siehst die wichtigen Dinge auf einen Blick, ohne zu klicken!\n> \n> **Anwendungsfall.** Du möchtest in Kommentaren Fortschritte teilen? Füge einfach ein „+s“ zum Link hinzu und schon sind alle auf dem gleichen Stand.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/markdown.html#show-the-issue-merge-request-or-epic-title-in-the-reference)__\n\n![Beispiel für das automatische Erweitern von URLs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750099376154.gif)\n\n\u003Cp>\u003C/p>\n\n## 5. Schnellzugriff\n\nMit einfachen Textbefehlen kannst du über den Schnellzugriff Aufgaben wie die Zuweisung von Benutzer(inne)n, das Hinzufügen von Bezeichnungen und vieles mehr direkt aus dem Beschreibungs- oder Kommentarfeld heraus erledigen. Das spart Klicks und Zeit.\n\n> **Warum liebe ich es?** Es spart Klicks und Zeit.\n> \n> **Anwendungsfall.** Beim Erstellen eines neuen Tickets verwende ich den Schnellzugriff, um automatisch Labels und einen Meilenstein hinzuzufügen und beim Speichern des Datensatzes eine Verbindung mit dem Epic herzustellen.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/project/quick_actions.html)__\n\n![Beispiel für eine Schnellzugriff-Aktion](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750099376156.gif)\n\n\u003Cp>\u003C/p>\n\n## 6. Stapelbearbeitung \n\nFüge Labels hinzu, ändere Beauftragte oder aktualisiere Meilensteine für mehrere Probleme auf einmal. Diese Funktion macht potenziell mühsame Aktualisierungen zum Kinderspiel und ermöglicht schnelle Anpassungen für zahlreiche Tickets.\n\n> **Warum liebe ich es?** Weil es lästige Updates zu schnellen Updates macht!\n> \n> **Anwendungsfall.** Du willst die Tickets des gesamten Sprints mit dem Label „Review erforderlich“ kennzeichnen? Verwende einfach einen Filter, wähle alle aus und füge die Labels für alle hinzu – kinderleicht.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#bulk-edit-issues-from-a-project)__\n\n![Beispiel für die Stapelbearbeitung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750099376157.gif)\n\n\u003Cp>\u003C/p>\n\n## 7. Epic-Bahnen\n\nGruppiere Tickets in deinem Board in Epics, um den Fortschritt visuell zu verfolgen und zu diskutieren. So kannst du deine Arbeit bei Besprechungen oder Standups besser einordnen.\n\n> **Warum liebe ich es?** Du kannst den Kontext der Arbeit leicht nachvollziehen, während du dir das Board ansiehst.\n> \n> **Anwendungsfall.** Durch die Gruppierung nach Epics kannst du deine Arbeit bei Standup-Reviews leicht mit der übergeordneten Initiative verknüpfen.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issues-in-swimlanes)__\n\n![Beispiel für Epic-Bahnen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750099376158.gif)\n\n\u003Cp>\u003C/p>\n\n## 8. Wiki-Diagramme \n\nVeranschauliche Ideen und Workflows direkt auf deinen Wikiseiten mit einfach zu erstellenden Diagrammen. Diese Funktion unterstützt das visuelle Lernen und vereinfacht komplexe Konzepte.\n\n> **Warum liebe ich es?** Es ist unglaublich benutzerfreundlich und flexibel.\n> \n> **Anwendungsfall.** Wenn du den Workflow einer neuen Funktion skizzierst, zeichnest du ihn direkt in die Wiki-Seite ein, damit er für alle im Team verständlich ist.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/administration/integration/diagrams_net.html)__\n\n![Beispiel für Wiki-Diagramme](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750099376159.gif)\n\n\u003Cp>\u003C/p>\n\n## 9. Tabellenerstellung\n\nKein Ärger mehr mit Markdown für die Tabellenerstellung. Mit dem Rich-Text-Editor kannst du mühelos Tabellen einfügen und formatieren, wodurch die Dokumentation übersichtlicher und strukturierter wird.\n\n> **Warum liebe ich es?** Es macht die Erstellung von Tabellen zum Kinderspiel und sorgt für saubere und strukturierte Aktualisierungen mit nur wenigen Klicks.\n> \n> **Anwendungsfall.** Stellst du eine Sprint-Retro zusammen? Füge schnell eine Tabelle ein, um Feedback, Maßnahmen und Eigentümer(innen) zu organisieren, damit der Review-Prozess für alle reibungsloser abläuft.\n> \n> __[Anleitung](https://docs.gitlab.com/ee/user/rich_text_editor.html#tables)__ \n\n![Beispiel für die Tabellenerstellung](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/image8_aHR0cHM6_1750099376160.gif)\n\n\u003Cp>\u003C/p>\n\n## 10. Einbetten von Videos und GIFs\n\nVerbessere die Beschreibungen oder Kommentare deiner Tickets und Epics mit eingebetteten GIFs und YouTube-Videos, um deiner Kommunikation eine dynamische Ebene zu verleihen.\n\n> **Warum liebe ich es?** Manchmal sagt ein GIF oder ein Video mehr als tausend Worte.\n> \n> **Anwendungsfall.** Du versuchst, einen Fehler in der Benutzeroberfläche zu erklären? Bette ein YouTube-Video ein, in dem du die vorgeschlagene Funktionsverbesserung kurz vorstellst.\n\n![Beispiel für die Einbettung von Videos und GIFs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099376/Blog/Content%20Images/Blog/Content%20Images/gif__1__aHR0cHM6_1750099376161.gif)\n\n\u003Cp>\u003C/p>\n\n## Erkunde diese Funktionen\n\nDiese Funktionen sind nur die Spitze des Eisbergs im umfassenden Toolkit von GitLab, das für mehr Effizienz und eine bessere Zusammenarbeit sorgt. Auch wenn sie nicht ausreichend genutzt werden, können sie erhebliche Auswirkungen auf deinen Workflow haben. Du solltest diese Funktionen weiter erkunden und in deine tägliche Routine integrieren. \n\n> Willst du deinen DevSecOps-Workflow mit GitLab verbessern? [Teste GitLab Ultimate 30 Tage lang kostenlos](https://gitlab.com/-/trial_registrations/new).\n",[729,706,773,774],"features","workflow",{"slug":776,"featured":6,"template":681},"top-10-gitlab-workflow-hacks-you-need-to-know","content:de-de:blog:top-10-gitlab-workflow-hacks-you-need-to-know.yml","Top 10 Gitlab Workflow Hacks You Need To Know","de-de/blog/top-10-gitlab-workflow-hacks-you-need-to-know.yml","de-de/blog/top-10-gitlab-workflow-hacks-you-need-to-know",{"_path":782,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":783,"content":789,"config":796,"_id":798,"_type":16,"title":799,"_source":18,"_file":800,"_stem":801,"_extension":21},"/de-de/blog/jenkins-to-gitlab-migration-made-easy",{"title":784,"description":785,"ogTitle":784,"ogDescription":785,"noIndex":6,"ogImage":786,"ogUrl":787,"ogSiteName":695,"ogType":696,"canonicalUrls":787,"schema":788},"Migration von Jenkins zu GitLab leicht gemacht","In diesem Schritt-für-Schritt-Leitfaden erfährst du, warum und wie du ganz einfach von Jenkins zu GitLab migrieren kannst.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Migration von Jenkins zu GitLab leicht gemacht\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Fernando Diaz\"}],\n        \"datePublished\": \"2024-02-01\",\n      }",{"title":784,"description":785,"authors":790,"heroImage":786,"date":792,"body":793,"category":14,"tags":794,"updatedDate":795},[791],"Fernando Diaz","2024-02-01","GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Das bedeutet, dass GitLab alles bietet, was du benötigst, um sichere Software schneller zu planen, zu entwickeln und bereitzustellen – alles in einem Tool.\n\nPlattformen vereinfachen die Integration verschiedener Tools (DIY-DevOps), um den Software-Entwicklungsprozess (SDLC) zu unterstützen. Da Jenkins keine Plattform ist, sind zusätzliche Tools erforderlich, um den Software-Entwicklungsprozess zu vervollständigen. Dieser DIY-DevOps-Ansatz erhöht die Komplexität der Toolchain, was die folgenden Nachteile mit sich bringt:\n\n- Bedarf an individuellem Support für die Integration und Orchestrierung von Tools\n- Schwierigkeiten bei der Wartung/Aktualisierung/Sicherung separater Tools\n- Ineffizienz bei der Evaluierung der Unternehmenstransformation\n- Schlechte Entwicklererfahrung\n- Zusätzliche Management-/Zeit-/Budgetkosten\n- Produktivitätsverlust\n- Ineffizienz im Hinblick auf Kontextwechsel und Zusammenarbeit\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>DIY-DevOps im Vergleich zu einer DevSecOps-Plattform\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nAus diesen Gründen erwägen viele Jenkins-Teams, zu einer DevSecOps-Plattform zu migrieren. Wer nach einer leistungsfähigeren, zuverlässigeren und sichereren Lösung sucht, sollte GitLab wählen! GitLab ist kostenlos für Einsteiger(innen) und bietet verschiedene Abonnementstufen, je nachdem, welche Anforderungen dein Unternehmen hat. Weitere Informationen zu unseren Angeboten und Funktionen findest du auf unserer [Preisseite](https://about.gitlab.com/de-de/pricing/).\n\nIn diesem Blog erfährst du:\n- wie du eine Migration planst\n- wie du Repositories von anderen Tools für die Quellcodeverwaltung (SCM) zu GitLab migrierst\n- wie du CI/CD-Pipelines von Jenkins zu GitLab migrierst\n- welche weiteren Überlegungen du dir zu Migrationen machen solltest\n\n### Planung einer Migration\n\nBevor du eine Migration von einem anderen Tool zu GitLab CI/CD startest, solltest du zunächst einen Migrationsplan erstellen. Ein Migrationsplan ist ein wichtiger technischer Schritt, um Erwartungen festzulegen. CI/CD-Tools unterscheiden sich im Hinblick auf ihren Ansatz und Aufbau sowie ihre technischen Besonderheiten. Das bedeutet, dass Migrationen keine simplen, direkten Zuordnungen von Daten sind. Ein Migrationsplan bietet folgende Vorteile:\n- Er legt eine klare Vorstellung deiner Migrationsziele fest und kommuniziert sie. Dies hilft deinen Benutzer(innen) dabei, zu verstehen, warum sich der Aufwand lohnt. Der Nutzen wird deutlich, wenn die Migration abgeschlossen ist, aber die Beteiligten müssen sich dessen auch während der Migration bewusst sein.\n- Er ermöglicht die Unterstützung und Beteiligung der entsprechenden Führungsteams – dies trägt zum oben genannten Punkt bei.\n- Er bietet die Gelegenheit, Benutzer(innen) über Veränderungen aufzuklären.\n- Er findet Wege, um Teile der Migration zu sequenzieren oder zu verzögern und zu verhindern, dass nicht migrierte (oder teilweise migrierte) Zustände zu lange bestehen bleiben.\n- Er dokumentiert die Vorteile der Verbesserungen, die GitLab CI/CD bietet, und aktualisiert deine Implementierung im Rahmen der Umstellung.\n\nMit einem Migrationsplan kannst du einen Prozess einrichten, bei dem du mit minimalen Unterbrechungen langsam zu GitLab migrieren kannst. Dies kann bedeuten, dass Jenkins und GitLab parallel eingesetzt werden, während bestimmte Projekte zu GitLab verschoben und von Jenkins abgezogen werden.\n\n### Definition eines Change-Management-Prozesses\n\nDer Migrationsplan sollte einen effektiven Change-Management-Prozess definieren. Entwicklungs- und IT Operations-Teams, Cloud-Administrator(inn)en sowie Sicherheits- und Qualitätsteams haben möglicherweise keine Erfahrung mit GitLab und sie wissen möglicherweise nicht, warum du oder deine Führungskraft sich entschieden haben, diesen Weg einzuschlagen.\n\nWer von den Veränderungen betroffen ist, muss Folgendes wissen:\n- __Warum__ die Veränderung vorgenommen wird\n- __Wie__ der zukünftige Zustand aussehen wird\n- __Wie__ das Unternehmen den neuen Zustand erreichen möchte\n- __Wo__ weitere Informationen oder Unterstützung zu finden sind \n\nZu diesem Zweck solltest du die folgenden Schritte in Erwägung ziehen, um Veränderungen für diese funktionalen Rollen zu steuern:\n- __Analysiere den aktuellen Zustand__: Dokumentiere den aktuellen Zustand der Prozesse. Sammle Indikatoren als Basis. Ermittle, was im Hinblick auf CI/CD funktioniert und was nicht, indem du wichtige Teammitglieder befragst. Dokumentiere die Herausforderungen, die du feststellst, sowohl in quantitativer als auch in qualitativer Hinsicht. Du musst andere von der Vision und dem Grund für die Veränderung überzeugen. Je klarer du also die Problemstellung definieren kannst, desto einfacher wird es, die Zustimmung des gesamten Unternehmens zu gewinnen. \n- __Baue eine Vision auf__: Nun, da du die aktuellen Probleme quantitativ mithilfe von Basisindikatoren und qualitativ (mit den Worten deiner Teammitglieder) beschrieben hast, stelle eine Vision des zukünftigen Zustands vor. Erläutere, warum dies wichtig ist (stelle einen Zusammenhang zu geschäftlichen Erfolgsindikatoren her). Biete Live- sowie aufgezeichnete Demos an, um aufzuzeigen, welche Möglichkeiten es gibt, und vergleiche diese Vision mit dem aktuellen Zustand. Betone diese Botschaft auf mehreren Kanäle und in verschiedenen Medien – Chat-Gruppen, allgemeine Meetings, E-Mail-Benachrichtigungen, Banner-Benachrichtigungen auf GitLab usw.\n- __Kläre die Belegschaft auf__: Investiere in [GitLab-CI/CD-Schulungen (nur in englischer Sprache verfügbar)](https://about.gitlab.com/services/education/gitlab-ci/), die von GitLab-Expert(inn)en durchgeführt werden. Evaluiere den Erwerb und das Verinnerlichen von Kenntnissen mithilfe von [GitLab-Zertifizierungen (nur in englischer Sprache verfügbar)](https://levelup.gitlab.com/pages/certifications). \n- __Kommuniziere Roadmap und Ressourcen__: Teile deinen Teammitgliedern den geplanten Zeitplan sowie die verfügbaren Ressourcen für die Migration mit. Nenne Community-Ressourcen wie Chat-Gruppen, Q&A-Boards oder die Kontaktzeiten von GitLab-Influencern oder -Influencerinnen, damit dein Team Fragen stellen und Unterstützung erhalten kann. Der Aufbau eines Belohnungssystems, das das Teams dazu anregt, frühzeitig umzusteigen und ihre Erfahrungen mit anderen Anwendergruppen zu teilen, wäre ein Pluspunkt!\n\nWenn du diese Elemente zu Beginn der Migration sicherstellst, stellst du die Weichen für ihren Erfolg. \n\n### Festlegung von Migrationszielen\nBevor du eine Migration durchführst, solltest du dir über deine Ziele im Klaren sein und wissen, wie du sie erreichen kannst. Einige Fragen, auf die du Antworten haben solltest, sind beispielsweise folgende:\n- Was ist dein Zeitplan für die Migration?\n- Wie ist dein Jenkins-Server aktuell konfiguriert?\n- Wie viele Projekte müssen migriert werden?\n- Wie komplex ist deine Pipeline?\n- Gibt es externe Abhängigkeiten, mehrere Pipeline-Trigger, parallele Builds usw.?\n- Wie/wo stellst du deinen Code bereit?\n- Was ist der Veröffentlichungs-/Überprüfungsprozess für die Bereitstellung von Code?\n- Ist der Workflow in Jenkins integriert oder gibt es einen separaten Workflow, der von Jenkins ausgelöst wird?\n- Welche Build-Artefakte oder Binärdateien sind für den Erfolg der Pipeline erforderlich?\n- Welche Plugins verwenden Jobs in Jenkins derzeit?\n- Welche Software ist auf den Jenkins-Agenten installiert?\n- Welche Lösung für die Quellcodeverwaltung verwendest du aktuell?\n- Verwenden deine Jenkins-Jobs gemeinsam genutzte Bibliotheken?\n- Welche Authentifizierungsmethode kommt für Jenkins zum Einsatz (Basic Authentication, LDAP/AD, SSO)?\n- Gibt es andere Projekte, auf die du von deiner Pipeline aus zugreifen musst?\n- Gibt es Zugangsdaten in Jenkins, die für den Zugriff auf externe Dienste verwendet werden?\n\nWenn du diese Fragen beantwortest, weißt du, wie du bei der Migration vorgehen solltest, wie lange sie dauert und wo du anfangen solltest. Wenn du einen Plan erstellt hast und dir die Erwartungen und möglichen Fallstricke bewusst sind, kannst du mit dem Migrationsprozess beginnen.\n\n### Voraussetzungen für die Migration\nSobald du einen Migrationsplan erstellt und alle Erwartungen an die Migration bedacht hast, kannst du mit der Einrichtung von GitLab beginnen. Hier sind einige empfohlene Voraussetzungen für die Migration:\n- Mache dich mit GitLab vertraut. Informiere dich über die [wichtigsten GitLab CI/CD-Funktionen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/index.html).\n- Folge den englichsprachigen Tutorials, um deine erste [GitLab-Pipeline](https://docs.gitlab.com/ee/ci/quick_start/index.html) und [komplexere Pipelines](https://docs.gitlab.com/ee/ci/quick_start/tutorial.html) zu generieren, die eine statische Website erstellen, testen und bereitstellen.\n- Lies die [Keyword-Referenz für .gitlab-ci.yml (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/index.html).\n- Richte GitLab ein und konfiguriere es.\n- Teste deine GitLab-Instanz.\n\nSobald du mit GitLab vertraut bist und eine Instanz konfiguriert hast, kannst du deinem Migrationsplan folgen und damit beginnen, Projekte von Jenkins zu GitLab zu verschieben. Stelle sicher, dass deine GitLab-Instanz mithilfe von bewährten Methoden für GitLab und gemäß [Referenzarchitekturen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/administration/reference_architectures/) ordnungsgemäß eingerichtet wurde.\n\n### Migration von Repositories zu GitLab\nEiner der wichtigsten Nachteile von Jenkins ist, dass es keine Lösung für die Quellcodeverwaltung (SCM, Source Code Management) bietet. Wenn du Jenkins verwendest, muss dein Code in einer separaten SCM-Lösung gespeichert werden, auf die Jenkins Zugriff haben muss. Da GitLab über eine integrierte Quellcodeverwaltung verfügt, ermöglicht der Umstieg von Jenkins auch die Migration der zuvor genutzten SCM-Lösung. Dies verringert die Kosten zusätzlich.\n\nGitLab bietet Tools, mit denen du dein Repository und seine Metadaten einfach zu GitLab verschieben kannst. Die folgenden Importer (nur in englischer Sprache verfügbar) unterstützen dich bei der Migration deiner Projekte zu GitLab:\n\n- [GitHub](https://docs.gitlab.com/ee/user/project/import/github.html)\n- [Eine weitere GitLab-Instanz](https://docs.gitlab.com/ee/user/project/settings/import_export.html)\n- [Bitbucket Cloud](https://docs.gitlab.com/ee/user/project/import/bitbucket.html)\n- [Bitbucket Server](https://docs.gitlab.com/ee/user/project/import/bitbucket_server.html)\n- [FogBugz](https://docs.gitlab.com/ee/user/project/import/fogbugz.html)\n- [Gitea](https://docs.gitlab.com/ee/user/project/import/gitea.html)\n- [Jira (nur Issues)](https://docs.gitlab.com/ee/user/project/import/jira.html)\n– [Repo per Manifestdatei](https://docs.gitlab.com/ee/user/project/import/manifest.html)\n- [Repo per URL](https://docs.gitlab.com/ee/user/project/import/repo_by_url.html)\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\" alt=\"GitHub to GitLab Repo Exporter\">\n   \u003Cfigcaption>Repoitory-Exporter von GitHub zu GitLab\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nJeder Importer importiert unterschiedliche Daten aus einem Projekt. Lies die [Dokumentation zum Import und zur Migration von Projekten (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/import/), um mehr Informationen über die bereitgestellten Importer zu erhalten und zu erfahren, welche Daten zu GitLab migriert werden. Darüber hinaus kannst du [den Import von Gruppen und Projekten automatisieren (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/import/#automate-group-and-project-import) und eine benutzerdefinierte Lösung erstellen, welche die Anforderungen deines Unternehmens noch besser erfüllt:\n\n- [Professional Services](https://about.gitlab.com/de-de/services/)\n- [Migrations-Tools](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n- [Häufig gestellte Fragen zur Migration](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n### So migrierst du ein Repository\nMit unseren integrierten Importern kannst du Repositories ganz einfach zu GitLab migrieren. In diesem Beispiel erfährst du, wie du ein Repo zusammen mit [seinen Ressourcen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/project/import/github.html#imported-data) (Tickets, Pull Requests, Meilensteine usw.) aus GitHub zu GitLab kopierst. Um ein Repository aus einem anderen GitHub zu GitLab zu migrieren, führe die folgenden Schritte aus:\n\n1. Wähle oben in der linken Menüleiste **Neu erstellen (+)** aus.\n2. Wähle im Abschnitt „In GitLab“ **Neues Projekt/Repository** aus.\n3. Wähle **Projekt importieren** aus.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\" alt=\"Import project selection\">\n   \u003Cfigcaption>Auswahl des zu importierenden Projekts\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n4. Klicke auf die Schaltfläche **GitHub**.\n    - Wenn du GitLab Self-Managed verwendest, musst du [den GitHub-Importer aktivieren (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#configure-allowed-import-sources).\n    - Beachte, dass andere Importer auf dieselbe Weise initiiert werden können.\n5. Jetzt kannst du:\n    - dich mit GitHub OAuth autorisieren: Wähle **Mit GitHub autorisieren** aus.\n    - einen persönlichen GitHub-Zugriffstoken verwenden:\n       - Gehe zu [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n       - Gib im Feld **Notizen** eine Token-Beschreibung ein.\n       - Wähle den Geltungsbereich für das Repository aus.\n       - Um Beteiligte zu importieren, wähle optional den Geltungsbereich **read:org** aus.\n       - Klicke auf die Schaltfläche **Token generieren**.\n       - Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein.\n6. Klicke auf die Schaltfläche **Authentifizieren**.\n7. Wähle die Elemente aus, die du migrieren möchtest.\n8. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest.\n9. Klicke auf die Schaltfläche **Importieren**.\n\nNun sollte sich das importierte Projekt in deinem Arbeitsbereich befinden. Weitere Informationen über die Migration von GitHub zu GitLab findest du in diesem englischsprachigen Video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nSobald du die Migration des Repositories abgeschlossen hast, kannst du deine Jenkins-Pipeline so einstellen, dass sie die Jenkins-Datei in GitLab nutzt. Lege dazu die Repository-URL für dein neu importiertes Projekt über das Jenkin-Pipeline-Konfigurationsmenü fest:\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\" alt=\"Jenkins Pipeline SCM settings\">\n   \u003Cfigcaption>SCM-Einstellungen für die Jenkins-Pipeline\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nDies ist nützlich für die anfängliche Repo-Migrationsphase und hilft dir dabei, sowohl Jenkins als auch GitLab parallel zu verwenden. So kannst du Dienstunterbrechungen vermeiden, während du die CI/CD-Funktionalität migrierst.\n\nDarüber hinaus kannst du das [GitLab-Jenkins-Plugin](https://plugins.jenkins.io/gitlab-plugin/) als Hilfestellung bei der Migration nutzen. Mit diesem Plugin kann GitLab den Status von Jenkins-Builds auslösen und abrufen.\n\n### Migration von CI/CD-Pipelines\nSobald du deine Repositories zu GitLab migriert hast, kannst du mit der Migration deiner Jenkins-Pipelines zu GitLab fortfahren. Dieser Prozess kann relativ simpel sein, du solltest dazu jedoch die Konzepte und die Syntax von Jenkins und GitLab verstehen.\n\nJenkins bietet zwei verschiedene Arten von Syntax für die Definition von Pipelines: Declarative und Scripted. Dieser Leitfaden behandelt die Migration von Pipelines des Typs Declarative, da diese am häufigsten vorkommen.\n\n### Schritt-für-Schritt-Migration der Pipeline\nIn diesem Tutorial wird eine Jenkins-Datei (Groovy) im Vergleich zu einer GitLab-CI/CD-Konfigurationsdatei (YAML) analysiert, die einen in Golang geschriebenen Microservice generiert, testet und bereitstellt. Anschließend werden die Pipeline in GitLab aktiviert und die Ergebnisse angezeigt. Die Pipeline wird:\n\n- das Golang-Container-Image mit dem Tag **alpine** verwenden,\n- einen Job zur Erstellung des Golang-Codes in einer ausführbaren Binärdatei ausführen,\n   - die erstellte ausführbare Datei als Artefakt speichern,\n- einen Job ausführen, um Unit-Tests durchzuführen,\n- einen Jobs zur Bereitstellung im Staging ausführen.\n   - Dieser wird nur ausgeführt, wenn der Commit auf den Branch **Staging** abzielt,\n   - beginnt, nachdem die Phase **Test** erfolgreich abgeschlossen wurde,\n   - verwendet das erstellte ausführbare Artefakt aus dem vorherigen Job.\n\nUnten findest du die Pipeline-Definitionen aus Jenkins und GitLab sowie beschreibende Kommentare. Im [Meow-Migrationsprojekt](https://gitlab.com/gitlab-de/projects/blogs/meow-migration) kannst du die Pipeline in Aktion sehen.\n\nSchaue dir eine in Groovy geschriebene Jenkins-Datei an:\n\n```  \n// Die höchste Ebene der Declarative-\n// Pipeline.\npipeline {\n\n  // Definiert den zu verwendenden Standard-Agenten,\n  // sofern nicht explizit in einem Job\n  // definiert.\n    agent any\n\n  // Definiert die Staging-Phasen, die in\n  // numerischer Reihenfolge ausgeführt werden. Jede Staging-Phase\n  // führt nur einen Job aus.\n    stages {\n\n    // Definiert den Namen der Staging-Phase.\n        stage('build') {\n      // Definiert das Container-Image,\n      // das für diesen Job verwendet werden soll. Dies überschreibt\n      // die Standardeinstellung 'agent any'.\n      // Das Jenkins-Docker-Plugin\n      // muss konfiguriert sein, damit dies\n      // ausgeführt wird.\n            agent { docker 'golang:alpine' }\n\n      // Definiert die Abfolge von Schritten,\n      // die bei der Ausführung der Staging-Phase\n      // befolgt werden soll.\n            steps {\n                sh 'go build -o bin/meow-micro'\n                sh 'chmod +x bin/meow-micro'\n            }\n\n      // Die Schritte, die nach Abschluss der\n      // Staging-Phase ausgeführt werden sollen.\n            post {\n              always {\n\n        // Speichert die Artefakte der Staging-Phase,\n        // die zur Verwendung in einem anderen Job\n        // generiert wurden.\n                archiveArtifacts artifacts: 'bin/meow-micro'\n                onlyIfSuccessful: true\n              }\n            }\n        }\n\n    stage('test') {\n            agent { docker 'golang:alpine' }\n            steps {\n                sh 'go test .'\n            }\n        }\n\n        stage('deploy') {\n      // Definiert die Bedingungen,\n      // die zur Ausführung des Jobs\n      // erfüllt sein müssen. In diesem Fall wird der\n      // Bereitstellungs-Job nur auf dem \n      // Staging-Branch ausgeführt.\n            when {\n              branch 'staging'\n            }\n            steps {\n                echo 'Deploying meow-micro to staging'\n        // Verwendet das Artefakt, das in der\n        // Build-Staging-Phase gespeichert wurde.\n                sh './bin/meow-micro'\n            }\n        }\n    }\n}\n```\n\nSchaue dir nun an, wie die gleiche Funktion in GitLab erstellt werden kann:\n\n```\n# Definiert das zu verwendende Standard-Image,\n# sofern nicht explizit in einem Job\n# angegeben.\ndefault:\n  image: alpine:latest\n\n# Definiert die Reihenfolge der auszuführenden Staging-Phasen.\n# Jede Staging-Phase kann mehrere Jobs umfassen.\nstages:\n  - build\n  - test\n  - deploy\n\n# Definiert den Namen des Jobs.\ncreate-binary:\n # Definiert die Staging-Phase, in welcher der Job ausgeführt wird.\n  stage: build\n # Definiert das Container-Image, das für\n # diesen Job verwendet werden soll. Dies überschreibt die Standardeinstellung.\n  image: golang:alpine\n # Definiert die Reihenfolge der Schritte,\n # die bei der Ausführung des Jobs befolgt werden sollen.\n  script:\n    - go build -o bin/meow-micro\n    - chmod +x bin/meow-micro\n # Speichert die Job-Artefakte, die zur\n # Verwendung in einem anderen Job gespeichert wurden.\n  artifacts:\n    paths:\n      - bin/meow-micro\n    expire_in: 1 week\n\nunit-tests:\n  stage: test\n  image: golang:alpine\n  script:\n    - go test .\n # Definiert Befehle, die im Anschluss an den Job\n # ausgeführt werden sollen.\n after_script:\n  - echo \"Tests Complete\"\n\nstaging-deploy:\n  stage: deploy\n # Definiert die Befehle, die vor dem\n # eigentlichen Job ausgeführt werden sollen.\n  before_script:\n    - apk update\n  script:\n    - echo \"Deploying meow-micro to staging environment\"\n    - ./bin/meow-micro\n # Definiert die Bedingungen, die zur\n # Ausführung dieses Jobs erfüllt sein müssen. In\n # diesem Fall wird der Bereitstellungs-Job der Staging-Phase nur \n # auf dem Staging-Branch ausgeführt.\n  rules:\n    - if: $CI_COMMIT_BRANCH == 'staging'\n # Erlaubt die Verwendung der Artefakte, die im\n # Build-Job gespeichert wurden, in diesem Job.\n  artifacts:\n    paths:\n      - bin/meow-micro\n```\n\nWie du vielleicht bemerkt hast, gibt es viele Gemeinsamkeiten zwischen Jenkins und GitLab im Hinblick auf die Syntax. Dies vereinfacht die Pipeline-Migration. Sieh dir die umfassende Liste der [Funktions- und Konzeptvergleiche (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/migration/jenkins.html#comparison-of-features-and-concepts) zwischen den beiden Tools an.\n\nNun, da du verstehst, wie man Jenkins in GitLab abbildet, kannst du damit beginnen, eine Pipeline mit der gleichen Funktionalität in GitLab zu erstellen. Um CI/CD zu migrieren, kannst du die folgenden Schritte ausführen:\n\n##### 1. Öffne das Repository, das du im obigen Abschnitt zu GitLab migriert hast.\n- Klicke oben in der linken Seitenleiste auf **Suchen oder aufrufen …**.\n- Wähle dein Projekt aus.\n\n##### 2. Öffne den [Pipeline-Editor (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/pipeline_editor/).\n- Wähle in der linken Seitenleiste **Build > Pipeline-Editor** aus.\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png\" alt=\"Pipeline editor menu\">\n   \u003Cfigcaption>Pipeline-Editor-Menü\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Klicke auf die Schaltfläche **Pipeline konfigurieren**.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\" alt=\"Configure pipeline selection\">\n   \u003Cfigcaption>Auswahl der Schaltfläche „Pipeline konfigurieren“\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 3. Befülle die Datei [.gitlab-ci.yml (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/yaml/).\n- Füge den GitLab-CI-Pipeline-Code hinzu. \n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png\" alt=\"Pipeline editor input\">\n   \u003Cfigcaption>Eingabe im Pipeline-Editor\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Prüfe, ob die Syntax korrekt ist.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\" alt=\"Pipeline syntax validation\">\n   \u003Cfigcaption>Validierung der Pipeline-Syntax\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n- Visualisiere die Pipeline.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\" alt=\"Pipeline visualization\">\n   \u003Cfigcaption>Visualisierung der Pipeline\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n##### 4. Committe die Datei in den Main-Branch.\n- Füge eine Commit-Nachricht hinzu.\n- Stelle sicher, dass es sich um den Main-Branch handelt.\n- Klicke auf die Schaltfläche **Änderungen committen**.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\" alt=\"Commit changes dialog\">\n   \u003Cfigcaption>Dialog „Änderungen committen“\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nSobald die Datei zusammengeführt wurde, wird die definierte Pipeline gestartet. Du kannst zu deinem Projekt zurückkehren und [die Pipeline anzeigen (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines), indem du sie auf der Seite deines Projekts **Build > Pipelines** auswählst. Da sie auf dem **Main**-Branch ausgeführt wurde, siehst du nur den Job **create-binary** sowie die „unit-test“ Jobs. Der Job **staging-deploy** wird nur auf dem Staging-Branch ausgeführt.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\" alt=\"Pipeline running on main branch\">\n   \u003Cfigcaption>Auf dem Main-Branch ausgeführte Pipeline\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nBei der Erstellung eines Staging-Branches wird die folgende Pipeline gestartet.\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\" alt=\"Pipeline running on staging branch\">\n   \u003Cfigcaption>Auf dem Staging-Branch ausgeführte Pipeline\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nWenn du auf einen Job klickst, wird dessen Ausgabe angezeigt:   \n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\" alt=\"create-binary job output\">\n   \u003Cfigcaption>Ausgabe des Jobs create-binary\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\" alt=\"unit-tests job output input\">\n   \u003Cfigcaption>Eingabe/Ausgabe des Jobs unit-tests\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\n\u003Ccenter>\n\u003Cfigure>\n   \u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\" alt=\"staging-deploy job output\">\n   \u003Cfigcaption>Ausgabe des Jobs staging-deploy\u003C/figcaption>\n\u003C/figure>\n\u003C/center>\n\u003Cp>\u003C/p>\n\nDu kannst sehen, wie das Artefakt im Job create-binary gespeichert und im Job staging-deploy verwendet wird. Und so einfach ist es, eine Pipeline von Jenkins zu GitLab zu migrieren!\n\n### Zusätzliche Überlegungen zur Migration\nEinige hilfreiche Überlegungen, die den Bereitstellungsprozess unserer Ansicht nach einfacher machen, sind folgende:\n\n- Versuche nicht, Aufgaben exakt als GitLab-Jobs zu replizieren. Nimm dir Zeit und schaue dir genauer an, was die aktuelle Pipeline bewirkt und welches Problem sie löst.\n\n- Einige Jenkins-Jobs sind möglicherweise zu komplex, um sofort zu GitLab migriert zu werden. Deshalb kann es von Vorteil sein, das [GitLab-Jenkins-Plugin](https://plugins.jenkins.io/gitlab-plugin/) zu verwenden, um Jenkins-Pipelines zu starten und ihre Ergebnisse direkt in GitLab anzuzeigen. Auf diese Weise kannst du bestimmte Aktionen langsam zu GitLab migrieren, bis die gesamte Pipeline verschoben werden kann.\n\n- Implementiere [Sicherheitsscanner und Codequalität (nur in englischer Sprache verfügbar)](https://docs.gitlab.com/ee/user/application_security/) mithilfe von integrierten Vorlagen, die GitLab von Anfang an bereitstellt. So kannst du die Sicherheit im Vorfeld kontrollieren und die Gefahr eines Sicherheitsverstoßes verringern.\nGestalte die CI/CD-Konfiguration nicht zu kompliziert und versuche nicht, alle Funktionsvorteile gleichzeitig zu nutzen. Modularisiere den Code und implementiere ihn in kleinen Iterationen.\n\n- Implementiere Funktionen zur Überwachung und Steuerung von Anfang an.\n\n- Bedenke, dass sich ein GitLab Runner (Go) möglicherweise anders verhält als ein Jenkins-Agent (Java). Die CPU-Auslastung und der Speicherverbrauch können unterschiedlich sein – achte darauf, sie im Laufe der Zeit miteinander zu vergleichen.\n\n- Ziehe in Erwägung, in automatische Skalierungsmechanismen zu investieren, und lege nicht benötigte Ressourcen am Wochenende oder außerhalb der Arbeitszeiten still.\n\n- Modernisiere die Anwendungsentwicklung, indem du deine Jobs containerisierst. Jenkins-Jobs laufen aktuell nicht in einem Container, sondern auf einem Jenkins-Agenten, der als VM ausgeführt wird.\n\nDiese Liste ist nicht erschöpfend, stellt aber einen guten Ausgangspunkt für einige Überlegungen dar, die du beachten solltest. Wenn du zusätzliche Hilfe benötigst, bietet GitLab [Professional Services](https://about.gitlab.com/de-de/get-help/) an, um dich bei deiner Migration zu unterstützen.\n\n### Mehr erfahren\nVielen Dank, dass du diesen Leitfaden gelesen hast! Ich hoffe, dass er dir dabei geholfen hat, besser zu verstehen, warum und wie du von Jenkins zu GitLab migrieren kannst. Noch nicht überzeugt? [Melde dich für eine kostenlose Testversion von GitLab an](https://about.gitlab.com/de-de/free-trial/) und erkenne den Nutzen einer DevSecOps-Plattform!\n\nHier findest du einige englischsprachige Ressourcen mit weiteren Informationen zu GitLab, den Vorteilen einer DevSecOps-Plattform und der Migration aus Jenkins:\n\n- [Migration von Jenkins](https://docs.gitlab.com/ee/ci/migration/jenkins.html)\n- [Planung einer Migration](https://docs.gitlab.com/ee/ci/migration/plan_a_migration.html)\n- [GitLab-Projektimporter](https://docs.gitlab.com/ee/user/project/import/)\n- [Tutorial: Einfache Migration von GitHub zu GitLab](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n- [Video: Einfache Migration von GitHub zu GitLab](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n- [Von Jenkins zu GitLab: Der ultimative Leitfaden zur Modernisierung deiner CI/CD-Umgebung](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n",[111,9],"2025-02-13",{"slug":797,"featured":93,"template":681},"jenkins-to-gitlab-migration-made-easy","content:de-de:blog:jenkins-to-gitlab-migration-made-easy.yml","Jenkins To Gitlab Migration Made Easy","de-de/blog/jenkins-to-gitlab-migration-made-easy.yml","de-de/blog/jenkins-to-gitlab-migration-made-easy",{"_path":803,"_dir":249,"_draft":6,"_partial":6,"_locale":7,"seo":804,"content":810,"config":817,"_id":819,"_type":16,"title":820,"_source":18,"_file":821,"_stem":822,"_extension":21},"/de-de/blog/what-are-the-benefits-of-a-microservices-architecture",{"title":805,"description":806,"ogTitle":805,"ogDescription":806,"noIndex":6,"ogImage":807,"ogUrl":808,"ogSiteName":695,"ogType":696,"canonicalUrls":808,"schema":809},"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":805,"description":806,"authors":811,"heroImage":807,"date":813,"body":814,"category":14,"tags":815,"updatedDate":816},[812],"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",[752,752,773],"2024-11-19",{"slug":818,"featured":93,"template":681},"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",1,[688,715,738,759,781,802],1758662276048]